Slide 1Programmatuur voor real-time controleYolande Berbers RTPReal-Time Programmatuur hoofdstuk 5: betrouwbaarheid en fout-tolerantie.

Presentatie over: "Slide 1Programmatuur voor real-time controleYolande Berbers RTPReal-Time Programmatuur hoofdstuk 5: betrouwbaarheid en fout-tolerantie."— Transcript van de presentatie:

1 slide 1Programmatuur voor real-time controleYolande Berbers RTPReal-Time Programmatuur hoofdstuk 5: betrouwbaarheid en fout-tolerantie

2 RTP slide 2Programmatuur voor real-time controleYolande Berbers inleiding n betrouwbaarheid en veiligheid zijn specifieke eisen voor real-time systemen u bij andere toepassingen (bv een wetenschappelijke berekening) verliest men bij een fout enkel computertijd u fouten in real-time systemen kosten soms mensenlevens u fouten in real-time systemen kunnen veel geld kosten u fouten in real-time systemen kunnen heel vervelend zijn voor de gebruiker (wie heeft graag een hele avond geen elektriciteit) n doelstelling van dit hoofdstuk: u de factoren begrijpen die de betrouwbaarheid beïnvloeden u studie van methodes om software fouten te kunnen tolereren

3 RTP slide 3Programmatuur voor real-time controleYolande Berbers bronnen van fouten n 4 bronnen van fouten u slechte (onvolledige, foutieve) specificatie l volgens sommigen zijn de meeste fouten hieraan te wijten l dit komt in deze cursus niet aan bod u ontwerpfouten in de software l deze fouten gaan we in dit hoofdstuk behandelen l onvoorspelbaar u fouten door componenten (bv processoren) die het begeven l dit wordt behandeld in hoofdstuk 14 l enigszins voorspelbaar u intermitente of permanente fouten van communicatiesysteem l dit wordt behandeld in hoofdstuk 14 l enigszins voorspelbaar

4 RTP slide 4Programmatuur voor real-time controleYolande Berbers betrouwbaarheid, faling en fouten n definitie van betrouwbaarheid u maat van succes waarmee een systeem zich gedraagt zoals opgedragen in zijn specificatie n definitie van faling u wanneer een systeem zich niet gedraagt zoals opgedragen in zijn specificatie (het doel wordt niet bereikt) n zeer betrouwbaar = kleine kans op faling n faling komt door interne problemen, hier dwalingen genoemd (errors in het Engels, errare in het Latijn betekent dwalen) n dwalingen komen door fouten (mechanische of algoritmische fouten, faults in het Engels)

5 RTP slide 5Programmatuur voor real-time controleYolande Berbers betrouwbaarheid, faling en fouten n in termen van toestanden: u een systeem wordt gekenmerkt door een aantal extern- zichtbare toestanden waarin het zich kan bevinden (deze toestanden zijn beschreven in de specificatie) u komt het systeem in een externe toestand niet beschreven in de specificatie, dan is dit een faling n tov componenten u de combinatie van de toestanden van al de componenten is de interne toestand van het systeem u een niet gespecificeerde interne toestand is een dwaling tov het systeem en is het gevolg van een fout u een fout wordt veroorzaakt door een foutieve component

6 RTP slide 6Programmatuur voor real-time controleYolande Berbers betrouwbaarheid, faling en fouten n het geheel kan ook recursief bekeken worden u een systeem bestaat uit componenten met elk een specificatie, en beschreven externe toestanden u een faling van een component (altijd tov de specificatie van deze component) resulteert in een fout u de fout resulteert in een niet-geoorloofde interne toestand van het systeem, dit is een dwaling u deze dwaling resulteert in het falen van het hele systeem fout dwaling falingfout

