Utvärderingsmodell för COTS och objektorientering i realtidstillämpningar. Rev B

Transkript

1 Utvärderingsmodell för COTS och objektorientering i realtidstillämpningar Rev B Torbjorn.Andreasson@emw.ericsson.se Lennart.Bie@emw.ericsson.se Mikael.Jeppsson@emw.ericsson.se Martin.Jigstam@emw.ericsson.se Annika.H.Ohlsson@emw.ericsson.se Kent.Petersson@emw.ericsson.se Ericsson Microwave Systems AB Breda internationella standarder, COTS (Commercial Off The Shelf) och objektorientering skapar nya möjligheter för konstruktion av allmänna datorbaserade system. Fenomenen börjar även göra sig gällande inom realtidsområdet. I rapporten presenteras en modell för utvärdering av fenomenen. Modellen syftar till att ta fram beslutsunderlag för val av plattformar och programmeringsspråk vid utveckling av realtidsorienterade system och applikationer. EMWAOHL / FCP Rev B 1

2 Innehållsförteckning 1 Bakgrund Klassificering av olika realtidssystem Mekanismer/Egenskaper Allmänna egenskaper Objektorienteringsegenskaper Realtidsegenskaper Modellen Språk Plattformar Konstruktionsfall Mätningar och resultat Generella instruktioner testfall Tolkning av resultat Konstruktionsfallsområde: Processhantering Implementering av periodisk process Schemaläggning periodiska processer Avbrottshantering Hantering av semaforköer Förekomst av prioritetsinvertering Maximalt antal användbara prioritetsnivåer Hantering av processer vid inläsning och utskrift Konstruktionsfallsområde: Minneshantering Dynamisk allokering/deallokering av minne Stack vs. Heap Fragmentering av dynamiskt minne Konstruktionsfallsområde: Modularisering och strukturering Åtkomst av dynamiskt allokerat minne Åtkomst av data med generella metoder Skapa instanser med hjälp av generella metoder Abstraktion av dataåtkomst Anpassning av klasser Konstruktionsfallsområde: Kommunikation och Distribution Meddelandeorienterad kommunikation Automatgenererad kommunikation Deterministisk kommunikation Pipes och Filter Abonnemangstjänst Abonnemangstjänst utökad Kommunikation med broker Dispatcher med Publisher-Subscriber (Observer) N-tier kommunikation Terminologi Referenser...83 Appendix A. Fota3_dis1.idl

3 1 Bakgrund Val av tekniker och plattformar för utveckling av moderna hård- och programvarurelaterade system karaktäriseras i mångt och mycket av COTS-orienterade vägval. Ambitionen är att så långt som möjligt undvika konstruktion av egna komponenter vilket var praxis till inte så länge inom försvarsindustrin. Utvecklingstiderna för militära projekt är i allmänhet långa vilket medfört att genomförda COTS-baserade teknikval redan är föråldrade innan systemen är klara. Det är inte alls ovanligt att vissa komponenter inte går att få tag på då systemen skall produceras. Under utvecklingsfasen är det relativt enkelt och smärtfritt att genomföra nya vägval men är betydligt svårare då systemet går till produktion, underhåll- och förvaltning. Det är inget ovanligt att försvarssystem skall underhållas och modifieras i år. Alternativet till COTS-baserad systemutveckling är istället egenkonstruktion, dvs att på egen hand konstruera och utveckla samtliga i systemet ingående komponenter. Denna princip har i allmänhet tillämpats vid utveckling av militära system och varit väl motiverat av t.ex. exceptionella miljökraven och att vara självförsörjande vid ett så kallat skymningsläge. Det finns båda fördelar och nackdelar med egenkonstruktion, t.ex. Dyrbart och resurskrävande att utveckla och underhålla egna komponenter i jämförelse med användning av COTS. Egna komponenter (i förhållande till COTS) tenderar till att vara för gamla redan innan de kan användas i utvecklingsarbetet av det egentliga systemet. En fördel med egenutvecklade system är däremot att man får full kontroll över den egna omgivningen. Det starkaste motivet till egenutvecklad systemutveckling baseras på principen om detaljerad kontroll och kännedom om alla i systemet ingående komponenter. Sådan systemkännedom är i allmänhet mycket svår att åstadkomma i system baserade på COTS-komponenter. Leverantörerna tillhandahåller eller exponerar sällan källkod, omgivning, etc. Därför har det utvecklats en mängd metoder för certifiering av COTSbaserade komponenter och system, t.ex. Black-Box Component Testing, Software Fault Injection, Operational System Testing, etc. Syftet är att skapa metoder som gör det möjligt för systembyggare att utvärdera, verifiera och förvissa sig om att de inköpta komponenterna uppfyller de uppställda kraven. En intressant företeelse i den programvarurelaterade världen är begreppet Open Source. Begreppet betyder att systemutvecklare inte bara får tillgång till färdiga exekverbara komponenter utan även till källkod. Detta innebär att komponenterna kan granskas in i minsta detalj av systembyggaren. Exempel sådana komponenter är operativsystemet Linux, nät-bläddraren Netscape, GNU-komponenterna, referensimplementationen av JDK (Java Development Kit), etc. 3

4 2 Klassificering av olika realtidssystem Det finns många olika definitioner på realtid och realtidssystem varav de flesta liknar följande definition: Realtidssystem är system som måste reagera på händelser från den fysiska omvärlden inom en viss tid. En definition av denna typ, liksom realtidssystem i sig, spänner över ett brett spektrum av system varför en klassificering av realtidssystem är nödvändig. En vanligt förekommande klassificering är uppdelning i hård-, medelhård- och mjuk realtid. Hård realtid Strikta krav på kort predikterbar svarstid. Exempel är flygplanstillämpningar. Medelhård realtid Krav på predikterbar svarstid. Långsammare system. Mjuk realtid Mer diffusa svarstidskrav. Inget krav på predikterbarhet. Exempel är presentationssystem. Ett alternativ är att utgå från olika tidskrav, deadlines och grundläggande implementeringsstrategier och kategorisera realtidssystemen efter dessa. I utvärderingsmodellen kommer ovanstående egenskaper att användas för kategorisering av realtidsapplikationer. Klassificering syftar till att skapa en terminologi som tillämpas i modellen samt för att kunna resonera om resultaten från mätningar. När det gäller tidskrav så kommer följande klassificering att användas: Systemkategorier Snabbt Långsamt Beskrivning Mycket korta svarstider. Särskild hänsyn till prestanda måste tas. Längre svarstider. Prestanda inget problem. Tabell 2-1 Klassificering av tidskrav Klassificeringen av vikten av varje tidskrav definieras enligt följande: Systemkategorier Strikta deadlines Hårda deadlines Mjuka deadlines Beskrivning Katastrofala följder om en deadline missas (värdet av svaret efter deadline är 0). Deadlines är exakt bestämda. Någon enstaka deadline får missas med inte allt för mycket tid (värdet av svaret efter deadline minskar mycket snabbt till 0). Deadline kan sättas inom ett litet tidsintervall. Irriterande med inga värre följder om en deadline missas (värdet av svaret efter deadline minskar långsamt ner till 0). Deadlines satta efter tycke och smak. Tabell 2-2 Klassificering av vikten av att hålla tidskraven 4

