Feiltolerant programvare

1. Feiltolerant programvare Hvordan få systemet til å fungere selv om det finnes ”faults”? Kap 6, Storey

2. Fra tidligere Fault: • Defekt i et system (SW, HW, design). Bugs i SW. • Årsaken til error. Error: • Avvik fra forventet oppførsel i system eller sub-system. • Utløses av en fault. • Den delen av systemet som er tilbøyelig til å lede til failure. System failure: • Systemet i sin helhet utfører ikke forventet funksjon

3. Fault Error Failure • Fault avoidance • Fault removal • Fault detection • Fault tolerance Fra tidligere

4. Teknikker • Siden feil er uunngåelig så vil mye av prosessen med å lage sikkerhetskritisk software omhandle hvordan man skal takle feil. • Det finnes en rekke teknikker som kan benyttes for å oppnå sikkerhetskritiske systemer. Disse kan grupperes inn i fire grupper: • Fault avoidance: Å unngå, ved konstruksjon (design metodologier, notasjon, formelle metoder), at feil inntreffer. Dette er hovedpoenget med selve designfasen. • Fault removal: Å oppdage eksisterende feil og eliminere dem (verifikasjon, validering og testing). • Fault detection: Å oppdage feil når systemet opererer i sin operasjonelle profil slik at effektene av feilene kan minimeres eller hindres (Functionality checking, consistency checking, loopback testing etc.). • Fault tolerance: Å sikre, ved defensiv programmering basert på redundans, at service er i overensstemmelse med spesifikasjon selv om feil inntreffer. Tillater altså systemet å operere riktig selv om feil er tilstede (N-version programming, recovery blocks etc.).

5. Introduksjon - Feiltoleranse Feiltoleranse • Evnen til å levere kontinuerlig service til brukere i overensstemmelse med spesifikasjon selv ved tilstedeværelse av feil. Målsetting • Å lage systemet slik at ”faults” ikke medfører ”system failures”. • Feiltoleranse involverer en eller annen form for redundans (redundancy). • Paradoks: Medfører større kompleksitet enn egentlig nødvendig for å utføre tiltenkt oppgave!

6. Introduksjon - Fault tolerance Feiltoleranse brukes bl.a. til å oppnå • mer ”safety” • høyere pålitelighet • større tilgjengelighet • større dependability

7. Typer av ”faults” - Faults kan karakterisere i henhold til: • form (”nature”) , • varighet (”duration), • utbredelse (”extent”). - Form: - Tilfeldig (random) fault • Tilfeldig feil i HW. - Systematisk (systematic) fault • Spesifikasjonsfeil, HW designfeil, SW feil (bug). • Vanligvis defineres disse som design ”faults”. • Feil inntreffer under gitte betingelser og vil inntreffe hver gang betingelsene er til stede.

8. Varighet (”duration”) Varighet: • ”Permanent” • Forsvinner ikke av seg selv. Korrektiv aksjon må utføres. • Designfeil er alltid ”permanent”. • Transient • Feil som inntreffer, men forsvinner etter en liten stund. • F.eks. alfa-partikler som endrer bitmønster i minnebrikker. • Lav frekvens, medfører ingen varige skader. • Intermittent” • Feil som kan inntreffe, forsvinne for så å komme tilbake igjen. • Resultat av f.eks. dårlige loddinger, manglende beskyttelse mot elektromagnetisk stråling. • Bemerk: Permanente feil kan virke som de er intermittent fordi de bare opptrer i spesielle situasjoner.

9. Varighet (”duration”) • SW feil er alltid permanente. • Designfeil er alltid permanente. • HW feil kan være permanente, transiente eller ”intermittent”

10. Utbredelse (”extent”) Utbredelse: • Localized fault (lokal fault) • Har kun effekt for en enkelt HW-komponent eller SW-modul. • Global fault • Effekt av feilen sprer seg utover i hele systemet.

11. SW faults(HW faults er orienteringsstoff) All ikke-triviell SW vil inneholde faults (bugs): • SW spesifikasjonsfeil • kodefeil • logiske feil • Stack ”overflow” og ”underflow” • Uinitialiserte variable • ….. - Software feiler ikke tilfeldig, men er systematiske • Feil inntreffer hver gang fault eksponeres. • SW blir ikke slitt • På grunn av stor kompleksitet er det umulig å oppdage alle faults. Må finne måter vi kan tolerere feil på!

12. Redundans • All feiltoleranse er basert på en eller annen form for redundans. Redundans: • Bruk av ekstra enheter/funksjonalitet som kan ta over dersom andre enheter/funksjoner feiler. • Dersom et system skal kunne fungere selv om feil inntreffer så må det finnes ”back-up” løsninger.