7 RTP slide 7Programmatuur voor real-time controleYolande Berbers betrouwbaarheid, faling en fouten n 3 types van fouten u voorbijgaande fout l een fout die op een bepaald moment optreedt, maar ook daarna verdwijnt (het effect ervan wel niet !) l vb: fout van hardware component door elektrisch veld u permanente fout l een fout die optreedt en blijft totdat hij hersteld wordt l vb: een draad die over is, een software ontwerp-fout u intermitente fout l voorbijgaande fout die regelmatig optreedt en verdwijnt l vb: een component die warmte-gevoelig is en regelmatig oververhit geraakt

8 RTP slide 8Programmatuur voor real-time controleYolande Berbers falingswijzen n classificatie van de manier waarop een systeem faalt u falen in het waarde-domein l een foutieve waarde wordt gegeven s deze kan binnen de grenzen liggen (maar toch fout zijn) s of buiten opgegeven grenzen vallen u falen in het tijds-domein l een dienst kan te vroeg geleverd worden l een dienst kan te laat geleverd worden l een dienst kan nooit geleverd worden s geen enkele verdere dienst wordt geleverd (fail silent) s andere systemen kunnen dit merken (fail stop) u een combinatie van waarde en tijd, of een onverwachte dienst

9 RTP slide 9Programmatuur voor real-time controleYolande Berbers falingswijzen tijdsdomein niet fail stop arbitrair (fail uncontrolled) waardedomein beperkings- fout waarde- fout te laatte vroeg fail controlledfail silent

10 RTP slide 10Programmatuur voor real-time controleYolande Berbers foutpreventie en fout-tolerantie n twee mogelijke aanpakken voor betrouwbare systemen: u foutpreventie l probeert te voorkomen dat er fouten zullen optreden, vóór het systeem in gebruik genomen wordt l bestaat uit s vermijden van fouten s verwijderen van fouten u fout-tolerantie l maakt het mogelijk dat het systeem blijft functioneren, zelfs als er fouten gebeuren l vangt fouten op tijdens het gebruik van het systeem n van belang: dat een systeem een welbepaalde falingswijze heeft

11 RTP slide 11Programmatuur voor real-time controleYolande Berbers foutpreventie n vermijden van fouten u hardware l gebruik van heel betrouwbare componenten l gebruik van verfijnde technieken voor het samenvoegen van componenten l zorg besteden aan de ‘verpakking’ om interferentie te voorkomen u software l ondubbelzinnige, liefst formele, specificaties l gebruik van goede ontwerp-methodes (software engineering) l gebruik van programmeertalen die abstractie en modulariteit ondersteunen l gebruik van softwareomgevingen (CASE-tools) die ontwikkelings- proces ondersteunen en zo helpen om complexiteit te beheersen

12 RTP slide 12Programmatuur voor real-time controleYolande Berbers foutpreventie n verwijderen van fouten (eerst vinden en dan verwijderen) u ontwerp-revisie u formele, liefst automatische, programma-verificatie u code inspectie u testen l kan enkel fouten aanwijzen, kan niet bewijzen dat een systeem foutloos is l testen in realistische condities: soms onmogelijk (bv Ariane) s vaak gaat men over tot simulaties s moeilijk om aan te tonen dat de simulaties perfect de werkelijkheid nabootsen (reden van Franse atoomtesten) l fouten in de vooronderstellingen waarop de specificaties gemaakt zijn kunnen nooit gevonden worden

13 RTP slide 13Programmatuur voor real-time controleYolande Berbers foutpreventie n foutpreventie faalt u wanneer de frequentie of de duur van de herstellingen niet toelaatbaar zijn u wanneer het systeem niet toegankelijk is voor onderhoud of herstellingen (extreem vb: Voyager) n foutpreventie alleen is nooit voldoende u bv hardware componenten zullen het begeven

