Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Integrerad modulär avionik med
virtualisering
av
Clas Enkvist
LIU-IDA/LITH-EX-A--13/046–SE
2013-10-08
Linköpings universitetInstitutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Integrerad modulär avionik med
virtualisering
av
Clas Enkvist
LITH-IDA-EX-13/046–SE
2013-10-08
Handledare: Miguel Svensson Saab Dynamics AB Mikael Asplund
IDA, Linköpings Universitet Examinator: Professor Simin Nadjm-Tehrani
Avdelningen för datavetenskap Linköpings Universitet
Sammanfattning
Det finns huvudsakligen tre olika sätt att konstruera ett partitionerat sy-stem på: Federerad arkitektur, Integrerad Modulär Avionik (IMA) med ARINC 6531 eller IMA med virtualisering. I den här rapporten undersöks
de olika arkitekturernas egenskaper och vilka möjligheter som finns för cer-tifiering av dem. Efter den teoretiska undersökningen har Virtualisering, och framförallt Xen, valts ut för en testimplementation och tillförlitlighetstester. Testimplementationen består av fyra partitioner där varje partition har sin specifika uppgift att lösa. Den fjärde partitionen används för att under-söka hur Xen hanterar en partition som aggressivt nyttjar I/O, processor eller arbetsminne.
Testerna visar att Xen har en svag punkt: all I/O hanteras via en egen, speciell, partition. Denna partition saknar dessutom möjligheter att priori-tera I/O från specifika partitioner. Den slutgiltiga slutsatsen av de tester som genomförts är att ett system byggt på Xen inte kan lämna samma till-förlitlighet som ett system med en federerad arkitektur eller ett system som bygger på ARINC 653.
Abstract
One can basically take three different approaches when designing a parti-tioned avionic system: Federated Architecture, Integrated Modular Avionics (IMA) with ARINC 6531or IMA with Virtualization. This report examines
the different architectural characteristics and the possibilities for certifying them. After the theoretical investigation, Virtualization and, in particular, Xen has been selected for a trial implementation and reliability tests.
The implementation consists of four partitions where each partition has its own specific task to solve. The fourth partition is used to examine how Xen handles a partition that aggressively utilizes I/O, processor or memory resources.
Tests show that Xen has a weak point: all I/O is handled through a sepa-rate and unique partition. This partition also lacks the ability of prioritizing I/O from specific partitions. The final conclusion of the tests carried out in this thesis is that a system built on Xen cannot provide the same reliability as a system with a federated architecture or a system based on ARINC 653.
Innehåll
1 Introduktion 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 1 1.3 Problembeskrivning . . . 2 1.3.1 Mål . . . 2 1.3.2 Metod . . . 2 1.4 Möjliga lösningar . . . 3 1.4.1 Översikt av arkitekturen . . . 4 1.5 Önskvärda egenskaper . . . 4 1.6 Avgränsningar . . . 4 1.7 Dokumentstruktur . . . 5 2 Bakgrund 7 2.1 Säkerhetskritiska taktiska system . . . 72.1.1 DO-178C . . . 7
2.2 Arkitekturer inom avionik . . . 10
2.2.1 Federerad arkitektur . . . 10 2.2.2 IMA arkitektur . . . 11 2.3 ARINC 653 . . . 12 2.3.1 Existerande ARINC 653 OS . . . 13 2.4 Virtualisering . . . 14 2.4.1 VMM . . . 14
2.4.2 Egenskaper hos virtuella maskiner . . . 15
2.4.3 Full virtualisering . . . 15 2.4.4 Paravirtualisering . . . 16 2.4.5 Xen . . . 16 2.5 Testplattform . . . 20 2.5.1 Bärbar dator . . . 21 2.5.2 Framdrivning . . . 21 2.5.3 GPS . . . 21
INNEHÅLL 3 Lösningsförslag 23 3.1 Övergripande arkitektur . . . 23 3.1.1 Federerad arkitektur . . . 23 3.1.2 IMA . . . 24 3.1.3 Val av arkitektur . . . 24
3.2 Val av plattform för virtualisering . . . 25
3.2.1 Xen . . . 25
3.2.2 Övriga . . . 25
3.2.3 Det slutgiltiga valet . . . 26
3.3 Utvecklingsprocess . . . 26
4 Systemdesign och implementation 27 4.1 Översikt . . . 27 4.2 Dom0 . . . 28 4.2.1 USB–värd . . . 28 4.3 VM0 . . . 28 4.3.1 Kommunikationsmodul . . . 30 4.3.2 Filtreringsmodul . . . 30 4.3.3 Bandstyrningsmodul . . . 31 4.3.4 GPS–modul . . . 31 4.3.5 USB–modul . . . 31 4.4 VM1 . . . 31 4.4.1 Ordermodul . . . 31 4.4.2 Kommunikationsmodul . . . 31 4.5 VM2 . . . 32 4.5.1 Störmodul . . . 32
5 Utvärdering och resultat 33 5.1 Tester . . . 33 5.1.1 Tillförlitlighet . . . 33 5.1.2 Intressant mätdata . . . 34 5.2 Testfall . . . 36 5.2.1 Referensfallet . . . 36 5.2.2 Minneshantering . . . 38 5.2.3 Processorhantering . . . 41 5.2.4 I/O–hantering . . . 44 5.2.5 Kör utanför området . . . 45 5.2.6 Felaktiga kommandon . . . 46 5.2.7 Slutsatser från testfallen . . . 47
6 Slutsatser och relaterade arbeten 49 6.1 Relaterade arbeten . . . 49
6.2 Erfarenheter från testimplementationen och litteraturstudien av Xen . . . 50
INNEHÅLL A Ordlista 56 B Störkod 58 B.1 Minneshantering . . . 58 B.2 Processorhantering . . . 59 B.3 I/O–hantering . . . 60
Figurer
1.1 Översikt av arkitekturen för testimplementationen. . . 4
2.1 Federerad respektive IMA arkitektur [12]. . . 10
2.2 VMM arkitektur. . . 14 2.3 Xens arkitektur. . . 17 2.4 Bandvagnen MMP-30. . . 20 4.1 Systemdesign. . . 28 4.2 Flödesschema för mjukvaran i VM0. . . 29 4.3 Tillåtet område. . . 30
5.1 Systemdesign med markerade mätpunkter. . . 35
5.2 Medelfördröjningen tillsammans med max- och min-fördröjningen vid exekvering av perlskriptet under referensfallet, med loga-ritmisk skala på y–axeln. . . 37
5.3 Medelfördröjningen tillsammans med max- och min-fördröjningen av kommunikationen mellan VM0 och VM1 under referens-fallet, med linjär skala på y–axeln. . . 37
5.4 Medelfördröjningen tillsammans med max- och min-fördröjningen vid exekvering av perlskriptet under minneshanteringstest A, med logaritmisk skala på y–axeln. . . 39
5.5 Uppkomsten av fördröjningar under mätomgång ett, minnes-hanteringstest A. . . 40
5.6 Medelfördröjningen tillsammans med max- och min-fördröjningen vid exekvering av perlskriptet under minneshanteringstest B, med logaritmisk skala på y–axeln. . . 41
5.7 Medelfördröjningen tillsammans med max- och min-fördröjningen vid exekvering av perlskriptet under processorhanteringstest A, med logaritmisk skala på y–axeln. . . 42
5.8 Medelfördröjningen tillsammans med max- och min-fördröjningen vid exekvering av perlskriptet under processorhanteringstest B, med logaritmisk skala på y–axeln. . . 43
FIGURER 5.9 Medelfördröjningen tillsammans med max- och min-fördröjningen
vid exekvering av perlskriptet under I/O–hanteringstestet, med logaritmisk skala på y–axeln. . . 45
Kapitel 1
Introduktion
Det här dokumentet är en rapport för ett examensarbete utfört som en del av civilingenjörsprogrammet i datateknik (30 hp). Arbetet har genomförts på Saab Dynamics Linköping och är examinerat vid Institutionen för data-vetenskap vid Linköpings universitet.
1.1
Bakgrund
Saab Dynamics har länge utvecklat avancerade farkoster för såväl militärt bruk som för civil säkerhet. Bland produkterna finns tunga farkoster som till exempel flygande robotar, torpeder och autonoma undervattensfarkoster. Dessa så kallade taktiska system är konstruerade för att lösa en specifik uppgift vilket ofta innebär att programvaran i dessa system inte är speciellt modulär. Programvaran måste även testas och verifieras i sin helhet innan den kan användas skarpt. Detta är en process som kostar både mycket tid och pengar samt gör det dyrt att förändra och underhålla produkterna.
För att minska kostnaderna för utveckling och underhåll samt förändra och förbättra utvecklingsprocessen önskar Saab Dynamics bryta upp pro-gramvaran till separata moduler som kan testas och verifieras var för sig.
1.2
Syfte
Syftet med examensarbetet är att undersöka vilka arkitekturer och stan-darder som finns för att dela upp programvara i olika moduler, samt att undersöka om en mjukvara som tillhandahåller virtualisering kan ge mot-svarande tillförlitlighet. Tanken är att mjukvara i en modul inte ska behöva testas och verifieras varje gång programvara i en annan modul modifieras. Förhoppningen är att även den höga utvecklingskostnaden sjunker i takt med att allt färre tester behöver genomföras.
KAPITEL 1. INTRODUKTION
1.3
Problembeskrivning
I det här examensarbetet studeras vilka arkitekturer och standarder som finns för att skapa och verifiera ett system där programvara delas in i olika partitioner. Framförallt undersöks möjligheterna att realisera en partitio-nerad arkitektur med hjälp av virtualisering och vilka krav som då ställs på systemdesign, kommunikation och hårdvara. Saab Dynamics har inte arbetat med partitionerade arkitekturer av den här typen tidigare och är intresserade av vilka standardlösningar som finns samt för- och nackdelar med dessa.
1.3.1
Mål
Målsättningen för det här examensarbetet är att besvara frågorna: • Vilka standarder för en partitionerad arkitektur finns?
• Vilka standarder finns för verifiering och certifiering av arkitekturen? • Går det att använda virtualisering för att realisera en partitionerad arkitektur med motsvarande tillförlitlighet som de påträffade standar-derna kräver?
• Vilka krav ställer virtualisering på systemdesign, kommunikation och hårdvara?
1.3.2
Metod
Frågeställningarna från målsättningen besvaras genom att undersöka vilka standarder och arkitekturer som finns för partitionering av programvara. Minst två av dessa standarder väljs ut för en mer ingående analys. De frågor som ska besvaras under denna utredning är:
• Vilka standarder/arkitekturer finns?
• Vilka krav ställer de valda standarderna/arkitekturerna på systemde-sign, kommunikation och hårdvara?
• Vilka möjligheter finns det för verifikation och certifiering av det sy-stem som produceras när standarden/arkitekturen följs?
• Vilka COTS produkter, som följer dessa standarder/arkitekturer, finns? Sedan genomförs en jämförelse med avseende på vilka krav de redan existerande lösningarna ställer på de hårdvaruplattformar som stöds. Frågor som besvaras i denna jämförelse är:
Finns stöd för:
1.4. MÖJLIGA LÖSNINGAR • PowerPc arkitekturen?
• Arm arkitekturen? • Andra arkitekturer?
• Portering till andra hårdvaruarkitekturer? – hur svår är en portering att genomföra?
Vidare väljs en mjukvara, som tillhandahåller virtualisering, ut för att skapa och implementera ett partitionerat system för styrning av en band-vagn. Vid denna implementation kommer det fokuseras på att skapa och testa ett partitionerat system, styrlogiken av bandvagnen kommer således att hållas på en väldigt enkel nivå.
Slutligen testas det system som konstruerats genom att programvara med onormalt beteende exekveras i en egen partition, den så kallade störpartitio-nen. Det onormala beteendet definieras av tre egenskaper: CPU–användning, minneshantering och I/O–hantering.
Störpartitionen utrustas med programvara för vart och ett av egenska-perna och tester utförs sedan med en störande egenskap aktiv åt gången. De data som loggas under samtliga tester är:
• Kommando och tidsstämpel på de data som skickas till den externa enheten som har hand om bandvagnens larvfötter.
• Statistik i form av fördelning av processoranvändning för de olika par-titionerna.
Utöver detta observeras även bandvagnens beteende då de olika testerna utförs.
1.4
Möjliga lösningar
Slutsatsen från den undersökande delen av examensarbetet är att det hu-vudsakligen finns tre sätt att designa en partitionerad arkitektur:
• Federerad arkitektur, det gamla sättet att designa en arkitektur. • Integrerad Modulär Avionik (IMA) med ARINC 653 (Aeronautical
Radio InC), flygindustrins standard för partitionering i tid och rum. • Virtualisering, en teknik för partitionering i tid och rum.
Federerade arkitekturer är något som man redan har kunskaper om på Saab Dynamics och IMA med ARINC 653 används flitigt på Saab Aeronautics. Saab Dynamics var därför intresserade av att titta närmre på om virtualise-ring kan användas för att skapa ett partitionerat system med motsvarande tillförlitlighet. Med anledning av detta intresse valdes det att titta närmre på virtualisering och undersöka om det finns några existerande lösningar som kan användas på bandvagnen.
KAPITEL 1. INTRODUKTION
1.4.1
Översikt av arkitekturen
Det, under examensarbetet, konstruerade systemet består huvudsakligen av tre olika partitioner, se figur 1.1. Varje partition består av en egen virtuell maskin (VM) och har en egen uppgift att lösa. De olika partitionerna ska tillsammans styra en bandvagn inom ett avgränsat område.
Styrpartitionen har till uppgift att ta emot ett styrkommando från or-derpartitionen, undersöka om kommandot får genomföras eller ej och sedan fullfölja eller avbryta kommandot. Orderpartitionens uppgift är endast att skicka olika styrkommandon till styrpartitionen. Störpartitionen används en-dast för att testa och undersöka det konstruerade systemets tillförlitlighet.
Figur 1.1: Översikt av arkitekturen för testimplementationen.
1.5
Önskvärda egenskaper
Under examensarbetet har ett antal önskvärda egenskaper hos det slutgiltiga systemet tagits fram:
• Programvara i en partition kan inte exekveras på ett sådant sätt att programvara i en annan partition aldrig får tillgång till processorn. • Programvara i en partition tillåts inte att skriva/läsa från den
min-nesrymd som ligger utanför den egna partitionen.
• Endast en partition har tillgång till de externa enheter som program-varan pratar med för att styra bandvagnen.
• Programvaran ska gå att köras på bandvagnens hårdvaruarkitektur, 32–bitars x86 utan hårdvarustöd för virtualisering.
1.6
Avgränsningar
1.7. DOKUMENTSTRUKTUR • Komplex funktionalitet behöver inte implementeras för bandvagnen. Målet är att påvisa en modulär struktur, inte att skapa en avancerad styralgoritm.
• Testimplementationen ska gå att köra på den hårdvara som finns till-gänglig för bandvagnen.
1.7
Dokumentstruktur
Nedan följer en kort beskrivning av dokumentets struktur. Kapitel 1 Innehåller en introduktion till detta examensarbete.
Kapitel 2 Förser läsaren med den bakgrundsinformation som behövs för att förstå examensarbetet.
Kapitel 3 Innehåller idéer på hur en arkitektur kan byggas, baserat på de påträffade standarderna, samt de val som gjorts under examens-arbetets gång.
Kapitel 4 Innehåller en beskrivning av den arkitektur som implementeras för att testa den utvalda virtualiseringsplattformen.
Kapitel 5 Innehåller en beskrivning av de tester som utförts samt resultatet av dessa.
Bilaga A Ordlista. Här hittar läsaren en ordlista som förklarar de tekniska termer och förkortningar som använts i examensarbetet. Bilaga B Testkod. Denna bilaga innehåller den kod som används för att
Kapitel 2
Bakgrund
Det här kapitlet kommer att förse läsaren med den bakgrundsinformation som behövs för att förstå examensarbetet.
2.1
Säkerhetskritiska taktiska system
Taktiska system, så som robotar, torpeder och autonoma undervattensfar-koster, är ofta klassade som säkerhetskritiska. Mjukvarudefekter i ett sådant system kan leda till katastrofala konsekvenser. För att minimera antalet mjukvarudefekter används ofta granskning och testning. Men dessa meto-der är inte tillräckliga då de inte upptäcker alla defekter, de kan inte heller bli helt automatiserade och testning sker oftast i slutet av utvecklingscy-keln. För att garantera att allvarliga mjukvarudefekter är så ovanliga att de kan anses som osannolika krävs förutom grundläggande testning också ett systematiskt sätt att upptäcka och skatta dessa. [5, 7]
2.1.1
DO-178C
DO–178C, Software Considerations in Airborne Systems and Equipment Certification, är en standard vars syfte är att ge vägledning genom utveck-lingen av mjukvara för luftburna system och annan utrustning, där kraven på säkerhet och tillförlitlighet ligger i samma nivå som kraven på flygduglighet. Dokumentet är framtaget av Radio Technical Commission for Aeronautics (RTCA), ett icke vinstdrivande företag som utvecklar rekommendationer för system som hanterar kommunikation, navigation, övervakning och flyg-ledning. Det är också den enda standarden som finns för säkerhetskritisk programvara i luftburna system.
Dokumentet förespråkar inte någon specifik utvecklingsprocess. Det bi-drar inte heller med några direkta krav på certifiering. Men det ger en grund-läggande vägledning för vilka aktiviteter som bör utföras och vad målet med dessa är. Att en produkt har blivit utvecklad enligt DO–178C medför inte
KAPITEL 2. BAKGRUND
att den automatiskt är flygduglig, det medför inte ens att den kan flyga. Det medför däremot att de aktiviteter som beskrivs i DO–178C har blivit utför-da och att produkten fungerar enligt den ursprungliga kravspecifikationen. Aktiviteterna som utförs delas upp i tre stadier: planering, utveckling och integrering. [5, 6, 7]
Standarden bygger på att delsystem tilldelas olika felkategorier beroen-de på vilka konsekvenser ett haveri i respektive beroen-delsystem får för beroen-det tota-la systemet. Varje felkategori är sedan mappad till en egen säkerhetsnivå. Ju högre säkerhetsnivå som ett delsystem får, desto hårdare krav ställer DO–178C på spårbarhet av krav från designspecifikationen samt testning av delsystemet [7].
Felkategorier
Systemfel kan delas in i fem olika kategorier enligt standarden DO–178C [5]. Nedan följer en beskrivning av dessa.
• Katastrofalt (Catastrophic) Feltillstånd som kan resultera i flera dödsfall och resulterar vanligtvis även i förlust av farkosten.
• Farligt (Hazardous) Feltillstånd som reducerar farkostens operatio-nella förmåga eller minskar besättningens förmåga att klara ogynn-samma driftsförhållanden i sådan utsträckning att:
– Felmarginalerna eller den funktionella kapaciteten minskar kraf-tigt,
– Fysisk nöd eller överbelastning i den grad att man inte längre kan lita på att besättningen kan utföra sina uppgifter korrekt eller fullständigt, eller
– Allvarliga skador eller dödsfall bland ett fåtal av passagerarna. • Allvarligt (Major) Feltillstånd som reducerar farkostens
operatio-nella förmåga eller minskar besättningens förmåga att klara ogynn-samma driftsförhållanden, till exempel: en signifikant reduktion av felmarginalerna eller farkostens funktionella kapacitet, en signifikant ökning av besättningens arbetsbörda eller omständigheter som påver-kar besättningens effektivitet, skapar obehag bland besättningen eller fysisk nöd, eventuellt även skador, bland passagerarna eller personalen. • Lindrigt (Minor) Feltillstånd som signifikant kan reducera farkos-tens säkerhet och kräver åtgärder från besättningen, utan att överbe-lasta dem. Lindriga feltillstånd kan vara, till exempel: lindrig minsk-ning av säkerhetsmarginalerna eller farkostens funktionella kapacitet, en lindrig ökning av besättningens arbetsbörda, exempelvis, rutinmäs-siga förändringar i färdplanen eller fysiskt obehag för passagerarna eller personalen.
2.1. SÄKERHETSKRITISKA TAKTISKA SYSTEM • Ingen inverkan (No Safety Effect) Feltillstånd som inte har nå-gon inverkan på säkerheten. Exempelvis, feltillstånd som inte påverkar farkostens kapacitet eller personalens arbetsbelastning.
Säkerhetsnivåer för mjukvara
I DO–178C finns det fem olika säkerhetsnivåer, Nivå A till Nivå E [5]. Nedan följer en beskrivning av relationen mellan mjukvarunivåerna och de tidigare listade felkategorierna.
Nivå A: En mjukvara vars felaktiga beteende skapar eller bidrar till att en systemfunktion felar och felet resulterar i ett katastrofalt (cata-strophic) feltillstånd hos systemet.
Nivå B: En mjukvara vars felaktiga beteende skapar eller bidrar till att en systemfunktion felar och felet resulterar i ett farligt (hazardous) feltillstånd hos systemet.
Nivå C: En mjukvara vars felaktiga beteende skapar eller bidrar till att en systemfunktion felar och felet resulterar i ett allvarligt (major) feltillstånd hos systemet.
Nivå D: En mjukvara vars felaktiga beteende skapar eller bidrar till att en systemfunktion felar och felet resulterar i ett lindrigt (minor) feltillstånd hos systemet.
Nivå E: En mjukvara vars felaktiga beteende skapar eller bidrar till att en systemfunktion felar och felet varken påverkar systemet operatio-nella kapacitet eller operatörens arbetsbörda. För en mjukvaru-komponent som är fastställd att tillhöra denna nivå, och CA (eng. Certification Authority) har bekräftat detta, finns inga ytterligare riktlinjer i DO–178C.
Krav på utvecklingsprocessen relativt säkerhetsnivåerna
DO–178C ställer olika krav på utvecklingsprocessen och den programvara som används beroende på vilken säkerhetsnivå delsystemet tillhör [5]. Nedan följer en kort beskrivning av de viktigaste kraven som ställs på utvecklings-processen och programvaran för de olika nivåerna.
Nivå A och B: I de här säkerhetsnivåerna krävs att varje kodrad går att spåra till krav i kravspecifikationen för systemet. Här krävs också full täckning av testfallen, det får med andra ord inte finnas en enda otestad kodrad i delsystemet. Dessutom ska objektkoden gå att spåra till kraven i kravspecifikationen. Nivå A har hårdare krav på att korrektheten hos testproce-durerna ska kontrolleras.
KAPITEL 2. BAKGRUND
Nivå C: I den här säkerhetsnivån krävs det inte att varje kodrad gå att spåra till krav i kravspecifikationen för systemet, men de bör göra det. I övrigt har den här säkerhetsnivån samma mål som nivå A och B.
Nivå D: Programvaran kan ses som en svart låda. I delsystem som har blivit klassade enligt denna nivå är det tillåtet att använ-da sig av oklassificerade programvaror, exempelvis Microsoft Windows. Dessa programvaror är inte tillåtna i delsystem som är klassade enligt nivå A - C.
Nivå E: Standarden har inga krav på utvecklingsprocessen av pro-gramvaran i den här säkerhetsnivån.
2.2
Arkitekturer inom avionik
Inom flygindustrin utvecklas system med två huvudsakliga arkitekturer. Dessa är, den klassiska federerade arkitekturen och den nyare arkitektu-ren som kallas Integrerad Modulär Avionik (IMA). En övergripande bild på hur upplägget av de båda arkitekturerna ser ut finns i figur 2.1.
Figur 2.1: Federerad respektive IMA arkitektur [12].
2.2.1
Federerad arkitektur
En federerad arkitektur är det klassiska angreppssättet vid implementation av flygande system. I den här arkitekturen körs varje funktion i systemet på egen hårdvara vilket ger en naturlig uppdelning av systemets olika funktioner och underlättar felisolering [8, 9, 11].
Uppdelningen medför också att man får ett mycket robust och feltole-rant system, i den meningen att varje funktion gafeltole-ranteras tillgång till både beräkningskraft och arbetsminne. När ett hårdvarufel inträffar på en nod i ett federerat system så är det först och främst funktionaliteten på den no-den som påverkas. Dock kan en felande nod även störa andra noder genom att belasta kommunikationsvägarna. En annan fördel är att man med den här uppdelningen kan utveckla varje delsystem för sig. De olika delsystemen
2.2. ARKITEKTURER INOM AVIONIK behöver inte vara beroende av varandra i en federerad arkitektur och in-teraktionen mellan dem kan således hållas begränsad. Detta gör också att man kan hålla koordinationen mellan utvecklarna av de olika systemen på ett minimum [9, 10].
Arkitekturens största nackdel är att den kräver mycket hårdvara, dvs. den tar upp mycket plats och vikt och drar även mycket ström. Varje funk-tion körs på egen hårdvara, vilket inte enbart kräver många processorer och minne, utan även mycket kablage för inkoppling av strömförsörjning och kommunikation med andra enheter. Vill man dessutom skapa ett feltolerant system med hjälp av redundans så ökar mängden hårdvara ännu mer. En fe-dererad arkitektur består ofta av en uppsjö av olika hårdvaruplattformar, av den enkla anledningen att varje delsystem kan utvecklas för sig. Detta leder till ökade kostnader för underhåll och reservdelar, då flera olika plattformar måste servas och underhållas [8, 9, 10, 11].
Fördelar: • Felisolering.
• Utveckla varje delsystem för sig. Nackdelar:
• Överdimensionerar hårdvara. • Ökade kostnader för underhåll.
2.2.2
IMA arkitektur
IMA arkitekturen har utvecklats för att lösa problemet med att system ba-serade på den federerade arkitekturen tar upp mycket plats, väger mycket och drar mycket ström. Istället för att fördela funktionaliteten på separat hårdvara så har man placerat den på samma hårdvara och åstadkommit separering via ett mjukvarulager mellan hårdvaran och de olika funktioner-na. På så vis har man lyckats reducera både antalet hårdvaruplattformar och mängden av olika hårdvaruarkitekturer som behövs, jämfört med den federerade arkitekturen. Detta leder till reducerade kostnader för hårdvara, kablage och underhåll av hårdvara [9, 10, 11].
IMA är baserat på en grundläggande princip: partitionering i tid och rum. Partitioneringen ser till att programvarorna inte hindrar eller påverkar varandra. Detta sker automatiskt genom implementationen av IMA–mjukvarans arkitektur (partitionering i tid) och minneskontrollerns (MMU, eng. Memo-ry Management Unit) separation av minnesMemo-rymden (partitionering i rum). Utöver partitioneringen i tid och rum krävs också att delade resurser, i form av in- och ut-signaler (I/O) och annan delad hårdvara, abstraheras bort från hårdvarulagret och hanteras via en implementation av en I/O–partition eller en virtuell enhetshanterare (VDM, eng. Virtual Device Manager) [9, 11].
KAPITEL 2. BAKGRUND
Partitionerna på en IMA är vanligtvis schemalagda på en fast, cyklisk basis. Aktiveringsordningen för de olika partitionerna är statisk och bestäms vid designen av systemet. Det är operativsystemet som bär ansvaret för att se till att de olika partitionerna får sin del av processortiden. Operativ-systemet är också ansvarigt för att tillhandahålla deadlines, periodicitet, fördröjningar och timeouts. Mekanismerna för dessa egenskaper finns imple-menterade i mjukvarulagret mellan plattformen och programvarorna [11].
Normalt sätt måste ett system med olika nivåer av säkerhet utvecklas och certifieras enligt säkerhetsklassningen på den mest kritiska komponen-ten i systemet. Något som kan vara kostsamt, speciellt om en programvara med låg säkerhetsnivå och många rader källkod ska ingå i systemet. Med IMA:s angreppssätt tillåts varje programvara bli testad och certifierad till sin egen säkerhetsnivå. Detta minskar utvecklingstiden och i slutändan även kostnaderna för systemet. Dock måste abstraktionslagret, som vanligtvis är ett ARINC 653 baserat operativsystem (OS), som används i IMA certifieras efter den mest kritiska programvaran i systemet. Dessutom så måste en in-gående analys och verifiering av att partitioneringen i tid och rum har blivit implementerad på rätt sätt genomföras. Detta för att försäkra sig om att ett fel i ett program med låg säkerhetsnivå inte kan få andra program, som körs på samma processor, att fallera [8, 9].
Fördelar:
• Effektivt utnyttjande av hårdvara.
• Reducerad kostnad för certifiering, jämfört med IMA utan modulär programvara.
Nackdelar:
• Mer komplex mjukvara, jämfört med ett system byggt på den federe-rade arkitekturen.
2.3
ARINC 653
ARINC 653 är en standard som beskriver vilka tjänster ett realtidsoperativ-system (RTOS) måste tillhandahålla för att uppnå en robust partitionering i tid och rum. En robust partitionering tillåter att partitioner med olika sä-kerhetsnivåer körs i samma system, utan att de påverkar varandra i tid och rum.
Standardens API (eng. Application Programming Interface, programva-rugränssnitt) kallas för APplication EXecutive (APEX) och är definierat som en mängd tjänster som ett ARINC 653–kompatibelt OS måste tillhan-dahålla gentemot programvaran som exekveras i OS:ets partitioner. Målet med APEX är att programvara, utvecklad oberoende av varandra, ska kunna
2.3. ARINC 653 exekveras tillsammans på samma hårdvara. ARINC 653 standarden beskri-ver gränssnittet och beteendet hos APEX, men utelämnar detaljerna kring hur det implementeras.
Mjukvara som exekveras i olika partitioner är, tack vare ARINC 653, helt isolerade från varandra. Detta betyder att en mjukvara som felar inte ska kunna påverka mjukvara som exekveras i andra partitioner. Isoleringen innebär också att validering, verifiering och certifiering av systemet under-lättas. [1, 3]
ARINC 653 specifikationen består av fyra delar:
• ARINC 653: Del 1, Grundläggande tjänster (Required Services). • ARINC 653: Del 2, Utökade tjänster (Extended Services).
• ARINC 653: Del 3, Testspecifikation (Conformity Test Specification). • ARINC 653: Del 4, Extra tjänster (Subset Services).
I del 1 beskrivs den minsta grundläggande och obligatoriska funktionali-tet som krävs, av OS:et, för att programvara som exekveras i partitionerna ska kunna utföra sina uppgifter. Avsikten är att hålla gränssnittet så ge-nerellt som möjligt. Del 2 behandlar utökade tjänster som är valbara, till exempel filsystem och loggbok. [1, 2]
2.3.1
Existerande ARINC 653 OS
Numera finns det flertalet COTS (eng. Commercial Off The Shelf, färdig-utvecklade produkter ”från lagerhyllan”) OS som är implementerade enligt ARINC 653 standarden. Exempel på dessa är:
• Integrity–178B RTOS från Green Hills Software [36]. • LynxOS–178 från LynxWorks [37].
• PikeOS från Sysgo [38].
• VxWorks 653 från Windriver [39]. Hårdvarustöd
De olika COTS produkterna har stöd för olika processorarkitekturer, se ta-bell 2.1. Kolumnen för portering är ikryssad om det finns möjligheter för användaren av OS:et att portera det till en ny arkitektur. [32, 33, 34, 35]
KAPITEL 2. BAKGRUND
OS x86 Arm PowerPc Portering LynxOS–178 X1 X PikeOS X2 X X X3 Integrity–178B X X VxWorks X4 X X5 Tabell 2.1: Processorstöd.
2.4
Virtualisering
Med hjälp av virtualisering kan man köra flera OS på samma hårdvara. Tekniken går ut på att skapa virtuella miljöer, så kallade VM, där OS och programvara får en emulerad hårdvara att köras på [13, 14, 15]. De virtuella maskinerna är, trots att de körs på samma hårdvara, isolerade från varandra vilket leder till att ett haveri i en VM inte ska påverka mjukvaran som körs i en annan VM. Isoleringen gör också att en VM kan startas om, precis som om den hade körts på en helt egen hårdvara, utan att påverka andra VM:er som körs på samma hårdvara. Virtualiseringstekniken gör det alltså möjligt för OS och programvara att köras på samma sätt, oavsett om den körs på egen hårdvara eller i en VM där hårdvaran delas med andra VM [13, 15].
Virtualiseringsteknologin kan huvudsakligen delas in i två olika grenar: full virtualisering och paravirtualisering [14, 15]. I båda grenarna är det VMM:ens (eng. virtual–machine monitor, virtuell maskin övervakare) upp-gift att abstrahera bort hårdvaran.
2.4.1
VMM
Figur 2.2: VMM arkitektur. En VMM, även kallad hypervisor, är
mjukvarulagret som hanterar en eller flera virtuella maskiner. Ett exempel på hur en sådan arkitektur kan se ut finns i figur 2.2. VMM:en skapar virtuella ma-skiner genom att använda teorin för full virtualisering och/eller paravirtualise-ring. Mjukvarulagret på en VMM kan antingen köras direkt på hårdvara eller
i ett OS som körs på hårdvaran. Mjukvaran i de virtuella maskinerna brukar kallas för gäster, medan VMM:en kallas för värd [13, 14, 15].
1Stödet för x86 är begränsat till vissa Intel Pentium processorer. 2Stödet för x86 är begränsat till vissa plattformar.
3Saknas stöd för önskad arkitektur så kan Sysgo implementera detta. 4Stödet för x86 är begränsat till vissa Intel Core 2 processorer.
5Portering till ny arkitektur tar vanligtvis 1 till 6 månader, beroende på hur avancerad den nya arkitekturen är [4].
2.4. VIRTUALISERING VMM:ens abstraktionslager (mjukvara) förser sina gäster med virtuella versioner av systemets hårdvara, så som I/O–utrustning, lagring, arbets-minne, processor, m.m. VMM:en tillser också att de virtuella maskinerna är isolerade från varandra så att problem i en VM inte kan påverka en annan VM [13, 15].
2.4.2
Egenskaper hos virtuella maskiner
Det grundläggande kravet för att en datorarkitektur ska gå att virtualiseras är att instruktioner som kan förändra eller läsa den underliggande hård-varans tillstånd måste fångas. Detta betyder att processorn måste avbryta exekveringen av gästprogramvaran och överföra kontrollen till VMM:en, när en gästprogramvara försöker köra en sådan instruktion. VMM:en kan sedan bestämma hur instruktionen ska hanteras och får på så viss full kontroll över vad som händer med den underliggande hårdvaran.
Vidare har en VMM tre grundläggande egenskaper:
• Ekvivalens, VMM:en tillhandahåller en programvarumiljö som är vä-sentligen identisk med miljön från den maskin som emuleras.
• Effektivitet, programmen som körs i miljön får en, i värsta fall, liten prestandaförsämring.
• Resurskontroll, VMM:en har fullständig kontroll över systemresur-serna.
Den första egenskapen medför att mjukvara som körs direkt på hårdvara även kan köras i en VM och tvärtom. Den andra egenskapen innebär att det, rent prestandamässigt, är möjligt att använda virtualisering. Medan den tredje egenskapen möjliggör isolering mellan de virtuella maskinerna [13, 15].
De tidigare nämnda grenarna (full virtualisering och paravirtualisering) har lite olika angreppssätt på att försöka uppfylla dessa krav.
2.4.3
Full virtualisering
Full virtualisering innebär, precis som det låter, att hela den underliggande hårdvarans arkitektur emuleras i VMM:en. Gästmjukvaran har således inte någon tillgång till de fysiska resurser som finns i plattformen, utan får endast använda virtuella resurser. De virtuella resurserna har samma gränssnitt och beteende som de fysiska resurserna, vilket gör att gästmjukvaran kan köras som om den skulle ha körts direkt på hårdvaran. Det gör också att VMM:ens programvara ökar i komplexitet, då hårdvarans gränssnitt blir allt mer avancerad [14, 15].
Den stora fördelen med detta angreppssätt är att gästmjukvaran inte be-höver modifieras och är helt ovetande om att den körs i en emulerad miljö. Dessutom skapar de virtuella resurserna ett skyddande lager som isolerar
KAPITEL 2. BAKGRUND
gästmjukvaran gentemot VMM:en och annan gästmjukvara. Exempelvis så skyddar implementationen av det virtuella minnet VMM:en på samma sätt som ett OS skyddas av sin virtuella implementation av minnet gentemot programvaran som körs i OS:et. Full virtualisering anses vara den säkraste VMM arkitekturen, på grund av den starka isolering som uppnås av arki-tekturen [14, 15].
Den omfattande virtualiseringen innebär alltså att full virtualisering är bra på att uppfylla kraven för ekvivalens och resurskontroll. Men den medför också att effektiviteten blir lidande då det går åt mycket beräkningskraft till att emulera all hårdvara.
2.4.4
Paravirtualisering
Med paravirtualisering har man försökt lösa problemen med den försämrade prestandan och den ökande komplexiteten som hänger ihop med full virtu-alisering. Tanken är att VMM:en görs enklare och snabbare genom att mo-difiera gästprogramvaran. Paravirtualisering är med andra ord något sämre på att uppfylla kraven för ekvivalens och resurskontroll, men är i gengäld bättre på kravet om effektivitet.
Gästprogramvaran modifieras så att skyddade anrop6går direkt till VMM:en istället för den emulerade processorn. På så vis kan gästprogramvaran göra anrop mot hårdvaran, via VMM:en, istället för att anropa den emulerade hårdvaran som i sin tur anropar hårdvaran.
Den största nackdelen med paravirtualisering är att gästprogramvaror måste modifieras, eller designas med VMM:en i åtanke, för att de ska gå att köras i de virtuella maskiner som en paravirtualiserad VMM tillhanda-håller. Men datorarkitekturer med hårdvarustöd för virtualisering, så kallad hårdvaruassisterad virtualisering, klarar av att köra omodifierade gästpro-gramvaror. Exempel på sådana processorarkitekturer är AMD Pacifica Te-chnology (AMD–V) och Intel Virtualization TeTe-chnology (VT–x). [14, 15]
2.4.5
Xen
Xen är en VMM som körs direkt på hårdvaran och har således inget OS mellan sin mjukvara och hårdvaruplattformen. Däremot krävs ett OS för att kontrollera de virtuella maskinerna samt tillhandahålla drivrutiner för den hårdvara som finns.
Xen skapar virtuella maskiner genom två olika tekniker, paravirtualise-ring och hårdvaruassisterad virtualiseparavirtualise-ring, tekniker som finns omnämnda i avsnitt 2.4.4. Det går dock att köra Xen på en processor som inte stöder hårdvaruassisterad virtualisering, men då med begränsningen att OS:en i de virtuella maskinerna måste vara paravirtualiserade. [17]
6Med skyddat anrop menas ett anrop som kan förändra eller läsa den underliggande hårdvarans tillstånd.
2.4. VIRTUALISERING Xen arkitektur
Xens arkitektur består huvudsakligen av två delar, Xen hypervisor och do-mäner, se figur 2.3. Domäner är motsvarigheten mot ARINC 653:s partitio-ner.
Figur 2.3: Xens arkitektur.
Xen hypervisor är programvarulagret som ligger närmast hårdvaran och ansvarar för att hantera processor, minne och avbrottsrutiner. Det är också den första programvaran som körs efter BIOS/UEFI.
I Xen kallas en instans av en VM för domän eller gäst. En speciell do-män, kallad domän 0 eller förkortat Dom0, finns till för att tillhandahålla drivrutiner för alla enheter i systemet. Dom0 innehåller också en verktygs-stack vilket är den programvara som behövs för att skapa, konfigurera och ta bort virtuella maskiner samt visa statistik som till exempel den nuvaran-de förnuvaran-delningen av processortinuvaran-den. Utan Dom0 fungerar inte Xen, då nuvaran-det är via Dom0 som de virtuella maskinerna måste gå för att kommunicera med systemets enheter och världen utanför. För att Dom0 ska fungera krävs ett OS med en kärna som har blivit modifierad till att köras i Dom0, en sådan kärna kallas Xen–aktiverad. En lista på tillgängliga Dom0 OS finns i tabell 2.2, där finns även tillgängliga paravirtualiserade OS med. [17]
KAPITEL 2. BAKGRUND
Distribution Dom0 version Paravirtualiserad version
Alpine Linux 2.4.x 2.3.x, 2.4.x CentOS och andra
RHEL kloner
5.x 5, 6
CentOS 6.4+ 6.4 och nyare -Debian 4.0, 5.0, 6.0 5.0, 6.0 Fedora 15, 16, 17 14, 16 Mageia Alla -Ubuntu 11.10, 12.04 LTS 10.04, 11.04, 12.04 med EC2 kärnan OpenSUSE 10.x, 11.x, 12.x 11.4 Oracle VM för x86 (OVS) Alla
-Oracle Linux - 5, 6 med Red Hat-kompatibel kärna el-ler Oracle Unbreakable Enterprise Kernel Redhat Enterprise
Li-nux (RHEL)
5.x 5, 6
SUSE Linux Enterpri-se Server (SLES)
10.x, 11.x 10, 11
Tabell 2.2: Tillgängliga Dom0-OS och paravirtualiserade gäst-OS [17]. Schemaläggning av domäner
I Xen finns det tre olika typer av schemaläggare som kallas: sEDF, ARINC653 och Credit–based. Domäner schemaläggs indirekt via schemaläggning av vir-tuella CPU:er (VCPU). Varje domän har, vid dess skapande, tilldelats en eller flera VCPU:er. [17]
sEDF står för simple Earliest Deadline First, eller på svenska: förenklad tidigast sluttid först. Algoritmen är prioritetsbaserad och prioriteten för var-je VCPU förändras under exekveringen av systemet. Prioriteten är beroende av hur lång tid systemets VCPU:er har kvar tills respektive VCPU:s nästa sluttid. Den VCPU som har kortast tid kvar till sin nästa sluttid får högst prioritet och schemaläggs således först. Värdet av sluttiden är baserat på ett antal parametrar som ställs in innan start av VCPU:erna (och de virtuella maskinerna). Xens utvecklare har bestämt att sEDF ska avvecklas till fördel för Credit–based schemaläggning. [17]
2.4. VIRTUALISERING ARINC653 är en schemaläggare som följer ARINC 653 standardens spe-cifikation för schemaläggning [17]. Schemaläggningen sker således via ett fast, förutbestämt, cykliskt schema. Ett utkast av dokumentationen för den-na schemaläggare finns endast tillgänglig, mot betalning, via DornerWorks [29].
Credit–based (kreditbaserad) är en schemaläggare som schemalägger VCPU:er efter dess prioritet och bygger på att varje VCPU tilldelas en kre-dit, maxgräns och tidsperiod (tidsperioden är alltid samma för alla VCPU:er, standardvärdet är 30 ms).
Maxgränsen uttrycks i procent och anger hur mycket beräkningskraft som en VCPU får använda: 50% betyder en halv CPU, 100% en hel CPU, 300% 3 CPU:er och så vidare.
Krediten är ett värde mellan 1 och 65535 där startvärdet som standard är satt till 256. En VCPU:s prioritet beror på dess kredit och kan anta två värden: över och under. Över betyder att VCPU:n har överförbrukat sina krediter (de är slut) och under betyder att VCPU:n har underförbrukat sina krediter (det finns krediter kvar). Krediten konsumeras medan en VCPU körs och negativ kredit medför att prioriteten sätts till över (positiv kredit medför således att prioriteten är under ). En gång i varje tidsperiod körs en tråd som beräknar hur mycket krediter varje VCPU har tjänat och adderar dessa till respektive VCPU.
Vid varje schemaläggningsbeslut (när en VCPU blockerar, väcks eller blir klar med sin tidsperiod) hämtas en ny VCPU från en prioritetskö som därefter tillåts att exekvera på CPU:n. Först och främst hämtas VCPU:er med prioriteten under, finns ingen sådan hämtas en VCPU med prioriteten över. När en VCPU läggs till i kön placeras den efter de andra VCPU:erna med samma prioritet. Således kommer alltid VCPU:er som har underkon-sumerat sin kredit att väljas ut före VCPU:er som har överkonunderkon-sumerat sin kredit. [17, 18]
Interpartitionskommunikation
I Xen har interpartitionskommunikationen implementerats som ett virtuellt nätverk. Implementationen består av två virtuella gränssnitt: ett placerat i Dom0 och ett annat placerat i gästens OS i form av en drivrutin. Drivrutinen i gästens OS beter sig som vilken drivrutin som helst och programvaran i gästens partition kommunicerar precis som om gäst–OS:et hade haft ett fysiskt nätverkskort.
Det räcker inte enbart med dessa virtuella gränssnitt för att kommuni-cera mellan partitionerna. Utöver gränssnitten krävs också att ett virtuellt nätverk konfigureras, något som ofta görs i Dom0 i form av en mjukvaru-brygga. Denna brygga skapar en virtuell switch som ser till att de paket som skickas över det virtuella nätverket hamnar hos rätt mottagare. [17]
KAPITEL 2. BAKGRUND Minneshantering
I Xen delas minnesrymden upp mellan partitionerna genom att paravirtua-lisera MMU:n. Modellen för att paravirtuaparavirtua-lisera MMU:n i Xen bygger på att gäst OS:en känner till minneshierarkin och tillåts skriva direkt till värdma-skinens adressrymd. För att undvika att gästernas OS skriver över varandras minnesrymder har varje sida i adressrymden en bestämd typ, bland annat typen skrivbar. Dessa attribut måste stämma överens med den typ som finns lagrad i gäst OS:ets tabell över tillgängliga sidor. Xen kan med hjälp av de paravirtualiserade anropen till MMU:n, sidtyperna och tabellen sedan bestämma om OS:et får tillgång till den begärda adressrymden eller inte. Ansvaret för att gäst OS:et skriver och läser i sin tilldelade adressrymd ligger alltså fortfarande på Xen. [17]
Tillgång till USB–enheter
Tillgång till systemets I/O–funktioner, däribland USB–enheter, sker via Dom0. Möjligheter att montera USB–enheter direkt till en vald VM finns, dock är stödet för denna teknik begränsad då endast ett fåtal av de para-virtualiserade OS:en klarar av detta. [17]
Hårdvarustöd
De processorarkitekturer som Xen huvudsakligen stöder är (under skrivan-det av denna rapport) x86, både 64- och 32-bit och ARMv7. Det har även funnits stöd för vissa processorer i PowerPC arkitekturen, dock avslutades den officiella utvecklingen för PowerPC 2010.
Det är möjligt att portera Xen till andra arkitekturer. Enligt Stefano Stabellini [30], som har porterat Xen till ARMv7, tar det uppskattningsvis ett till två år för ett team på två till tre personer att genomföra en portering av Xen till en ny arkitektur. [17]
2.5
Testplattform
Figur 2.4: Bandvagnen MMP-30. Testplattformen som använts under
examensarbetet består av en band-vagn av modellen MMP–30 från The Machine Lab, se figur 2.4. Plattformen har även utrustats med ett utvecklingskort från Olimex (an-vänds för att driva motorerna), en GPS (eng. Global Positioning Sy-stem) och en bärbar dator av mo-dellen Dell Latitude D810.
2.5. TESTPLATTFORM
2.5.1
Bärbar dator
Den bärbara datorn är av modellen Dell Latitude D810. Den har en enkel-kärnig Intel Pentium M processor vilket gör att eventuell problematik med system bestående av flera kärnor inte behöver utredas i det här examensar-betet.
2.5.2
Framdrivning
Framdrivningen av bandvagnen handhas av ett utvecklingskort (SAM7H64) från Olimex som har en ARM–processor från Atmel (AT91SAM7S64). Ut-vecklingskortet styr bandvagnens motorer och hämtar även data från odo-metrarna som är anslutna till motorerna. Kortet kommunicerar med test-plattformens dator via USB. [16]
Protokoll
Framdrivningsenheten har fyra olika kommandon, se tabell 2.3. För att sty-ra bandvagnens motorer skickas ett meddelande som innehåller den önskade hastigheten för både höger och vänster band (ett negativt värde anger back). Meddelandet har utseendet ’sVXXYY’, där XX är två bytes som represen-terar vänster bands hastighet och YY represenrepresen-terar höger bands hastighet, båda i mm/s. Utvecklingskortet svarar sedan med meddelandet ’sVOK’.
För att hämta odometerdata och bandhastigheter skickas meddelandena ’upDi’ respektive ’upVe’. Svaret har utseendet ’LXXRYY’, där XX är has-tigheten i tiondels mm/s respektive avverkad strecka (också här i tiondels mm) sedan senaste mätning på vänster band och YY är analogt höger band. Meddelandet ’rese’ nollställer variablerna för avverkad sträcka på ban-den. Framdrivningsenheten svarar med ’reseOK’. [16]
Uppgift Kommando Svar Ställa in hastighet sVXXYY sVOK Hämta odometerdata upDi LXXRYY Hämta bandhastigheter upVe LXXRYY Nollställ körd sträcka rese reseOK
Tabell 2.3: Protokollet som används för att styra framdrivningsenheten [16].
2.5.3
GPS
GPS:en är en U–blox EVK–5H och består av en liten låda med USB–anslutning samt en extern antenn. Den skickar, med jämna mellanrum, ut en rad olika meddelanden via USB. Ett av dem kallas GLL (eng. Geographic position Lattitude / Longitude, Geografisk position Latitud / Longitud) och har for-matet:
KAPITEL 2. BAKGRUND
$GPGLL, Latitud, N, Longitud, E, ttmmss.ss, Valid, Mode*cs En mer ingående beskrivning av formatet finns i tabell 2.4. [31]
Fält Beskrivning $GPGLL Meddelandets ID
Latitud Latitud i grader och minuter
N N/S indikering, N = norr, S = söder Longitud Longitud i grader och minuter E E/W indikering, E = öst, W = väst ttmmss.ss Nuvarande tid i UTC
Valid V = felaktig data, A = korrekt data
Mode*cs Flagga för positioneringssätt och checksumma Tabell 2.4: Beskrivning av formatet för GLL [31].
Kapitel 3
Lösningsförslag
I det här kapitlet beskrivs förslag på hur en partitionerad arkitektur kan skapas. För och nackdelar vägs in i en jämförelse och ett av förslagen väljs ut för en testimplementation.
Oavsett vilken av de föreslagna lösningarna som väljs så är det viktigt att utarbeta och specificera en plan för hur kommunikation mellan olika mjukvarulager får ske. Det är också viktigt att tänka på hur kommunika-tionen hanteras, så att partikommunika-tionen som skickar/tar emot inte förlorar sina eventuella realtidskrav. Exempelvis bör man fundera på hur man hanterar blockerande kommunikation, då det inte alltid är möjligt att bestämma hur länge en partition får vänta på att ett meddelande ska skickas eller tas emot.
3.1
Övergripande arkitektur
För att kunna påvisa en partitionerad arkitektur krävs först och främst att mjukvaran kan delas upp i olika partitioner. Dessa partitioner kan sedan fördelas på olika hårdvara, som i en federerad arkitektur, eller samma hård-vara, som i en IMA arkitektur. Används samma hårdvara så krävs ytterligare mjukvara för att åstadkomma en separation mellan dessa partitioner.
3.1.1
Federerad arkitektur
En federerad arkitektur (se avsnitt 2.2.1) har den stora fördelen att par-titionerna varken behöver konkurrera om processorkraft eller arbetsminne. Något som gör att ett system baserat på denna arkitekturen antagligen blir enklare att testa och validera, då det räcker med att garantera att kommu-nikationsvägarna fortfarande fungerar som de ska när nya funktioner läggs till.
Saab Dynamics dock är väl förtrogen med hur en federerad arkitektur bör utvecklas och fungera. Dessutom krävs det mer hårdvara än vad som finns tillgängligt för det här examensarbetet.
KAPITEL 3. LÖSNINGSFÖRSLAG
3.1.2
IMA
IMA arkitekturen (se avsnitt 2.2.2) har den stora fördelen att den tillgängliga beräkningskraften utnyttjas bättre, jämfört med en federerad arkitektur. Dessutom är det ett mer okänt område för Saab Dynamics. I och med att det krävs en hel del mjukvara för att få igång ett system med IMA så är en existerande prototyp att föredra framför en helt egenutvecklad prototyp. IMA med ARINC 653
ARINC 653 är en välkänd standard (även för Saab Dynamics) och det finns flertalet tillgängliga lösningar som är baserade på den. Dock har de varie-rande stöd för den hårdvara som finns tillgänglig för examensarbetet och de är dessutom både kostsamma och svåra att få tag på med kort varsel. IMA med Virtualisering
Det finns flertalet mer eller mindre färdiga lösningar även för virtualisering. Den stora fördelen med dessa lösningar, jämfört med en lösning baserad på ARINC 653, är att de är både lättillgängliga och gratis. Flera av de existerande lösningarna ska dessutom vara kompatibla med den hårdvara som finns tillgänglig för examensarbetet.
3.1.3
Val av arkitektur
Efter att ha undersökt vilka typer av arkitekturer som finns för att skapa ett partitionerat system så föll valet på IMA med virtualisering. Detta val gjordes av följande anledningar:
• Virtualisering i inbyggda system är, för Saab Dynamics, ett outfors-kat område, till skillnad från en federerad arkitektur och ett system baserat på ett ARINC 653 OS.
• Virtualisering utnyttjar den tillgängliga beräkningskraften bättre, jäm-fört med en federerad arkitektur.
• Existerande virtualiseringslösningar finns att ladda ned i öppen käll-kod, vilket gör att man relativt snabbt kan få igång ett system baserat på den tekniken.
• Flera existerande virtualiseringslösningar har stöd för den tillgängliga hårdvaruplattformen, till skillnad från existerande ARINC 653 OS, som har ett begränsat stöd för samma plattform.
• Det visade sig vara svårt att, snabbt, få tag på en utvärderingslicens av till exempel VxWorks ARINC 653 OS.
3.2. VAL AV PLATTFORM FÖR VIRTUALISERING
3.2
Val av plattform för virtualisering
Innan den valda plattformen fastslogs undersöktes rad olika lösningar. För att komma igång så snabbt som möjligt gjordes valet att undersöka vilka lösningar som finns tillgängliga utan licenskostnader. Under denna under-sökning visade det sig att det finns en hel del olika lösningar med olika krav på hårdvaruplattform och av varierande kvalitet. De plattformar som har undersökts är: CodeZero, NOVA, OKL4, POK, RT-Xen, Xen och XtratuM.
3.2.1
Xen
Xen är en VMM för x86 arkitekturen och startade som ett forskningsprojekt på Cambridge University. Numer är Xen ett gemensamt projekt under The Linux Foundation1. Till projektet finns det en stor wiki2 med information
om hur Xen fungerar och vilka steg som krävs för att kompilera och starta Xen på en ny dator. Utöver wikin finns också ett forum med tillhörande e–postlistor, både för utvecklare och användare.
3.2.2
Övriga
CodeZero från B Labs riktar sig först och främst mot mobila inbyggda system och stödet är därför begränsat till ARMv7. De verkar inte ha något forum, men däremot en e–postlista för utvecklingsfrågor [22].
NOVA från Tekniska Universitetet i Dresden (Tyskland) påstår sig till-handahålla grundläggande mekanismer för virtualisering. Dock kräver NO-VA en processor med hårdvarustöd för virtualisering (AMD–V eller Intel VT–x) [23].
OKL4 från OK–labs bygger på en så kallad mikrokärna i L4–familjen. Forum finns för version 3.0 som är kompatibel med ARM–processorer, för att få kompatibilitet med x86 krävs dock att version 2.1 används. Dock saknas nödvändig information för att få igång ett system med OKL4 version 2.1 [24].
POK är en virtualiseringslösning för PowerPC- och LEON3-arkitekturer som delvis har stöd för ARINC 653. Dock saknas drivrutinsstöd för USB–enheter [25].
RT-Xen är en utökning av Xen för att möjliggöra stöd för virtuella maskiner med krav på realitd. Utvecklingsteamet bakom RT-Xen rekom-menderar att programvaran körs på en plattform med en processor byggd för x64 arkitekturen [26].
XtratuM som är x86-kompatibel och utvecklades ursprungligen på Uni-versity of Valencia. Numera tillhör rättigheterna för XtratuM ett avknopp-ningsföretag som heter Fentiss3. XtratuM bygger på filosofin i ARINC 653 men är dock ej kompatibelt med ARINC 653, till exempel saknas stöd för
1http://www.linuxfoundation.org 2http://wiki.xen.org
KAPITEL 3. LÖSNINGSFÖRSLAG
APEX [27]. Vid försök att starta ett givet Hello World –exempel gav Xtra-tuM ett felmeddelande för att sedan hänga sig/avslutas. Felet uppkom både på en egenhändigt kompilerad version och en given virtuell maskin som bara var att starta i till exempel Virtual Box.
3.2.3
Det slutgiltiga valet
Efter en närmre undersökning av de olika virtualiseringslösningarna så val-des slutligen Xen ut för en testimplementation av styrsystemet på bandvag-nen. Att valet föll på Xen beror främst på två anledningar:
• Xen har stöd för den hårdvara som finns på bandvagnen (x86 processor utan stöd för hårdvaruassisterad virtualisering).
• Xen har ett stort community, samt e-postlistor. Således finns det goda möjligheter till att få hjälp.
3.3
Utvecklingsprocess
Under det här examensarbetet kommer inte utvecklingsprocessen från DO–178C att följas. DO–178C valdes bort på grund av att examensarbetet har så pass begränsade tidsramar. Det tar helt enkelt för lång tid att utveckla ett test-system med de krav som standarden ställer.
Istället användes en process som utvecklats under examensarbetets gång. Den går ut på att först designa systemet som ska utvecklas och försöka få med så många delar av systemet som möjligt. I arbetet med designen ingick även att bryta upp systemet i små moduler, som sedan är relativt enkla att realisera i programkod. Designen dokumenterades genom att rita upp ett blockschema, där varje block representerar en egen programvarumo-dul. Modulerna kopplas sedan samman med riktade pilar som representerar kommunikationsvägarna genom systemet. Det fina med pilarna är att de inte bara visar kommunikationsvägarna, de ger även en visuell bild av hur programvarublocken är beroende av varandra.
När designfasen är över är det dags att realisera de olika modulerna. Då väljs den modul som har flest beroenden, det vill säga den modul som andra moduler är beroende av, ut först. När den modulen anses vara klar väljs en modul som är beroende av den färdiga modulen ut för implementation. På så vis underlättas testningen av de moduler som utvecklats och testerna kan modifieras för att passa den systematiska inkrementeringen av antalet moduler i systemet.
Kapitel 4
Systemdesign och
implementation
Det här kapitlet beskriver den design som utvecklats och använts vid imple-mentationen av en modulär arkitektur, med hjälp virtualiseringsplattformen Xen.
4.1
Översikt
Systemet har huvudsakligen delats upp i fyra partitioner, se figur 4.1. I VM0 och VM1 exekveras den programvara som styr testplattformen. Programva-ran i VM0 har till uppgift att tillse att bandvagnen inte gör något dumt, som till exempel köra utanför det avgränsade området. VM1 finns till för att skicka både korrekta och felaktiga kommandon till VM0. VM1 testar således både hur bra VM0 klarar av att hantera förutsedda felaktiga kommandon och hur meddelanden som skickas mellan olika partitioner påverkas, i form av fördröjningar, av Xen och andra partitioner.
VM2 har skapats för att på olika sätt försöka störa de andra partitio-nernas exekvering genom att införa oförutsedda fel. Denna VM behövs för att undersöka hur Xen hanterar en partition med programvara som har ett onormalt beteende vad gäller CPU–användning, minneshantering och I/O–hantering.
Den kreditbaserade schemaläggaren används för att schemalägga parti-tionerna. Den är inställd på standardvärdena, det vill säga varje VM (och Dom0) har en tidsperiod på 30 ms och en startkredit på 256. Att valet föll på den kreditbaserade schemaläggaren istället för ARINC653–schemaläggaren beror på att dokumentationen för ARINC653–schemaläggaren inte hade till-räcklig detaljnivå för hur den används.
KAPITEL 4. SYSTEMDESIGN OCH IMPLEMENTATION
Figur 4.1: Systemdesign.
4.2
Dom0
Dom0 består av en Xen–aktiverad Ubuntu 12.04 installation. Eftersom Dom0 tillhandahåller de USB–drivrutiner som krävs så får Dom0 även agera USB–värd.
4.2.1
USB–värd
USB–värden är ett program, skrivet i C++, som huvudsakligen utför 3 upp-gifter:
1. Leta rätt på USB–enheterna och öppna en kommunikationskanal för vardera USB–enhet.
2. Skapa en ny tråd och starta en serveranslutning per tråd, via sockets. Vänta på att klienten (VM0) ska ansluta.
3. Vidarebefordra det data som kommer från VM0 till USB och vice versa.
Den enda filtrering av data som USB–värden tillåts göra är för kommu-nikation mot GPS:en där endast intressant data (GPGLL) skickas vidare till VM0. Denna filtrering görs för att avlasta nätverkstrafiken och förenkla GPS-modulen, som bara behöver kunna tolka ett meddelande.
4.3
VM0
I VM0 har en paravirtualiserad Debian 6.0.7 distribution installerats. Valet föll på Debian eftersom en bugg i installationsförfarandet gjorde det omöjligt att installera Ubuntu som gästOS på den tillgängliga hårdvaran.
4.3. VM0 VM0 har till uppgift att ta emot styrkommandon utifrån, undersöka om dessa kommandon får utföras och sedan vidarebefordra dessa till bandvag-nens framdrivningsenhet, via USB–värden i Dom0. Allt arbete som utförs i VM0 utförs av en ensam tråd som arbetar enligt flödesdiagrammet i figur 4.2.
Funktionaliteten i VM0 är uppdelad i ett antal olika moduler(se figur 4.1), dels för att separera de olika funktionerna från varandra, men också för att abstrahera bort de protokoll som används för kommunikationen mot andra partitioner. Samtliga moduler är skrivna i C++.
KAPITEL 4. SYSTEMDESIGN OCH IMPLEMENTATION
4.3.1
Kommunikationsmodul
Kommunikationsmodulen i VM0 är till för att sätta upp och ta hand om kommunikationen mellan VM0 och VM1. Modulen gör detta genom att star-ta en insstar-tans av serverimplemenstar-tationen för kommunikation via sockets och sedan vänta på att VM1 ska ansluta.
4.3.2
Filtreringsmodul
Filtreringsmodulen har till uppgift att undersöka om inkommande don anses som giltiga eller inte. Modulen kan bedöma inkommande komman-don genom att den, via GPS, kan bestämma bandvagnens rörelsemönster. Den tar emot kommandon via kommunikationsmodulen, undersöker om det är ett tillåtet kommando och skickar sedan tillåtna kommandon vidare till bandstyrningsmodulen.
Tillåtna kommandon
Figur 4.3: Tillåtet område. Ett kommando anses som tillåtet då det
uppfyller två krav:
• Kommandot finns i protokollet, se tabell 4.1, och
• Bandvagnen kommer att befin-na sig inom 10 meter från sin utgångspunkt (den position där bandvagnen startas och initieras) efter att kommandot har genom-förts, se figur 4.3.
Protokoll
Protokollet som används för att kommunicera med filtreringsmodulen inne-håller endast tre olika kommandon, se tabell 4.1. För att förmå bandvagnen att köra framåt respektive bakåt skickas ett kommandot FX, där F är bok-staven F i ASCII och X är ett positivt respektive negativt heltal av typen short. På samma sätt kan bandvagnen förmås att rotera åt höger respektive vänster med kommandot RX, där X är positivt för rotation åt höger och analogt negativt för rotation åt vänster. Kommandot T används för att be-rätta för filtreringsenheten att inga fler styrkommandon kommer att skickas. Alla övriga kommandon betraktas som felaktiga.
4.4. VM1 Uppgift Kommando Svar
Kör frammåt/bakåt FX ok Rotera höger/vänster RX ok
Avsluta T TOK
Tabell 4.1: Protokollet som används för att kommunicera med filtreringsmo-dulen.
4.3.3
Bandstyrningsmodul
Bandstyrningsmodulen är till för att abstrahera kommunikationen med mo-torer och odometrar på bandvagnen. Modulen använder protokollet från avsnitt 2.5.2, som beskriver hur framdrivningsenheten fungerar, för att kom-municera med framdrivningsenheten via USB–modulen. Detta underlättar vid ett eventuellt byte av USB–modul i VM0.
4.3.4
GPS–modul
GPS–modulen har till uppgift att abstrahera kommunikationen mot GPS:en på bandvagnen. Gränssnittet mot filtreringsmodulen innehåller endast en procedur som triggar hämtning av data från USB–enheten och presenterar dessa som longitud och latitud. Proceduren extraherar dessa värden från GPGLL formatet som omnämns i avsnitt 2.5.3.
4.3.5
USB–modul
USB–modulen är enbart en instans, per anslutning, av klientimplementatio-nen för kommunikation via sockets och ansluter mot USB–värden i Dom0.
4.4
VM1
Även i VM1 har en paravirtualiserad Debian 6.0.7 distribution installerats. VM1 har en enda uppgift: att skicka styrkommandon till VM0.
4.4.1
Ordermodul
Ordermodulen är en modul vars enda uppgift är att bombardera VM0 med styrkommandon som följer protokollet som beskrivs i tabell 4.1. Denna mo-dul känner varken till bandvagnens position eller hur den rör sig.
4.4.2
Kommunikationsmodul
Kommunikationsmodulen i VM1 är en instans av klientimplementationen för kommunikation via sockets och ansluter mot motsvarande modul i VM0.
KAPITEL 4. SYSTEMDESIGN OCH IMPLEMENTATION
4.5
VM2
Precis som i VM0 och VM1 så har en paravirtualiserad Debian 6.0.7 distri-bution installerats i VM2. VM2 finns till av en enda anledning: att på olika sätt störa VM0, VM1 och Dom0.
4.5.1
Störmodul
I störmodulen exekveras den kod som används för att undersöka tillförlitlig-heten hos Xen. För mer information om hur denna kod beter sig, se testfallen för minneshantering, processorhantering och I/O–hantering i kapitel 5. För den intresserade läsaren finns koden i bilaga B.
Kapitel 5
Utvärdering och resultat
I det här kapitlet beskrivs de tester som genomförts på bandvagnsstyrsy-stemet för att utvärdera graden av separation i tid och rum av den valda virtualiseringslösningen. Kapitlet innehåller även en beskrivning av utföran-det samt resultaten av respektive testfall.
5.1
Tester
Totalt har sex olika tester genomförts. Det första testfallet används som referens och de tre efterkommande testfallen är till för att undersöka om virtualisering, och framförallt Xen, är en lämplig kandidat för att bygga ett partitionerat system med motsvarande tillförlitlighet som en federerad ar-kitektur eller en arar-kitektur baserad på ARINC 653. Resterande två testfall används för att undersöka hur bandvagnens styrpartition beter sig när or-derpartitionen på olika sätt försöker få styrpartitionen att styra bandvagnen utanför det avgränsade området.
Under samtliga tester körs ett perlskript i Dom0. Perlskriptet är hämtat från phplens.com [28] och modifierat för att fungera med den verktygsstack som används i Dom0. Dess uppgift är att en gång i sekunden mata ut en tids-stämpel, med upplösningen 10 µs, följt av processoranvändningen för Dom0 och respektive VM. Från perlskriptets utdata har sedan jitter beräknats. Eftersom endast positivt jitter har påträffats under testfallen så kommer jittret att benämnas som fördröjning under resterande delar av rapporten.
5.1.1
Tillförlitlighet
Med en tillförlitlig arkitektur avses en arkitektur där partitioner som an-ses som kritiska alltid kan utföra sina uppgifter, oavsett hur en partition som inte anses som kritisk beter sig vad gäller processor-, minnes- eller I/O–hantering. I fallet med bandvagnen anses Dom0, VM0 och VM1 vara kritiska partitioner, medan VM2 anses som en icke–kritisk partition. VM2
KAPITEL 5. UTVÄRDERING OCH RESULTAT
ska med andra ord varken kunna förhindra eller fördröja de mätningar som utförs med hjälp av perlskriptet i Dom0. VM2 ska inte heller påverka VM0 eller VM1 genom att förstöra data i deras minnesrymd eller fördröja dem så pass mycket att bandvagnen beter sig annorlunda genom att till exempel stanna upp och invänta nästa styrkommando.
Tillförlitlighet, av den här betydelsen, uppnås i ARINC 653 genom en robust partitionering i tid och rum. Partitioneringen i tid sker genom an-vändandet av ett deterministiskt och cykliskt schema med förutbestämda tidsperioder för varje partition. Schemaläggaren i Xen löser partitioneringen i tid genom att schemalägga partitioner efter dess prioritet, vilken förändras under exekveringens gång och beror av hur mycket processortid en viss par-tition har fått tillgång till. Därför är det viktigt att undersöka hur processer som i någon mening är tidskritiska exekveras i en partition när andra par-titioner belastar systemet genom att använda maximalt med processortid. Ett exempel på en sådan process är en process som med jämna mellanrum utför någon form av mätning, till exempel perlskriptet som beskrivs i avsnitt 5.1.2.
Partitioneringen i rum kan delas in i två underkategorier: partitionering av arbetsminne och partitionering av I/O–enheter. ARINC 653 garanterar en partitionering av arbetsminnet genom att inte tillåta olika partitioner att skriva i varandras minnesrymd. Xen löser detta genom att paravirtu-alisera anropen till värdmaskinens MMU och sedan förbjuda tillgång till den minnesrymd som inte tillhör den anropande partitionen. Tillgång till I/O–enheter garanteras, i ARINC 653, genom att det endast är den sche-malagda partitionen som har tillgång till I/O–enheter. I Xen är det bara Dom0 som har tillgång till systemets I/O–enheter. Detta medför att en par-tition som använder I/O–enheter måste kommunicera med dessa via Dom0 och dessutom vänta på att Dom0 ska schemaläggas för att utföra kommuni-kationen. I värsta fallet blir väntetiden på att Dom0 ska schemaläggas 30 x 3 = 90 ms.
I en federerad arkitektur garanteras tillförlitligheten genom att varje par-tition körs på egen hårdvara och har således ingen att konkurrera om hård-varuresurserna med.
För att kunna påstå att en arkitektur som bygger på virtualisering, och framförallt Xen, har liknande tillförlitlighet som en arkitektur baserad på ARINC 653 eller en federerard arkitektur krävs att partitioneringen i tid och rum lämnar samma garantier. Det vill säga att uppfyllelse av funktio-nella krav inte ska kunna påverkas av fördröjningar eller andra störningar. För att möjliggöra mätningar av sådana avvikelser krävs tester inom tre huvudsakliga områden: processor-, minnes- och I/O–hantering.
5.1.2
Intressant mätdata
Under samtliga tester samlas en mängd intressant mätdata in:
5.1. TESTER ett perlskript som är inställt att en gång i sekunden mata ut en tids-stämpel, med en upplösning på 10 µs, samt fördelningen av proces-sortiden över de virtuella maskinerna och Dom0. Skriptet anropar ett Xen-kommando som i sin tur ansvarar för att mata ut datat med rätt periodicitet.
(2) Tidsstämpling av styrkommandon, enligt protokollet från avsnittet om testplattformens framdrivning (2.5.2), som skickas från VM0 till USB–enheten som styr bandvagnens motorer.
(3) Distansen från centrum av det avgränsade området till bandvagnens position.
(4) Tidsstämpling av de styrkommandon som skickades från VM1 till VM0.
(5) Tidsstämpling av respons på kommando skickat från VM1 till VM0. (1) används dels för att se hur Xen fördelar processortiden, men framförallt för att undersöka hur Xen hanterar en process som kan anses vara tidskritisk och måste genomföra sina beräkningar med ett bestämt intervall. (2), (4) och (5) används för att undersöka om de olika testfallen påverkar styrningen av bandvagnen i form av fördröjningar. (3) används för att utreda huruvida bandvagnen håller sig innanför det avgränsade området eller ej.
Figur 5.1 innehåller systemdesignen från avsnitt 4.1 med markeringar för vart respektive mätdata samlas in.