13. Modul 1 Voterings-element Modul 1 Input Output Modul 1 Eks: Triple Modular Redundancy Dette arrangementet kan tolerere feil i en enkelt modul uten at dette påvirker systemets output.

14. Typer av redundans • HW-redundans • Bruk av ekstra HW for deteksjon og toleranse av feil, f.eks. sensorer i et TMR arrangement. • SW-redundans • Bruk av ekstra SW for deteksjon og toleranse av feil (faults). • Informasjonsredundans • Bruk av ekstra informasjon for deteksjon og toleranse av feil, f.eks. checksums • Temporal (time) redundans • Bruk av ekstra tid for deteksjon og toleranse av feil, f.eks. til å repetere beregninger og sammenligning av resultatene (kan avdekke transiente feil)

15. Begrensninger ved redundans • TMR gir beskyttelse mot random HW failures, men ikke mot designfeil (siden identiske moduler sannsynligvis vil utløse samme feil). • Failures som er et resultat av lignende faults i redundante moduler kalles ”common-mode failures” (fellesfeil). • En kan ikke sikre mot slike feil ved kun å benytte flere like enheter. • Vanlig løsning er å kombinere redundans med diversitet.

16. Diversitet • I diverse systemer implementeres samme funksjonalitet på forskjellige måter. • Forskjellige typer HW-moduler • Forskjellige SW-moduler • Gir økt sikkerhet mot common-mode faults (i bytte mot økte design kostnader). • Diversitet i design og implementasjon hjelper ikke mot spesifikasjonsfeil • Kan ha diversitet i spesifikasjon også! • Mennesker har en tendens til å gjøre samme type feil

17. Feildeteksjonsteknikker • Mange feiltoleranseteknikker forutsetter at feil detekteres først. • Det finnes mange teknikker for å oppdage feil, både for HW og SW. Noen aktuelle teknikker er

18. Begrep og uttrykk (1) • Backward recovery: Ulike system tilstander er lagret på forhåndsbestemte recovery points og ved oppdagelse av en feiltilstand så vil systemet settes tilbake til en tidligere lagret systemtilstand og starte på nytt fra denne tilstanden. • Foreward recovery: Transisjon inn i en ny systemtilstand der softwaren kan operere (ofte i en degradert tilstand).

19. Begreper og uttrykk (2) • Acceptance test: En program-spesifikk, feil-oppdagende mekanisme laget av programmereren, som sjekker resultatene ved program eksekvering. • Voting: En voter sammenligner resultatene fra to eller flere funksjonelt like software komponenter og bestemmer hvilke, hvis noen, av disse resultatene er korrekte. Ulike type votere er:

20. SW feiltoleranse Kan være to ting: • Toleranse av SW faults, f.eks. vha. HW. • Toleranse av faults (både HW og SW) ved bruk av SW. • Hvordan kan vi lage SW som håndterer og tolererer faults i SW?

21. Software design teknikker for feiltoleranse: • To vanlige teknikker for SW feiltoleranse er N-versjon programmering og recovery blocks. • Begge teknikkene er basert på redundans og antagelsen om at fellesfeil av komponenter inntrer svært sjelden. • Mer avanserte teknikker for software feiltoleranse kan lages ved å kombinere de to enkle teknikkene til å lage hybride teknikker. • Consensus recovery blocks • Acceptance voting • N self-checking programming

22. Recovery blocks • En av de tidligste teknikkene for feiltoleranse i software. • Den avgjørende modulen er en aksept test. • Benytter flere forskjellige programversjoner, men i motsetning til N-versjon programmering kjøres disse ikke i parallell. • Et potensielt problem med denne teknikken er at det kan være vanskelig å finne enkle og pålitelige aksept tester. • Antar at sannsynligheten for fellesfeil er svært liten.

23. modul N modul 1 input M1 M2 M3 Mn ……… aksept test N aksept test 1 A1 A2 A3 An system feil suksess riktig output Skisse: Recovery blocks

24. Primær modul ? Sekundær modul ? Ikke akseptert Ikke akseptert Akseptert Akseptert Recovery blocks Gjenoppretter systemstatus Recovery-point

25. N-versjon programmering • N-versjon programmering kjører parallell eksekvering av N uavhengig utviklet, funksjonelt like versjoner (basert på samme spesifikasjon). • Avgjørelsen om outputen taes av en voter. • Voteren godtar alle output som input og bruker disse til å bestemme den rette eller beste outputen hvis den eksisterer. • Det antas også her at sannsynligheten for fellesfeil er svært liten.

26. input M1 M2 M3 MN modul 1 modul N ……. modul output Voter system feil Riktig output Skisse: N-versjon programmering