14 RTP slide 14Programmatuur voor real-time controleYolande Berbers fout-tolerantie n absoluut noodzakelijk omdat foutpreventie onvoldoende is n volledige fout-tolerantie u systeem blijft functioneren bij een fout (soms maar voor korte tijd), maar zonder belangrijk verlies in functionaliteit of performantie n graceful degradation (fail soft) u systeem blijft functioneren bij een fout, met verlies in functionaliteit en/of performantie tijdens herstel u meerdere gradaties zijn hier mogelijk u voor systemen waar beschikbaarheid heel belangrijk is (bv air traffic control) n fail safe u systeem behoudt integriteit maar stopt (beter dan rare dingen) u bv flappen vleugels vliegtuig symmetrisch zetten bij probleem

15 RTP slide 15Programmatuur voor real-time controleYolande Berbers voorbeeld van ‘graceful degradation’: luchtverkeersleiding volledige functionaliteit overname door backupsysteem bij catastrofe nood-functionaliteit waarbij geen vliegtuigen botsen minimale functionaliteit: basis- luchtverkeersleiding

16 RTP slide 16Programmatuur voor real-time controleYolande Berbers fout-tolerantie n vaak-gemaakte verkeerde veronderstellingen u de gebruikte algoritmen werden correct ontworpen u alle falingswijzen van de componenten zijn gekend u alle mogelijke interacties van het systeem met zijn omgeving werden voorzien

17 RTP slide 17Programmatuur voor real-time controleYolande Berbers redundantie n alle technieken voor fout-tolerantie: gebaseerd op redundantie u extra elementen toegevoegd om fouten te detecteren en te herstellen u deze componenten zijn redundant want niet nodig in perfect systeem u terminologie: beschermende redundantie u deze extra componenten kunnen het systeem complexer maken, en zo minder betrouwbaar ! (ook duurder, groter,...) l redundantie-componenten moeten goed gescheiden zijn van rest van systeem l redundantie-componenten moeten tot het minimum beperkt worden n groot deel van rest van hdst behandelt software-redundantie

18 RTP slide 18Programmatuur voor real-time controleYolande Berbers hardware-redundantie n statische redundantie u extra componenten die het effect van fouten verbergen u vb: 3 identieke sub-componenten (TMR Triple Modular Redundancy) die allen een resultaat geven, en waartussen gestemd wordt (dus een fout wordt weg-gemaskeerd) u veronderstelling: geen gelijke fouten bij de drie (bv ontwerpfout), wel bv voorbijgaande fout of foutieve component u algemeen: N identieke comp. (NMR) om meer fouten te maskeren n dynamische redundantie u redundantie voorzien binnen een component die fouten detecteert u de component geeft aan dat er een fout is u een andere component moet de fout opvangen u vb: checksums bij transmissie, pariteitsbits van het geheugen n hier wordt verder niet op ingegaan

19 RTP slide 19Programmatuur voor real-time controleYolande Berbers software redundantie n software redundantie u analoog aan hardware redundantie l statische redundantie s genoemd N-version programming l dynamische redundantie s gebaseerd op error detectie en herstel

20 RTP slide 20Programmatuur voor real-time controleYolande Berbers N-versie-programmering n wordt gebruikt voor verbergen van ontwerp-fouten (software kan niet ‘defect’ worden zoals hardware componenten) n onafhankelijk ontwerp van N (>2) functioneel equivalente programma's vertrekkend van dezelfde specificatie u door verschillende mensen of groepen van mensen, die niet met elkaar in contact komen u andere benaming: diversiteit van ontwerp u een vergelijkingsmodule vergelijkt de uitkomst bekomen door de verschillende programma’s en neemt hieruit een besluit n veronderstellingen u programma kan ondubbelzinnig gespecifieerd worden u bekomen programma’s zullen onafhankelijk fouten veroorzaken u geen relatie tussen fouten in de ene en fouten in de andere

21 RTP slide 21Programmatuur voor real-time controleYolande Berbers N-versie-programmering versie 1versie 2versie 3 resultaat vergelijkings- module

