Evaluering av kritiske programmerbare systemer. Monica Kristiansen

Størrelse: px
Begynne med side:

Download "Evaluering av kritiske programmerbare systemer. Monica Kristiansen"

Transkript

1 Evaluering av kritiske programmerbare systemer Monica Kristiansen 1

2 Sikkerhetsfaglig mantra Det er ikke nok å bygge et system som er sikkert. Du må også kunne overbevise andre om at det er sikkert. 2

3 Dagens temaer Hva menes med kritiske programmerbare systemer? Hvem stiller krav til kritiske programmerbare systemer? Hvilke krav stilles til kritiske programmerbare systemer? Hvordan dokumenterer man at kritiske programmerbare systemer oppfyller kravene? Risikohåndtering Pålitelighetsbasert (statistisk) testing 3

4 Hva menes med kritiske programmerbare systemer? - Systemer som ved å feile kan forårsake betydelige skader på mennesker, miljø og/eller økonomiske verdier. - Vi krever at kritiske programmerbare systemer er dependable, dvs. at de er: - Sikre - Trygge - Pålitelige 4

5 Avanserte løfteraketter (Ariane 5) 5

6 Avanserte flyegenskaper 6

7 Avanserte flyegenskaper 7

8 Hi-Tech passasjerfly 8

9 Avansert medisinsk utstyr 9

10 Bruk av programvare i kritiske systemer En spennende verden! For spennende? er det egentlig for vanskelig å utvikle sikre programmerbare systemer? er dårlige programmerbare systemer egentlig et for stort problem? 10

11 11 Avanserte løfteraketterl

12 12 Avanserte løfteraketterl

13 13 Avanserte løfteraketterl

14 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

15 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

16 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 16

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

18 Hi-Tech passasjerfly A320 Abu Dhabi: Flyet kjørte av rullebanen i stor fart, nesehjulet kollapset. 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. Åsaken til problemet var en feil i en microchip i flyets Fly-By-Wire system A320 Warzawa: Flyet kjørte i stor fart av rullebanen. Årsaken var at stertk 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 sekuder 2 døde

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

20 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

21 Hvorfor går 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! 21 21

22 Hvorfor går 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ø 22 22

23 Sitat fra risikoanalyse av kritisk 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 Dette er ikke bare tullete Det er farlig! 23 23

24 Innføring av ny teknologi 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 Hvem stiller krav til kritiske programmerbare systemer? Hvis safety-critical systemer, samfunnskritiske systemer eller systemer som involverer håndtering av konfidensiell informasjon, så er det myndighetene gjennom diverse tilsynsorgan: Jernbanetilsynet Luftfarttilsynet Datatilsynet Etc. Hvis business-kritisk systemer, så er det de enkelte firmaer, eventuelt i henhold til bransjeordninger. 25

26 Hvilke krav stilles til kritiske programmerbare systemer? Prosesskrav Bruk anerkjente prinsipper, følge standarder. Produktkrav Akseptabel risiko (nivåer definert i standarder). Driftskrav Endringer medfører ny evaluering Viktig standard i Europa: IEC 61508: Functional safety of electrical/electronic/ programmable electronic safety-related systems Består av 7 deler. Part 3: Software requirements er av spesiell interesse 26

27 Safety integrity level Det stilles ulike krav til sikkerhetskritiske systemer dette gir opphav til safety integrity level. Prosessen med å utvikle sikkerhetskritiske systemer kan ble sett på som en prosess for risikoreduksjon. Høyrisiko systemer krever mye mer risikoreduksjon enn lavrisiko systemer. Jo større risikoreduksjon, jo høyere safety integrity level. 27

28 28 Risikoreduksjon

29 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) to < to < to < to < 10-1 NOTE See notes 3 to 9 below for details on interpreting this table.

30 Safety lifecycle 1 2 Concept Overall scope definition 3 Hazard and risk analysis 4 Overall safety requirements 5 Safety requirements allocation Overall planning 6 OveralI 7 Overall 8 operation and maintenance planning safety validation planning OveralI 8installation and commissioning planning 9 Safety-related 10 Safety-related systems: 11 E/E/PES Realisation (see E/E/PES safety lifecycle) systems: other technology Realisation External risk reduction facilities Realisation 12 Overall installation and commissioning 13 Overall safety validation Back to appropriate overall safety lifecycle phase 14 Overall operation, 15 maintenance and repair Overall modification and retrofit 16 Decommissioning or disposal

31 Software safety lifecycle Software safety lifecycle 9.1 Software safety requirements specification E/E/PES safety lifecycle (see figure 2) Safety functions requirements specification Safety integrity requirements specification 9.2 Software safety validation planning 9.3 Software design and development 9.4 PE integration 9.5 Software operation and (hardware/software) modification procedures 9.6 Software safety validation 31 To box 12 in figure 2 of part 1 To box 14 in figure 2 of part 1

32 Development lifecycle E/E/PES safety requirements specification Software safety requirements specification Validation Validation testing Validated software E/E/PES architecture Software architecture Integration testing (components, subsystems and programmable electronics) Software system design Integration testing (module) Module design Module testing 32 Output Verification CODING

33 Prosesskrav Konkrete anbefalinger (lite utdrag) Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Formal proof C R R HR 2 Probabilistic testing C R R HR 3 Static analysis B.6.4 Table B.8 4 Dynamic analysis and testing B.6.5 Table B.2 R HR HR HR R HR HR HR 5 Software complexity metrics C.5.14 R R R R Software module testing and integration Programmable electronics integration testing See table A.5 See table A.6 Software system testing (validation) See table A.7

34 Produktkrav Utviklet i henhold til anerkjente prinsipper Standarder gir en del konkrete retningslinjer Demonstrert akseptabel risiko gjennom risikoanalyser og verifikasjon & validering (V&V) I alle faser av utviklingen! 34

35 Produktkrav - Noen konkrete retningslinjer Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Use of coding standard C HR HR HR HR 2 No dynamic objects C R HR HR HR 3a No dynamic variables C R HR HR 35 3b Online checking of the installation of dynamic variables C R HR HR 4 Limited use of interrupts C R R HR HR 5 Limited use of pointers C R HR HR 6 Limited use of recursion C R HR HR 7 No unconditional jumps in programs in higher level languages C R HR HR HR a) Measures 2 and 3a do not need to be applied if a compiler is used (1) which ensures that sufficient memory for all dynamic variables and objects will be allocated before runtime, or (2) which inserts runtime checks for the correct online allocation of memory. b) Appropriate techniques/measures shall be selected according to the safety integrity level.

