Skisse til løsningsforslag Eksamen 19. mai 2000

Oppgave 1 Safety: et systems evne til ikke å medføre fare for mennesker eller miljø. Primary safety: Inkluderer farer direkte forårsaket av datasystemets hardware, eks: jording etc. Functional safety: Dette 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

Oppgave 1 a) Pålitelighet er sannsynligheten for at et system skal fungere tilfredsstillende over en gitt tidsperiode og under gitte forhold. Med å fungere tilfredsstillende menes å operere som definert i system spesifikasjonen. Antas at enheten er korrekt ved starten og at det ikke er foretatt noe vedlikehold i denne perioden. Pålitelighet er av spesiell relevans i områder / programmer der kontinuerlig og uavbrutt operasjon er essensiell for vedlikehold av safety (luftfart).

Oppgave 1 b) Ofte vil et system kunne settes i sikker tilstand ved at dets funksjon avbrytes, dvs. ved at systemet stoppes (failsafe tilstand). Safety oppnås i en slik situasjon på bekostning av pålitelighet. Tilsvarende kan det tenkes at man velger å operere et system til tross for feil i sikringssystemer for å kunne nå de pålitelighetsmessige kravene som er satt. Eksempel: Togtrafikk har både krav til regularitet (dvs. pålitelighet) og til safety.

Oppgave 2 a) Systemer som involverer programmerbare enheter vil alltid innebære høy kompleksitet, noe som gjør det vanskelig både å lage et sikkert system, men også å vurdere hvor sikkert systemet faktisk er. Små og uvesentlige endringer i input kan gi voldsomme utslag i et SW-basert systems oppførsel, i motsetning til fysiske systemer der små endringer i ytre påvirkning kun vil gi små endringer i systemets oppførsel (”bends before breaking”). Vi har begrenset erfaring og kunnskap når det gjelder bruken av denne nye teknologien sammenlignet med eldre mer ”hardware” pregede systemer. Teknologien åpner mange muligheter og det har lett for å bli slik at fokus er mest på ”time to market”, ”cost to market” og ”fancy” funksjonalitet fremfor god kvalitet og tilstrekkelig sikkerhet.

Oppgave 2 b) Nei, ikke alle språk er egnet til bruk i safety relaterte systemer. Kun et fåtall språk regnes som akseptable til slike anvendelser. I kritiske systemer er derfor valg av språk et kritisk punkt og flere forhold bør vurderes: Funksjonelle egenskaper ved språket: Ingen tradisjonelle programmeringsspråk tilfredsstiller alle de funksjonelle egenskapene definert av Carrè . En av grunnene til dette er at de fleste språk ikke er utviklet for bruk i kritiske applikasjoner. Allikevel er noen språk bedre enn andre. For eksempel er Ada og Pascal bedre enn C og C++. For svært kritiske applikasjoner er det vanlig å benytte sikre “subsets” av språk som Ada og Pascal. Et subset er en begrensning eller utelatelse av deler av språket i den hensikt å oppnå høyere sikkerhet og integritet i språket og å sikre verifikasjon (fjerner svakhetene assosiert med et eksisterende språk). I tillegg benyttes ”annotations” , dvs. å legge til formelle kommentarer i et program for å definere dens funksjoner og operasjoner Tilgjengelighet og kvalitet på verktøy: Benytt velbrukte og validerte kompilatorer. Kunnskap og erfaring i utviklingsteamet: Utviklere som arbeider med et språk de kjenner vil begå færre feil og jobbe raskere.

Oppgave 2 b) Hovedårsaken til dette er at man ved safety relaterte systemer må ha stor grad av kontroll med hvordan det endelige systemet faktisk vil oppføre seg når man lager selve programkoden. Språket bør bl.a. være klart og utvetydig definert, det bør være egnet til å implementere aktuell funksjonalitet samt at det bør være mulig å verifisere i forhold til spesifikasjonen. Skal testing være mulig må systemet være ”designed for testability” Dette legger begrensninger på bl.a. valg av programmeringsspråk og på hvilke egenskaper i språkene som kan benyttes.

Oppgave 3 a) Med hasard mener vi hendelse/situasjon som potensielt kan medføre skade på mennesker eller miljø. Med risiko mener vi den fare uønskede hendelser representerer for mennesker, miljø og økonomiske verdier (kvalitativt), eventuelt kombinasjonen av sannsynligheten for en hasard, og konsekvens av hasarden dersom den inntreffer (kvantitativt).

Oppgave 3 b) Begge brukes til å identifisere hasarder. HazOp Strukturert ”brainstorming”. 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. 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. Systemeiere, brukere og utviklere. Eksperter (prosessteknikk, driftsteknikk osv.) Opprinnelige ledeord kommer fra kjemisk industri: Ikke/ingen, mer, mindre, deler av, mer enn, motsatt, andre/annerledes. Ulike ledeord vil altså gis forskjellige fortolkninger avhengig av i hvilken industri de benyttes. Derfor må meningen av hvert ledeord defineres som en del av HazOp studien.

Litt forenklet fremgangsmåte 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

Oppgave 3 c) FTA: en årsaksanalyse. - Grafisk metode som starter med en hendelse direkte relatert til en identifisert hasard som ”topphendelse” og som så forsøker å beskrive/illustrere de mulige årsaker til at topphendelsen inntreffer (”bakover” i tid). Logiske diagrammer Statisk bilde. Kvalitativ og kvantitative analyser Deduktiv metode: Arbeider oss ”nedover”. Finner årsakene? Knytter sammen årsaker med logiske porter (AND og OR).