22 RTP slide 22Programmatuur voor real-time controleYolande Berbers N-versie-programmering n voorzorgen u gebruik van verschillende talen u gebruik van verschillende compilers en softwareontwerp- omgevingen u gebruik van verschillende processoren zodat ook tegelijk hardware-redundantie gebruikt wordt u vb: vluchtcontrole-systeem van Boeing 777: 3 verschillende programma’s in Ada op 3 verschillende processoren, gecompileerd door 3 verschillende compilers n fout bij Ariane had misschien kunnen vermeden worden met N-versie-programmering

23 RTP slide 23Programmatuur voor real-time controleYolande Berbers N-versie-programmering n vereenvoudigde rol van de vergelijkingsmodule u roept de verschillende versies op u wacht op de resultaten u vergelijkt en kiest n in werkelijkheid kan meer interactie nodig zijn u vaak periodische functies bij real-time en embedded systemen u men wil tussenresultaten al vergelijken u de vergelijkingsmodule kan op basis van tussenresultaten versies uitschakelen, of andere tussenresultaten doorgegeven

24 RTP slide 24Programmatuur voor real-time controleYolande Berbers N-versie-programmering n soort interactie (zie ook volgende transparant) u vergelijkingsvector (kan meer dan 1 resultaat zijn) u status: informatie over hoe het resultaat verkregen werd l bv recente radarmetingen, of extrapolatie van oude waarden u acties te ondernemen door versies

25 RTP slide 25Programmatuur voor real-time controleYolande Berbers N-versie-programmering versie 1versie 2versie 3 resultaten en status acties vergelijkings- module

26 RTP slide 26Programmatuur voor real-time controleYolande Berbers N-versie-programmering n mogelijke complicaties u de verschillende versies zijn in verschillende talen geschreven l het formaat van de resultaten is lichtjes verschillend l communicatie gebeurt anders (zie latere hoofdstukken) u de antwoorden komen niet tegelijk (een bepaalde versie kan veel minder efficiënt zijn dan een andere) l moet de vergelijkingsmodule blijven wachten of zit één versie in een oneindige lus ? n granulariteit van interactie u vaak: meer overhead, structuur versies moet meer gelijk zijn u minder vaak: grotere divergentie tussen de resultaten

27 RTP slide 27Programmatuur voor real-time controleYolande Berbers vergelijking van resultaten n geen probleem voor integers of tekst n vaak zijn resultaten niet zo exact (bv reële getallen) u gevolg van verschillende hardwarevoorstellingen u gevolg van verschillende berekeningen, zodat de afrondingsfouten verschillend zijn u niet-exacte stemming: aangepaste vergelijkingstechnieken n resultaten kunnen verschillen, maar allemaal eigenlijk goed zijn u als er meerdere oplossingen zijn (wortel van 4degraadsvergelijking) u consequent vergelijkingsprobleem l versies vergelijken elk gemeten waarden en drempels, waarbij de gemeten waarden heel dicht bij de drempel liggen l vb (zie volgende slide): temperatuurdrempel Td, drukdrempel Pd

28 RTP slide 28Programmatuur voor real-time controleYolande Berbers vergelijking van resultaten yes no > Td T3T3 T2T2 T1T1 > Pd P1P1 P2P2 P3P3 V1V1 V2V2 V3V3

29 RTP slide 29Programmatuur voor real-time controleYolande Berbers discussiepunten bij N-versie prog. n initiële specificatie u meeste software fouten zouden voortkomen van slechte specificatie l niet compleet, inconsistent, niet begrijpbaar, dubbelzinnig u formele notaties helpen u fout in specificatie zal optreden in alle N versies n onafhankelijkheid van ontwerp u er bestaat geen eensgezindheid over het niet optreden van gelijke fouten in N verschillende versies n budget u kost N maal hoger, onderhoud zeer moeilijk u contractor zal dit daarom nooit zelf voorstellen, behalve als verplicht u al het geld besteden aan één versie geeft misschien betrouwbaarder resultaat

