Oplossing mogelijke theorievragen Real Time Systemen

Oplossing mogelijke theorievragen Real Time Systemen Dumon Willem - 4Elicti 2009-2010 Uit elk van de 5 reeksen vragen wordt 1 vraag gesteld. Er kan een oefening ivm berekenen v Schedulability gegeven worden (zonder jitter/blocking) k = kunnen, kan w = worden, wordt m = moeten, moet 1 Reeks 1 1.1 Geef de definitie van real-time systemen. Een real-time systeem is een systeem dat informatie verwerkt en een antwoord geeft binnen een bepaalde tijdspanne. De juistheid hangt dus niet enkel af van het resultaat maar ook van de responstijd. Niet tijdig een antwoord geven is even erg als geen of een fout antwoord. 1.2 Wat betekent hard, soft, real en firm real-time? Hard: systemen waar het absoluut noodzakelijk is dat er een antwoord is voor de deadline verstrijkt. 1 laat antwoord = falen van systeem (hartmonitor, kerncentrale, vlucht controle systemen,...). Soft: systemen waar deadlines belangrijk zijn maar waar het system nog correct blijft functioneren wanneer er een deadline gemist w. 1 laat antwoord = kwaliteitsverlies. Herhaaldelijk missen van deadline = falen v systeem (vluchtreservatiesysteem, data-acquisitiesysteem). Real: harde realtime systemen waar de responstijd zeer kort is (raket sturingen) Firm: combinatie van Hard & Soft = Soft waar data onbruikbaar is als er een late respons is (beademingstoestel: een paar seconden vertraging in beademing is niet erg) Een systeem k zowel harde als zachte deadlines hebben (realiteit kosten functie) 1.3 Geef de figuur voor een typisch embedded systeem en bespreek. Computer: sampling v meettoestellen op regelmatige tijdstippen real-time klok noodz Constant informeren van toestand systeem aan menselijke operator Toestandswijzigingen bijhouden in databank: voor post mortems (systeem crash) voor administratieve doeleinden 1

1.4 Wat zijn de kenmerken van real-time systemen? 1. Groot & Complex: Groot: grote verscheidenheid aan real-world gebeurtenissen waarop m k gereageerd w Complex: systeem m continu mee veranderen met wijzigende noden en activiteiten. Real-time talen en omgevingen complexe omgevingen opdelen in handelbare systemen. 2. Manipulatie van echte getallen: model nodig, oplossen differentiaalvergelijkingen, rekening houden met sampling en nauwkeurigheid (ADC s - DAC s) 3. Extreem betrouwbaar en veilig: Hoe meer afhankelijkheid van computers, hoe erger de gevolgen k zijn van iets dat mis loopt (economisch, milieu, mensenlevens) Minimaliseren kans op menselijke fouten Rekening houden met moeilijkheden inherent aan toepassing + bij softwareontwikkeling 4. Gelijktijdige controle van aparte systeemcomponenten Controlleren robots, sensor,... Op meerdere plaatsen nood aan meerdere processoren Nood aan programmeertalen die parallelle systemen ondersteunen 5. Real-time facilities Responstijd cruciaal systeem krachtig genoeg nemen zodat Worst Case-gedrag geen ongewenste vertraging geeft tijdens kritische periodes Nodig: Specifiëren van tijdstippen: wanneer uitvoeren (sensor uitlezen), wanneer antwoord Opgeven van deadlines Reageren wanneer niet aan alle vereisten k voldaan w (deadline(s) gemist) Reageren op situaties waar tijdseiseisen dynamisch wijzigen (noodlanding vliegtuig) Om antwoordtijden te halen voorspelbaar gedrag nodig (= probleem!) 6. Interactie met hardware interupts device-afhankelijk, interrupts vroeger: OS of Assembly code nu: real-time 2