5 Implementeringsstrategier klassificeras enligt följande: Systemkategorier Beskrivning Händelsestyrt Händelser bearbetas momentant då de uppstår. Bearbetning av flera samtidiga händelser sker parallellt. Cykliskt Aktiviteter bearbetas enligt ett sekventiellt schema som upprepas kontinuerligt. Tabell 2-3 Klassificering av olika implementeringsstrategier. Observera att ett system kan vara en kombination av dessa kategorier. Ett system kan vara både händelsestyrt och cykliskt. Det är uppenbarligen en stor skillnad på olika system enligt ovanstående tabeller, till exempel mellan ett snabbt, cykliskt system med strikta deadlines och ett långsamt händelsestyrt system med mjuka deadlines. Ytterligare synpunkter på systemkategoriseringen Vissa starkt cykliska applikationer, ofta av DSP-karaktär, där allting är cykliskt kan snarast sägas vara av filterkarraktär. I dessa applikationer kan ofta all tillgänglig tid planeras (nästan 100% CPU-utnyttjande). Oftast behöver inte avbrott användas. Denna typ av applikationer anser vi inte tillhöra gruppen realtids-applikationer trots att de ofta förekommer där det finns stränga tidskrav. Den typiska realtidsapplikationen har en stark koppling till avbrott. Ofta är karaktären av typen kontroll-applikation, i det att den kontrollerar andra förlopp som ofta varierar över tiden. Dessa typer av system kallas ofta för reaktiva system (reactive systems). Händelserna i dessa reaktiva applikationer är ofta avbrottsstyrda och obestämda i tiden och när de inträffar krävs en deterministisk reaktion från realtidsapplikationen. Reaktiva system har oftast en mycket högre nivå av komplexitet än de cykliska. Om kraven på determinism är höga och det samtidigt förekommer många oförutsägbara asynkrona avbrott kan det vara en utmaning att konstruera denna typ av system och speciella prioriterings-algoritmer kan behöva användas för att kunna garantera worst case - svarstider. Applikationer kan ofta utnyttja sin cykliskhet till att planera arbete under sin cykel. Däremot sker ändå synkroniseringen mot de yttre cykliska förloppen direkt eller indirekt via avbrott. Dessutom kan dessa applikationer därutöver ha ytterligare avbrottsstyrda händelser som kan ha högre prioritet och därmed påverka och försvåra det cykliska arbetet. Sammantaget gör detta att denna typ av applikationer ändå ibland implementeras utan att cykliskheten utnyttjas alltför mycket, eller t.o.m. inte alls. I andra fall kan denna typ av applikationer använda prioriteringen mellan applikationens processer (tasks) för att garantera svarstiden (jfr. rate monotonic algoritmen). I många system som endast behöver uppfylla mjuk realtid är det tillräckligt att beakta den genomsnittliga svarstiden, något som absolut inte är tillräckligt för system för hård realtid. 5

6 Självklart har alla operativsystem, som gör anspråk på att kunna härbärgera realtidsapplikationer, olika prioriteringsalgoritmer och OS-primitiver som uppfyller realtidskrav. Detta innefattar t.ex. preemptive scheduling, priority inversion och att det går att kontrollera prioriteringar, köordningar m.m. i anropen till primitiverna. 6

7 3 Mekanismer/Egenskaper Ett realtidssystem har krav på egenskaper som systemet måste ha. För att uppfylla dessa krav är det nödvändigt att komponenterna som systemet är uppbyggt av också har ett antal egenskaper. I utvärderingsmodellen beaktas de egenskaper som beskrivs nedan. Observera att egenskaperna inte är oberoende av varandra. Den allmänna egenskapen modifierbarhet, till exempel, beror i stor utsträckning på vilken struktur en komponent har och för att möjliggöra en bra struktur finns till exempel de objektorienterade egenskaperna arv och inkapsling. 3.1 Allmänna egenskaper Komplexitet hur stort och (o)begripligt systemet är. Implementerbarhet hur lätt det är att implementera en viss typ av tjänst på en plattform. Modifierbarhet hur lätt det är att ändra eller lägga till funktionalitet till systemet. Portabilitet hur enkelt systemet/applikationen går att flytta till en annan plattform. Skalbarhet hur lätt det är att utöka systemet med nya instanser av komponenter som redan ingår. Robusthet hur stora förändringar från omvärlden som systemet klarar innan påverkan på funktionaliteten blir oacceptabel. 3.2 Objektorienteringsegenskaper Polymorfism möjligheten att implementera metoder (procedurer och funktioner) som fungerar för olika typer av data. Dynamisk bindning möjligheten att vänta med bindningen mellan operationsnamn och dess implementering till exekveringstillfället (run-time). Arv möjligheten att strukturera data på ett utbyggbart sätt. Tillsammans med polymorfism används arv för att underlätta återanvändning av kod. Aggregering möjligheten att beskriva att en klass är sammansatt av andra klasser eller sätta samman objekt så att de bildar ett nytt objekt på en högre nivå. Inkapsling möjligheten att strukturera data så att användning och implementering särskiljs. Med en väl genomförd inkapsling skall många ändringar av implementeringen kunna genomföras utan att användningen av data behöver ändras. Objektinstansiering möjligheten att dynamiskt kunna skapa flera instanser av ett objekt. 7