30 RTP slide 30Programmatuur voor real-time controleYolande Berbers dynamische software redundantie n N-versie-programmering is statisch u elke versie heeft een vaste relatie tot het geheel u elke versie wordt gebruikt, of er nu fouten optreden of niet n dynamische redundantie u redundante componenten treden enkel in actie na ontdekking dwaling u 4 fazen l dwaling-detectie l schadediagnose en schadebeperking, o.a. analyse van het effect van de dwaling (verkeerde resultaten kunnen al verspreid zijn) l herstel van dwaling, o.a. terugbrengen naar toestand van waar normale werking weer mogelijk is (ev. met minder functionaliteit) l behandeling van de fout zelf (anders kan die weer toeslaan)

31 RTP slide 31Programmatuur voor real-time controleYolande Berbers 1. dwaling-detectie n 2 klassen u detectie door de omgeving l vb door de processor (illegale instructie, overflow, deling door 0, segmentation violation) l vb door het run-time systeem (een index die buiten het bereik van een rij gaat) l dit wordt besproken in hoofdstuk 6 l vb door besturingssysteem (scheduling, zie volgende slide) u detectie door de toepassing (zie verdere slides)

32 RTP slide 32Programmatuur voor real-time controleYolande Berbers intermezzo: besturingssysteem en run time systeem n een programma draait bovenop een run-time systeem (soms afgekort als RTS) n het run-time systeem draait bovenop het besturingssysteem hardware besturingssysteem run-time systeem code gegenereerd door compiler programma

33 RTP slide 33Programmatuur voor real-time controleYolande Berbers detectie door de toepassing (7 soorten) n detectie via replicatie u mogelijk vanaf 2 versies l indien de 2 versies verschillend resultaat geven: eentje moet fout zijn n detectie via codering u test op corrupte gegevens u gebaseerd op redundante informatie in de gegevens u vb checksum

34 RTP slide 34Programmatuur voor real-time controleYolande Berbers detectie door de toepassing n detectie via structurele testen u controleren van integriteit van gegevensstructuren u gebaseerd op extra informatie u vb: gelinkte lijsten l aantal elementen l redundante pointers (dubbel gelinkt, circulair) l andere status informatie

35 RTP slide 35Programmatuur voor real-time controleYolande Berbers detectie door de toepassing n detectie via tijdsmetingen u wachthondtimer: l moet een signaal krijgen om de zoveel tijd l signaal komt niet: component zal niet meer reageren u het missen van deadline door bepaalde component opmerken l kan opgemerkt worden door andere component van toepassing l kan opgemerkt worden door de scheduling: eigenlijk detectie door omgeving (zie hoofdstuk 13) u deze technieken zeggen niets over correctheid van waarde van resultaat, enkel over de timing

36 RTP slide 36Programmatuur voor real-time controleYolande Berbers detectie door de toepassing n detectie via omgekeerde berekeningen u wanneer uit de output de input kan berekend worden, kun je de juistheid nagaan (bv vierkantswortel) u speciale technieken nodig als je werkt met reële getallen n detectie via redelijkheidstesten u gebaseerd op kennis van de toepassing (“kan dit resultaat wel”) u gebeurt veel via beperking van waardenbereik door programmeertaal u asserties zijn hier een vorm van l logische expressies, worden tijdens uitvoering ge-evalueerd

37 RTP slide 37Programmatuur voor real-time controleYolande Berbers detectie door de toepassing n detectie via dynamische redelijkheidstesten u vb bij regelingen maakt output meestal geen zware sprongen u dynamisch omdat de waarden niet vergeleken worden met vooraf gekende waarden u wordt dit extern getest: detectie door omgeving

38 RTP slide 38Programmatuur voor real-time controleYolande Berbers 2. schadediagnose en schadebeperking n noodzaak: u tijd kan verstreken zijn tussen het optreden van een fout en de detectie van een dwaling die hier het gevolg van is n schadebeperkingsmaatregelen u moeten reeds bij het ontwerp van de software voorzien zijn n veel gebruikte naam: firewall (o.a. internet)