tijd-kritisch directe controle betrouwbaarheid geen low-level programming 7. Efficiënt implementeren en uitvoeren high level taal, focus op oplossing abstractie implementatiedetails embedded: responstijden grootteorde µs geen taal gebruiken die dit niet aankan 2 Reeks 2 2.1 Bespreek het Simple Proces Model (Fixed Priority Scheduling, Rate Monotonic Assignment, Schedulability Test) Simple Proces Model: vast aantal processen periodisch met gekende periodes processen zijn onafhankelijk van elkaar system-overhead, context-switching,... genegeerd (zero cost) & alle processen hebben een deadline gelijk aan hun periode (proces m voltooid zijn vooraleer het volgende keer losgelaten w) alle processen hebben een vaste worst case execution time Fixed Priority Scheduling meest gebruikt elk proces heeft een vaste statisch prioriteit (pre-runtime, voortgaand op tijdseisen) processen w uitgevoerd volgens hun prioriteit Rate Priority (Rate Monotonic Assignment) elk proces krijgt een unieke prioriteit toegewezen gebaseerd op zijn periode hoe korter de periode, hoe hoger de prioriteit (1 = laagste prioriteit) T i < T j P i > P j als een proces gescheduled k w met Fixed Priority Scheduling, k het ook gescheduled w met Rate Priority RMA = optimaal Schedulability Test: test adhv/e specifieke formule, op basis van dewelke men k bepalen of een reeks processen k gescheduled w. Richtlijnen zijn: Alle processen m schedulable zijn, gebruik makend van average execution times average arrival rates Alle hard real-time processen m schedulable zijn, gebruik makend van worst case execution times worst case average arrival rates van alle processen (ook soft realtime) 3

Figuur 1: Voorbeeld reeks processen Figuur 2: Prioriteit Inversie, toegepast op vb 2.2 Wat is het probleem bij scheduling als processen interageren? (priority ceiling protocols) Probleem: een hoge prioriteit die m wachten (geblokkeerd) op een bewerking of bron van een lagere prioriteit = Prioriteit Inversie, cf figuren. Priority Ceiling Protocols: hiermee w op 1 enkele processor een hogere-prioriteitsproces max 1 keer geblokkeerd door een proces v lagere prioriteit deadlocks vermeden: een taak w niet gescheduled als een resource die het zou k blokkeren, al geblokkeerd is door een andere taak. transitief blokkeren verboden: transitief blokkeren = proces van hogere prioriteit geblokkeerd processen met lagere prioriteit ook geblokkeerd wederzijdse uitsluiting gewaarborgd (= exclusieve toegang tt bronnen) 1. Original Ceiling Priority Protocol (OCCP): elk proces statisch default prioriteit elke bron statische ceiling waarde (de maximum prioriteit van de verzameling processen die de resource gebruiken) proces heeft een dynamisch prioriteitswaarde = MAX(default prioriteit, geërfde prioriteit) Priority inheritance: als proces met prioriteit 1 een belangrijker proces met prioriteit 5 blokkeert, dan krijgt het eerste proces tijdelijk prioriteit 5, zodat geen priority inversion optreedt. 4

een proces k enkel een bron reserveren (vergrendelen) als de dynamische prioriteit hoger is dan het plafond van eender elke andere gereserveerde (vergrendelde) bron (exclusief dat welke het proces zelf gereserveerd heeft) 2. OCCP toegepast op voorbeeld, zie figuur 3: proces a begint en voert E en Q uit static ceiling Q = 4 (prio v proces d) proces b wil beginnen uitvoeren, dus proces a w gestopt (preëmptief) proces c wil beginnen uitvoeren, dus proces b w gestopt (preëmptief). proces c voert E uit en wil V uitvoeren, maar k dit proces niet blokkeren omdat proces c met dynamische prioriteit 3 (max(eigen prio, geërfde prio) en ng niets geërfd) < static ceiling V = 4 proces c w geblokkeerd proces b w ook geblokkeerd, want wil E uitvoeren, maar dyn prio v proces b (= 2) < static ceiling v E = 4 proces a voert nogmaals Q uit, en w preëmptief onderbroken door proces d proces d voert 2x E uit, en wil resource Q maar dyn prio v proces d = 4! > static ceiling Q = 4 dus w geblokeerd proces a k nog 2x Q uitvoeren, waarna Q vrijkomt om uitgevoerd te w door proces d, die daarna ook V uitvoert en nogmaals E uitvoert. proces c w gedeblokkeerd en k V uitvoeren, waarna E nog w uitgevoerd proces b is aan de beurt en voert 2x E uit proces A k nogmaals E uitvoeren. 3. Immediate Ceiling Priority Protocol (ICCP): elk proces een statisch default prioriteit elke bron statische ceiling waarde (de maximum prioriteit van de verzameling processen die de resource gebruiken) proces heeft een dynamisch prioriteitswaarde = MAX(default prioriteit, ceiling geërfde prioriteit) als gevolg zal een proces enkel in het begin geblokkeerd zijn eens het proces start met executie m alle bronnen vrij zijn, is dit niet het geval dan is er een ander proces met dezelfde of een hogere prioriteit dat voorgang heeft 4. OCPP vs. ICPP Figuur 3: OCPP toegepast op vb Worst Case gedrag nagenoeg hetzelfde 5

