Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Skisse til løsningsforslag

Liknende presentasjoner


Presentasjon om: "Skisse til løsningsforslag"— Utskrift av presentasjonen:

1 Skisse til løsningsforslag
Eksamen 20. mai 2005 Hjelpemidler: Ingen Oppgavesettet inneholder både en norsk versjon og en engelsk versjon.

2 Oppgave 1a) Når man arbeider med kritiske systemer er det en del begreper som ligger til grunn. Forklar kort hva som menes med følgende begreper: Safety Sikkerhetskritisk system (safety-critical system) Pålitelighet (reliability) Dependabilitet (dependability)

3 Svar oppgave 1a) Safety: Safety-critical system:
En egenskap et system har til ikke å medføre skade for mennesker eller miljø. Safety-critical system: Et system som har til å oppgave å sørge for safety (som regel i tillegg til å utføre andre funksjoner). Brukes gjerne om alle systemer som ved å feile medfører fare for mennesker og/eller miljø. Pålitelighet (reliability): Sannsynligheten for at system vil fungere tilfredsstillende over en gitt tidsperiode og under gitte forhold. Dependability: Egenskap til et system som gjør at vi kan ha tillit til at systemet fungerer etter intensjonen. Dependability benyttes ofte som et samlebegrep for safety, pålitelighet, tilgjengelighet, integritet, etc.

4 Oppgave 1b) Beskriv i korte trekk de ulike fasene i utviklingen av sikkerhetskritiske systemer. Benytt en livssyklus modell til å presentere de ulike fasene.

5 Svar oppgave 1b) Prosessen med å utvikle sikkerhetskritiske systemer er ofte både komplisert og tidkrevende. Som de fleste utviklingsprosjekter består utviklingen av forskjellige faser. Ofte blir disse fasene presentert gjennom en livssyklus modell (V-modellen, Waterfall modellen, Spiral modellen, RUP). I figuren nedenfor er en skisse av V-modellen vist. Modellen identifiserer hovedelementene i en utviklingsprosess og er kun en tilnærmelse av selve utviklingsprosessen. I praksis blir ikke stegene fullført i en fullt så streng sekvensiell rekkefølge og design involverer ofte en del iterasjon. Modellen viser heller ikke informasjonsflyten mellom stegene.

6 Svar oppgave 1b) Det bør kommenteres at hasard- og risikoanalyser er en aktivitet som foregår under hele utviklingsløpet, integrert i de øvrige aktiviteter Dersom dere også peker på at man ved utvikling av sikkerhetskritiske systemer gjerne begynner å planlegge testing, verifisering og sertifisering tidlig i utviklingsløpet er det også bra.

7 Svar oppgave 1b) Kravanalyse og hasardanalyse: Starten på et hvilken som helst utviklingsprosjekt starter med system krav (customer requirements) som gir oss en abstrakt definisjon av hva systemet skal gjøre. Disse kravene må formaliseres inn i et dokument med funksjonelle krav. Deretter utføres hasard og risikoanalyse for identifisere potensielle farer og å allokere et integritetsnivå. En output fra disse analysene er safety kravene til systemet som definerer hva systemet må gjøre for å sikre safety. Hasard og risikoanalyse er deretter en aktivitet som vil foregå under hele utviklingsløpet, integrert i de øvrige aktiviteter. Utarbeidelse av spesifikasjon: Fra safety kravene og de funksjonelle kravene til systemet utarbeides en spesifikasjon som vil inneholde mål som sikrer safety i henhold til det integritetsinvået som er satt. Overordnet design: Når spesifikasjonen er laget blir denne brukt som basis for top-level design (overordnet design) som definerer arkitekturen til systemet. Top-level designet vil dele systemet inn i mindre moduler for å lette design og teste prosesser. Spesifikasjoner vil designes for hver module.

8 Svar oppgave 1b) Detaljert design: I detaljert design vil hver av modulene bli designet detaljert. Modulkoding og testing. Deretter vil modulene bli kodet og testet individuelt. Systemintegrasjon: Når modulene er ferdige og verifisert, integreres systemet. Systemtest: Til slutt må hele systemet verifiseres og valideres. Sertifisering: Siste steg for safety-critical systems er å overbevise et eksternt organ at systemet er sikkert nok (det en fordel å benytte standarder og guidelines som sikrer sertifisering).

9 Oppgave 1c) Forklar hvordan utviklingsprosessen kan sees på som en sekvens av transformasjoner og definisjoner. Diskuter verifikasjonsprosessen i forhold til denne modellen.

10 Svar oppgave 1c) Spesifikasjonen til et system går igjennom en serie av transformasjoner når systemet beveger seg fra de opprinnelige kravene fra kunden, gjennom spesifikasjon, top-level design, detaljert design etc. til implementasjon. Hver av disse transformasjonene produserer en ny og forhåpentligvis ekvivalent definisjon av det originale systemet. Når kritiske systemer produseres er det viktig at hver av disse transformasjonene er korrekte. Oppgaven med å sikre at en ny definisjon er ekvivalent med den forrige kalles verifikasjon.