39 RTP slide 39Programmatuur voor real-time controleYolande Berbers schadediagnose en schadebeperking n methoden u 2 structurele methodes (zie volgende slides) l modulaire decompositie (statische structuur) l atomaire acties (dynamische structuur) u andere methodes l beveiliging gelijktijdig gebruik van hulpmiddelen (zie Hdst 11) l protectiemechanismen (beveiligingsmaatregelen) s bv gebaseerd op toegangscontrolelijsten s bv wie (of welke software) mag wat doen –met welk stuk geheugen –met welk bestand

40 RTP slide 40Programmatuur voor real-time controleYolande Berbers schadediagnose en schadebeperking l modulaire decompositie (statische structuur) s besproken in Hoofdstuk 4 s verbergen van interne voorstelling –fouten worden minder vaak gemaakt –fouten planten zich minder gemakkelijk voort naar andere modules s duidelijke grenzen van een module –goed gedefinieerde interfaces –maakt het makkelijker om met asserties te werken

41 RTP slide 41Programmatuur voor real-time controleYolande Berbers schadediagnose en schadebeperking l atomaire acties (dynamische structuur) (zie Hdst 10) s een actie die een “alles-of-niets” effect heeft s voor de buitenwereld is deze actie ondeelbaar, ze is precies ogenblikkelijk s andere namen: transactie, atomaire transactie s het systeem zal overgaan van een consistente toestand naar een andere consistente toestand s aan het einde van de actie wordt nagegaan of de actie het systeem in een consistente toestand brengt (=commit)

42 RTP slide 42Programmatuur voor real-time controleYolande Berbers 3. herstel van de dwaling n meest belangrijke faze van fout-tolerantie n 2 aanpakken: voorwaarts en achterwaarts herstel n voorwaarts herstel u gaat van een foutieve toestand naar een consistente toestand door selectieve herstellingen u dit is zeer toepassingsafhankelijk, men kan er weinig algemene zaken over zeggen u gebaseerd op juiste voorspelling van oorsprong van fout en van toegebrachte schade u voorbeeld: inbrengen van extra pointers, redundante informatie zodat verloren of foutieve informatie hersteld kan worden (dubbel-gelinkte lijst, code-theorie)

43 RTP slide 43Programmatuur voor real-time controleYolande Berbers herstel van de dwaling n achterwaarts herstel u methode l brengt systeem terug in een (vroegere) consistente toestand l een ander deel van het programma wordt daarna uitgevoerd, dat een andere versie is u terminologie: dit heet checkpointing vanaf een herstelpunt u vereisten l bijhouden van eerdere consistente toestanden l bijhouden van input tussen consistente toestand en dwaling u voordeel l men moet de precieze plaats van de fout niet kennen l kan ondersteund worden door ‘systeem’, onafhankelijk van de toepassing (separation of concerns)

44 RTP slide 44Programmatuur voor real-time controleYolande Berbers achterwaarts herstel: checkpointing verloop van toepassing herstelpunt herstelling van toestand detectie van dwaling eerste versie andere versie herstelpunt fout

45 RTP slide 45Programmatuur voor real-time controleYolande Berbers herstel van de dwaling u nadelen van achterwaarts herstel l doet schade niet teniet l kan veel tijd in beslag nemen s zowel voor het bijhouden van de herstelpunten s als voor het herstellen zelf s is vaak niet redelijk bij real-time systemen l vergt heel veel geheugen l oplossingen s incrementele checkpointing –bijhouden van welke acties men uitgevoerd heeft (auditing, logs) –deze acties in omgekeerde volgorde teniet doen

46 RTP slide 46Programmatuur voor real-time controleYolande Berbers herstel van de dwaling l problemen bij checkpointing van gescheiden interagerende processen s interactiepunten tussen checkpoints s het domino-effect (zie tekening op volgende transparant) s oplossing: consistente herstellijnen