Figuur 4: ICPP toegepast op vb ICPP is makkelijker implementeerbaar ICPP heeft minder wisselingen omdat er geblokkeerd w voor executie, blokkeringen in begin ICPP heeft meer prioriteit verschuivingen nodig OCPP verandert de prioriteit als een block zich voordoet 2.3 Leg volgende formule uit: R i = B i + C i + j hp(i) R i + J j C j T j B: Worst-case blocking time for the process (if applicable) C: Worst-case computation time of the process D: Deadline of the process I: The interference time of the process J: Release jitter of the process N: Number of processes in the system P: Priority assigned to the process (if applicable) R: Worst-case response time of the process T: Minimum time between process releases (process period) U: The utilization of each process (= C T ) a-z The name of a process D i R i = C i + I i Gedurende R, zal elke hogere-prioriteitstaak j een # keer uitvoeren. Ri = # releases v hogere-prioriteitstaak j T j Ri C j = totale interferentie door hogere prioriteitstaak j T j I i = Ri j hp(i) C j = totale interferentie op proces j van alle hogere prioriteitstaken T j R i = C i + I i = C i + Ri C j j hp(i) T j 6

Rekening houdend met Blocking: R i = C i + I i + B i = C i + B i + Rekening houdend met release Jitter per proces: 3 Reeks 3 R i = C i + I i + B i = C i + B i + j hp(i) j hp(i) Ri T j C j Ri + J i C j 3.1 Wat zijn de problemen bij het instellen van de delay voor een proces? delay (abs of relatief) is de minimum delay en niet de maximum delay: instellen proces 5s wachten delay = 5s na 5s zal dit proces zijn beurt afwachten om uitgevoerd te w + tijd voor proceswissel 5s = minimale delay Lokale drift = het teveel aan tijd bij relatieve en absolute delays, k niet vermeden w (proces bv uitgevoerd na 5,5s: delay = 5s & drift = 0,5s). Cumulatieve drift = over-run door cumuleren van alle lokale driften. k vermeden w als lokale driften elkaar mogen overlappen (superimpose) T j t a s k T; task body T i s begin loop Action ; delay 5. 0 ; end loop ; end T; Listing 1: met cumulatieve drift (verkeerd) t a s k T; task body T i s I n t e r v a l : c o n s t a n t Duration := 5. 0 ; Next Time : Time ; begin Next Time := Clock + I n t e r v a l ; loop Action ; delay u n t i l Next Time ; Next Time := Next Time + I n t e r v a l ; end loop ; end T; Listing 2: zonder cumulatieve drift (correct) 3.2 Hoe reageer je op het niet voorkomen van een extern event? Door het proces dat aan het draaien is, te laten wachten op de externe event. Indien deze niet binnen een opgegeven tijd plaatsvindt, dan w het proces afgebroken (timeout). In Real Time Java: 7

