Hasardidentifikasjon

1. Hasardidentifikasjon Hvordan finne ut hva som kan gå GALT – FØR det går galt. Kap. 3 i Storey

2. Hasard (trussel, uønsket hendelse) • Hendelse/situasjon som potensielt kan medføre skade på mennesker eller miljø. • Bilkollisjon, lynnedslag, flystyrt. • Feil på bremser, signalfeil på toglinje. • Feil informasjon om kjøreretning, tillatt hastighet er angitt feil, etc. • Assosiert med hver av disse hasardene er en risiko, som karakteriseres ved sannsynligheten for at hendelsen skal inntreffe og dens sannsynlige konsekvenser.

3. Risk Management (RM) • Risk Management: • Alle systematiske tiltak en bedrift iverksetter for å oppnå og opprettholde et sikkerhetsnivå i overensstemmelse med de målene en har satt seg. • Spesifisere mål og akseptkriterier for risiko. • Ha et bevisst forhold til hva som kan gå galt, konsekvensene hvis noe går galt og hvilke muligheter man har til å redusere risikoen til et nivå som er akseptabelt. • Vi trenger en ”risk management” process som håndterer: • utvikling, så vel som • drift

4. Generelt om å ”komme i gang” med RM • Hva er ”target of evaluation” (ToE)? • Hvilke krav må vi forholde oss til? • Standarder? • Myndigheter? • Kunder, marked? • Hva trenger vi av informasjon om ToE? • Modeller • Dokumentasjon fra utvikling • Beskrivelse av operasjonell kontekst, etc. • Hvilke analyse metoder må vi bruke for å kunne dokumentere at kravene er oppfylt? • Kople analysemetoder og modeller

5. Risk Management Process

6. Risk Management Process ”Risk Management” prosessen er delt inn i forkjellige faser: • Context identification • Hva, hvorfor, hvilke premisser? • Risk identification • Hva kan gå galt (identifikasjon av hasarder)? • Hvordan kan dette skje (Årsaksanalyse)? • Risk analysis • Analyserer, evaluerer og dokumenterer konsekvensene til uønskede hendelser (konsekvensanalyse) • Anslår sannsynligheten for uønskede hendelser • Risk evaluation • Bestemmer risikonivå, prioriterer risikoer og kategoriser risikoer • Risk treatment • Identifikasjon og evaluering av risikoreduserende tiltak for uønskede hendelser med uakseptabel risiko.

7. Og så…. • ….gjøres gjerne alt sammen om igjen i en iterativ prosess. • Har man foreslått endringer, for eksempel i form av risikoreduserende tiltak har man et nytt system som må analyseres. • Kan selvfølgelig konsentrere arbeidet om de forhold som faktisk har blitt påvirket av endringene.

8. Vanlige metoder for hasardidentifikasjon Hvordan identifisere hva som kan gå galt? De to mest brukte analyse teknikkene er: • Failure Mode Effect Analysis (FMEA/FMEA): • Strukturert gjennomgang av ”alle” enheter • Gjennomføres av en eller flere personer • Hazard and Operability Studies (HazOp): • Styrt brainstorming med 4-8 personer • Tilpasses kontekst

9. Mange typer grunnlagsmateriale For eksempel: • Kravdokumenter • Tekniske tegninger • Data/kommandoflyt • Brukergrensesnitt • Meldingssekvensdiagrammer • Kodestruktur • Kode • Tilstandsmaskiner • mm

10. Gjøres i alle faser av utvikling ”Top-down” satt sammen av flere ”bottom-up”

11. Top-down vs. Buttom-up • De forskjellige ”lagene” kan knyttes sammen med feiltreanalyse (FTA) • Velger analysegrunnlag etter hva som er mest hensiktsmessig for hver enkelt ”lag” i analysen • I noen sammenhenger vil man kreve at bottom-up og top-down er mer kompletterende • Bottom-up helt fra bunn til topp, ”uavhengig” av top-down analysen

12. 2. Grensesnitt mot bruker 1. Omgivelser #include <stdio.h> #include <conio.h> #include <math.h> #include <string.h> int i,j,n; long double a,Ta,f,pmin,pstep,fmin; FILE *fp; char *fnavn[12],*ttxt[12],*svar; long double fak(k) int k; { int i; long double j; 3. Design/prosessbeskrivelse 4. Programkode Eksempel på top-down analyse

13. FME(C)A • Går systematisk igjennom alle komponenter og funksjoner. • For hver komponent/funksjon identifiseres: • alle mulige feilmåter (feilmodier), • mulige årsaker til hver feilmåte, • mulige konsekvenser, både lokalt og for systemet som helhet, av hver feilmåte, • mulige risikoreduserende aksjoner. • I FMECA vil man også klassifisere feilene i henhold til sannsynlighet og alvorlighet (criticality). • Teknikken kan benyttes ved ulike faser i utviklingsprosjektet.