8 3.3 Realtidsegenskaper Tidsåtgång är den viktigaste egenskapen i realtidssystem. Mäts i olika former t.ex. exekveringstid, åtkomsttid och allokeringstid. Resurshantering hur de (oftast) begränsade resurserna utnyttjas i systemet. Exempel på resurser är processorkapacitet och minne. Determinism förutsägbarhet avseende tidsåtgång och resurshantering. Jitter maximum av den från gång till gång varierande fördröjningen mellan teoretisk starttid och faktisk starttid. Konfigurerbarhet möjlighet att variera systemets beteende. Konfigurationskrav krav att konfigurera systemets beteende i detalj. Latens tiden från en begäran till dess att begäran är uppfylld. 8

9 4 Modellen Modellen definierar tre klasser/dimensioner av alternativa vägval som måste beaktas vid utveckling av realtidssystem, se Figur 4-1. Den syftar till att tjäna som verktyg för att ta fram rekommendationer och beslutsunderlag då olika kombinationer övervägs. Modellen är flexibel genom att ta bort eller utöka mängden konstruktionsfall, språk och plattformar. Konstruktionsfall Språk Plattform Figur 4-1 Modellen De tre klasserna/dimensionerna i modellen har följande betydelse: Språk beskriver en mängd olika programmeringsspråk. Plattform beskriver en mängd olika kombinationer av middleware, operativsystem och hårdvara. Konstruktionsfall beskriver en mängd olika typkonstruktioner. Varje konstruktionsfall tydliggör en eller flera egenskaper i systemet eller egenskaperna för en mekanism. Konstruktionsfallen är generella och kan appliceras på valfri plattform och språk, även på framtida sådana företeelser. Genom att applicera ett konstruktionsfall på alla kombinationer av plattformar och språk, dvs täcka ett horisontellt plan i figuren ovan, kan olika plattformar och språk jämföras med varandra. För att undersöka egenskaperna hos en specifik kombination av språk och plattform, implementeras samtliga konstruktionsfall i det valda språket på den valda plattformen. I praktiken är det omöjligt att täcka alla kombinationer av rymden som definieras av modellen. En del konstruktionsfall kanske inte går att implementera på alla plattformar. Framför allt är det ointressant att lägga ner tid på en absurda kombinationer. För att kunna jämföra plattformar med varandra är det dock viktigt att ett antal konstruktionsfall spänner över de plattformar som ska jämföras. Detsamma gäller om flera språk ska jämföras. Att jämföra olika konstruktionsfall med olika språk är heller inte meningsfullt. 9

10 Rekommendationer för val av plattform och/eller språk görs genom att realisera modellens konstruktionsfall med hjälp av ett antal kandiderande språk och plattformsalternativ. Resultaten analyseras därefter med avseende på de önskade realtidsegenskaperna. 4.1 Språk Modellen skall appliceras på en mängd olika språk vilket betyder att konstruktionsfallen skall implementeras i de olika språken. De språk som först och främst avses innehåller objektorienterade mekanismer, vilket alltså inte nödvändigtvis är detsamma som objektorienterade språk. De mekanismer som ska finnas är implementeringsstöd för arv, polymorfism, inkapsling och instantiering. Dessa mekanismer är typiska för objektorienterad design och räcker för att enkelt kunna implementera en sådan design. Objektorienterade språk har förutom ovanstående mekanismer begrepp som klass och objekt. Tyvärr har begreppet objekt en tvetydig betydelse och kommer därför inte att användas i det fortsatta resonemanget. Istället används begreppen klass och instans. Naturligtvis går det att tillämpa utvärderingsmodellen på icke objektorienterade språk som helt saknar objektorienterade mekanismer. Då blir man tvungen att på egen hand realisera/implementera ovan definierade mekanismer. 4.2 Plattformar Med begreppet plattform menar vi kombinationen av de komponenter som används för att exekvera ett konstruktionsfall som är implementerat i ett programmeringsspråk. Exempel på olika sorters plattformskomponenter är: Hårdvara (processorer, bussar, etc.), Operativsystem (t.ex. Windows, Linux, VxWorks, EPOC, etc), Middleware (t.ex. CORBA, RMI, RPC, etc.), Även operativsystemen kan indelas i olika klasser, se Tabell 4-1. Operativsystemstyp Beskrivning DesktopOS Operativsystem som i första hand utvecklats för hantering av t.ex. administrativa applikationer, utvecklingsmiljöer för programvara eller hårdvara. Systemen erbjuder en rik flora av fönstersystem, kommunikationstjänster, och andra stödsystem. Exempel på operativsystem med dessa egenskaper är Windows och Solaris. RealtidsOS (RTOS) Specialiserade OS Operativsystem som i första hand utvecklats för att hantera stränga realtidskrav t.ex. reglersystem för flygplan. Exempel på operativsystem med sådana egenskaper är OSE, VxWorks och psos. Operativsystem som i första hand utvecklats för att stödja realisering av komponenter inom speciella områden t.ex. utveckling av DSP:er och smart-cards. Tabell 4-1 Klassificering operativsystem 10

11 Olika plattformar ger olika mycket stöd för de konstruktionsfall som ska implementeras. I Figur 4-2, illustreras fyra sätt att implementera ett konstruktionsfall. a) OS med få stödfunktioner, största delen av konstruktionsfallet implementeras på egen hand. b) OS med många stödfunktioner alternativt samma OS som i a men med extra hjälpprogramvara (t.ex. något middleware). En delar av implementeras fortfarande på egen hand. c) Inköpt programvara har utnyttjats så mycket det går för realisering av det önskade konstruktionsfallet. d) Inköpt programvara erbjuder det önskade konstruktionsfallet. Heldragna pilar symboliserar inköpt plattform och streckade pilar den del man måste implementera själv. Konstruktionsfall a b c d Maskin Figur 4-2 Arbetsinsats vid implementering av konstruktionsfall på olika plattformstyper Förutom dessa fyra alternativ finns även ett femte: implementera även operativsystemet (eller de nödvändiga funktionerna) själv. 4.3 Konstruktionsfall För att utvärdera olika egenskaper implementeras ett antal konstruktionsfall byggda på mönster. Eftersom samma konstruktionsfall implementeras på olika plattformar och i olika språk kan resultaten från de olika plattformarna/ språken jämföras Områden Konstruktionsfallen är uppdelade i följande områden: Processhantering Konstruktionsfall för utvärdering av synkronisering och möjligheter att styra schemaläggning. 11

