1 Utvikling av kritiske systemer Introduksjon Kap. 1 og 2 i Storey.

Presentasjon om: "1 Utvikling av kritiske systemer Introduksjon Kap. 1 og 2 i Storey."— Utskrift av presentasjonen:

1 1 Utvikling av kritiske systemer Introduksjon Kap. 1 og 2 i Storey

2 2 Praktiske forhold For informasjon om kurset, forelesningsnotater etc., sjekk bloggen jevnlig: http://mobapp.hiof.no/courses/2007/safety/ Nyheter finner dere under courses på News. Forelesere –Monica Kristiansen (monica.kristiansen@hiof.no)monica.kristiansen@hiof.no –Rune Winther, Sizarta Sarshar, samt muligens noen gjesteforelesere. Kurset er todelt: –Teoretisk del: forelesninger og oppgaveløsning, der en introduksjon i utvikling av kritiske programmerbare systemer gis. –Praktisk del: utvikling av feiltolerant programvare for roboter, der den beste gruppa får delta i en robotkonkurranse. For mer informasjon om konkurransen og banen robotene skal kjøre på se: http://www.dtu.dk/Subsites/robocup.aspx

3 3 Introduksjon Formål med kurset: -Gi en oversikt over, og forståelse for, hvordan man kan utvikle programvare for kritiske systemer. -Kritisk system: system som ved å feile kan forårsake betydelige skader på mennesker, miljø eller økonomiske verdier. -Vi krever at kritiske systemer er ”dependable”, dvs at de er: -Sikre -Pålitelige -trygge

4 4 Motivasjon for kurset Fokus er ofte på teknologi: –Språk –Verktøy –Plattformer –”Fancy” tekniske løsninger De målene som ofte anses viktigst er: –”Time to market” –”Cost to market” – Funksjonalitet

5 5 Motivasjon for kurset Resultat: –Dårlig kvalitet –Dårlig sikkerhet –Store kostnader i senere faser av livssyklusen –Tap av menneskeliv, penger og miljø

6 6 -ER DET EGENTLIG SÅ VANSKELIG Å UTVIKLE SIKKER PROGRAMVARE? -ER DÅRLIG PROGRAMVARE NOE PROBLEM?

7

8 8 Eksempel 1: Netcom Netcoms SMS-tjeneste var ute av drift en periode sommeren 2005. –tapt trafikk = tapt inntekt –kompensering i etterkant = tapt inntekt –misfornøyde kunder, presseoppslag = tapt inntekt Netcoms SMS-tjeneste er, for Netcom, et kritisk system!

9 9 Eksempel 2: Therac 25

10 10 Eksempel 2: Therac-25 http://sunnyday.mit.edu/therac-25.html -Et datamaskinstyrt stråle- behandlingsapparat. -Basert på software fra Therac-20 (og Therac-6). -De elektromekaniske sikkerhetsmekanismene på Therac-20 ble erstattet med SW-baserte sikkerhetsmekanismer. I perioden fra Juni 1985 til januar 1987 ble 6 pasienter gitt massive overdoser av stråling. Årsaker: -Liten toleranse ovenfor avvik i inputprosedyre. -Dårlig implementasjon -For stor tiltro på programvare.

11 Eksempel 3: Ariane 5

12

13

14 14 Eksplosjonen av Ariane 5 http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html -4. juni 1996 eksploderte en ubemannet Ariane 5 rakett på sin jomfrutur. -Kun ca 40 sekunder etter ”lift-off” og med en høyde på 3700m, dreide raketten ut av sin flybane, brakk og eksploderte. -Årsaken til feilen var en software feil i referansesystemene (både aktiv og back-up). -Mer spesifikt var det en 64 bit floating point number relatert til horisontal hastighet på raketten som ble konvertert til en 16 bit integer. Nummeret var større enn det maks en 16 bit integer kan lagre og dermed feilet konverteringen.

15 15 Vårt forhold til risiko A life without adventure is likely to be unsatisfying, but a life in which adventure is allowed to take whatever form it will, is likely to be short. Bertrand Russel Kan reformuleres for bedrifter: En bedrift uten vilje til å ta risiko vil neppe blomstre, men en bedrift som neglisjerer risiko vil neppe overleve.

16 16 Vårt forhold til risiko Risikohåndtering handler, bokstavelig talt, om kalkulert risiko. Ved å kartlegge –hva som kan gå galt –hva konsekvensene er hvis noe går galt –hvor stor mulighet det er for at det går galt kan vi vurdere om en risiko er verdt å ta eller ikke.

17 17 Innføring i ny teknologi Sitat fra en risikoanalyse av et kritisk SW-basert system It is assumed that after the system is tuned up and tested, no errors will arise from the computer software. This may not be true, but as software error possibilities and the effects hereof are impossible to predict, this assumption is made.