47 RTP slide 47Programmatuur voor real-time controleYolande Berbers domino-effect R 11 R 12 R 13 R 21 R 22 P1P1 P2P2 interactie herstelpunt tijdsas detectie oplossing: consistente herstel- punten, herstellijnen

48 RTP slide 48Programmatuur voor real-time controleYolande Berbers 4. behandeling van de fout n niet omdat fout gevonden werd dat ze hersteld is: ze zou kunnen her-optreden n 2 fazen u opsporing van de precieze fout u herstel van de fout n dit is vaak zeer systeem-specifiek u bv herstel van een hardware component n vergt soms vervanging van een software module u moet in sommige gevallen dynamisch gebeuren (bv bij satellieten)

49 RTP slide 49Programmatuur voor real-time controleYolande Berbers herstelblok: vorm van achterwaarts herstel n taalondersteuning voor achterwaarts herstel u bij begin van een blok: automatisch herstelpunt u bij einde van een blok: een aanvaardingstest u blok in het midden: primaire module n bij niet aanvaarding van uitgangstest na primaire module u programma wordt hersteld tot herstelpunt aan begin van blok u een alternatieve module wordt uitgevoerd n bij niet aanvaarding van uitgangstest na alternatieve module u programma wordt hersteld tot herstelpunt aan begin van blok u een andere alternatieve module wordt uitgevoerd, enz, enz. n mechanisme wordt geïllustreerd in de volgende transparant

50 RTP slide 50Programmatuur voor real-time controleYolande Berbers schema van herstelblok ingang van herstel- blok opmaak van herstel- punt nog alter- natieven ? voer volgend alternatief uit vernietig herstel- punt niet OK OK ja nee uitgang van herstel- blok herstel herstel- punt aan- vaar- dings- test

51 RTP slide 51Programmatuur voor real-time controleYolande Berbers herstelblok n herstelblok maakt geen deel van bestaande real-time taal n mogelijke syntax zou zijn: ensure acceptance test by primary module else by alternative module else by alternative module …. else by alternative module else error

52 RTP slide 52Programmatuur voor real-time controleYolande Berbers herstelblok n hestelblokken kunnen ook genest zijn u als alle alternatieve modules in een genest herstelblok gefaald hebben l buitenste herstelpunt wordt hersteld l een alternatieve module voor het buitenste blok wordt uitgevoerd

53 RTP slide 53Programmatuur voor real-time controleYolande Berbers herstelblok n voorbeeld van gebruik van een herstelblok: oplossen van een differentiaal vergelijking u methode 1: expliciete Kutta methode l snel maar onnauwkeurig bij bepaalde stijve vergelijkingen u methode 2: impliciete Kutta methode l veel trager, maar lost stijve verg. nauwkeurig op u als aanvaardingstest algemeen: ook ontwerpfouten worden gevonden ensure Rounding_error_within_acceptable_tolerance by Explicit Kutta Method else by Implicit Kutta Method else error

54 RTP slide 54Programmatuur voor real-time controleYolande Berbers herstelblok n testen op zowel ontwerp- als afrondingsfouten: ensure Rounding_error_within_acceptable_tolerance by ensure sensible_value by Explicit Kutta Method else by Predictor-Corrector K-step Method else error else by ensure sensible_value by Implicit Kutta Method else by Variable Order K-step Method else error

55 RTP slide 55Programmatuur voor real-time controleYolande Berbers herstelblok n de aanvaardingstest u is een dwaling-detectie mechanisme u ontwerp van de test is cruciaal l compromis tussen volledigheid en efficiëntie l als test foutief is: dwalingen worden niet opgemerkt ! u merk op: term is aanvaardingstest en niet correctheidstest l ook verminderde dienst wordt eventueel toegelaten

