Oplossing mogelijke theorievragen Real Time Systemen

Oplossing mogelijke theorievragen Real Time Systemen Dumon Willem - 4Elicti 2009-2010 Uit elk 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 elk systeem dat informatie verwerkt en een antwoord moet geven oiv extern gegenereerde stimuli (oa klok) binnen een bepaalde tijdspanne. De juistheid hangt dus niet enkel af v/h logische resultaat, maar ook v/h tijdstip waarop dit resultaat gegeven wordt. Niet tijdig of geen antwoord geven is even erg als 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 v systeem (hartmonitor, kerncentrale, vluchtcontrole systemen,...). • Soft: systemen waar deadlines belangrijk zijn maar waar het system nog correct blijft functioneren wnnr 1 deadline gemist w. ¯ 1 laat antwoord = kwaliteitsverlies. Herhaaldelijk missen v deadline = falen v systeem (vluchtreservatiesysteem, data-acquisitiesysteem). • Real: harde realtime systemen met zeer korte responstijd (vb raketsturingen) • Firm: combinatie v hard & soft ∼ = Soft waar data onbruikbaar is als er een late respons is (beademingstoestel: een paar seconden vertraging in beademing is niet erg, maar het moet wel gebeuren) 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 v toestand systeem aan menselijke operator • Toestandswijzigingen bijhouden in databank: – voor post mortems (systeem crash) – voor administratieve doeleinden vb: doorstroming in pijp met sensor meten → processing → klep/kraan regelen 1

1.4

Wat zijn de kenmerken v 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 v re¨eele getallen: model nodig, oplossen differentiaalvergelijkingen, rekening houden met sampling en nauwkeurigheid (ADC’s - DAC’s) 3. Extreem betrouwbaar en veilig: • Hoe meer afhankelijkheid v computers, hoe erger de gevolgen k¯ zijn v iets dat mis loopt (economisch, milieu, mensenlevens) • Minimaliseren kans op menselijke fouten (als interactie met operator nodig) • Rekening houden met moeilijkheden inherent aan toepassing & bij softwareontwikkeling 4. Gelijktijdige controle v 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¨eren v tijdstippen: wanneer uitvoeren (sensor uitlezen), wanneer antwoord Opgeven v 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 (speciale) hardware-interfaces • device-afhankelijk, interrupts • vroeger: OS of Assembly code • nu: real-time 2

– tijd-kritisch → directe controle – betrouwbaarheid → geen low-level programming 7. Effici¨ent implementeren en uitvoeren • high level taal, focus op oplossing → abstractie implementatiedetails • embedded: als responstijden ∼ µ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 & alle processen hebben een deadline gelijk aan hun periode (proces m ¯ voltooid zijn vooraleer het volgende keer losgelaten w) ¯ – processen zijn onafhankelijk v elkaar – system-overhead, context-switching,... verwaarloosd (zero cost) – alle processen hebben een vaste Worst Case Execution Time WCET • Fixed Priority Scheduling – meest gebruikt – elk proces heeft vaste prioriteit (pre-runtime vestgelegd, afgeleid v 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) Ti < Tj ⇒ Pi > Pj – als een proces gescheduled k¯ w ¯ met Fixed Priority Scheduling, k¯ het ook gescheduled w ¯ met Rate Priority ⇒ RMA = optimaal • Schedulability Test = Utilisation Based Analyse: test adhv/e specifieke formule, op basis v dewelke men k¯ bepalen of een reeks processen k¯ gescheduled w. ¯ U=

N X Ci i=0

Ti

1

≤ N (2 N − 1)

Richtlijnen zijn: – Alle processen m ¯ schedulable zijn, gebruik makend v ∗ average execution times ∗ average arrival rates – Alle hard real-time processen m ¯ schedulable zijn, gebruik makend v ∗ worst case execution times ∗ worst case average arrival rates v alle processen (ook soft realtime) opm: efficient → als voorwaarde klopt: zeker schedulable volgens RMS not necessary → als voorwaarde niet klopt kan het nog altijd schedulable zijn 3

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 v een lagere prioriteit = Prioriteit Inversie, cf figuren.

Figuur 1: Voorbeeld reeks processen

