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 instans av serverimplementationen 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 komman- 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 arkitektur 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.
KAPITEL 5. UTVÄRDERING OCH RESULTAT
5.2
Testfall
I den här sektionen beskrivs varje utfört testfall och var för sig. Samtliga testfall innehåller en beskrivning av utförandet, förväntat resultat, utfall och en kort diskussion kring vilka slutsatser som dragits. Det första testfallet används som en referenspunkt och innehåller därför enbart en beskrivning av utförandet och resultatet.
5.2.1
Referensfallet
I det här testet undersöks hur Xen beter sig när de skript som samlar in data för testkörningarna används. Detta testfall används som referensfall när data från resterande tester analyseras.
Utförande
Under varje mätomgång körs skriptet som samlar in data vid samtliga tester samtidigt som bandvagnens övriga partitioner försöker utföra sina uppgifter genom att styra bandvagnen inom ett avgränsat område. Totalt utförs tio mätomgångar. Under samtliga mätomgångar samlades 42 mätpunkter in i Dom0, det vill säga varje mätomgång utfördes i ca 42 sekunder.
Resultat
Figur 5.2 innehåller en graf där medelfördröjningen tillsammans med max- och min-fördröjningen är plottad för respektive mätomgång.
Medelfrödröjningen, uträknad från samtliga mätomgångar, hamnade på 19,8 ms. Det vill säga: medeldifferensen mellan två mätpunkter blev 1,0198 sekunder (det inställda värdet var 1 sekund). Den värsta fördröjningen upp- mättes till 52 ms och den minsta till 18 ms, vilket motsvarar ett spann på hela 34 ms.
De sex bästa mätningarna (de med minst fördröjning) fick en medel- fördröjning på 18,6 ms. Dessa mätningar hade även en jämn spridning av fördröjningen och spannet mellan max och min blev här endast 4 ms.
Under två värsta mätningarna (nummer ett och sex) blev medelfördröj- ningen i Dom0 25 ms, tiden mellan mätningarna blev alltså 1,025 sekunder lång. Under dessa två mätomgångar var de största fördröjningarna återkom- mande i pulser med ca 5 mätpunkters mellanrum och hade en magnitud på runt 40 ms.
5.2. TESTFALL
Figur 5.2: Medelfördröjningen tillsammans med max- och min- fördröjningen vid exekvering av perlskriptet under referensfallet, med logaritmisk skala på y–axeln.
Styrkommandon De sex bästa mätomgångarna saknar helt fördröjning- ar i kommunikationen mellan VM0 och VM1, samt VM0 och Dom0. Som synes i figur 5.3 fick de övriga fyra (nummer ett, två, sex och nio) fördröj- ningar på upp till två sekunder från dess att ett styrkommando skickas från VM1, tills dess att VM1 erhåller ett svar. Dessa fördröjningar har uppstått vid kommunikationen mellan VM0 och Dom0 och reproduceras ut till VM1.
Figur 5.3: Medelfördröjningen tillsammans med max- och min- fördröjningen av kommunikationen mellan VM0 och VM1 under re- ferensfallet, med linjär skala på y–axeln.
KAPITEL 5. UTVÄRDERING OCH RESULTAT Slutsatser
Av testfallet dras två olika slutsatser: Antingen är Xen-verktyget som an- vänds i perlskriptet inte tillräckligt exakt för att kunna ge en fördröjning på 1 sekund. Eller så kör systemet andra processer som stör Xen så pass mycket att Xen inte klarar av att upprätthålla den inställda fördröjningen av den anledningen. Oavsett vilket så kommer detta testfall att användas som referens och resterande testfall kommer att jämföras mot detta.
5.2.2
Minneshantering
I det här testet undersöks huruvida Xen lyckas isolera partitionernas tillde- lade arbetsminne.
Utförande
Under varje mätomgång körs programvara i VM2, som allokerar minne i en oändlig loop, samtidigt som bandvagnens övriga partitioner försöker utföra sina uppgifter genom att styra bandvagnen inom ett avgränsat område.
Utöver de tidigare beskrivna datainsamlingsmetoderna, se avsnitt 5.1.2, körs även ett kommando, i VM2, som övervakar minnesanvändningen både i arbetsminnet och swappen. Testfallet är uppdelat i två deltester (A och B), skillnaden mellan testerna är att swappen är avstängd i deltest B. Un- der varje deltest utförs tio mätomgångar, därefter analyseras och jämförs mätningarna mot varandra och mot referensfallet. Under varje mätomgång samlas 20 respektive 4 mätvärden in från skriptet i Dom0 vid deltest A re- spektive B. Att deltest B bara har 4 mätvärden beror på att testet anses vara över när programvaran i VM2 tvingas avbryta sin exekvering på grund av att arbetsminnet tar slut. Koden för testprogrammet finns i bilaga B. Förväntat resultat
Xen klarar av att hålla isoleringen av arbetsminnet och testprogrammet i VM2 avbryts när partitionens arbetsminne tar slut.
Utfall
Deltest A - med swap Med hjälp av kommandot som körs i VM2 uppstår följande händelseförlopp:
1. Programmet allokerar arbetsminne, tills dess att ca 80% har förbru- kats.
2. OS:et anser att arbetsminnet är slut och börjar flytta data till swap- filen.
5.2. TESTFALL Av händelseförloppet att döma så klarar Xen av att hålla gränserna för det tilldelade arbetsminnet. Dock påverkas Dom0 negativt av att VM2 tvingas använda swap-filen. Något som syns tydligt i figur 5.4 där medelfördröjning- en samt max- och min-fördröjningen finns plottad för alla tio mätomgång- arna.
Fördröjningarna uppträder, under alla mätomgångar förutom nummer fem och tio, huvudsakligen som två toppar av varierande storlek. Figur 5.5 visar hur fördröjningarna uppträder under mätomgång ett (axeln mätpunk- ter ska tolkas som en tidsaxel med ca. 1 sekund mellan varje mätpunkt). Dessa fördröjningar syns även, med samma mönster, i loggarna från kom- munikationen mellan VM0 och VM1, samt VM0 och Dom0. Det är endast under mätomgång sex och åtta som dessa fördröjningar är tillräckligt stora (över 2 sekunder) för att bandvagnens körstil ska påverkas. Bandvagnen får, under dessa mätomgångar, en ryckig körstil när fördröjningarna inträffar: den stannar för att sedan köra vidare igen. Precis som i referensfallet så uppstår fördröjningarna vid kommunikationen mellan VM0 och Dom0 och reproduceras ut till VM1.
Figur 5.4: Medelfördröjningen tillsammans med max- och min- fördröjningen vid exekvering av perlskriptet under minneshante- ringstest A, med logaritmisk skala på y–axeln.
KAPITEL 5. UTVÄRDERING OCH RESULTAT
Figur 5.5: Uppkomsten av fördröjningar under mätomgång ett, min- neshanteringstest A.
Slutsatser
Xen klarade av att hålla isoleringen av arbetsminnet. Men den I/O–kommunikation som uppstår då VM2 tvingas göra plats i arbetsminnet genom att flytta da- ta till hårddisken medför att övriga delar av systemet drabbas av kraftiga fördröjningar.
Deltest B - utan swap Med hjälp av kommandot som körs i VM2 fås följande händelseförlopp fram:
1 Programmet allokerar arbetsminne, tills dess att ca 80% har förbru- kats.
2 OS:et anser att arbetsminnet är slut och terminerar programmet.