36 Produktkrav Noen (flere) konkrete retningslinjer Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Fault detection and diagnosis C R HR HR 2 Error detecting and correcting codes C.3.2 R R R HR 3a Failure assertion programming C.3.3 R R R HR 3b Safety bag techniques C R R R 3c Diverse programming C.3.5 R R R HR 3d Recovery block C.3.6 R R R R 3e Backward recovery C.3.7 R R R R 3f Forward recovery C.3.8 R R R R 3g Re-try fault recovery mechanisms C.3.9 R R R HR 3h Memorising executed cases C R R HR 4 Graceful degradation C.3.11 R R HR HR 5 Artificial intelligence - fault correction C NR NR NR 6 Dynamic reconfiguration C NR NR NR 7a Structured methods including for example, JSD, MASCOT, SADT and Yourdon. C.2.1 HR HR HR HR 7b Semi-formal methods Table B.7 R R HR HR 7c Formal methods including for example, CCS, CSP, HOL, LOTOS, OBJ, temporal logic, VDM and Z C R R HR 8 Computer-aided specification tools B.2.4 R R HR HR a) Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measures has to be satisfied.

37 Hvordan dokumenterer man at kritisk programvare oppfyller kravene? Prosess QA-dokumenter Sertifisering/revisjon av organisasjon/prosess Dokumentasjon av utviklingsaktiviteter Produkt Designvalg Implementasjonsprinsipper Analyse, analyse, analyse,. Testing, testing, testing, 37

38 Risikohåndtering 38 Risikohåndtering handler, bokstavelig talt om kalkulert risiko. Formål: Grunnlag for å ta en beslutning om hvorvidt risikonivået er akseptabelt eller ikke Kontinuerlig arbeid for å oppnå akseptabel risiko Består av å: Identifisere hva som kan gå galt / uønskede hendelser (hasarder) Analysere mulige årsaker og konsekvenser av uønskede hendelser Vurdere sannsynligheten for de forskjellige uønskede hendelsene skal inntreffe Vurdere tiltak for å reduserte risikonivået til et akseptabelt nivå.

39 Hvordan starter vi? 39 Hva er target of evaluation (TOE)? Hva er kravene til systemet? Standarder? Tilsyn? Kunder, marked? Hvilken informasjon trenger vi om TOE? Modeller av det tekniske systemet, hvordan det påvirkes av andre systemer, mennesker og organisasjoner. Dokumentasjon av utviklingsprosessen. Beskrivelse av operasjonell profil. Hvilke analytiske teknikker trenger vi for å dokumentere at kravene er oppfylt? Teknikker for å identifisere hva som kan gå galt. Teknikker for å finne sannsynligheten for at noe skal gå galt. Teknikker for å finne årsaker og konsekvenser hvis noe skulle gå galt. Vi trenger å binde de analytiske teknikkene og modellene sammen

40 40 Risk Management Process: AS/NZS 4360

41 Risikohåndteringsprosessen Risikohåndteringsprosessen 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. 41

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

43 Analytiske teknikker - De to mest brukte analyseteknikkene er: Failure Mode, Effect and Criticality Analysis (FMEA/FMECA): Hazard and Operability Studies (HazOp): Feiltreanalyse (FTA). Hendelsestreanalyse (ETA) 43

44 FME(C)A 44 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. I FMECA vil man også klassifisere feilene i henhold til sannsynlighet og alvorlighet (criticality). Teknikken kan benyttes ved ulike faser i utviklingsprosjektet.

45 FMEA Eksempel 1 ID # Enhet Feil-modus Årsak Lokal effekt System effekt Tiltak 1 Bryter som registrer er om utstyr er Indikerer åpen når den skulle indikert lukket på plass 2 Indikerer lukket når den skulle indikert åpen. 1. Brudd 2. Ekstrem temperatur 1. Kortslutning i bryter 2. Høy spenning Detekterer ikke at utstyr er på plass. System indikerer feilaktig at utstyr er på plass. Umulig å bruke maskin, system er failsafe. Maskin tillates brukt selv om utstyr ikke er på plass, system er unsafe. Bruk bryter av høy kvalitet. Preventivt vedlikehold og jevnlige inspeksjoner. Legg til tilleggskontroller? 45

46 Hazard and Operability Studies (HazOp) 46 Strukturert brainstorming. Systematisk gjennomgang av systemet ved 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. Gruppen: ledes av en erfaren Hazop-leder. bør til sammen dekke alle relevante aspekter (systemeiere, brukere, utviklere og eksperter). Opprinnelige ledeord/attributter: Ledeord: Ikke/ingen, mer, mindre, deler av, mer enn, motsatt, andre/annerledes. Disse må tolkes i computersammenheng. Attributter: trykk, temperatur, flyt.

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

48 Feiltreanalyse (FTA) 48 I dag den mest brukte analysemetoden i risikoanalyse og pålitelighetsanalyse. 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 Deduktiv metode: Arbeider oss nedover. Finner årsakene? Knytter sammen årsaker med logiske porter (AND og OR).

49 Fault Tree Analysis (FTA) Kode If a > b then x:=f(x) else x:=10 x > p.g.a. if-statement then-part gir gir x > else-part gir gir x > a > b før før If-then-else x:=f(x) gir gir x > a <= <= b før før If-then-else x:=10 gir gir x >

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

51 System: Trykksensor Alarm relay Sirene Trykksensor ETA - Eksempel Alarm relay Sirene Fungerer Fungerer Alarm Aktiv Fungerer Feiler Feiler Fungerer Inaktiv Inaktiv For høyt trykk Fungerer Feiler Fungerer Inaktiv Inaktiv Feiler Feiler Feiler Fungerer Inaktiv Inaktiv 51 Feiler Inaktiv

52 Risikoklassifisering Alvorlighet av konsekvenser hvis hasard inntreffer Risikoklassifisering Frekvens/sannsynlighet for hasard 52

53 Risk classification - IEC Frequency Consequence Catastrophic Critical Marginal Negligible Frequent I I I II Probable I I II III Occasional I II III III Remote II III III IV Improbable III III IV IV Incredible IV IV IV IV Risk class Class I Class II Class III Class IV Interpretation Intolerable risk Undesirable risk, and tolerable only if risk reduction is impracticable or if the costs are grossly disproportionate to the improvement gained Tolerable risk if the cost of risk reduction would exceed the improvement gained Negligible risk 53

54 54 Allocation of SIL

55 Pålitelighetsbasert testing av programvare Hvordan optimalisere testing i forhold til oppnådd pålitelighet? 55

56 Problemer med testing og feilretting Testingen og feilrettingen er for dårlig, lite effektiv tar for lang tid Programmet feiler for ofte Forsinket leveranse Kostnadsoverskridelser Konsekvens : Tapte kunder/marked Pålitelighetsbasert testing medfører: at produktet oppfyller kundens krav redusert Time To Market reduserte kostnader mer tilfredse kunder 56

57 Pålitelighet som kvalitetsmål Hva menes med pålitelighet? Forventet antall feil pr. tidsenhet. Gjennomsnittlig tid til feil (MTTF). Sannsynligheten for at systemet fungerer feilfritt i en gitt tidsperiode. Programvarepålitelighet er et kvalitetsmål med brukerperspektiv! 57