time-outs op acties voorzien subclasse van AsynchronouslyInterruptedException genaamd Timed bij het verlopen van de timer w er een AsynchronouslyInterruptedException gegenereerd die dan k opgevangen w 3.3 Welke tijdseisen k je stellen op processen? deadline: tijdstip tegen wanneer het laatst voltooid m zijn minimum delay: de minimium tijd voor het starten vh proces maximum delay: de maximum tijd voor het starten vh proces maximum execution time: maximale verstreken rekentijd maximum elapse time: maximale totale verstreken tijd tijdseisen: periodisch: vast tijdsinterval tussen elke release = periode sporadisch: er zit een minimum tijdsinterval tussen elke release (minimum interarrival time). Proces mag minder vaak opgestart w, maar niet vaker (manier om beter te k werken met aperiodische processen) aperiodisch: helemaal geen regelmaat in tijd tussen elke release moeilijk uit te drukken in scheduling deadlines: hard, soft, interactief & firm (cf vraag 2) 3.4 Hoe detecteer je het overschrijden van tijdseisen en hoe ga je erop reageren? We k bij het opstarten v/e proces met deadline een recovery procedure laten opstarten. De recovery procedure w uitgevoerd met een delay = deadline van dat proces. Indien de deadline toch gehaald is, dan w de procedure nooit uitgevoerd. Nadeel: Deze methode veronderstelt dat de taak mag w gestopt indien de deadline niet gehaald is, om het recovery proces op te starten. Oplossing: De taak met een andere prioriteit uitvoeren. Om dit te verwezelijken is het geschikter om dit door een asynchroon event te laten gebeuren. (In Real Time Java zal de virtuele machine een Asynchroon Event oproepen, die door Event Handlers w afgehandeld. Hierdoor k het proces gestopt w of verder w uitgevoerd, evt. met andere prioriteit) Opmerking: Real Time Java kent ook Sporadic Event Handlers maar die w niet uitgevoerd bij het overschrijden van een deadline en w dus enkel voor soft deadlines gebruikt. 4 Reeks 4 4.1 Wat zijn atomische acties en wat zijn de eisen ervoor? Een actie is atomisch als het uitvoerend proces: zich niet bewust is van het bestaan van andere actieve processen tijdens de actie en vice versa niet communiceert met andere processen terwijl het een actie uitvoert 8

er geen toestandswijzigingen zijn, behalve die die het proces zelf veroorzaakt. Het proces zal ook zijn eigen toestandswijzigingen niet bekend maken tot de actie voltooid is (bvb: veranderen waarde van variabele) als direct (zonder vertraging uitgevoerd) en ondeelbaar k w gezien door andere processen Waarvoor nodig: parallellisme soms m 2 processen 1 communicatie uitvoeren die niet mag onderbroken w (banktransactie) de betrokken processen m een consistent (niet-tegenstrijdig) systeem staat zien interferentie met andere processen vermijden Atomische transactie zelfde als actie maar m ofwel slagen ofwel geen effect hebben (error recovery) Eigenschappen atomische acties: goed gedefinieerde grenzen (begin, einde, scheiding tussen processen betrokken bij atomische actie en deze die dat niet zijn) ondeelbaar: mogen geen informatie uitwisselen tss interne en externe processen (behalve resourcemanagers) de processen mogen de atomische actie niet verlaten vooraleer alle deelnemende processen voltooid zijn (bij slagen van de atomische actie) geen synchronisatie bij start: processen k op momenten binnenkomen waarde van gedeelde data na verschillende acties bepaald door strikte opeenvolging van acties in bepaalde volgorde mogen nesten zolang er geen overlap is met andere atomische acties meerdere atomische acties k parallel w uitgevoerd 4.2 Bespreek conversations, dialogs en colloquys. Conversations = atomische acties voor rollback (=backward error recovery). a c t i o n A with (P2, P3) do ensure <acceptance t e s t > by primary module else by a l t e r n a t i v e module else by a l t e r n a t i v e module else e r r o r end A; Listing 3: Conversations in proces P1 bij het starten van de actie w de staat van de deelnemende processen opgeslagen in een recovery point, die samen een recovery line vormen binnen de actie (zie listing) w rollback van alle processen naar het recovery point voorzien als een proces faalt 9