12 Minneshantering Konstruktionsfall för utvärdering av olika sätt att hantera minne, t ex statisk allokering, dynamisk allokering och garbage collection. Modularisering och strukturering Konstruktionsfall för att utvärdera modulariserings- och metoder för strukturering. Kommunikation och distribution Konstruktionsfall för att utvärdera kommunikations- och distributionsmetoder Konstruktionsfallsmall Konstruktionsfall definieras av ett antal beskrivningar med tillhörande rubriker: Namn beskrivande namn på konstruktionsfallet. Efter namnet följer en motivering till varför konstruktionsfallet är av intresse i sammanhanget Beskrivning beskrivning av konstruktionsfallet genom exempel på typapplikation. Beskrivningen innehåller nödvändig information om konstruktionsfallet som inte passar under de andra rubrikerna. Struktur definieras i första hand med UML-diagram [13]. Strukturen kan även hänvisa till kända mönster som i så fall ska följas. I de fall funktionaliteten för ingående klasser/objekt inte anses självklar efter den ovan nämnda beskrivningen finns en mer detaljerad beskrivning. Implementering mer detaljerade krav på implementeringen av konstruktionsfallet för att få implementationerna i olika språk på olika plattformar så lika som möjligt. Testfall hur systemet ska testas med hjälp av konstruktionsfallet. Mätningar vad som ska mätas under testerna. 12

13 5 Mätningar och resultat För att mätningar på en implementering av ett konstruktionsfall ska kunna jämföras med mätningar på andra implementeringar måste mätningarna utföras enligt en gemensam mall. Vissa anvisningar som är specifika för konstruktionsfallet finns specificerat i respektive konstruktionsfall. Utöver de specifika anvisningarna gäller instruktionerna i 5.1. Resultaten av mätningarna ska sedan tolkas enligt Generella instruktioner testfall Nedanstående instruktioner gäller samtliga testfall om inget motstridigt står angivet i testfallet. Vid motstridigheter gäller anvisningarna i testfallet. Mät i stabila tillstånd Under uppstart och ändring av parametrar beter sig systemet oftast annorlunda än i stabila tillstånd. Mätningarna i denna rapport är avsedda att utföras när systemets beteende är stabilt. Upprepa mätningarna Genom att upprepa mätningarna undviks resultat som beror på ej önskvärda transienta störningar. Efter ett antal upprepade mätningar bör majoriteten av mätresultaten ligga inom en liten felmarginal. Rapportera spridning i resultatet Spridning mellan mätresultaten förekommer alltid. En stor spridning kan bero på faktorer i plattformen som inte kan påverkas eller att påverkande faktorer inte kontrollerats under mätningarna. Variera parametrar Variera parametrar och undersök hur mätningarna påverkas. Mätningarna kan påverkas av en parameter som inte anses ha någon betydelse. Parametrar som påverkar resultatet bör ensas för att resultaten ska kunna jämföras. Om resultatet inte påverkas av en parameter som borde påverka systemet kan mätmetoden vara felaktig. Kontrollera att mätmetoden inte påverkar Vid mätning i ett system påverkas alltid systemet. För att få ett korrekt resultat av en mätning måste en mätmetod med minimal inverkan på resultatet användas. Variera parametrar och uppskatta rimligheten i mätresultaten. Sök förklaringar Mätresultat som inte blir som förväntat bör förklaras. Om orsaken inte kan åtgärdas är sambandet mellan orsak och verkan ett användbart resultat i sig. Går orsaken att åtgärda kan mätningarna göras om med bättre resultat. 13

14 5.2 Tolkning av resultat Utvärdering av en plattform eller språk enligt modellen i denna rapport är tänkt att ge fyra typer av resultat. Mätningarna på de olika implementeringarna av konstruktionsfallen kommer att ge en mängd värden. Dessa värden är resultat i sig och ger för den insatte en bild av de olika egenskaperna hos plattformarna och språken. För att underlätta kunskapsspridning bör mätvärdena även tolkas och översättas till termer av egenskaper och beteende. En jämförelse av egenskaperna och beteendet hos det utvärderade systemet med de egenskaper som krävs av de olika typerna av realtidssystem som diskuterats tidigare ger möjlighet att sprida resultaten till en bredare publik. Ett annat mycket viktigt resultat är de erfarenheter som framkommer under arbetet med utvärderingen. En femte typ av resultat fås om flera plattformar och språk utvärderas och jämförs. 14

15 6 Konstruktionsfallsområde: Processhantering I realtidssammanhang är det bara de allra enklaste systemen som består av en enda process. Det vanliga är att system består av ett antal processer som skall exekveras på ett antal processorer där antalet processer överskrider antalet processorer. Detta leder till att flera processer exekverar på samma processor och därmed konkurrerar om tid att exekvera på. Beteendet hos systemet beror på: 1. hur processorns tid delas mellan processerna, d.v.s. om processerna exekverar enligt en förutbestämd (cyklisk) ordning eller om flera exekverbara processer konkurrerar. 2. hur nästa process som får exekvera väljs ut, d.v.s. vilken av de vid tillfället exekverbara processerna som står i tur att exekvera. 3. hur länge en process får exekvera, d.v.s. om processen får exekvera tills den inte kan fortsätta exekvera eller om den blir avbruten. Processerna i ett system där samtliga processer ska exekvera cykliskt på en processor enligt ett förutbestämt schema kan slås ihop till en process som exekverar cykliskt. Det enda kravet ett sådant system ställer på plattformen är att den klarar av att hantera en cyklisk (periodisk) process. I system där flera processer är exekverbara samtidigt och konkurrerar med varandra om tiden används ofta prioriteter för att avgöra vilken process som ska exekvera. Vilken prioritet en process har och hur prioriteten används varierar beroende på språk och plattform. Konstruktionsfallen i detta kapitel syftar till att undersöka hur plattform och språk hanterar processer i olika sammanhang. De två första konstruktionsfallen är inriktade på hantering av periodiska processer; det första huruvida plattformen kan hantera periodiska processer och det andra konstruktionsfallet vilka olika schemaläggningsalgoritmer som kan användas. En annan typ av processer som är vanliga i realtidssystem är processer som ska exekvera vid avbrott vilka behandlas i det tredje konstruktionsfallet. Resterande konstruktionsfall är inriktade på hantering av prioriteter i olika situationer; placering i köer, prioritetsinvertering, antal tillgängliga prioritetsnivåer samt inläsning och utskrift. 15

