Evaluering av IT-systemer Introduksjon

1. Evaluering av IT-systemerIntroduksjon Monica Kristiansen

2. Bruk av programvare i kritiske systemerEn spennende verden!

3. Avanserte løfteraketter (Ariane 5)

4. Avanserte flyegenskaper

5. Avanserte flyegenskaper

6. Hi-Tech passasjerfly

7. Avansert medisinsk utstyr

8. ER DÅRLIG PROGRAMVARE NOE PROBLEM?ER DET EGENTLIG VANSKELIG Å UTVIKLE SIKKER PROGRAMVARE? Eller er dette en for spennende verden ?

10. Avanserte løfteraketter

11. Avanserte løfteraketter

12. Avanserte løfteraketter

13. 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 var en software feil som rett og slett skyltes at programkoden var for dårlig testet. • Det ironiske var at feilen oppsto i en del av softwaren som kun har betydning før raketten tar av.

14. Eksplosjonen av Ariane 5 Årsak: • Klarte ikke å konvertere en 64-bit floating point til en 16 bit signed integer i en rutine som ikke hadde noen funksjon etter at raketten hadde tatt av! • Nummeret var større enn det maks en 16 bit integer kan lagre og dermed feilet konverteringen.

15. Avanserte flyegenskaper X-31 styrtet fordi trykkmåleren (et rør på utsiden av flyet) ble tildekket av is. Og fordi det var ingen mulighet for manuell ”override” i programkoden  ingen feiltoleranse

16. X-31 • 19. januar 1995 gikk jetflyet bokstavlig talt rett i bakken. • Årsaken var en opphopning av is på en trykkmåler som resulterte i en falsk avlesning av det totale lufttrykket – resulterte i feil informasjon ang. flyets hastighet. • Dette medførte videre at flyets kontrollsystem automatisk feilkonfigurerte for en lavere hastighet enn det flyet egentlig hadde. • Og selv om piloten visste at alt var som det skulle, tillot ikke programkoden piloten til å ta over flyet manuelt.

17. Hi-Tech passasjerfly • A320 Abu Dhabi: Flyet kjørte av rullebanen i stor fart, nesehjulet kollapset. • Årsak: En ”flight control failure” tvang mannskapet til å avbryte take-off selv om de hadde nådd en hastighet som tilsa at de måtte ta av. • Årsaken til problemet var en feil i en microchip i flyets Fly-By-Wire system • A320 Warszawa:Flyet kjørte i stor fart av rullebanen. • Årsak: Sterk sidevind og store vannmengder på rullebanen gjorde at flyets programkode ikke forstod at det ble foretatt en landing. • Resultatet var at oppbremsing av flyet ble hindret I hele 9 sekunder – 2 døde.

18. Avansert medisinsk utstyr: Therac-25 http://sunnyday.mit.edu/therac-25.html I perioden fra Juni 1985 til januar 1987 ble 6 pasienter gitt massive overdoser av stråling (3 personer døde av skadene). Årsaker: • Svak softwareutvikling (svakheter i spesifikasjon, dokumentasjon, lite testing mm.) • For stor tiltro til software og fjerning av hardware sikkerhetsmekanismer. • Sikkerhetsanalysen av Therac-25 inkluderte ikke software, selv om software hadde ansvar for nesten alle sikkerhetsmekanismene.

19. Feil plassering av kodelinjen kostet liv! I perioden fra juni 1985 til januar 1987 ble 6 pasienter gitt massive overdoser av stråling! Tre personer døde!

20. Et annet eksempel: Netcom Netcom’s SMS tjeneste var ute av drift en kort periode sommeren 2005. Dette forårsaket: • Nedgang i trafikk – tap av inntekt • Tilbakebetaling – tap av inntekt • Misfornøyde kunder og dårlig rykte – tap av inntekt Netcoms SMS-tjeneste er, for Netcom, et kritisk system!

21. Hvorfor går det galt? MANGLER KOMPETANSE OG MOTIVASJON NÅR DET GJELDER SIKKERHET! Fokus er oftest på teknologi : • Valg av språk • Valg av verktøy • Valg av plattformer • Fancy tekniske løsninger Innfører ny teknologi for å spare penger – ikke liv! Motvilje mot å gjøre det som er nødvendig!

22. Hvorfor går det galt? De målene som oftest anses viktige er: • ”Time to market” • ”Cost to market” • Kompleks funksjonalitet (”Fancyness”) Resultatet er som oftest: • Dårlig kvalitet • Dårlig sikkerhet • Store kostnader i senere faser av utviklingen • Tap av menneskeliv, penger og miljø

23. 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.

24. 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.” Virkeligheten er noe annerledes! • Kostnader relatert til SW vil over et systems levetid kunne bli kolossale! • Det er lett å gjøre feil i SW! • SW er uhyre komplekst og vi klarer knapt å anslå påliteligheten.

25. 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 • Kompleksitet • Kompleksitet • Kompleksitet • Kompleksitet • Kompleksitet • Kompleksitet • Kompleksitet

26. Safety Integrity Level (IEC 61508) Table 2 — Safety integrity levels: target failure measures for a safety function, allocated to an E/E/PE safety-related system operating in low demand mode of operation

27. FMEA Eksempel 1

28. 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