56 RTP slide 56Programmatuur voor real-time controleYolande Berbers vgl N-versie programmering en herstelblokken n statische versus dynamische redundantie u N-versie programmering: statische redundantie (alle versies worden altijd uitgevoerd) u herstelblokken: dynamische redundantie (alternatieven worden enkel uitgevoerd als een dwaling ontdekt wordt) n ontwerpoverhead u beide: ontwikkeling van alternatieve algoritmen u N-versie programmering: ontwikkeling van vergelijkingsmodule u herstelblokken: ontwikkeling van een aanvaardingstest n uitvoeringsoverhead u N-versieprogrammering: vraagt N-maal zoveel hulpmiddelen u herstelblokken: vraagt maken van herstelpunten en herstellen zelf (hardware ondersteuning voor maken van herstelpunten is mogelijk)

57 RTP slide 57Programmatuur voor real-time controleYolande Berbers vgl N-versie programmering en herstelblokken n diversiteit van ontwerp u door beide gebruikt u beide dus gevoelig aan fouten in specificatie n dwaling-detectie u N-versie programmering: vergelijkt verschillende resultaten l indien vergelijking mogelijk: efficiënter dan aanvaardingstest u herstelblokken: aanvaardingstest l biedt meer flexibiliteit s bij niet-exacte stemming s wanneer meerdere goede oplossingen bestaan s bij consistent vergelijkingsprobleem

58 RTP slide 58Programmatuur voor real-time controleYolande Berbers vgl N-versie programmering en herstelblokken n atomiciteit u N-versie programmering: vergelijking en keuze voordat interactie met omgeving plaatsvindt (per definitie) u herstelblokken: kunnen ook zo gestructureerd worden dat er pas interactie is met omgeving na aanvaardingstest (dan is er ook geen interactie met omgeving tijdens blok)

59 RTP slide 59Programmatuur voor real-time controleYolande Berbers dynamische redundantie en uitzonderingen n terminologie u uitzondering: het optreden van een dwaling (in het Engels: exception) u een uitzondering signaleren (of werpen): de oproeper van een operatie attent maken op de uitzondering (in het Engels: raising, signalling, throwing) u behandeling (of opvang) van uitzondering: actie die oproeper neemt n behandelen van uitzondering: u normaal vorm van voorwaarts herstel u kan ook gebruikt (misbruikt) worden voor achterwaarts herstel

60 RTP slide 60Programmatuur voor real-time controleYolande Berbers dynamische redundantie en uitzonderingen n waarvoor werden uitzonderingen niet/wel ingevoerd: u niet: voor vinden van ontwerpfouten (maar kunnen er voor dienen) u wel: voor behandeling van abnormale situaties n uitzonderingen worden algemeen gebruikt voor u behandeling van abnormale situaties in de omgeving u tolereren van ontwerpfouten u aanbieden van algemene dwalingdetectie- en herstel-methode

61 RTP slide 61Programmatuur voor real-time controleYolande Berbers dynamische redundantie en uitzonderingen dienst aanvraag normaal antwoord interface uitzondering faling uitzondering dienst aanvraag normaal antwoord interface uitzondering faling uitzondering normale werking behandeling uitzondering interne uitzondering terugkeer naar normale werking

62 RTP slide 62Programmatuur voor real-time controleYolande Berbers veiligheid en betrouwbaarheid n veiligheid: vrij van condities die oorzaak zijn van dood, ongelukken, ziekte, beschadiging, verlies, milieuhinder, …. n het veiligste vliegtuig is een vliegtuig dat nooit vliegt ! n is heel toepassing afhankelijk

63 RTP slide 63Programmatuur voor real-time controleYolande Berbers betrouwbaarheid (dependability) n engels - nederlands u dependability - betrouwbaarheid u reliability - betrouwbaarheid n betrouwbaarheid (dependability) heeft heel veel aspecten u beschikbaar (available): het is klaar om te gebruiken u stabiliteit (reliable): continuïteit in dienstverlening u veilig (safe): geen catastrofale gevolgen u confidentieel: geen uitgave van geheime informatie u integer: geen ongepaste wijziging van informatie u onderhoudbaarheid: herstellingen en evoluties zijn mogelijk