1 Evaluering av IT-systemer Introduksjon Monica Kristiansen

2 Bruk av programvare i kritiske systemer En spennende verden!

3 Avanserte løfteraketter (Ariane 5)

Avanserte flyegenskaper 4

5

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

12

13 Eksplosjonen av Ariane 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 15 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 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 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 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.

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

20 Et annet eksempel: Netcom Netcom’s SMS tjeneste var ute av drift en kort periode sommeren 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

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 Safety integrity level Low demand mode of operation (Average probability of failure to perform its design function on demand) 4  to   to   to   to  NOTESee notes 3 to 9 below for details on interpreting this table.

27 FMEA Eksempel 1

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