18 18 Gode råd Hvordan kommer vi oss videre? KISS = Keep It Simple Stupid! –Bli ikke fristet til å lage ”fancy” løsninger. Forstå det grunnleggende! –Trenger vi egentlig flere språk eller verktøy? Husk at alvorlige konsekvenser kan inntreffe! –Det er utrolig hvor fort man glemmer dette når budsjettene er i ferd med å sprekke.

19 19 Flere gode råd Se opp for mytene! ”SW-baserte systemer er billigere enn analoge eller elektromekaniske systemer”. ”Det er lett å gjøre endringer i SW”. ”SW-baserte systemer er mer pålitelige og sikre”.

20 20 Fordeler og ulemper med software vs fysiske systemer Kan utføre mange og komplekse funksjoner svært raskt. Kan håndtere mange typer input og gi mange typer output. Liten fysisk størrelse. Lite slitasje problemer, elektronikken er ofte svært pålitelig. Fleksibilitet Kan utføre sikkerhetsfunksjoner som er umulig på annen måte. Kompleksitet

21 21 Hvordan håndtere risiko? Definere et akseptabelt risikonivå 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

22 22 Grunnleggende ”verktøy” Modeller –teknisk system mange abstraksjonsnivåer –interaksjon med andre systemer –interaksjon med mennesker/organisasjoner –avvikshendelser Risikoanalysemetoder –identifikasjon av hva som kan gå galt –analyse av hvor sannsynlig det er at noe går galt –kartlegging av de mulige konsekvensene hvis det går galt

23 23 Definisjoner og begreper Safety: -En egenskap et system har til ikke å medføre skade for mennesker eller miljø. -Primary safety: farer direkte forårsaket av datasystemets hardware. -Functional safety: dekker aspekter som vedrører utstyr som direkte kontrolleres av datasystemet og er relatert til korrekt funksjonering av dataens hardware og software. -Indirect safety: relatert til indirekte konsekvenser av data feil eller produksjon av uriktig informasjon. Safety-critical/safety-related 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ø.

24 24 Utvikling av safety-related systems

25 25 Definisjoner og begreper Pålitelighet (reliability): -Sannsynligheten for at system vil fungere tilfredsstillende over en gitt tidsperiode og under gitte forhold. Tilgjengelighet (availability): -Sannsynligheten for at systemet skal fungere på et vilkårlig valgt tidspunkt. -Andel av tiden systemet fungerer tilfredsstillende.

26 26 Definisjoner og begreper Integritet (integrity): -Et systems evne til å oppdage og rapportere feil. Informasjonsintegritet (data integrity): -Et systems evne til å forhindre feil i egne databaser og til å oppdage, eventuelt reparere, slike feil. -Assosieres gjerne med motstandsdyktighet mot hacking etc. Vedlikeholdbarhet (maintainability): -Et systems evne til å undergå reparasjon, vedlikehold, oppgradering etc.

27 27 Definisjoner og begreper 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, vedlikeholdbarhet og konfidensialitet.

28 28 Definisjoner og begreper Safety krav (safety requirements): -Safety-relaterte krav til systemets funksjoner og oppførsel. -” Shut-down” mekanismer skal finnes. -”Interlocks” skal hindre utilsiktet aktivering. -Enkeltfeil skal ikke kunne utløse ”katastrofale” hasarder. -Safety krav er et resultat av hasard og risikoanalyser basert på funksjonelle krav, samt krav i standarder og forskrifter.

29 29 Definisjoner og begreper Risiko Kvalitativt: -Den fare som uønskede hendelser representerer for mennesker, miljø og økonomiske verdier. Kvantitativt: -Kombinasjonen av sannsynlighet/frekvens for en hasard og konsekvensen av hasarden dersom den inntreffer.

30 30 Definisjoner og begreper Risikomatrise Ikke-akseptabel risiko Akseptabel risiko

31 31 Definisjoner og begreper Verifikasjon og validering Verifikasjon: -Prosess for å avgjøre om systemet er i henhold til spesifikasjonen. Validering: -Prosess for å avgjøre om systemet er egnet for tiltenkt bruk.

32 32 Definisjoner og begreper Feiltyper Fault: -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.

33 33 Definisjoner og begreper FaultErrorFailure Fault avoidance Fault removal Fault detection Fault tolerance Fault og failure er de sentrale begrepene. ”Error” brukes i forskjellige betydninger.

34 34 Definisjoner og begreper Tilfeldig (random) fault -Tilfeldig feil i HW. Systematisk (systematic) fault -Spesifikasjonsfeil, designfeil, kodefeil (bug) -Feil inntreffer under gitte betingelser og vil inntreffe hver gang betingelsene er til stede. Bemerk at alle programvarefeil er systematiske feil!

35 35 Oppgaver Uke 2 -Kap 1: 5, 6, 7, 10, 12, 16, 22 og 25 -Kap 2: 2, 6, 10, 12, 13, 14 og 20