27. N-versjon programmering • Teknikken gir en viss beskyttelse mot feil i SW-design og implementasjon. • Gir ikke beskyttelse mot spesifikasjonsfeil. • Gir ingen garanti mot fellesfeil. • Store utviklingskostnader • Kostnadene øker med en faktor som er større enn N. • Krever mer prosessortid • Lenger tid med en prosessor • Større kostnader og mer kompleksitet med flere prosessorer. • Brukes bare i ekstremt kritiske systemer. • Effekten er omdiskutert.

28. Consensus recovery blocks • En hybrid kombinasjon av recovery blocks og N-versjon programmering. • Teknikken krever n uavhengige programversjoner, en aksept test og en voting prosedyre. • Hvis N-versjon programmering feiler så vil systemet benytte recovery blocks på de samme programversjonene i stedet (aksept test på de samme modul resultatene). • Kun hvis både NVP og RB feiler så vil systemet feile. • Takler både situasjoner med multiple korrekte output og når alle output kun opptrer en gang.

29. input suksess NVP riktig output feil RB riktig output system feil Skisse: Consensus recovery blocks

30. Acceptance voting: • Også en hybrid kombinasjon av N-versjon programmering og recovery blocks. • Motsatt av consensus recovery blocks. • Som i N-versjon programmering eksekveres modulene i parallell. • Outputen fra hver modul blir deretter gitt til en aksept test. • Hvis aksept testen aksepterer outputen sendes den videre til en voter. Voteren får altså kun output som har blitt akseptert av aksept testen. • Systemet feiler hvis voteren ikke mottar noen output.

31. modul 1 M1 M2 M3 Mn modul N modul output ……… A1 A2 A3 An aksept test N aksept test 1 Aksept test output Voter system feil Suksess riktig output Skisse:Acceptance voting

32. N self-checking programming • En variant of N-versjon programmering med recovery. • N moduler eksekveres i par (N er partall). • Outputen fra hvert par testes og hvis de ikke er i overensstemmelse, vil en se bort i fra responsen fra dette paret. • Hvis outputen fra et par stemmer overens, vil denne outputen bli sammenlignet med outputen fra andre par. • Feil oppstår hvis alle parene er i uoverensstemmelse eller hvis parene er i overensstemmelse men produserer ulike output.

33. input M1 M2 M3 M4 modul 1 modul 4 modul output compare compare par feiler par feiler compare system feil riktig output Skisse: N self-checking programming

34. Wrapping • Ideen bak wrapping er å kontrollere input og/eller output fra en komponent ved å sette spesial utviklet software komponenter (wrappers) på input og output sidene av komponenten. • På denne måten vil wrapperen: • Hindre spesiell input fra å nå komponenten. • Sjekke output fra komponenten og sikre at disse møter spesielle krav. • Problemet med wrapping er at det kan være vanskelig å bestemme hvilke input / output komponenten kan takle og hvilke den ikke kan takle.

35. The simplex architecture • Beskytter mot feil i et komplekst system ved å sørge for et enkelt back-up system med høy pålitelighet. • I kontrast til N-versjon programmering har vi her ulike krav (ulik spesifikasjon) til de ulike systemene, mens ett sett av krav prioriterer presentasjon, så prioriterer det andre sikkerhet. • Metoden er ulik wrapping siden den ser på system tilstanden og ikke monitorerer komponenten direkte. • Den kritiske delen ved fremgangsmåten er å oppdage at komponenten mister kontroll og koble over på back-up komponenten tidsnok til å hindre system feil.

36. Valg av arkitektur • Skal safety sikres av HW eller SW? • SW kan utføre mer sofistikerte funksjoner. • SW medfører større kompleksitet. • Det er en fordel å unngå unødig kompleksitet i safety-funksjonene.  Hvis en moduls funksjon kan oppnås ved å benytte ikke-programmerbare systemer , så vil dette ofte foretrekkes.  Hvis det er mulig bør vi skille kontroll og safety funksjoner • safety implementeres i HW og kontroll (ofte kompleks) i SW. • Noen ganger vanskelig (f.eks. i en autopilot)

37. PES 1 PES 1 PES PES 2 PES 2 NP NP PES 1 PES 2 PES 3 Eksempler på arkitekturer for feiltolerante systemer PES = Programmable Electronic System NP = Non Programmable system

38. Fault coverage • Andelen av alle faults som er håndtert med ”avoidance”, ”removal”, ”detection” eller ”tolerance”. • Vanskelig å ha noen formening om hvor stor andelen er (spesielt for ”avoidance”). • Kan gjøre visse analyser som har verdi ved sammenligning av forskjellige design. • Kan bruke feilinjeksjon.