FTA - Eksempel Eller Og Tap av styring Feil i styrings algoritme Feil i beregning Ingen manuell inngripen Feil i styring mekanisme Eller Og

Oppgave 3 c) ETA: en konsekvensanalyse Tar utgangspunkt i hendelser som kan påvirke systemet og kartlegger de mulige videre hendelsesforløp for å bestemme deres mulige konsekvenser. Ser ”fremover” i tid. Disse hendelsene inkluderer både hendelser assosiert med forventet operasjon av systemet og feiltilstander. Fokus på ”barrierer”, dvs. spesielle egenskaper et system har til å stoppe en potensielt farlig utvikling.

ETA - Eksempel System: Sensor Alarm Nødstopp Hindring på skinne Hendelse OK System stoppes OK Kollisjon Mulig kollisjon System stoppes, men feil i alarm System stoppes, men feil i sensor System stoppes (av ukjent grunn) Feiler OK Kan anslå konsekvenser OK Feiler Feiler Hindring på skinne Kan anslå sannsynligheter Feiler OK Feiler

Oppgave 3 d) Dere bør identifisere minst 2 feilmodier for hver komponent og ha med følgende kolonner i tabellen:

Oppgave 3 f) Slik koden er skrevet så vil bilens fart faktisk bli endret for hver runde i while-løkken! Hvis ikke set_speed(speed()+d) kalles, så kalles set_speed(speed()-d) i stedet. En enkel løsning på dette spesielle problemet ville vært å byttet ut ”else” med ”else if avstand() < 200”. Så lenge avstanden er mellom 200 og 300 cm vil ikke bilens hastighet bli endret.

Oppgave 4a)

Oppgave 4a) Starten på et hvilken som helst utviklingsprosjekt starter med system krav (customer requirements) som gir oss en abstrakt definisjon av hva systemet skal gjøre. Disse kravene må formaliseres inn i et dokument med funksjonelle krav. Deretter utføres hasard og risikoanalyse for identifisere potensielle farer og å allokere et integritetsnivå. En output fra disse analysene er safety kravene til systemet som definerer hva systemet må gjøre for å sikre safety. Fra safety kravene og de funksjonelle kravene til systemet utarbeides en spesifikasjon som vil inneholde mål som sikrer safety i henhold til det integritetsinvået som er satt.

Oppgave 4a) Når spesifikasjonen er laget blir denne brukt som basis for top-level design (overordnet design) som definerer arkitekturen til systemet. Top-level designet vil dele systemet inn i mindre moduler for å lette design og teste prosesser. Spesifikasjoner vil designes for hver module. I detaljert design vil hver av modulene bli designet detaljert og deretter konstruert og testet individuelt. Når modulene er ferdige og verifisert, integreres systemet. Til slutt må hele systemet verifiseres og valideres. Siste steg for safety-critical systems er å overbevise et eksternt organ at systemet er sikkert nok (det en fordel å benytte standarder og guidelines som sikrer sertifisering).

Oppgave 4a) Det er viktig å kommentere at hasard/risikoanalyser er en aktivitet som foregår under hele utviklingsløpet, integrert i de øvrige aktiviteter. Dersom du i tillegg påpeker på at man ved utvikling av safety relaterte systemer også gjerne begynner å planlegge testing, verifisering og sertifisering tidlig i utviklingsløpet så er det veldig bra.

Oppgave 4b) Hver av utviklingsfasene i v-modellen (spesifikasjon, overordnet design, detaljdesign, implementasjon) kan sees på som forskjellige definisjoner av det samme systemet, bare beskrevet på forskjellige måter. Overgangen fra en fase til en annen foregår ved at en definisjon transformeres til en annen. Verifikasjonsprosessen består essensielt i å ”bevise” at hver definisjon er ekvivalent med den forrige slik at det endelige (implementerte) systemet er det samme som det systemet som er beskrevet i spesifikasjonen, og som er validert mot kravene.

Oppgave 4c Siden spesifikasjonen sammenlignes med kravene, og kravene av natur er mindre presise og sjelden komplette kan spesifikasjonen ikke verifiseres. Så lenge kravene ikke kan være en komplett systembeskrivelse, mens spesifikasjonen skal være komplett, vil det ikke være mulig å ”mappe” hele spesifikasjonen tilbake til kravene. Verifikasjon består i å avgjøre hvorvidt et system oppfyller en gitt spesifikasjon, eller mer generelt om systemdefinisjonen fra en utviklingsfase er i tråd med de kravene som ble spesifisert i forrige fase. Validering består i å vurdere hvorvidt en spesifikasjon er i henhold til, og konsistent med, kundens krav og behov. (Er det spesifiserte systemet egnet til planlagt bruk?)

Oppgave 4d) Fordeler: Presis systemdefinisjon uten tvetydigheter Mulig å utføre analyser av bl.a. kompletthet og konsistens på et tidlig tidspunkt. Gjør det mulig å utføre matematiske bevis for at en implementasjon er i samsvar med spesifikasjonen. Systemet kan ”animeres” før faktisk utvikling og implementasjon. Ulemper: Krever spesiell kompetanse Tidkrevende og kostbart