Transcript Utvikling av kritiske systemer

Hasardidentifikasjon
Hvordan finne ut hva som kan gå
GALT –
FØR det går galt.
Kap. 3 i Storey
1
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.
2
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
3
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?
4
– Kople analysemetoder og modeller
Risk Management Process
5
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.
6
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.
7
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
8
Mange typer grunnlagsmateriale
For eksempel:
• Kravdokumenter
• Tekniske tegninger
• Data/kommandoflyt
• Brukergrensesnitt
• Meldingssekvensdiagrammer
• Kodestruktur
• Kode
• Tilstandsmaskiner
• mm
9
Gjøres i alle faser av utvikling
”Top-down” satt sammen av flere ”bottom-up”
Top-Down
Bottom-up
Bottom-up
Bottom-up
10
Krav
Design
Kode
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
11
Eksempel på top-down analyse
1. Omgivelser
#include
#include
#include
#include
2. Grensesnitt mot bruker
<stdio.h>
<conio.h>
<math.h>
<string.h>
int i,j,n;
long double a,Ta,f,pmin,pstep,fmin;
FILE *fp;
char *fnavn[12],*ttxt[12],*svar;
12
long double fak(k)
int k;
{
int i;
long double j;
4. Programkode
3. Design/prosessbeskrivelse
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.
13
• I FMECA vil man også klassifisere feilene i henhold
til sannsynlighet og alvorlighet (criticality).
• Teknikken kan benyttes ved ulike faser i
utviklingsprosjektet.
FMEA Eksempel 1
ID Enhet
#
1
2
14
Bryter
som
registrer
er om
utstyr er
på plass
Feil-modus
Årsak
Lokal effekt
System
effekt
Tiltak
Indikerer
”åpen” når
den skulle
indikert
”lukket”
1. Brudd
2. Ekstrem
temperatur
Detekterer
ikke at utstyr
er på plass.
Umulig å
bruke maskin,
system er
”failsafe”.
Bruk bryter av
høy kvalitet.
Indikerer
”lukket når
den skulle
indikert
”åpen”.
1. Kortslutning
i bryter
2. Høy
spenning
System
indikerer
feilaktig at
utstyr er på
plass.
Preventivt
vedlikehold og
jevnlige
inspeksjoner.
Maskin tillates Legg til
brukt selv om tilleggsutstyr ikke er
kontroller?
på plass,
system er
”unsafe”.
new responsible
: Terminal
: Acd
FMEA - Eksempel 2
: TLTRul es
primary :
Term inal
secondary :
Terminal
1: GrabServiceGroup(AG, SG, RelationState)
Request can be
initiated from new
responsible or, e.g.,
Signal system.
2: GrabServiceGroupOk(SG, AG, RelationState)
Is it Ok to grab?
Old primary responsible
looses responsibility
Removes calls from
queue
For each call in SG
queue
3 : Dea ssig nAgent(S G, AG, Rel ationSt ate)
4: RemoveCall(AcdCallHandle)
5: DeassignAgent(SG, AG, RelationState)
Secondary
responsible (if any)
6: RemoveCall(AcdCallHandle)
looses responsibility.
Removes calls from
queue
7: AssignAgent(AG, SG, R el ationS tate)
Now is primary
responsible
Add calls to queue
8: Incomin gC all(AcdCallHandle, CallInform ation)
9: AgentRelationship(SG, AG, Re lationState)
All other agents are
updated with
information
15
10: GrabServiceGroupDone(SG, AG, RelationState)
others :
Term inal
FMEA - Eksempel 2
Aksjon /
melding
1. GrabSer
vice
Group
16
Feilmåter
Feileffekt (med referanse til identifiserte hasarder)
Alv.kl. Test
#
3
a) Parameter Feil togleder identifiseres og får oppdatert ansvar,
AG feil.
hasard 2
i) Ansvar det ikke er bedt om vil bli tildelt
ii) Ansvar som skulle beholdes blir fjernet (hvis sg
identifiserer mer enn 1 gruppe)
iii)Ansvar som ønskes, blir ikke tildelt
b) Parameter Feil servicegruppe identifiseres og får oppdatert ansvar, 3
SG feil
hasard 2
i) Ansvar det ikke er bedt om vil bli tildelt
ii) Ansvar som ønskes, blir ikke tildelt
Et virkelig FMECA skjema - fra analyse av SW-design
17
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”
18
• 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
Ressurser på nett
• http://www.fmeainfocentre.com/
19
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.
20
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.
21
• 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.
Start
Forklar overordnet design
Litt forenklet
fremgangsmåte
Velg enhet
Velg ledeord + attributt
Ja
Mulige avvik?
Nei
Nei
Ferdig med alle
ledeord/attributter?
Ja
Nei
Ferdig med alle enheter?
Ja
22
Slutt
Undersøk årsaker,
konsekvenser,
mulig beskyttelse
og dokumenter
HazOp - Programvarespesifikke ledeord
(Tor Stålhane, SINTEF)
Objekt type Ledeord
Prosess
Funksjonalitet
Input / output
Datalagring
Lagring
Input / output
Informasjon
23
Informasjon
Avvik
Total eller delvis feil
Ikke all input blir brukt på riktig måte
Uønsket input blir brukt
Deler av output ikke påvirket
Ustabil
Ødelagt
Kan ikke hentes ut
Støy blir lagret
Total eller delvis feil
Uønskede data
Feil
Inkonsistent
Ingen
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.
24
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
25
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)
26
• 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.
Eksempel og rapportskjema
27
Del av
system
Alarm
Ledeord
Avvik
Konsekvenser
Årsaker
Foreslått løsning
Ingen
Ingen
alarm
Person i
faresonen
varsles ikke
1. Person i
faresonen er
ikke oppdaget.
2. Person i
faresonen er
oppdaget, men
alarm utløses
ikke.
1. Forbedre
sensorer
2. Korrigere alarmalgoritme
Alarm
Feil
Feil alarm
Person i
faresonen
varsles ikke og
det utløses en
annen falsk
alarm.
3. Feil i alarmalgoritme
4. Feil i alarmliste henvisning
3. Korrigere alarm
algoritme
4. Korrigere liste
håndtering/sorte
ring
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.
28
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.
29
Oppgaver Uke 3
- Kap 3: 1, 3, 4, 7, 8, 9, 11.
30