11 Oppgave 1d) Verifikasjon og validering oppnås ved å utføre forskjellige tester av systemet. Gi en kort forklaring av begrepene dynamisk og statisk testing.

12 Svar oppgave 1d) Dynamisk testing:
Eksekvering av et antall test cases som undersøker spesielle aspekter ved systemet. Hvert test case inneholder et sett av input data, en spesifikasjon av forventet output og en forklaring av funksjonen som testes. Dynamisk testing inkluderer normalt: Functional testing: identifiserer og tester alle funksjonene til systemet som er definert i kravene. Krever ingen kunnskap om implementasjonen av systemet og er derfor en black-box approach. Structural testing: benytter detaljert kunnskap om den interne strukturen i et system og benytter denne informasjonen til å undersøke individuelle komponenter og deres interaksjoner (white-box approach). Random testing: mens funksjonelle og strukturelle metoder velger input for å undersøke spesielle egenskaper ved systemet, velger random testing input tilfeldig fra hele inputrommet. Prøver å finne feil som ofte blir oversett med mer systematiske fremgangsmåter. Dynamisk testing inneholder altså en miks av black-box og white-box teknikker (se boka)

13 Svar oppgave 1d) Statisk testing:
Statisk testing undersøker egenskaper og struktur ved et system uten å kjøre det. Noen teknikker utføres manuelt (walkthroughs, design reviews, inspections og checklists), andre ved hjelp av automatiserte verktøy. Statiske teknikker kan benyttes til å etablere egenskaper i software eller hardware som er sanne under alle betingelser. Statisk testing (eller statisk analyse) krever kjennskap til naturen av systemet og benytter derfor kun white-box teknikker.

14 Oppgave 2a) Beskriv forskjellen mellom begrepene ”fault”, ”error” og ”failure”. Forklar forskjellen mellom begrepene ”tilfeldige” (random) og ”systematiske” (systematic) faults.

15 Svar oppgave 2a) Fault: Error: System failure:
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.

16 Svar oppgave 2a) Tilstedeværelsen av en fault kan lede til en error, som er mekanismen der en fault blir synlig. En software fault vil kun skape problemer når den delen av programmet der den faktiske feilen befinner seg eksekveres. Hvis tilstedeværelsen av en error vil forårsake systemet i sin helhet til å avvike fra sin forventede funksjon, så sier vi at vi har en system failure. Et av målene i sikkerhetskritiske systemer er at errors ikke skal resultere i system failure. Tilfeldige (random) faults: Tilfeldig feil i HW. Systematiske (systematic) faults: 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. Alle programvarefeil er systematiske feil!

17 Oppgave 2b) Siden ”faults” er uunngåelig vil mye av prosessen med å lage sikkerhetskritiske systemer omhandle hvordan man skal håndtere feil. Redegjør for de fire grunnleggende teknikkene for utvikling av sikkerhetskritiske systemer.

18 Svar oppgave 2b) 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.). Dessverre er ingen av disse metodene 100% effektive, slik at i sikkerhetskritiske systemer benyttes ofte en kombinasjon av disse teknikkene for at system feil skal holdes på et akseptabelt nivå.

19 Oppgave 2c) Forklar kort begrepene redundans og diversitet. Hvilke typer feil takler redundans og hvilke typer feil takler redundans ikke? Løser diversitet problemet med fellesfeil (common-mode failures)? Begrunn svaret.

20 Svar oppgave 2c) 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. Redundans gir beskyttelse mot random HW failures, men ikke mot designfeil (siden identiske moduler sannsynligvis vil utløse samme feil). Sikrer ikke mot fellesfeil (common-mode failures, dvs. failures som er et resultat av lignende faults i redundante moduler). I diverse systemer implementeres samme funksjonalitet på forskjellige måter: Forskjellige typer HW-moduler Forskjellige SW-moduler Diversitet kan benyttes til å takle tilfeldige komponent feil og noen former for designfeil. I tillegg gir diversitet økt sikkerhet mot fellesfeil (i bytte mot økte design kostnader). Bruk av diversitet løser ikke alle problemene med common-mode failures (fellesfeil) fordi: Diversitet i design og implementasjon hjelper ikke mot spesifikasjonsfeil. Da må en i tillegg ha diversitet i spesifikasjon. Erfaring viser at selv ulike (diverse) designteam gjør de samme design feilene. Mennesker har altså en tendens til å gjøre samme type feil.

21 Oppgave 2d) Beskriv to vanlige teknikker som benyttes til å oppnå feiltoleranse i software (benytt gjerne skisser i tillegg til tekst). Hvilke antagelser ligger til grunn for disse teknikkene?

22 Svar oppgave 2d) 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. Begge teknikkene benytter forskjellige programversjoner basert på den samme spesifikasjonen.

23 Svar oppgave 2d) 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.

24 Svar oppgave 2d) ……… A3 M3 Mn A1 A2 An input modul 1 aksept test 1
modul N suksess riktig output system feil aksept test N

25 Svar oppgave 2d) 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 Svar oppgave 2d) M1 M2 M3 MN ……. Voter input system feil modul 1
modul N Riktig output modul output