58 Hovedprinsipp Kvantifisere forventet bruk, og benytte dette til å fokusere ressurser på de viktigste funksjonene. lage tester som er realistiske i forhold til faktisk bruk. Skiller mellom Failure : Observert avvik/feil under kjøring. Fault : Feil (bug) som forårsaker failure når den eksekveres. 58 Failure : Brukerperspektiv Fault : Utviklerperspektiv Fokus på dette!

59 Hvordan anslå påliteligheten til et program? Viktige momenter: Vi bør ha bestemt oss for hva som er tilstrekkelig pålitelighet. Påliteligheten er avhengig av hvordan systemet brukes. Vi må altså vite : hvilke krav som stilles av kunden, og hvordan kunden kommer til å bruke systemet. 59

60 Måling av pålitelighet p - Overordnet fremgangsmåte Definer tilstrekkelig pålitelighet (sammen med kunden). Lag bruksprofil. Lag testbeskrivelse med utgangspunkt i bruksprofil. Utfør testing. Noter tidspunkt for feil. Rett feil. Anslå påliteligheten og fortsett eventuelt testingen til påliteligheten er akseptabel. 60

61 Bruksprofil En bruksprofil er en (statistisk) modell som beskriver forventet bruk av programmet. Konsept Beskriv aktuelle operasjoner. Beskriv aktuelle operasjonelle tilstander. Identifiser initiatorer. Anslå hvor ofte hver operasjon vil bli brukt. 61

62 Eksempel : Kalkulator Bruksprofil, forts. Operasjoner Sannsynlighet Addisjon 0.4 Subtraksjon 0.3 Multiplikasjon 0.2 Divisjon 0.1 Operasjonelle tilstander Desimaltall Hexadesimale tall Initiatorer Brukeren

63 Bruksprofil, forts. Bruk av bruksprofil under testing medfører at påliteligheten til systemet på ethvert tidspunkt i testing og feilretting er optimal i forhold til medgått tid. tid som er nødvendig for å nå kundens krav om pålitelighet blir minimert. 63

64 Testing og feilretting Utfør tester med utgangspunkt i bruksprofil. Identifiser failures Noter tid til hver failure. Program debugges mellom hver feil! Feil nr. Tid til neste feil

65 Predikert pålitelighet (Tid til neste failure ) 4000 Tid mellom feil Feil nr.

66 Fremdriftskontroll - Prosjektleder kan benytte pålitelighetsprediksjonene til å: Oppdage lite effektiv testing og feilretting. Uforutsette problemer i designet. Utilsiktet videreutvikling i feilrettingsfasen. Vurdere fremdrift i forhold til tidsplan. Må man sette inn flere ressurser? Kan man prioritere ressurser til bruk i andre prosjekter? 66

67 Fordeler ved å bruke pålitelighet p som kvalitetsmål Bruk av pålitelighet som kvalitetsmål gjør at vi fokuserer på de viktigste feilene, nemlig de som oftest vil inntreffe i virkelig bruk. Det er lett å forstå og ta stilling til. Det medfører mer effektiv feilsøking. Det gir bedre kontroll med faktisk kvalitet før leveranse. Det gir bedre kontroll med tids- og ressursforbruk. 67

68 Oppsummering Utvikling av kritisk programvare krever spesielt fokus på risikohåndtering Det er ikke nok å utvikle sikker programvare DEN MÅ OGSÅ KUNNE DOKUMENTERES Å VÆRE SIKKER! Skikkelig bruk av risikoanalyser gir færre overraskelser i senere faser Risikoanalyse er etterpåklokskap på forhånd Ole Arnt Johnsen, morecom 68

Evaluering av IT-systemer Introduksjon. Monica Kristiansen

Evaluering av IT-systemer Introduksjon. Monica Kristiansen Evaluering av IT-systemer Introduksjon Monica Kristiansen 1 Bruk av programvare i kritiske systemer En spennende verden! 2 Avanserte løfteraketter (Ariane 5) 3 Avanserte flyegenskaper 4 Avanserte flyegenskaper

Detaljer

Hasardidentifikasjon. Hvordan finne ut hva som kan gå GALT FØR det går galt.

Hasardidentifikasjon. Hvordan finne ut hva som kan gå GALT FØR det går galt. Hasardidentifikasjon Hvordan finne ut hva som kan gå GALT FØR det går galt. 1 Hasard (trussel, uønsket hendelse) 2 Hendelse/situasjon som potensielt kan medføre skade på mennesker eller miljø. Bilkollisjon,

Detaljer

IEC 61508. Hovedprinsipper og veiledning

IEC 61508. Hovedprinsipper og veiledning IEC 61508 Hovedprinsipper og veiledning Stein Hauge SINTEF Tlf: 75 17 33 70 / 930 18 395 haustein@online.no / stein.hauge@sintef.no 1 Bare måtte bruke IEC 61508 1 2 3 4 5 6 7 8 9 1010 1 1212 1313 1414

Detaljer

IEC 61508. Innhold. Tor Onshus. Hovedpunktene i IEC 61508 Prosessikkerhet Programvareutvikling Oppfølging i drift Maskinsikkerhet

IEC 61508. Innhold. Tor Onshus. Hovedpunktene i IEC 61508 Prosessikkerhet Programvareutvikling Oppfølging i drift Maskinsikkerhet 1 IEC 61508 Tor Onshus Teknisk kybernetikk Norges teknisk naturvitenskaplige universitet, NTNU tlf: 73594388 mob: 92697460 Tor.Onshus@itk.ntnu.no http://www.itk.ntnu.no/ansatte/onshus_tor Innhold 2 Hovedpunktene

Detaljer

Maskinsikkerhet. Maskinforskriften. Maskindirektivet Relevante standarder. Tor Onshus

Maskinsikkerhet. Maskinforskriften. Maskindirektivet Relevante standarder. Tor Onshus 1 Maskinsikkerhet Tor Onshus Teknisk kybernetikk Norges teknisk naturvitenskaplige universitet, NTNU tlf: 73594388 fax: 73594399 Tor.Onshus@itk.ntnu.no http://www.itk.ntnu.no/ansatte/onshus_tor 2 Maskinforskriften

Detaljer

Use of LOPA in the safety lifecycle, the BP way

Use of LOPA in the safety lifecycle, the BP way Use of LOPA in the safety lifecycle, the BP way Arvid Nilsen, automasjonsingeniør.est BP Norge CASIS ansvarlig BP Norge ESRA seminar SIL I drift 29.januar 2014 Introduksjon Dette er ikke et LOPA-kurs LOPA

Detaljer

En praktisk anvendelse av ITIL rammeverket