16 6.1 Implementering av periodisk process För att undvika dynamik i realtidssystem, och därmed få större kontroll över systemets beteende, väljer man ofta att polla indata och beräkna utdata periodiskt istället för att beräkna utdata när indata har ändrats. En del applikationer, till exempel styrsystem, som innehåller kontroll-loopar lämpar sig väl för en sådan implementering. Detta konstruktionsfall avser att undersöka hur plattformen hanterar en periodisk process Beskrivning I moderna flygplan styr man inte höjd- och skevroder direkt med styrspaken utan via en dator. Datorn hämtar periodiskt information om höjd, hastighet, stigningsvinkeln, pådrag på motorerna, mängden kvarvarande bränsle, utsläpp från motorerna, pilotens inställningar och utslag på styrspaken. Med hänsyn till alla dessa och ett antal andra parametrar ställer man in höjd- och skevroder, pådrag på motorerna, bränsleblandning mm. Detta är ett exempel på en reglerloop som med fördel implementeras som en periodisk process som läser av inställningar och styrutrustningens lägen, beräknar nya värden och lägger ut de nya värdena Struktur Ett lämpligt mönster att utgå ifrån är Control loop [4]. Process * Sensor {abstract} GetValue() SensorImpl GetValue() 1 ControlLoop Initialize() Shutdown() Step() 1 * Actuator {abstract} SetValue() ActuatorImpl SetValue() Figur 6-1 Objekt-/klassdiagram kontroll-loop Systemet styrs av en process som exekverar en oändlig loop där ett nytt varv påbörjas med ett bestämt tidsmellanrum. Varje varv anropas metoden step i klassen ControlLoop. I metoden step hämtas värden från samtliga sensorer (av klassen SensorImpl), nya värden för ställdonen beräknas och sätts i respektive ställdon (av klassen ActuatorImpl). För att enkelt kunna byta ut sensorer och ställdon, har abstrakta klasser införts som gränssnitt mot dessa (Sensor respektive Actuator). 16

17 6.1.3 Implementering Implementera en kontroll-loop enligt struktur ovan. Alla referenser till sensorer och ställdon i klassen ControlLoop skall vara referenser till de abstrakta klasserna. Exekveringstiden samt perioden i loopen skall vara konfigurerbar. Observera att fördröjningar för att förlänga exekveringstiden måste vara av typen busy-wait, d.v.s. processen ska vara upptagen med arbete. Fördröjningar i processen för att åstadkomma en längre period måste däremot vara inaktiv väntan. Antalet sensorer och ställdon anpassas för att få en algoritm i loopen med lagom komplexitet. Det bör finnas sensorer och ställdon av olika typer. Algoritm TBD Testfall 1. Olika lång period. Variera perioden samtidigt som exekveringstiden hålles konstant. Upprepa med några olika exekveringstider. 2. Olika lång exekveringstid. Håll perioden konstant och variera exekveringstiden. Upprepa med några olika periodlängder Mätningar Utvecklingstid Uppskatta hur lång tid det tar att implementera en kontroll-loop på detta sätt jämfört med att utveckla samma kontroll-loop utan objektorientering. Undersök hur lång tid tar det att byta ut en sensor. Jitter Mät tiden och spridningen i tid från när exekveringen av ett varv ska börja tills exekveringen startar. Kontrollera att tiden inte ökar för varje varv. Faktisk exekveringstid Mät tiden från när exekveringen i ett varv börjar till när den slutar. Kontrollera om den är konstant (vilket den borde vara) eller om processen avbryts av andra sporadiska processer. Påverkan Undersök om jitter och faktisk exekveringstid beror på periodens längd och/eller (inställd) exekveringstid. 17

18 6.2 Schemaläggning periodiska processer Detta konstruktionsfall syftar till att undersöka möjligheter till olika schemaläggning av periodiska processer Beskrivning Ett antal processer med olika periodicitet och exekveringstid schemaläggs enligt ett antal olika algoritmer för att undersöka hur enkelt/svårt det är att påverka schemaläggningen och hur bra olika algoritmer fungerar på plattformen Struktur Systemet består av fem processer med olika periodicitet, exekveringstid, deadlines och prioriteter. Process 1 har exekveringstid 1x och period p/6. Process 2 har exekveringstid 1x och period p/4. Process 3 har exekveringstid 2x och period p/3. Process 4 har exekveringstid 2x och period p/2. Process 5 har exekveringstid 4x och period p. Deadline för samtliga processer är slutet på perioden. Med rate monotonic scheduling [6] är systemet schemaläggningsbart enligt Figur ruta = 1x Figur 6-2 Processerna schemalagda med p = 24x med rate monotonic scheduling Implementering Implementera fem processer med exekveringstid enligt ovan så att x kan varieras. Perioden enligt ovan (p = 24x) skall hanteras som en minsta möjliga (teoretisk) period. Vid exekvering av systemet skall perioden p (och därmed perioderna för de enskilda processerna) kunna ändras mellan exekveringarna Testfall Utför följande testfall med olika schemaläggningsalgoritmer, t.ex.: rate monotonic, earliest deadline first och round robin [6], [11]. 1. Lång period, långa exekveringstider. Välj ett relativt stort värde på x. Sätt p mycket större än 24x så att alla deadlines uppfylls lätt. 2. Minska perioden. Minska perioden p successivt tills minst en deadline inte klaras. 18

19 3. Kort exekveringstid Gör om 1 och 2 med litet värde på x Mätningar Jitter Mät tiden och spridningen i tid från när exekveringen av en process ska börja tills exekveringen startar. Ändrad schemaläggningsalgoritm Undersök hur enkelt/svårt det är att byta schemaläggningsalgoritm. Prova både egenhändigt implementerade algoritmer och algoritmer tillhandahållna av systemet (om några). Upplösning på tiden Undersök hur jitter, exekveringstider och minsta möjliga period varierar vid olika lång exekveringstid. Kontrollera vilken upplösning på tiden som används i systemet. Periodlängd Mät upp kortast möjliga faktiska periodlängd. Undersök orsaken till skillnaden mellan kortaste uppmätta period och kortaste teoretiska period. Exekveringsordning Kontrollera att processerna exekverar i den ordning de borde enligt aktuell schemaläggningsalgoritm. Default schemaläggningsalgoritm Ta redo på vilken schemaläggningsalgoritm som är default i systemet. 19