enkel communicatie toegestaan met processen in de conversation en met resource managers, overgeërfd v atomische actie want conversatie daaruit opgebouwd om de conversatie te verlaten m alle processen hun acceptance test voltooien Geslaagd Conversation beëindigd en recovery points verwijderd Niet geslaagd ALLE processen hersteld tot hun oorspronkelijke staat en overgaan tot alternatieve module enkel strikte nesting toegestaan als alle alternatieven (zie listing) falen m de recovery op een hoger niveau afhandelen deelname is niet verplicht (verlaten voor deadline te halen) zolang er niet m gecommuniceerd w met een ontbrekend proces k de conversatie voltooien als er m gecommuniceerd w met een ontbrekend proces k het proces wachten (geblokeerd) of voortdoen Voordelen: mogelijk om conversaties te specifi ren zonder verplichte deelname mogelijk dat processen met een deadline de conversatie verlaten en verder doen, eventueel met uitvoer van een alternatieve code. Kritiek op conversations: Dialogs ALLE processen w hersteld en gaan naar alternatief als er faling is Voor 2 e module k het misschien zijn dat een proces met totaal andere processen zou m communiceren. soms beter opnieuw proberen in plaats van over te gaan op alternatieve module alternatieve module meestal andere acceptance tests groep processen in atomische actie, bij fout w het recovery point hersteld en faalt de dialog (geen alternatieve modules) processen die willen deelnemen aan een backward recoverable atomic action, voeren een DI- ALOG statement uit: DIALOG name\_and\_acceptance\_test SHARES(variables) dialog statements hebben drie functies: 1. de atomic action identificeren 2. een globale acceptatie test declareren voor de atomic action 3. de variabelen die bij de atomic action zullen gebruikt w specificeren elk proces dat wil deelnemen, definieert ook een DISCUSS-statement dat onderdeel is van de atomische actie en dat de actie een naam geeft: DISCUSS dialog name BY sequence of statements TO ARRANGE boolean expression; de reeks DISCUSS-statements vormt hier de recovery line RULE: een proces mag de dialog niet verlaten vooraleer alle acieve processen succesvol hun local en global acceptance test hebben afgelegd 10

mogelijk om verschillende dialogs samen te nemen tot een dialog sequence (zie listing 4) SELECT d i a l o g 1 OR d i a l o g 2 // Als d i a l o g 1 f a a l t OR d i a l o g 3 // Als d i a l o g 2 f a a l t ELSE l a a t s t e redmiddel // Als a l l e d i a l o g s g e f a a l d hebben END SELECT Colloquys bevat groep dialogs controleert de acties Listing 4: Verschillende dialogs vormen een dialog sequence beslist welke herstelactie w gestart bij een fout van een dialog mogelijk om alternatieve dialogs te definiëren met mogelijk een andere groep processen 4.3 Bespreek atomische acties en Forward Error Recovery. Atomische acties zie 4.1. Forward Error Recovery en Exception Handling w gebruikt voor real-time applicaties waar geen roll back mogelijk is. als er een exception in een proces in een atomische actie optreedt, w de exception asynchroon opgegooid in alle processen die deelnemen aan de actie. zowel terminatie als voortzettingsmodellen zijn mogelijk voortzetting: als een proces een exception veroorzaakt k deze mogelijk door de handler w opgelost waardoor het proces k voortwerken alsof er niets is gebeurd terminatie: als een proces een exception veroorzaakt zorgt de handler ervoor dat het proces w beëindigd hybride: de handler kiest afhankelijk van de situatie of het proces w voortgezet of beëindigd als er geen handler zit in één van de processen die bij de actie w gebruikt of als een handler faalt, dan faalt de atomische actie met een standaard exception: Atomic Action Failure en deze w opgeroepen in alle betrokken processen. Resolutie van gelijktijdig voorkomende exceptions: 2 exceptions die tegelijk voorkomen in een atomic action leiden tot twee afzonderlijke exception handlers in elk proces moeilijkheid: welke v/d 2 m afgehandeld w? 3e exception gebruiken die wijst op optreden van 2 vorige tegelijk exception tree: handler gebruiken voor exception op wortel van kleinste subtree die alle opgetreden exceptions bevat. behandelen van concurrent exceptions: elk onderdeel van een atomic action k zijn eigen exception tree declareren & verscheidene processen die betrokken zijn bij een atomic action k verschillende exception trees hebben 11