Figuur 2: Prioriteit Inversie, toegepast op vb • 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 v hogere prioriteit geblokkeerd ⇒ processen met lagere prioriteit ook geblokkeerd – wederzijdse uitsluiting gewaarborgd (= exclusieve toegang tt bronnen) 1. Original Ceiling Priority Protocol (OCPP): – elk proces vaste default prioriteit – elke bron vaste plafondwaarde (de maximum prioriteit v de verzameling processen die de resource gebruiken) – proces heeft dynamisch prioriteitswaarde = MAX(default prioriteit, ge¨erfde 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 v 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), a mag Q uitvoeren omdat nog geen enkele andere bron geblokkeerd is – proces b wil beginnen uitvoeren, dus proces a w ¯ gestopt (pre¨emptief) – proces c wil beginnen uitvoeren, dus proces b w ¯ gestopt (pre¨emptief) – 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¨erfde prio) en ng niets ge¨erfd) < static ceiling Q = 4, met Q geblokkeerd door proces a ⇒ a blokeert c dus erft prio van c! – proces c w ¯ geblokkeerd – proces b w ¯ ook geblokkeerd, want proces a heeft hogere dyn prio (ge¨erfd van c) – proces a voert nogmaals Q uit, en w ¯ pre¨emptief onderbroken door proces d – proces d zorgt ervoor dat a,b & c pre¨emptief onderbroken worden, voert 2x E uit, en wil resource Q maar dyn prio v proces d = 4 ≯ static ceiling Q = 4 dus w ¯ geblokeerd – proces a blokkeert proces d en erft prio = 4 & k¯ nog 2x Q uitvoeren (geen enkele andere resource geblokkeerd), waarna Q vrijkomt om uitgevoerd te w ¯ door proces d, die daarna ook V uitvoert en nogmaals E uitvoert. Hierdoor verliest a de ge¨erdfde prio en komt terug op prio 1 – 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.

Figuur 3: OCPP toegepast op vb 3. Immediate Ceiling Priority Protocol (ICCP): – elk proces een statisch default prioriteit – elke bron statische ceiling waarde (de maximum prioriteit v de verzameling processen die de resource gebruiken) – proces heeft een dynamisch prioriteitswaarde = MAX(default prioriteit, ceiling ge¨erfde 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

5

Figuur 4: ICPP toegepast op vb 4. OCPP vs. ICPP – Worst Case gedrag nagenoeg hetzelfde – 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: Ri = Bi + Ci +

X

d

j∈hp(i)

Ri + Jj e Cj Tj

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 Di ≥ Ri = Ci + Ii • Gedurende R, zal elke hogere-prioriteitstaak j een # keer uitvoeren.   Ri = # releases v hogere-prioriteitstaak j  Tj  Ri × Cj = totale interferentie door hogere prioriteitstaak j Tj   P Ri Ii = j∈hp(i) × Cj = totale interferentie op proces j v alle hogere prioriteitstaken Tj X  Ri  Ri = Ci + Ii = Ci + × Cj Tj j∈hp(i)

6

• Rekening houdend met Blocking: Ri = Ci + Ii + Bi = Ci + Bi +

X  Ri  × Cj Tj

j∈hp(i)

• Rekening houdend met release Jitter per proces: Ri = Ci + Ii + Bi = Ci + Bi +

X  Ri + Ji  × Cj Tj

j∈hp(i)

3

Reeks 3

3.1

Wat zijn de problemen bij het instellen v de delay voor een proces?

• delay (abs = tt bep tijd ↔ relatief = bep periode) = minimum delay, nt 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 v alle lokale driften. k¯ vermeden w ¯ als lokale driften elkaar mogen overlappen (superimpose) ⇒ drift meerekenen op voorhand bij je delay

3.2

Hoe reageer je op het niet voorkomen v 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: • time-outs op acties voorzien • subclasse v AsynchronouslyInterruptedException genaamd Timed • bij het verlopen v 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) 7

3.4

Hoe detecteer je het overschrijden v 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 v 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 verwezenlijken 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 v een deadline (k¯ dit niet detecteren) ⇒ 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 v het bestaan v andere actieve processen tijdens de actie en vice versa • niet communiceert met andere processen terwijl het een actie uitvoert • 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 v 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, dit omdat een resource maar voor heel kleine tijd gebruikt wordt tijdens de atomische actie en door die RM dan t´och voor andere processen zou mogen gebruikt worden)

8

– de processen mogen de atomische actie niet verlaten vooraleer alle deelnemende processen voltooid zijn (bij slagen v de atomische actie) – geen synchronisatie bij start: processen k¯ op 6= momenten binnenkomen – waarde v gedeelde data na verschillende acties bepaald door strikte opeenvolging v 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 e n s u r e by −− primary module e l s e by −− a l t e r n a t i v e module e l s e by −− a l t e r n a t i v e module else error end A;