20 6.3 Avbrottshantering En speciell typ av processer är de som skall exekvera vid avbrott. Till skillnad från processer som exekverar kontinuerligt (med eventuell väntan) skapas och startas dessa processer av systemet när ett avbrott sker och tas bort när avbrottet behandlats. För att detta skall fungera måste dessa processer göras kända för systemet. Om och hur det görs behandlas i detta konstruktionsfall Beskrivning En enkel process ska implementeras och läggas in som avbrottsrutin i systemet Struktur Strukturen består av en enda process som ska exekveras som avbrottsrutin Implementering Implementera en process som gör något detekteringsbart. Om plattformen eller det valda sättet att generera avbrott har specifika krav på nollställning av avbrottet måste dessa uppfyllas. Avbrottet ska vara av sådan sort att systemet i sig inte avbryter avbrottsrutinen Testfall 1. Avbrott Se till att avbrott genereras med jämna mellanrum Mätningar Utvecklingstid Uppskatta hur enkelt/svårt det är att skapa en avbrottsrutin. Exekveringsstart Mät tiden och spridningen i tiden mellan avbrottet och start av avbrottsrutinen. Exekveringstid Mät tiden från exekveringsstart tills processen har exekverat klart. 20

21 6.4 Hantering av semaforköer En process med högre prioritet ska gå före en process med lägre prioritet om de väntar på samma semafor oavsett i vilken ordning de begärde semaforen. På grund av kömekanismer eller för att undvika svält kan det på en del plattformar hända att processen med lägre prioritet får gå före [5], [6] Beskrivning Exekveringsordningen testas genom att implementera två processer med åtkomst till samma semafor. Den ena processen har hög prioritet, tar, väntar och släpper semaforen tre gånger i rad utan att vänta mellan gångerna och väntar sedan en stund innan den börjar om. Den andra processen har lägre prioritet, exekveras kontinuerligt och tar och släpper semaforen ofta. På en plattform som hanterar kön till semaforen på rätt sätt kommer processen med högre prioritet att exekvera färdigt innan den andra processen får fortsätta exekvera Struktur Strukturen är mycket enkel och består av två processer och en gemensam semafor enligt Figur 6-3. process A process B High priority Synchronization through common semaphore Low priority Figur 6-3 Process-struktur 21

22 6.4.3 Implementering Processerna implementeras enligt nedanstående pseudokod. Process A() { SetPriority(high); Signal(Semaphore); Loop Wait(1000); For (i=0; i<3; i++) { Wait(Semaphore); PutString( A ); WaitTime(1000); Signal(Semaphore); } } } Process B() { SetPriority(low); Loop Wait(Semaphore); PutString( B ); WaitTime(330); Signal(Semaphore); } } Testfall 1. Med utskrift Exekvera processer enligt ovan och kontrollera att processen med hög prioritet får exekvera färdigt innan processen med låg prioritet för exekvera (utskrift BBBBAAABBBBAAABB...). 2. Utan utskrift Tag bort utskriftssatserna och kontrollera på något annat sätt i vilken ordning processerna exekverar. Studera om exekveringsordningen ändras. 3. Annan synkronisering Byt ut synkroniseringsmekanismen mot t.ex. ett skyddat objekt eller monitor Mätningar Exekveringstid och ordning Kontrollera i vilken ordning processerna exekverar och deras exekveringstid (ett varv i loopen) samt spridningen i exekveringstid. Utskrift Undersök hur mycket utskrifterna påverkar beteendet. Synkroniseringsmekanismer Undersök vad som skiljer i tid och beteende mellan olika synkroniseringsmekanismer. 22

23 6.5 Förekomst av prioritetsinvertering Detta konstruktionsfall studerar ytterligare ett fall där processer kan komma att exekveras i en felaktig ordning [7]. Orsaken i detta fall är att en process med låg prioritet håller en resurs som en process med hög prioritet behöver tillgång till, och därmed hindrar exekvering av processen med hög prioritet Beskrivning För att undersöka detta fall behövs tre processer med hög, medelhög respektive låg prioritet. Processerna med hög och låg prioritet behöver båda exklusiv tillgång till en och samma resurs. Antag att processen med låg prioritet har exklusiv tillgång till resursen när processen med medelhög prioritet börjar exekvera. Processen med medelhög prioritet avbryter då processen med låg prioritet. Antag sedan att processen med hög prioritet ska exekveras. Processen med hög prioritet avbryter processen med medelhög prioritet och exekverar tills den behöver tillgång till den gemensamma resursen som är låst av processen med låg prioritet. Om detta fall inte specialbehandlas är det bara processen med medelhög prioritet som kan exekvera, vilket betyder att processen med hög prioritet får vänta på processen med medelhög prioritet Struktur Systemets struktur med dess tre processer och gemensamma resurs (semafor) visas i Figur 6-4. process C Medium priority process A process B High priority Synchronization through common semaphore Low priority Figur 6-4 Process-struktur Implementering Implementera 3 processer med olika prioritet (låg, medel, hög). Processen med låg prioritet håller en resurs större delen av tiden. Samma resurs skall begäras av processen med hög prioritet. Processen med medel prioritet får inte använda sig av resursen. Se till att processerna är redo för exekvering i prioritetsordning med den lägsta prioriteten först. 23

24 6.5.4 Testfall 1. Exekvera processerna Exekvera processerna enligt implementering ovan. 2. Serveranrop Byt synkronisering via semafor till anrop till server med kritisk region. Exekvera processerna med olika prioritetsnivåer på servern Mätningar Utvecklingstid Uppskatta hur enkelt/svårt det är att implementera processer. Exekveringstid Mät hur lång tid det tar att exekvera de tre processerna. Exekveringsordning Undersök i vilken ordning processerna exekveras. Undersök möjligheterna att påverka beteendet. Väntetid Mät hur länge processen med hög prioritet får vänta och spridningen i väntetid. Prioritet på servern Undersök vilken prioritet servern bör ha för att processerna ska exekvera i rätt ordning och om serverns prioritet ändras under exekvering. 24