En praktisk anvendelse av ITIL rammeverket NIRF 17. april 2012 En praktisk anvendelse av ITIL rammeverket Haakon Faanes, CIA,CISA, CISM Internrevisjonen NAV NAVs ITIL-tilnærming - SMILI NAV, 18.04.2012 Side 2 Styring av tjenestenivå Prosessen omfatter

Detaljer

Jernbaneverkets erfaringer med implementering av RAMS

Jernbaneverkets erfaringer med implementering av RAMS Jernbaneverkets erfaringer med implementering av RAMS Terje Sivertsen, seksjonsleder signal Infrastruktur Teknikk, Premiss og utvikling Jernbaneverket RAMS-seminar, NJS, Oslo, 18. april 2007 1 Innhold

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Programseminar 10-11 mars 2004

Programseminar 10-11 mars 2004 operasjonell risikoanalyse HMS Petroleum Beslutningsstøtteverktøy (NFR) Hovedprosjekt gjennom delprosjektet "Barrierer og " Jan Erik Vinnem, /HiS (jev@preventor.no) Programseminar 10-11 mars 2004 10.03.2004

Detaljer

Bruk av RAMS ved anskaffelser av rullende materiell og nye infrastrukturanlegg

Bruk av RAMS ved anskaffelser av rullende materiell og nye infrastrukturanlegg Scandpower Risk Management AS Postboks 3 2027 Kjeller Bruk av RAMS ved anskaffelser av rullende materiell og nye infrastrukturanlegg Karl Ove Ingebrigtsen, Divisjonsdirektør Terje Nilsen, Sjefingeniør

Detaljer

IEC 61508 OLF-070. Teknisk kybernetikk Norges teknisk naturvitenskaplige universitet, NTNU. Bakgrunn http://www.ptil.no/

IEC 61508 OLF-070. Teknisk kybernetikk Norges teknisk naturvitenskaplige universitet, NTNU. Bakgrunn http://www.ptil.no/ 1 IEC 61508 OLF-070 Tor Onshus Teknisk kybernetikk Norges teknisk naturvitenskaplige universitet, NTNU tlf: 73594388 fax: 73594399 Tor.Onshus@itk.ntnu.no http://www.itk.ntnu.no/ansatte/onshus_tor Bakgrunn

Detaljer

Grunnleggende testteori. Etter Hans Schaefer

Grunnleggende testteori. Etter Hans Schaefer Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,

Detaljer

Managing Risk in Critical Railway Applications

Managing Risk in Critical Railway Applications Managing Risk in Critical Railway Applications Topics Railway signalling Real projects Regulator, standards and the law Acceptance criteria for signalling systems (SIL) Risk analysis a special case The

Detaljer

3.4 RISIKOSTYRING. Hva er risiko? Risikostyring Metoder for risikoanalyse

3.4 RISIKOSTYRING. Hva er risiko? Risikostyring Metoder for risikoanalyse 3.4 RISIKOSTYRING Hva er risiko? Risikostyring Metoder for risikoanalyse I design av kvalitet og prosesser må vi forebygge farlige forhold og uønskede hendelser. Som en generell regel gjelder 80/20-regelen

Detaljer

Oversikt over standarder for. risikoanalyse, risikovurdering og risikostyring

Oversikt over standarder for. risikoanalyse, risikovurdering og risikostyring Oversikt over standarder for risikoanalyse, risikovurdering og risikostyring Risikoanalyser, risikovurdering og risikostyring Å gjennomføre risikovurderinger er en viktig oppgave for mange private og offentlige

Detaljer

Bruk av ALARP analyse for beslutningstaking på behovet for sikkerhetssystemer / barrierer