onduidelijk hoe parameters van fouten combineren... Exceptions en interne atomische acties geneste atomische acties: een proces in atomische actie geeft een exception als andere processen betrokken zijn bij een geneste actie alle processen die betrokken zijn m deelnemen aan de recovery action.! interne actie ondeelbaar 2 oplossingen: 5 Reeks 5 1. wacht met de exception te geven tot de interne actie gedaan is. Niet zo goed idee want: De exception k iets te maken hebben met een gemiste deadline. De exception tijdelijk onderdrukken k dus een nefaste impact hebben op tijdig reageren van het systeem. De exception k gerelateerd zijn aan een deadlock in de geneste atomische actie geneste actie zal nooit voltooid w. 2. laat interne actie een voorafgedefinieerde Abortion Exception hebben. Dit geeft aan dat een exception is gegeven in een omringende actie, waardoor de geneste atomische actie m gestopt w, zodat alle processen k meedoen aan de recovery. Indien geen voorgedefinieerde Abortion Exception wachten op voltooien v/d geneste atomische actie. 5.1 Beschrijf kort het HRT HOOD proces. Hard Real-Time Hierarchical Object-Oriented Design Focus op ontwikkeling van fysische en logische architectuur (architectural design) Object-gebaseerde notatie Onderverdelen in modules met goed gedefinieerde interfaces: ofwel direct geïmplementeerd ofwel verder onderverdeeld Gestandaardiseerd formalisme: tekstueel en grafisch Regels automatisch laten checken: bvb scheduling, precondities,... Design = voortgang van alsmaar specifiekere commitments commitments = eigenschappen van ontwerp die niet gewijzigd mogen w door de ontwerpers die zich op een specifieker ontwerp-niveau bevinden. aspecten van design zonder commitment = obligations te behandelen in lagere (specifiekere) niveaus. Ontwerpverfijning (obligations omzetten naar commitments) vooral beïnvloed door beperkingen van uitvoeringsomgeving: resource constraints: CPU klokfrequentie, netwerkbandbreedte,... mechanism constraints: interrupt prioriteiten, task dispatching, data locking,... Obligations, commitments en constraints hebben belangrijke invloed op architectuur-design, wat k opgeplitst w in 2 delen: 12

1. logical architecture: onafhankelijk van uitvoeringsomgeving & doel = vooral voldoen aan functionele eisen 2. physical architecture: vooral niet-functionele eisen & vormt een basis om na te gaan of aan functionele eisen voldaan w, na implementatie. Verschillende soorten objecten: Actief: controle over uitvoering eigen code &in staat andere objecten op te roepen Passief: omgekeerde van actief Protected: controle over eigen operaties, niet mogelijk om code van andere objecten op te roepen, geen arbitraire synchronisatiebeperkingen & blokkeertijden die ze veroorzaken bij hun oproepers, m analyseerbaar zijn Cyclisch: vertegenwoordigen periodieke activiteiten & spontaan oproepen van code van andere objecten Sporadisch: hebben 1 operatie die sporadisch w opgeroepen & spontaan oproepen code van andere objecten Naar einde van ontwerp toe mag programma alle objecttypen bevatten, behalve actieve: actieve objecten enkel voor achtergrondtaken actieve objecten enkel gebruikt bij ontwerp m naar einde toe veranderd w naar ander type. 5.2 Beschrijf kort het ROPES proces. Rapid Object-Oriented Process for Embedded Systems ROPES Macro Cycle: 1. Analysis: identificatie van alle aspecten voor correctheid 2. Design Requirements analysis Informatie verkrijgen van klant in vorm van: use cases, state charts (= toestandsdiagrammen) & beperkingen Activiteiten: use case maken, externe events identificeren, gedragsscenarios definiëren, beperkingen & interfaces nr andere systemen Systeem in kleinere delen splitsen en gedrag uitwerken Actoren in externe omgeving identificeren (mensen, subsystemen, apparaten) ofwel apparaat gebruikt door mens OF mens zelf = afh v systeem Messages (tss systeem en actoren) = semantiek (inhoud) + structuur + parameters Protocols (die die messages gebruiken) voor communicatie verfijnen Systems analysis/engineering Object analysis Architectural Mechanistic ( mechanisms?) Detailed 3. Translation 4. Testing 13