25 6.6 Maximalt antal användbara prioritetsnivåer Många schemaläggningsalgoritmer använder prioriteter för att bestämma exekveringsordningen. Ett exempel är rate monotonic scheduling som använder en prioritetsnivå för varje periodlängd. För schemaläggningsalgoritmer som kräver många prioritetsnivåer kan antalet prioritetsnivåer som är tillgängliga hos plattformen bli begränsande för antalet processer Beskrivning Hur bra en plattform klarar att hantera ett antal prioritetsnivåer kan testas genom att exekvera ett system bestående av processer med ett stort antal olika prioritetsnivåer Struktur Systemet ska byggas upp av ett antal oberoende processer. Vilken process som exekverar ska bestämmas endast av processernas prioritetsnivåer och inte av beroenden mellan processerna. En schematisk bild på systemets struktur visas i Figur 6-5. process 1 process 2 process 3... process N Priority 1 Priority 3 Priority N Priority 2 Figur 6-5 Process-struktur Implementering Implementera ett system med konfigurerbart antal processer och med konfigurerbart antal processer per prioritetsnivå. Processerna får ej innehålla inläsning eller utskrifter om det finns minsta misstanke om att det skulle kunna påverka prioriteterna. Samtliga processer ska exekvera periodiskt (samma period) och bli exekverbara samtidigt. Perioden ska vara så lång att systemet blir schemaläggningsbart Testfall 1. Prioritetsnivåer Exekvera ett antal (5 50) processer med olika prioritetsnivåer. 2. Processer per prioritetsnivå Utöka systemet med att antal (1 5) processer per prioritetsnivå. 25

26 6.6.5 Mätningar Exekveringsordning Kontrollera att processerna exekverar i rätt ordning. Antal prioritetsnivåer Undersök hur många prioritetsnivåer en användare/utvecklare har tillgång till. Hantering av prioritetsnivåer Undersök hur många prioritetsnivåer plattformen använder internt och hur en eventuell översättning från användarens/utvecklarens prioritetsnivåer till de interna prioritetsnivåerna görs. 26

27 6.7 Hantering av processer vid inläsning och utskrift En del plattformar har speciell hantering av processer som läser in från eller skriver ut till skärm. Till exempel kan sådana processer exekveras med annan prioritet än den satta på grund av just inläsning/utskrift. En annan underlig hantering är att klassa en process som väntar på indata (från terminal) som exekverbar under väntetiden. Detta får till effekt att systemet under långa perioder kan stå helt stilla även om det finns processer som skulle kunna exekvera utan att vänta Beskrivning Ett exempel som testar detta är följande: Systemet består av tre processer och två buffertar. Process A läser från terminal och lagrar data i Buffer 1. Process B hämtar data från Buffer 1 och lägger in data i Buffer 2. Process C slutligen hämtar data från Buffer 2 och skriver ut den på skärmen. Det förväntade beteendet är att det man skriver in ekas tillbaka inom en (mycket) kort tid Struktur Figur 6-6 visar systemets struktur med de tre aktiva objekten (processerna) samt de två passiva datalagringsobjekten (buffertarna). process A buffer 1 process B buffer 2 process C Figur 6-6 Process- och objektstruktur Implementering Implementera ett system enligt beskrivningen och strukturen ovan. Processerna skall avslutas när man skickar EOF (Ctrl-D). Prioriteterna på processerna skall vara konfigurerbara Testfall 1. En prioritetsnivå Exekvera systemet med samma prioritet på alla tre processerna. 2. Två prioritetsnivåer Exekvera systemet med högre/lägre prioritet på en av processerna. Testa för olika processer. 3. Tre prioritetsnivåer Exekvera systemet med olika prioritet på processerna. Variera prioritetsordningen. 27

28 6.7.5 Mätningar Latens Mät tiden (och spridningen i tiden) det tar för olika mängd data att passera igenom systemet. Exekveringsordning Kontrollera i vilken ordning processerna exekverar. Prioriteter Undersök om processerna exekverar med den givna prioriteten. Om annan prioritet förklara varför. 28

29 7 Konstruktionsfallsområde: Minneshantering Problem inom området minneshantering hanteras i realtidssystem på ungefär samma sätt som inom övriga områden. För konstruktören är det, som så många andra gånger, en avvägning mellan generella verktyg och specialsydda lösningar. Fördelar med generella verktyg är att: 1. de ofta redan finns implementerade, vilket medför billigare utvecklingskostnader (COTS) 2. de generella verktygen används av många, vilket ofta medför att de är mer uttestade och tenderar till att fungera bättre än egna lösningar Nackdelarna är bland annat att: 1. man inte kan använda speciell kunskap om det enskilda problemet vilket medför att den generella lösningen därför kan bli alltför kostsam resursmässigt 2. man kan ha dålig kunskap om den generella lösningen vilket gör att man inte vågar använda den eftersom man inte kan prediktera vilka resurser som behövs. Den dåliga kunskapen kan bero på att man inte har tillgång till alla detaljer (t.ex. källkod) eller att man helt enkelt inte har tid och/eller kunskap att sätta sig in i produkten. Inom realtidssystem är resurser i fråga om tid och minne många gånger mycket knappa vilket gör att speciallösningar blir mer vanliga än annars. Dessutom är predikterbarhet en önskvärd egenskap vilket gör att de generella lösningarna många gånger inte duger. När det gäller minneshantering så skall generella lösningar på både allokerings- och deallokerings-problemet bedömas. I första och tredje konstruktionsfallet mäts skillnaden i allokerings- och deallokerings-tid mellan en konventionell och en objektorienterad lösning. I konstruktionsfall tre allokeras minnet i en mer godtycklig ordning än i första fallet, detta fall är tänkt att försöka mäta i vilken utsträckning fragmentering av minnet kan påverka resursåtgången. I det andra konstruktionsfallet mäts skillnaden mellan stackallokering och heapallokering av minne. 29