Listing 1: Conversations in proces P1 • bij het starten v de actie w ¯ de staat v de deelnemende processen opgeslagen in een recovery point, die samen een recovery line vormen • binnen de actie (zie listing) w ¯ rollback v alle processen naar het recovery point voorzien als een proces faalt • enkel communicatie toegestaan met processen in de conversation en met resource managers, overge¨erfd v atomische actie want conversatie daaruit opgebouwd • om de conversatie te verlaten m ¯ alle processen hun acceptance test voltooien – Geslaagd ⇒ Conversation be¨eindigd 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¨eren zonder verplichte deelname – mogelijk dat processen met een deadline de conversatie verlaten en verder doen, eventueel met uitvoer v een alternatieve code.

9

• Kritiek op conversations: – ALLE processen w ¯ hersteld en gaan naar alternatief als er faling is e – Voor 2 module k¯ het misschien zijn dat een proces met totaal andere processen zou m ¯ communiceren. – soms beter opnieuw proberen in plaats v over te gaan op alternatieve module – alternatieve module meestal andere acceptance tests Dialogs • 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 DIALOG 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 v 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 • 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 // A l s d i a l o g 1 f a a l t OR −−d i a l o g 3 // A l s d i a l o g 2 f a a l t ELSE −−l a a t s t e r e d m i d d e l // A l s a l l e d i a l o g s g e f a a l d h e b be n END SELECT

Listing 2: Verschillende dialogs vormen een dialog sequence Colloquys • bevat groep dialogs • controleert de acties • beslist welke herstelactie w ¯ gestart bij een fout v een dialog • mogelijk om alternatieve dialogs te defini¨eren met mogelijk een andere groep processen

10

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¨eindigd – hybride: de handler kiest afhankelijk v de situatie of het proces w ¯ voortgezet of be¨eindigd • als er geen handler zit in ´e´en v 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 v 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 v 2 vorige tegelijk → exception tree: handler gebruiken voor exception op wortel v kleinste subtree die alle opgetreden exceptions bevat. – behandelen v concurrent exceptions: elk onderdeel v een atomic action k¯ zijn eigen exception tree declareren & verscheidene processen die betrokken zijn bij een atomic action k¯ verschillende exception trees hebben – onduidelijk hoe parameters v 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: 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 v 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. 11

5

Reeks 5

5.1

Beschrijf kort het HRT HOOD proces.

• Hard Real-Time Hierarchical Object-Oriented Design • Focus op ontwikkeling v 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 v alsmaar specifiekere commitments – commitments = eigenschappen v ontwerp die niet gewijzigd mogen w ¯ door de ontwerpers die zich op een specifieker ontwerp-niveau bevinden. – aspecten v design zonder commitment = obligations ⇒ te behandelen in lagere (specifiekere) niveaus. • Ontwerpverfijning (obligations omzetten naar commitments) vooral be¨ınvloed door beperkingen v 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: 1. logical architecture: onafhankelijk v 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 v actief – Protected: controle over eigen operaties, niet mogelijk om code v andere objecten op te roepen, geen arbitraire synchronisatiebeperkingen & blokkeertijden die ze veroorzaken bij hun oproepers, m ¯ analyseerbaar zijn – Cyclisch: vertegenwoordigen periodieke activiteiten & spontaan oproepen v code v andere objecten – Sporadisch: hebben 1 operatie die sporadisch w opgeroepen & spontaan oproepen code v andere objecten – Aperiodisch • Naar einde v 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. 12

5.2

Beschrijf kort het ROPES proces.

Rapid Object-Oriented Process for Embedded Systems ROPES Macro Cycle (lengte project): 1. Analysis: identificatie v alle aspecten voor correctheid • Requirements analysis – Informatie verkrijgen v klant in vorm v: use cases, state charts (= toestandsdiagrammen) & beperkingen – Activiteiten: use case maken, externe events identificeren, gedragsscenarios defini¨eren, 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 2. Design • Architectural • Mechanistic (∼mechanisms?) • Detailed 3. Translation: design omzetten naar code & unit testing 4. Testing: Integration & Validation Testing ROPES Micro Cycle: tijd nodig voor 1 increment of versie (4 tot 6 weken) ROPES Nano Cycle: tijd nodig voor produceren, compileren, uitvoeren & testen v/e heel klein gedeelte (30 minuten - 1 uur)

Figuur 5: ROPES Spiraalmodel

13

Figuur 6: ROPES Cycles

6

Modelchecking • guard = voorwaarde om een path te kunnen nemen, booleaanse expressie • assignment = waarde toekennen (bij path) aan bepaalde variabele (integer, boolean, timer) • synchronisation = koppeling tussen Expression? en Expression!, kan in 2 versch automata zijn • invariant = voorwaarde om in een staat te mogen komen

14