Hasardidentifikasjon

Presentasjon om: "Hasardidentifikasjon"— Utskrift av presentasjonen:

1 Hasardidentifikasjon
Hvordan finne ut hva som kan gå GALT – FØR det går galt. Kap. 3 i Storey Sannsynligvis den viktigste mekanismen for å forbedre safety i et system er å identifisere måtene et system kan gjøre skade. Når problemområdene er identifisert, så kan viktighetsgraden av dem vurderes. Hvis de er signifikante må passende tiltak iverksettes for å fjerne eller dempe deres effekter.

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. Situasjoner som kan forårsake skade kalles en hasard. Eks: Bli truffet av en metioritt. - Bli slått ned av lynet. Falle av en sykkel. - Flystyrt. Tråkke på en tegnestift. - Feil på bremser. Kollidere med bilen. - Signalfeil på toglinje. Feil informasjon om kjøreretning, etc. Hvis en slik hendelse inntraff ville vi kalle det en ulykke, mens potensialet for at en slik ulykke skal skje kalles en hasard.

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
Denne risk management prosessen er hentet fra AS/NZS 4360

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. Identify context: Identifiserer ”target of evaluation” og definerer rammen og bakgrunnen for analysen. I tillegg må hvilke krav en må forholde seg til identifiseres. Identify risks: identifiser hasarder, hva kan gå galt og hvordan dette kan skje? Analyse risks: hva er sannsynligheten for at den uønskede hendelsen skal inntreffe og hvilke konsekvenser har den. Evaluate risks: bestemmer risikonivå, prioriterer risikoer og kategoriser risikoer. Treat risks: Identifikasjon 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 Eksempel på top-down analyse
#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; 1. Omgivelser 2. Grensesnitt mot bruker 3. Design/prosessbeskrivelse 4. Programkode

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 Sequence diagram in UML

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 Coincident failure: Når to eller flere funksjonelt like software komponenter feiler på samme input. Vi sier at flere komponenter inneholder en common-cause fault hvis feilens natur, dens variable og funksjonene den påvirker er lik for alle komponenter.

19 Ressurser på nett

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. 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. For hvert avvik prøver teamet å svare på en rekke spørsmål for å bestemme om avviket kan inntreffe , og hvis så, om det kan resultere in en hasard. Hvor potensielle hasarder er oppdaget stilles flere spørsmål for å bestemme når det kan inntreffe

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. Erfaring viser at disse ledeordene også er brukbare for andre systemer, f.eks i computersammenheng. Men de må tolkes annerledes (se eks. i lærebok).

22 Litt forenklet fremgangsmåte
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 Arrangere nødvendige møter
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.