27 Oppgave 3a) Beskriv grunnprinsippene i en HAZOP, FTA og ETA. Illustrer metodene ved å benytte små eksempler. Hva skiller FTA og ETA fra hverandre?

28 Svar oppgave 3a) HAZOP: Strukturert ”brainstorming”.
En HAZOP studie er en systematisk analyse av hvordan avvik fra normal operasjon i et system kan oppstå og om disse avvikene resulterer i hasarder. Metoden utføres ved å benytte et sett av ledeord og attributter. En HazOp analyse blir vanligvis utført av en gruppe på 4-8 personer med detaljert kunnskap om systemet som analyseres. Ledes av en erfaren HazOp-leder. Systemeiere, brukere og utviklere. Eksperter (prosessteknikk, driftsteknikk osv.) Opprinnelige ledeord kommer fra kjemisk industri: Ikke/ingen, mer, mindre, deler av, mer enn, motsatt, andre/annerledes. Ulike ledeord vil altså gis forskjellige fortolkninger avhengig av i hvilken industri de benyttes. Derfor må meningen av hvert ledeord defineres som en del av HazOp studien.

29 Litt forenklet fremgangsmåte
Start Forklar overordnet design Velg enhet Velg ledeord + attributt Mulige avvik? Ferdig med alle ledeord/attributter? Ferdig med alle enheter? Slutt Undersøk årsaker, konsekvenser, mulig beskyttelse og dokumenter Ja Nei Litt forenklet fremgangsmåte

30 Svar oppgave 3a) ETA: Tar utgangspunkt i hendelser som kan påvirke systemet og kartlegger de mulige videre hendelsesforløp for å bestemme deres mulige konsekvenser. Ser ”fremover” i tid. Disse hendelsene inkluderer både hendelser assosiert med forventet operasjon av systemet og feiltilstander. Fokus på ”barrierer”, dvs. spesielle egenskaper et system har til å stoppe en potensielt farlig utvikling.

31 Svar oppgave 3a) System: Sensor Alarm Nødstopp Hindring på skinne
Hendelse OK System stoppes OK Kollisjon Mulig kollisjon System stoppes, men feil i alarm System stoppes, men feil i sensor System stoppes (av ukjent grunn) Feiler OK Kan anslå konsekvenser OK Feiler Feiler Hindring på skinne Kan anslå sannsynligheter Feiler OK Feiler

32 Svar oppgave 3a) FTA: Grafisk metode som starter med en hendelse direkte relatert til en identifisert hasard som ”topphendelse” og som så forsøker å beskrive/illustrere de mulige årsaker til at topphendelsen inntreffer (”bakover” i tid). Logiske diagrammer Statisk bilde. Gir grunnlag for både kvalitativ og kvantitative analyser. Kan anvendes i både design og drift fase. Deduktiv metode: Arbeider oss ”nedover”. Finner årsakene. Knytter sammen årsaker med logiske porter (AND og OR).

33 Svar oppgave 3a) Tap av styring Eller Feil i styrings algoritme
Feil i beregning Ingen manuell inngripen Feil i styring mekanisme Eller Og

34 Svar oppgave 3a) Et feiltre er annerledes enn et hendelsestre ved at det takler problemene motsatt vei. Hendelsestrær starter med alle mulige hendelser og følger disse fremover for å bestemme deres mulige konsekvenser. Feiltrær derimot starter med identifiserte hasarder og følger disse bakover for å bestemme deres mulige årsaker. FTA er en årsaksanalyse og ser bakover i tid (deduktiv metode. ETA derimot er en konsekvensanalyse og ser fremover i tid (induktiv metode).

35 Oppgave 3b) Ta utgangspunkt i systemskissen og beskrivelsen av de ulike system komponentene gitt nedenfor, og utfør en FMEA av komponentene Eyebot og GPS. Bemerk at analysen ikke behøver å være komplett. Poenget er at du klart og tydelig viser hvordan en FMEA skal gjennomføres.

36 Svar oppgave 3b) d) Dere bør identifisere minst 2 feilmodier for hver komponent og ha med følgende kolonner i tabellen:

37 Oppgave 3c) Hvordan kan resultatene fra en FMEA benyttes videre i en FTA?

38 Svar oppgave 3c) Feiltrær benyttes ofte i assosiasjon med FMEA og HazOp fordi den grafiske naturen av feiltrær ofte forenkler fortolkningen av forskjellige avhengigheter. Feilmodier i FMEA kan identifisere uønskede hendelser, som kan settes som top-hendelser i FTA.

39 Oppgave 3d) Hva menes med begrepene i) kuttmengde og ii) minimal kuttmengde i et feiltre? På hvilken måte kan minimale kuttmengder benyttes i FTA?

40 Svar oppgave 3d) En kuttmengde i et feiltre er en mengde av basishendelser som ved å inntreffe sikrer at topphendelsen inntreffer. En kuttmengde sies å være minimal hvis den ikke kan reduseres Minimale kuttmengder kan benyttes til å beregne sannsynligheten for at topphendelsen skal inntreffe i en FTA.


Laste ned ppt "Skisse til løsningsforslag"

Liknende presentasjoner


Annonser fra Google