Oppgave gjennomgang Kap. 5 og 6.

Presentasjon om: "Oppgave gjennomgang Kap. 5 og 6."— Utskrift av presentasjonen:

1 Oppgave gjennomgang Kap. 5 og 6

2 Oppgaver Kap 5: 1, 6, 7, 9, 10, 11, 12, 13, 18, 23, Kap 6: 3, 4, 14, 15, 16, 17, 18, 34, 35, 36, 37, 38

3 Svar på spørsmål 5.1 De fire hovedteknikkene for å sikre ”safety” gjennom design er: Å produsere et system som er ”safe” i seg selv. Benytte designteknikker som hindrer eller minimerer tilfellene av hasarder (interlocks, guards). Benytte teknikker som kontrollerer hasarder når de oppstår (failsafe devices, damage control and containment). Benytte teknikker som har som mål å redusere skadene av hasarder (warning devices, the training of staff in emergency procedures).

4 Svar på spørsmål 5.6 og 5.7 6) V-modellen identifiserer de ulike stegene i utviklingsprosessen og indikerer avhengigheter og relasjoner mellom de ulike stegene. Modellen kan tegnes på forskjellige måter og vise ulike nivåer av detaljer. Den kan f.eks. vise output fra hver fase og flyten av data mellom fasene. Se figurene 1.4, 5.1 og 12.1 i boka. 7) En enkel ”safety” livssyklusmodell kan benyttes til å modellere et system, uansett hvilket sikkerhetsnivå (integrity level) det har. Aktivitetene som utføres i hver fase vil derimot variere utifra hvilket sikkerhetsnivå en modellerer.

5 Svar på spørsmål 5.9, 5.10, 511 9) Viktige karakteristikker av en system spesifikasjon inkluderer: Correctness Completeness (en spesifikasjon må også si hva et system ikke skal gjøre). Consistency (en spesifikasjon må ikke si forskjellige ting på forskjellige steder). Unambiguity. 10) En vanlig årsak til ufullstendig spesifikasjon er at man ikke spesifiserer hva systemet skal gjøre i situasjoner som vi anser å være umulige. 11) Det er svært vanskelig å skrive en komplett utvetydig spesifikasjon med et naturlig språk. Utvetydig språk gjør det også vanskelig å benytte automatiske metoder for å sjekke spesifikasjonen om den er riktig, komplett og konsistent. Problem med utvetydighet kan takles ved å benytte semi-formelle eller formelle spesifikasjonsspråk.

6 Svar på spørsmål 5.12 12) Svakheter i spesifikasjonen er ofte ikke synlige før systemet er komplett, og å rette opp i slike feil er da ofte svært kostbart. En måte å takle feil i spesifikasjonen er å benytte software animation, også kjent som prototyping. Denne teknikken benyttes til å illustrere ulike karakteristikker ved systemet definert i spesifikasjonen. Generelt benyttes animasjon til å undersøke spesielle aspekter ved systemet i stedet for å tilfredsstille hele spesifikasjonen. Fordelen med denne teknikken er at den tillater en ingeniør som er ansvarlig for kravdokumentene å undersøke hvilke implikasjoner deres avgjørelser har, og gir dem mulighet til å endre feil før hele systemet er designet ferdig. Denne prosessen belyser også misforståelser i kravene forårsaket av tvetydighet. Teknikken er ulik fra simulering som studerer utførelsen av et forsøksdesign. Software animation benyttes til å validere spesifikasjonen, mens simulering benyttes til å undersøke design.

7 Svar på spørsmål 5.13 13) Progressive integration: Her kombineres først et lite antall moduler for å lage et minimalt system, som deretter testes (problemer som oppdages fjernes). Deretter legges det til ekstra moduler etter hverandre og testing utføres i hvert steg. Denne prosessen fortsetter helt til systemet er fullstendig. Big bang integration: Her kombineres alle modulene umiddelbart og hele systemet testes som en helhet.

8 Svar på spørsmål 5.18 18) Det er naturlig å etablere en strategi for operasjon og vedlikehold av systemet på et tidlig tidspunkt, når den kan påvirke design prosessen. Ofte utføres planleggingen av operasjon og vedlikehold i parallell med design fasen.