30 7.1 Dynamisk allokering/deallokering av minne. Det förekommer ofta att objekt måste allokeras under exekvering, det går helt enkelt inte att i förväg bestämma hur många instanser som måste allokeras. Det är därför viktigt att ta reda på hur objektorienterade egenskaper påverkar allokeringstiden Beskrivning Detta konstruktionsfall försöker mäta hur mycket mer tid och minne som krävs för att allokera instanser av olika klasser (med vissa OO-egenskaper som exempelvis arv) jämfört med att enbart allokera data i en post som är brukligt i icke OO-språk Struktur Programmets struktur kommer att vara ganska enkel. För att få en någorlunda rättvis jämförelse behövs det dock ett antal klasser. Dessa kan förslagsvis se ut enligt (pseudo kod): OO Class1 { private type1 a1, a2; private type2 a3; private type3 a4; public get/set a1; public get/set a2; public get/set a3; public get/set a4; } Class2 extends Class1 { private type1 a5; private type2 a6; public get/set a5; public get/set a6; } Class3 extends Class2 { private type4 a7; public get/set a7; } Icke OO Struct class1 { type1 a1, a2; type2 a3; type3 a4; } get/set a1; get/set a2; get/set a3; get/set a4; Struct class2 { type1 a1, a2, a5; type2 a3, a6; type3 a4; } get/set a1; get/set a2; get/set a3; get/set a4; get/set a5; get/set a6; Struct class3 { type1 a1, a2, a5; type2 a3, a6; type3 a4; type4 a7; } get/set a1; get/set a2; get/set a3; get/set a4; get/set a5; get/set a6; get/set a7; Tabell 7-1 Exempel på en arvsstruktur och dess motsvarighet i icke OO-språk Dessa objekt kommer att användas genomgående i detta kapitel. 30

31 7.1.3 Implementering Implementeras på lämpligt sätt för att uppfylla testfallen (se nedan). Deallokeringen av instanser kan görs på tre olika sätt för att ge en bild av hur OS/implementeringsspråk optimerar sitt minne. 1. Instanserna deallokeras i samma ordning som de allokerats (FIFO). 2. Instanserna deallokeras i bakvänd ordning som de allokerats (LIFO). 3. Instanserna deallokeras i slumpvis ordning. För att inte val av slumptalsalgoritm ska påverka resultaten på något sätt bör en egen enkel slumptalsgenerator implementeras, exempelvis enligt [9]: X n+1 = a*x n + b (mod m) där konstanternas värden kan vara a = b = m = 2 15 X 0 = 1234 I objektorienterade språk anropas en konstruktor vid instantieringen av en klass. Denna konstruktor har till uppgift att göra, för den specifika instansen, nödvändiga initieringar, exempelvis tilldela alla variabler initialvärden. För att kunna göra rättvisa mätningar mellan OO-implementeringar och icke OO-implementeringar måste därför en av följande åtgärder vidtagas: 1. Klasserna implementeras utan konstruktorer. 2. Tiden för allokering av objekt inkluderar tilldelning av initial data till variablerna i posten Testfall 1. Allokering och deallokering av enskilda instanser av Class3 utan arv. Detta testfall görs för att få en uppfattning om hur lång tid det tar att allokera/deallokera en instans resp. en post i olika typer av språk, samt hur mycket minnesutrymme som går åt i de båda fallen. 2. Allokering och deallokering av enskilda instanser av Class3 med arv. Samma testfall som ovan, men de allokerade instanserna har några arvsnivåer. Frågan som förhoppningsvis får ett svar i detta testfall är hur mycket arvet påverkar allokeringstid och minnesutrymmet. Föregående testfall ger en referens för hur allokeringstid och minnesutrymme påverkas. 3. Allokering och deallokering av flera instanser av Class3 utan arv. Detta testfall tvingar fram nyallokering av instanserna. I föregående testfall finns möjligheten att samma minne som just raderades återanvänds direkt (en typ av cache funktion). Effekter av krav på nyallokering av minnessidor från RTsystemet påverkar den totala exekveringstiden. Språk som använder GC kommer att få en chans att åtminstone statistiskt kunna visa sina starka resp. svaga sidor vid deallokering av objekt. För att dessa effekter ska kunna visas bör testfallet upprepas flera gånger utan att testprogrammet startas om. 31

32 4. Allokering och deallokering av flera instanser av Class3 med arv. Som föregående testfall men med arv Mätningar Allokeringstid I de fall då enskilda instanser allokeras mäts tiden för själva allokeringen. Då flera instaser allokeras mäts den totala tiden för allokeringen. Sedan kan resultatet delas med antalet allokerade instanser. Deallokeringstid Mäts på samma sätt som allokeringstiden. Minnesåtgång Hur stor plats i minnet tar de olika elementen, med och utan arv. Är det någon skilnad? 32

33 7.2 Stack vs. Heap Genom att göra funktionsanrop allokeras det ideligen nya variabler på stacken i minnesarean. Hur mycket tid förlorar man på det? Går det fortare att allokera data på stacken än på heapen och i så fall hur mycket. Syftet med detta konstruktionsfall är i första hand att försöka ta reda på detta och mäta skillnader i exekveringstid (och minnesåtgång) när det gäller att allokera på stacken jämfört med att allokera på heapen och hur olika plattformar påverkar detta Beskrivning En typ av algoritmer, som är enkla att implementera och lätta att skala, är sorteringsalgoritmer. Många av dessa algoritmer tillhör klassen Divide and Conquer[10], d.v.s. dela upp problemet i mindre delar och lös delproblemen var för sig. Till dessa hör bl.a. Quicksort[10] och Mergesort[10]. Utav dessa två algoritmer är Mergesort den som är enklast att mäta på, och det är dessutom den som använder mest minne av de båda Struktur Instanser av typen Class1 (se föregående konstruktionsfall) används och jämförelseoperationen sker på ett av medlemsattributen Implementering Implementera Mergesort på några olika sätt och mät exekveringstiden för de olika fallen. För att få någorlunda jämförbara program ska algoritmen implementeras på samma sätt i samtliga fall. Skillnaden är enbart hur de temporära fälten, som krävs i mergesort, allokeras. 1. Allokera ett globalt temporärt fält på stacken som är tillräckligt stor för att rymma alla element som ska sorteras. 2. Allokera ett globalt temporärt fält på heap:en som är tillräckligt stort för att rymma alla element som ska sorteras. Fältet deallokeras i slutet av programmet när sorteringen är klar. 3. Allokera temporära fält på stacken i varje anrop till funktionen merge. Fälten ska vara precis så stora som krävs för att sammanfläta de delfält som merge anropas med. 4. Allokera temporära fält på heap:en i varje anrop till funktionen merge. Fälten ska vara precis så stora som krävs för att sortera de delfält som merge anropas med. Fälten deallokeras i slutet av merge. Algoritmen implementeras enligt: mergesort( in out Array a ) { If length of a > 1 { k length of a / 2; mergesort( a[ 0..k ] ); mergesort( a[ k+1..length of a ] ); merge( a, k ); } } 33