Bruk av ALARP analyse for beslutningstaking på behovet for sikkerhetssystemer / barrierer Bruk av ALARP analyse for beslutningstaking på behovet for sikkerhetssystemer / barrierer Morten Sørum, Senior Advisor Safety, Statoil Classification: Internal 2014-11-16 ALARP prinsippet ALARP (As Low

Detaljer

Analyseverktøy for pålitelighet av instrumenterte sikkerhetssystemer

Analyseverktøy for pålitelighet av instrumenterte sikkerhetssystemer Analyseverktøy for pålitelighet av instrumenterte sikkerhetssystemer Lars Bodsberg Forskningssjef SINTEF Teknologi og samfunn lars.bodsberg@sintef.no www.sintef.no/pds Sikkerhetssystemkonferansen 2010

Detaljer

FMEA / FMECA Hensikt Metodebeskrivelse

FMEA / FMECA Hensikt Metodebeskrivelse FMEA / FMECA Feilmodi- og feileffektanalyse (Failure Modes and Effects Analysis - FMEA) er den mest brukte systematiske metodene for å analysere feil i tekniske systemer. Dersom en beskriver eller rangerer

Detaljer

Risiko, usikkerhet og beslutninger

Risiko, usikkerhet og beslutninger Risiko, usikkerhet og beslutninger Professor Jørn Vatn, NTNU Abelia-seminar 24. November 2005 1 Risikovurdering og risikostyring (IEC 60300-3-9) 2 Risiko, usikkerhet og beslutninger 3 Klassisk tilnærming,

Detaljer

Bruk av risikoverktøy i byggeprosjekter, eksempel Strindheimstunnelen

Bruk av risikoverktøy i byggeprosjekter, eksempel Strindheimstunnelen Bruk av risikoverktøy i byggeprosjekter, eksempel Strindheimstunnelen BegrensSkade fagdag 26.november 2015 Bjørn Kalsnes, NGI, DP 5 leder Torgeir Haugen, NCC 2015-11-26 BS fagdag 1 Innhold Hva er risiko?

Detaljer

Fakultet for informasjonsteknologi, Institutt for datateknikk og informasjonsvitenskap AVSLUTTENDE EKSAMEN I. TDT42378 Programvaresikkerhet

Fakultet for informasjonsteknologi, Institutt for datateknikk og informasjonsvitenskap AVSLUTTENDE EKSAMEN I. TDT42378 Programvaresikkerhet Side 1 av 5 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap AVSLUTTENDE EKSAMEN

Detaljer

Oversikt over standarder for. risikoanalyse, risikovurdering og risikostyring

Oversikt over standarder for. risikoanalyse, risikovurdering og risikostyring Oversikt over standarder for risikoanalyse, risikovurdering og risikostyring Risikoanalyser, risikovurdering og risikostyring Å gjennomføre risikovurderinger er en viktig oppgave for mange private og offentlige

Detaljer

Medisinsk statistikk, KLH3004 Dmf, NTNU 2009. Styrke- og utvalgsberegning

Medisinsk statistikk, KLH3004 Dmf, NTNU 2009. Styrke- og utvalgsberegning Styrke- og utvalgsberegning Geir Jacobsen, ISM Sample size and Power calculations The essential question in any trial/analysis: How many patients/persons/observations do I need? Sample size (an example)

Detaljer

Eksempel på anvendelse

Eksempel på anvendelse Temadager 14. 15. oktober 2009 Estimering av restlevetid som underlag for vedlikehold og reinvestering Eksempel på anvendelse Bruk av sviktsannsynlighet fra restlevetidestimat som inngangsdata i risikoanalyser

Detaljer

Bruker vi ressursene der det nytter? Eksempler fra risikoanalyser i ulike bransjer. Inge Alme Teknisk Direktør Scandpower 10.

Bruker vi ressursene der det nytter? Eksempler fra risikoanalyser i ulike bransjer. Inge Alme Teknisk Direktør Scandpower 10. Bruker vi ressursene der det nytter? Eksempler fra risikoanalyser i ulike bransjer. Inge Alme Teknisk Direktør Scandpower 10. mai 2012 Innhold Kort intro til risikoanalyser Bruken av risikoanalyer i ulike

Detaljer

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst.

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst. Brukerkrav og use case diagrammer og -tekst 19. januar 2012 Agenda Brukerkrav og use case Diagrammer Tekst Praktisk eksempel 1 OOAD i livsløpsperspektiv Krav Design Konstruksjon Her er vi i nå Testing

Detaljer

Institutt for biovitenskap

Institutt for biovitenskap Institutt for biovitenskap Oppslag for alle avtrekksskap: Alle avtrekksskap skal ha forklaring på alarmsystem på det enkelte skap. Dette varier fra skap til skap. e.g. på IBV finnes det minst 3 ulike typer.

Detaljer

Livsløpstesting av IT-systemer

Livsløpstesting av IT-systemer Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Lynkurs 10. Januar 2012

Lynkurs 10. Januar 2012 Lynkurs 10. Januar 2012 Mål : Dagens lynkurs skal gi dere noen holdepunkter for å komme i gang med arbeidet med bacheloroppgaven på en systematisk og strukturert måte. Fokus er rettet mot arbeidet knyttet

Detaljer

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring Seminar om risikoanalyse og testing innen sikkerhet Bjørnar Solhaug SINTEF, 11. juni, 2013 Technology for a better society 1 Oversikt Risikoanalyse

Detaljer

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

CSM i NSB. En orientering om implementeringen av Forskrift om felles sikkerhetsmetode for risikovurderinger i NSB.

CSM i NSB. En orientering om implementeringen av Forskrift om felles sikkerhetsmetode for risikovurderinger i NSB. CSM i NSB Morgenmøte om risikovurderinger Oslo, 22. august 2012 En orientering om implementeringen av Forskrift om felles sikkerhetsmetode for risikovurderinger i NSB. Bakgrunn o A common framework for

Detaljer

IT Service Management

IT Service Management IT Service Management Forelesning uke 7 Innhold Endringer Endringer i ITIL: Service Transition Endringer - en nødvendig onde? If it ain t broke don t fix it. De fleste supportsaker synes å skyldes endringer

Detaljer

AVSLUTTENDE EKSAMEN I/FINAL EXAM. TDT4237 Programvaresikkerhet/Software Security. Mandag/Monday 15.12.2008. Kl. 09.00 13.00

AVSLUTTENDE EKSAMEN I/FINAL EXAM. TDT4237 Programvaresikkerhet/Software Security. Mandag/Monday 15.12.2008. Kl. 09.00 13.00 Side 1 av 7 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL//NYNORSK/ENGLISH Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap

Detaljer

Nye standarder for risikoanalyse/-styring Revisjon av Norsok Z-013

Nye standarder for risikoanalyse/-styring Revisjon av Norsok Z-013 Nye standarder for risikoanalyse/-styring Revisjon av Norsok Z-013 Jan Erik Vinnem AS ESRA seminar 24.11.2009 Pres Z-013 jev 1 Oversikt Arbeidsprosessen & -gruppen Oversikt over standarden Innhold og omfang

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

KIS - Ekspertseminar om BankID

KIS - Ekspertseminar om BankID www.nr.no KIS - Ekspertseminar om BankID Dr. Ing. Åsmund Skomedal Forsknings sjef, DART, Norsk Regnesentral asmund.skomedal@nr.no 18. mars 2009 Tema til diskusjon Agenda punkter Kritisk analyse av digitale

Detaljer

4. SIKKERHETSHENSYN Risiko i prosess design og drift Gruppering av utstyr (soneinndeling) Sikkerhetsbarrierer Forholdstall for ulykker

4. SIKKERHETSHENSYN Risiko i prosess design og drift Gruppering av utstyr (soneinndeling) Sikkerhetsbarrierer Forholdstall for ulykker 4. SIKKERHETSHENSYN Risiko i prosess design og drift Sannsynlighet Konsekvens Vi arbeider for å redusere sannsynlighet for uhell Vi arbeider for å avgrense konsekvensene av uhell Risiko = Sannsynlighet

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

Hva kreves av en god byggherre? «Store utbyggingsprosjekter», 23. okt 2014

Hva kreves av en god byggherre? «Store utbyggingsprosjekter», 23. okt 2014 Hva kreves av en god byggherre? «Store utbyggingsprosjekter», 23. okt 2014 Paul Torgersen Leder Metier Consulting 20. oktober 2014 Side 2 Innhold Hva er prosjektsuksess? Hva kjennetegner de beste? Mine

Detaljer

Risikoanalyse Brann Noen aspekter

Risikoanalyse Brann Noen aspekter Risikoanalyse Brann Noen aspekter Jørn Vatn Professor, NTNU 1 Risikoanalyse vs TEK/VTEK Historisk har man tilnærmet seg brannsikkerhet ved å stille krav til tekniske løsninger Disse kravene er basert på

Detaljer

ROS analyse for samfunnskritiske IKT systemer. Utfordringer og muligheter 24/11-05

ROS analyse for samfunnskritiske IKT systemer. Utfordringer og muligheter 24/11-05 ROS analyse for samfunnskritiske IKT systemer Utfordringer og muligheter 24/11-05 Hermann Steen Wiencke Proactima/Universitetet i Stavanger 1 Et samarbeid mellom Universitetet i Stavanger og Rogalandsforskning

Detaljer

Strategiske og operasjonelle risikoanalyser

Strategiske og operasjonelle risikoanalyser 1 Strategiske og operasjonelle risikoanalyser Stein Haugen K. G. Jebsen Professor i Teknisk Sikkerhet NTNU 2 Bakgrunn Chapter 6: On the usefulness of Risk Analysis in the light of Deepwater Horizon and

Detaljer

Erfaringsbaserte datakilder

Erfaringsbaserte datakilder Erfaringsbaserte datakilder IEC 61508 seminar, Sandefjord 04. mars 2008 Stein Hauge, SINTEF Jeg skal snakke om: 1. Innledning litt generelt om feildata 2. Eksempler på datakilder 3. Hvordan etableres anbefalte

Detaljer

Prosjektstyring, metodikk og løsningsutforming for SAP prosjekter. Sveinung Gehrken Fram

Prosjektstyring, metodikk og løsningsutforming for SAP prosjekter. Sveinung Gehrken Fram Prosjektstyring, metodikk og løsningsutforming for SAP prosjekter Sveinung Gehrken Fram Til diskusjon Hva kjennetegner vellykkede SAP prosjekter? Hvilken metodikk skal man velge? Noen tanker om løsningsvalg

Detaljer

Oppgave 1a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet.

Oppgave 1a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet. TDT445 Øving 4 Oppgave a Definer følgende begreper: Nøkkel, supernøkkel og funksjonell avhengighet. Nøkkel: Supernøkkel: Funksjonell avhengighet: Data i en database som kan unikt identifisere (et sett

Detaljer

Risikoanalysemetodikk

Risikoanalysemetodikk Risikoanalysemetodikk Mars 2012 Eva Henriksen, eva.henriksen@telemed.no Eva Skipenes, eva.skipenes@telemed.no Sikkerhetsrådgivere NST www.telemed.no/sikkerhet Metodikk for Risikoanalyse Risikovurdering

Detaljer

Innovasjonsvennlig anskaffelse

Innovasjonsvennlig anskaffelse UNIVERSITETET I BERGEN Universitetet i Bergen Innovasjonsvennlig anskaffelse Fredrikstad, 20 april 2016 Kjetil Skog 1 Universitetet i Bergen 2 Universitetet i Bergen Driftsinntekter på 4 milliarder kr

Detaljer

LCC som fokusområde i NSB ved store

LCC som fokusområde i NSB ved store Presentasjon i LCC Forum i Oslo Jan Runesson Direktør NSB Persontog Materiellanskaffelser Utgangspunkt Vi har mye kompetanse på hva som feiler på tog, hvor ofte og til hvilke kostnader og konsekvenser

Detaljer

buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata

buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata buildingsmart Norge seminar Gardermoen 2. september 2010 IFD sett i sammenheng med BIM og varedata IFD International Framework for Dictionaries Hvordan bygges en BIM? Hva kan hentes ut av BIM? Hvordan

Detaljer

Integritetsstyring Et verktøy for økt ytelse

Integritetsstyring Et verktøy for økt ytelse Integritetsstyring Et verktøy for økt ytelse Stig Brudeseth, MsC. Manager, Inspection Management Mye kontroll og lite ytelse? Vi utfører utstrakt kontroll av tilstand på utstyret vårt Kan vi få en merverdi

Detaljer

Aggregering av risikoanalyser med hensyn til etterlevelse

Aggregering av risikoanalyser med hensyn til etterlevelse Aggregering av risikoanalyser med hensyn til etterlevelse Atle Refsdal Atle.Refsdal@sintef.no 1 Oversikt Problemstilling Eksempler og kravtyper Målsetting og utfordringer Skisse til metode 2 Problemstilling

Detaljer

Tom Røise 18. Februar 2009

Tom Røise 18. Februar 2009 Forelesning IMT2243 18. Februar 2009 Tema : Kravspesifisering : litt mer om prosessen Viewpoint en myk tilnærming Use Case en scenariebasert teknikk innen metoden Objektorientert Analyse brukes til å avklare

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

Detaljer

Systemutviklingsmetoder

Systemutviklingsmetoder Systemutviklingsmetoder Kapittel 2, 4, 5 07.01.2004 Kirsten Ribu 1 I dag Et eksempel på et system med kravspesifikasjon Utviklingsmodeller: Strukturert systemutvikling (Fossefall-modellen) Evolusjonær

Detaljer

Debugging. Tore Berg Hansen, TISIP

Debugging. Tore Berg Hansen, TISIP Debugging Tore Berg Hansen, TISIP Innhold Innledning... 1 Å kompilere og bygge et program for debugging... 1 Når debugger er i gang... 2 Symbolene i verktøylinjen... 3 Start på nytt... 3 Stopp debugging...

Detaljer

Risk Modelling, Integration of Organisational, Human and Technical factors

Risk Modelling, Integration of Organisational, Human and Technical factors Risk Modelling, Integration of Organisational, Human and Technical factors Fra BORA til Risiko_OMT Innledning og leveranser ESRA seminar 8.2.2011 Aktiv bruk av risikoanalyser BORA seminar 3.5.2006 avslutning

Detaljer

Effektivisering av store komplekse prosjektleveranser. Agnar Johansen Prosjektleder

Effektivisering av store komplekse prosjektleveranser. Agnar Johansen Prosjektleder Effektivisering av store komplekse prosjektleveranser Agnar Johansen Prosjektleder La oss begynne med konklusjonen Teknisk Ukeblad, 1. september 2014: Nytt forskningsprogram Norge kan godt, I har skal

Detaljer

Risikoanalyse i et pasientsikkerhetsperspektiv tanker og idéer

Risikoanalyse i et pasientsikkerhetsperspektiv tanker og idéer Risikoanalyse i et pasientsikkerhetsperspektiv noen tanker og idéer Helse Vest 19. mars 2013 Sola Standhotell Willy Røed PREPARED. Presentasjon Willy Røed, PhD - Konsulent i Proactima AS - Førsteamanuensis

Detaljer

Prosjektledelse - fra innsiden

Prosjektledelse - fra innsiden Prosjektledelse - fra innsiden Presentasjon hos UiO 31.08.2012 Ida Lau Borch, fagansvarlig i Metier AS Det ligger et fantastisk potensial i det å være best i prosjektledelse og -styring Prosjekteierstyring

Detaljer

Brønnkontroll Veien videre

Brønnkontroll Veien videre Brønnkontroll Veien videre Stavanger 16 17 September 2011 Oddvar Midttveit Senior Vedlikeholdsingeniør Kjapt om EngMa AS Etablert: Mai 2010 Ansatte: 4 (6 fra 1.nov -11) Erfaring: Ca. 100 år samlet relevant

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Fra sekvensielt til parallelt

Fra sekvensielt til parallelt Fra sekvensielt til parallelt «Sanntidprogrammering etter 34 år» Øyvind Teig senior utviklingsingeniør Autronica Fire and Security, «a UTC company» Gjesteforelesning på Høgskolen i Sør-Trøndelag (HiST)

Detaljer

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene

Detaljer

Skjulte avhengigheter i signalsystemene? - Hvordan unngå at togene kolliderer

Skjulte avhengigheter i signalsystemene? - Hvordan unngå at togene kolliderer Skjulte avhengigheter i signalsystemene? - Hvordan unngå at togene kolliderer Terje Sivertsen Seksjonsleder Signal Jernbaneverket Banedivisjonen Teknikk, Premiss og utvikling Skjulte avhengigheter i komplekse

Detaljer

Sorte svaner. Terje Aven Universitetet i Stavanger. Brann og eksplosjonssikring i petroleumsindustrien 2014, Haugesund 6-7 Mai Tekna

Sorte svaner. Terje Aven Universitetet i Stavanger. Brann og eksplosjonssikring i petroleumsindustrien 2014, Haugesund 6-7 Mai Tekna Sorte svaner Terje Aven Universitetet i Stavanger Brann og eksplosjonssikring i petroleumsindustrien 2014, Haugesund 6-7 Mai Tekna Aven (2013) On the meaning of a black swan in a risk context. Safety Science,

Detaljer

Menneskelige og organisatoriske risikofaktorer i en IO-kontekst

Menneskelige og organisatoriske risikofaktorer i en IO-kontekst Menneskelige og organisatoriske risikofaktorer i en IO-kontekst The interplay between integrated operations and operative risk assessments and judgements in offshore oil and gas Doktoravhandling Siri Andersen

Detaljer

TIDLIGFASE CASE. Hvilke erfaringer har de prosjekterende og entreprenørene? Svein

TIDLIGFASE CASE. Hvilke erfaringer har de prosjekterende og entreprenørene? Svein TIDLIGFASE CASE Hvilke erfaringer har de prosjekterende og entreprenørene? Svein CASE TIDLIGFASE Gjennomført totalt fem workshop med entreprenører og prosjekterende. Delvis hver for seg, delvis sammen

Detaljer

Fra sekvensielt til parallelt

Fra sekvensielt til parallelt Fra sekvensielt til parallelt «Sanntidprogrammering etter 33 år» Øyvind Teig senior utviklingsingeniør Autronica Fire and Security, «a UTC company» Gjesteforelesning på Høgskolen i Sør-Trøndelag (HiST)

Detaljer

LED belysning for Ex-sone

LED belysning for Ex-sone LED belysning for Ex-sone Carsten Bonderup 04.06.2013, IFEA Bergen 2012 Eaton Corporation. All rights reserved. Cooper Crouse-Hinds LED produktgrupper LED lommelykter LED flomlys LED Pendanter LED Exit-skilt

Detaljer

Jernbaneverket Postboks 4350 2308 HAMAR. Att.: Saksbehandler: Mona Stryken, 22 99 59 22 Vår ref.: 06/84-96 SF2-521 Deres ref.: Dato: 24.11.

Jernbaneverket Postboks 4350 2308 HAMAR. Att.: Saksbehandler: Mona Stryken, 22 99 59 22 Vår ref.: 06/84-96 SF2-521 Deres ref.: Dato: 24.11. Jernbaneverket Postboks 4350 2308 HAMAR Att.: Wergelandsveien 3 NO-0167 Oslo Telefon: 22 99 59 00 Telefaks: 22 99 59 03 post@sjt.no www.sjt.no Saksbehandler: Mona Stryken, 22 99 59 22 Vår ref.: 06/84-96

Detaljer

ESRA - Er sikkerheten blitt for dyr? Hva er et kost-effektivt sikkerhetsnivå i offshorevirksomheten? Morten Sørum Senior rådgiver sikkerhet

ESRA - Er sikkerheten blitt for dyr? Hva er et kost-effektivt sikkerhetsnivå i offshorevirksomheten? Morten Sørum Senior rådgiver sikkerhet ESRA - Er sikkerheten blitt for dyr? Hva er et kost-effektivt sikkerhetsnivå i offshorevirksomheten? Morten Sørum Senior rådgiver sikkerhet Industriutfordringen CAPEX OPEX 2 Classification: Restricted

Detaljer

Social Media Insight

Social Media Insight Social Media Insight Do you know what they say about you and your company out there? Slik fikk Integrasco fra Grimstad Vodafone og Sony Ericsson som kunder. Innovasjon og internasjonalisering, Agdering

Detaljer

Passasjerer med psykiske lidelser Hvem kan fly? Grunnprinsipper ved behandling av flyfobi

Passasjerer med psykiske lidelser Hvem kan fly? Grunnprinsipper ved behandling av flyfobi Passasjerer med psykiske lidelser Hvem kan fly? Grunnprinsipper ved behandling av flyfobi Øivind Ekeberg 5.september 2008 Akuttmedisinsk avdeling, Ullevål universitetssykehus Avdeling for atferdsfag, Universitetet

Detaljer

Veileder for tilsynspersjonell om risikovurderinger

Veileder for tilsynspersjonell om risikovurderinger Veileder for tilsynspersjonell om risikovurderinger Veileder for tilsynspersonell om risikovurderinger INNHOLD 1. Innledning...1 2. Hva er egentlig risiko?...2 3. Risikostyring...2 4. Risikobildet...3

Detaljer

DC/AC inverters DC/AC invertere

DC/AC inverters DC/AC invertere DC/AC inverters DC/AC invertere Mascot range of DC/AC inverters Using a 12V or 24V battery, these inverters are ideal for applications such TV, video, smaller household appliances, and tools for camping,

Detaljer

Risikostyring og systemsikkerhet i bygninger teori og praksis

Risikostyring og systemsikkerhet i bygninger teori og praksis Risikostyring og systemsikkerhet i bygninger teori og praksis Henrik Bjelland Ph.D., Seniorrådgiver Seksjon HMS- og Risikostyring Bakgrunn Bygninger er avanserte systemer Flere delsystemer skal virke sammen

Detaljer

Risikobasert testing

Risikobasert testing Hans Schaefer hans.schaefer@ieee.org Prosjekt- og produktrisiko for testeren Prioritering av en første test Prioritering av senere tester Risikoledelse i selve testprosjektet 2009 Hans Schaefer page 1

Detaljer

Replacing the tube and/or tyre of a drive wheel, indoor/outdoor

Replacing the tube and/or tyre of a drive wheel, indoor/outdoor ASSEMBLY INSTRUCTION Replacing the tube and/or tyre of a drive wheel, indoor/outdoor EN NO 9010182A 5.2.7 9010182 Replacing the tube and/or tyre of a drive wheel, indoor/outdoor Preparation Be sure that

Detaljer

ATO program for Renewal of IR, Class or Type-rating

ATO program for Renewal of IR, Class or Type-rating May be used by the ATO in order to establish an individual training program for renewal of IR, Class or Type-rating in accordance with FCL.625 IR(c)(d) / AMC1 FCL.625(c) and FCL.740(b)(1)(2) / AMC1 FCL.740(b)(1)

Detaljer

PLAN. INF5180 Produkt og prosessforbedring i systemutvikling DEL 5 Målsetninger og måling. Geir Amsjø. geirams@ifi.uio.no, geir.amsjo@spitia.

PLAN. INF5180 Produkt og prosessforbedring i systemutvikling DEL 5 Målsetninger og måling. Geir Amsjø. geirams@ifi.uio.no, geir.amsjo@spitia. PLAN ACT INF5180 Produkt og prosessforbedring i systemutvikling DEL 5 Målsetninger og måling Geir Amsjø geirams@ifi.uio.no, geir.amsjo@spitia.no DO CHECK Målsetningsbasert Måling Det vi måler må knyttes

Detaljer

HMS-forum 2013. Tirsdag 12 mars 2013. Risikovurdering som verktøy i daglige beslutninger

HMS-forum 2013. Tirsdag 12 mars 2013. Risikovurdering som verktøy i daglige beslutninger HMS-forum 2013 Tirsdag 12 mars 2013. Risikovurdering som verktøy i daglige beslutninger Arild A. Danielsen Risk Manager arild.danielsen@fada.no 1 Risikovurdering Det vanlige er at risiko er et uttrykk

Detaljer

Norges ledende bedrift innen Linux og åpen programvare

Norges ledende bedrift innen Linux og åpen programvare Velkommen til Linpro Norges ledende bedrift innen Linux og åpen programvare Kort om Varnish Dag-Erling Smørgrav Senior Programvareutvikler Fagansvarlig C / C++ 2007-04-26 Hva er Varnish? HTTP-akselerator,

Detaljer

Independent audit av kvalitetssystemet, teknisk seminar 25-26 november 2014

Independent audit av kvalitetssystemet, teknisk seminar 25-26 november 2014 Independent audit av kvalitetssystemet, teknisk seminar 25-26 november 2014 Valter Kristiansen Flyteknisk Inspektør, Teknisk vedlikehold Luftfartstilsynet T: +47 75 58 50 00 F: +47 75 58 50 05 postmottak@caa.no

Detaljer

CSM Hva betyr dette for oss? Mona Tveraaen Kjetil Gjønnes Monika L. Eknes Jernbaneverket

CSM Hva betyr dette for oss? Mona Tveraaen Kjetil Gjønnes Monika L. Eknes Jernbaneverket CSM Hva betyr dette for oss? Mona Tveraaen Kjetil Gjønnes Monika L. Eknes Jernbaneverket Introduksjon Hensikt Gjennomgang av de ulike elementene i CSM hvordan disse håndteres hos oss våre tolkninger diskusjon

Detaljer

SIKKERHET OG TILLIT FRA ET TVERRFAGLIG PERSPEKTIV

SIKKERHET OG TILLIT FRA ET TVERRFAGLIG PERSPEKTIV SIKKERHET OG TILLIT FRA ET TVERRFAGLIG PERSPEKTIV Abelia Innovasjon Fagnettverk for Informasjonssikkerhet Oslo 17. mars 2005 Sikkerhet og tillit hva er sammenhengen? Ketil Stølen Sjefsforsker/Professor

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Universitet på dypt vann?

Universitet på dypt vann? Universitet på dypt vann? Professor Arnfinn Nergaard Masterstudiet i Offshoreteknologi Institutt for Konstruksjonsteknikk og Materialteknologi Marin- og undervannsteknikk Universitetet i Stavanger UiS

Detaljer

Frekvensbånd for mobilkommunikasjon i Norge dagens bruk, tillatelser, FDD/TDD, sameksistens, GSM-R og naboer

Frekvensbånd for mobilkommunikasjon i Norge dagens bruk, tillatelser, FDD/TDD, sameksistens, GSM-R og naboer Frekvensbånd for mobilkommunikasjon i Norge dagens bruk, tillatelser, FDD/TDD, sameksistens, GSM-R og naboer Tekna, seminar om mobilt bredbånd, 29. mars 2011 av John-Eivind Velure seksjonssjef i Post-

Detaljer

Forelesningsnotat. Kapittel 9 Designing and Constructing Software Code related Issues. Design og utvikling av programvare

Forelesningsnotat. Kapittel 9 Designing and Constructing Software Code related Issues. Design og utvikling av programvare Forelesningsnotat Kapittel 9 Designing and Constructing Software Code related Issues 1 Design og utvikling av programvare Grunnleggende metoder (Kap 9.1) Utvikling av kode (Kap 9.2) Programmeringsspråk

Detaljer

Fra risikoanalyse til sikkerhetsforberedende handling

Fra risikoanalyse til sikkerhetsforberedende handling Fra risikoanalyse til sikkerhetsforberedende handling TEKNA: Brann og eksplosjonssikring i petroleumsvirksomheten Erik Østby, Frank Børre Pedersen Haugesund, 16 mars 2007 Introduksjon Målet med fordraget:

Detaljer

The Future of Academic Libraries the Road Ahead. Roy Gundersen

The Future of Academic Libraries the Road Ahead. Roy Gundersen The Future of Academic Libraries the Road Ahead Roy Gundersen Background Discussions on the modernization of BIBSYS Project spring 2007: Forprosjekt modernisering Process analysis Specification Market

Detaljer

EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON

EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON Side 1 av 5 NTNU Norges teknisk-naturvitenskapelige universitet Institutt for telematikk EXAM TTM4128 SERVICE AND RESOURCE MANAGEMENT EKSAM I TTM4128 TJENESTE- OG RESSURSADMINISTRASJON Contact person /

Detaljer

NOVUG 3 februar 2009

NOVUG 3 februar 2009 NOVUG 3 februar 2009 Tjenestekatalog og CMDB En kombinasjon som fungerer i praksis 2008 Prosesshuset AS All tillhørende informasjon kan bli endret uten varsel 1 Introduksjon Stig Bjørling Ellingsen Gründer

Detaljer

ISO-standarderfor informasjonssikkerhet

ISO-standarderfor informasjonssikkerhet Verifying security since 1999 ISO-standarderfor informasjonssikkerhet ISO/IEC 27000-serien Information technology Security techniques oiso/iec 27000 Information security management systems Overview and

Detaljer

Validering og verifisering. Kirsten Ribu

Validering og verifisering. Kirsten Ribu Validering og verifisering Kirsten Ribu 2005 1 I dag Validering og verifisering Inspeksjon Testing 2 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer

Detaljer

Hva er risikovurdering?

Hva er risikovurdering? DLE-konferansen 2011 Color Fantasy 13.-15. september Hva er risikovurdering? Sjefingeniør Oddmund Foss Enhet for elektriske anlegg 1 Risiko 2 Hva er egentlig risiko? Risiko kan defineres som den fare eller

Detaljer

or*dtrosnilt,'+'.q':'

or*dtrosnilt,'+'.q':' %,u lbnvaston.*.'. or*dtrosnilt,'+'.q':' JavaBin 5. mai Vidar Alvestad - Skatteetaten Inspirert av: Noen eksempler er hentet fra boken. Jeg tror Mr. Feathers tilgir meg dersom du kjøper boken ;-) Hva er

Detaljer