9 Svar på spørsmål 5.23 23) Hovedaktivitetene i en ”safety analysis process” er: 1) Analyser hasardene. a) identifiser potensielle hasarder. b) evaluer hendelsene som leder til disse hasardene. 2) Identifiser ”safety-related” systemer. 3) Sett sikkerhetsnivå (safety integrity level) for disse systemene. 4) Design systemet ved å benytte kriteriene som ligger til grunn for det sikkerhetsnivået som er satt. 5) Utfør en sikkerhetsnivåanalyse som fastsetter hvilket sikkerhetsnivå som systemet har oppnådd. 6) Forsikre, utifra resultatene i analysen i 5), at sikkerhetsnivået som ble satt i 3) har blitt oppnådd. Sikkerhetsanalyse er en vedvarende prosess som fortsetter igjennom hele utviklingsprosessen.

10 Svar på spørsmål 6.3 3) 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.

11 Svar på spørsmål 6.4 4) Permanent Transient Intermittent
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. alfapartikler som endrer bitmønster i minnebrikker. Intermittent Feil som kan inntreffe, forsvinne for så å komme tilbake igjen. Resultat av f.eks. dårlige loddinger, manglende beskyttelse mot elektromagnetisk stråling.

12 Svar på spørsmål 6.14, 6.15 14) Fault coverage: Andelen av alle faults som er håndtert med ”avoidance”, ”removal”, ”detection” eller ”tolerance”. Vanlige mål inkluderer: - fault removal coverage (the success in finding faults during the testing phase of system development) - fault detection coverage (the ability of a system to detect faults during operation) - fault tolerance coverage (the ability of a system to tolerate faults) 15) Redundans: Bruk av ekstra enheter/funksjonalitet i et system, som ikke er nødvendig hvis systemet er feilfritt, og som har som mål å tolerere feil.

13 Svar på spørsmål 6.16, 6.17 16) Failures som er et resultat av lignende faults i redundante moduler kalles ”common-mode failures” (fellesfeil). Slike problemer kan takles ved å forbedre dependabiliteten til de enkelte modulene, men takles mest effektivt med å benytte diversitet. 17) I diverse systemer implementeres samme funksjonalitet på forskjellige måter. Diversitet kan benyttes til å takle tilfeldige komponent feil og noen former for designfeil. Diversitet vil derimot ikke takle feil i spesifikasjonen siden de diverse implementasjonene er utviklet utifra den samme (feilaktige) spesifikasjonen.

14 Svar på spørsmål 6.18, 6.34 18) Bruk av diversitet løser ikke alle problemene med common-mode failures (fellesfeil) fordi: 1) Diversitet takler ikke spesifikasjonsfeil. 2) Erfaring viser at selv ulike (diverse) designteam gjør de samme design feilene. 34) Software 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.

15 Svar på spørsmål 6.35 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. M1 M2 M3 MN ……. input Voter system feil modul 1 modul N Riktig output modul output

16 Svar på spørsmål 6.36 Recovery blocks benytter flere forskjellige programversjoner, men i motsetning til N-versjon programmering kjøres disse ikke i parallell. Den avgjørende modulen er en aksept test. Prosessen begynner med at outputen fra den første versjonen testes for aksept. Hvis outputen ikke aksepteres, vil systemet gå tilbake til den systemtilstanden det var i før den første versjonen ble kjørt (kan gjøres ved å etablere ”recovery point”). Deretter blir den andre versjonen kjørt og dens output testet for aksept, osv. Hvis alle programversjonene (modulene) kjøres og ingen aksepteres så vil systemet feile.

17 Svar på spørsmål 6.36 ……… M1 M2 M3 Mn A1 A2 A3 An input modul 1
aksept test 1 modul N suksess riktig output system feil aksept test N

18 Svar på spørsmål 6.37, 6.38 37) Duplisering av identiske software moduler gir ingen beskyttelse mot software feil, sidene de samme feilene vil være tilstede i alle versjonene. 38) Ikke-programmerbare moduler er attraktive i utvikling av sikkerhetskritiske systemer fordi de normalt har lavere kompleksitet enn programmerbare moduler. Ikke-programmerbare enheter er ofte lettest å benytte i systemer som har failsafe tilstander. Derimot er det vanskelig å benytte ikke-programmerbare enheter i systemer som ikke har failsafe tilstander. (eks. backup system for flight control computer).