14. FMEA Eksempel 1

15. FMEA - Eksempel 2

16. FMEA - Eksempel 2

17. Et virkelig FMECA skjema - fra analyse av SW-design

18. FMEA - kommentarer • Kan utføres av grupper eller av en enkelt person, men... • Krever god forståelse av systemet • Sentralt for å kunne identifisere • hva som kan gå galt • konsekvenser • I grupper bør 1 være ”djevelens advokat” • Potensielt svært arbeidskrevende fordi den går igjennom mange detaljer, også mange som ikke er kritiske (fordi det er vanskelig på forhånd å avgjøre hva som er kritisk) • Gir en systematisk oversikt over feilene i et system og er en god start for mer kvantitative analyser. • Svært effektiv for systemer som mest sannsynlig vil svikte pga feil i enkeltkomponenter. Derimot ingen god analysemetode for systemer der fellesfeil (common cause failures) anses som et betydelig problem. • Kan utføres i alle utviklingsfaser, og på basis av mange forskjellige modeller/dokumenter

19. Ressurser på nett • http://www.fmeainfocentre.com/

20. Hazard and Operability Studies (HazOp) • Utviklet innen kjemisk industri på 60-tallet. • Brukes i dag mye innen oljeindustrien • Strukturert ”brainstorming”. • Systematisk gjennomgang av systemet sammen med bruk av dedikerte ”ledeord” og ”attributter” som gir en styrt assosiasjonsprosess. • 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. • Må til sammen dekke alle relevante aspekter (system-eiere, brukere, utviklere og eksperter). • HazOp har blitt tilpasset en rekke systemer / kontekster.

21. HazOp - ledeord Opprinnelige ledeord/attributter: • Ledeord: Ikke/ingen, mer, mindre, deler av, mer enn, motsatt, andre/annerledes. • Disse må tolkes i computersammenheng (se lærebok). • Attributter: trykk, temperatur, flyt. Ledeord tilpasset timingproblemer: • Tidlig, sent, før, etter. • Ulike ledeord må gis forskjellige fortolkninger avhengig av i hvilken industri de benyttes. • Derfor må meningen av hvert ledeord defineres som en del av HazOp studien.

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

23. HazOp - Programvarespesifikke ledeord (Tor Stålhane, SINTEF)

24. Bruk av ledeord Setter ofte sammen til utsagn: • Algoritmen ”sorter” bruker feil input. • Sorterer etter feil kriterium. • Sorterer feil kolonne. • Informasjonen ”Eier” kan ikke hentes ut. • Lagringsmedium er skadet. • Har ikke nødvendige aksessrettigheter.

25. Valg av ledeord/attributter • Veldig viktig • Avgjør i stor grad hvilke aspekter man analyserer • Må tilpasses den konkrete situasjon • men bør velges fra anerkjente ”sett” av ledeord og ikke finnes på i ”hytt og pine” • Viktig at formalismen ikke trøtter ut deltagerne

26. HazOp forts. • Forberede studiet • Anskaffe nødvendig data • Omforme dataene, og planlegge studiesekvensen • Dette gjøres av lederen og det er derfor viktig at vedkomne vet hva han/hun gjør • Velger ut lederord (og definerer meningen av ledeordene) og hvordan systemet skal ”angripes”. • Arrangere nødvendige møter • Ikke for lange (maks 3 timer), heller flere. • Utføre analysen • Kombinere ledeord og attributter i en bestemt rekkefølge • Finn mulige avvik • Utvikling av dens årsaker, konsekvenser og foreslått løsning • Dokumentering av resultatene (HazOp-tabell) • Det siste steget i HazOp analyse er å prioritere resultatene og finne områder som bør undersøkes videre. Når hasarder er identifisert er det nytting å undersøke disse videre i en feiltre analyse.

27. Eksempel og rapportskjema

28. HazOp sukssesskriterier • Fullstendig og nøyaktig system og prosessbeskrivelse • Gruppen bør være teknisk dyktige og ha stor systemforståelse. • Gruppen bør ha god evne: • til å avgrense systemet de analyserer (f.eks detaljeringsnivå). • til å konsentrere seg om de alvorlige farene som blir identifisert.

29. HazOp begrensinger • HazOp er avhengig av en god HazOp-leder: • Ikke konkurrere med medlemmene. • Ta seg tid til å høre på alle. • Ikke la noen komme på defensiven. • Sammensetningen av medlemmene er viktig: • Ikke send stedfortredere. • Sett av tid. • Valg av ledeord og attributter! • Krever kreativitet. • Kan være svært effektive men tar ofte svært lang tid.

30. Oppgaver Uke 3 • Kap 3: 1, 3, 4, 7, 8, 9, 11.