Velkommen til jernbane session nr. 4 Håndtering af systemer med software (SW)
Hvem er vi? Lars Mortensen Trafik- og Byggestyrelsen Center for Jernbane lmo@tbst.dk Torben Lundbeck Trafik- og Byggestyrelsen Center for Luftfart1 TOLU@tbst.dk Sikkerhedskonferencen 2015 2
Agenda Orientering om arbejdet med at udarbejde en vejledning om håndtering af jernbanesystemer med software. Principperne for håndtering af SW ændringer på luftfartsområdet. Vi starter med vejledningen Sikkerhedskonferencen 2015 3
Vejledningens formål I vejledningen besvares følgende spørgsmål: a) Hvilke standarder og regler er relevante i forhold til SW? b) Hvordan bruges CSM RA i forhold til systemer med SW? c) Hvordan skal systemdefinitionen udformes? d) Hvordan afgøres det om en SW ændring er signifikant? e) Hvilket ansvar har Jernbanevirksomheden/Infrastrukturforvalteren? f) Hvordan er arbejdsdelingen mellem CSM assessoren (AsBo) og softwareassessoren (ASR)? g) Hvordan afgøres det om en SW ændring er Major/Minor jf. EN 50128? h) Hvordan afgøres det om en SW ændring skal betragtes som fornyelse/opgradering jf. interoperabilitetsdirektivet? i) Hvornår skal systemet med SW certificeres? j) Hvilken dokumentation skal fremsendes til TBST? Sikkerhedskonferencen 2015 4
EN50128: Programmel for styre- og sikkerhedssystemer. Sikkerhedskonferencen 2015 5 http://www.programmingresearch.com/resources/webinars/webinar-achieving-en-50128-compliance/
Hvad er SW? Definition in EN 50128: intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system. SW programs Procedure Rules System System Documentation Sikkerhedskonferencen 2015 6
Ændringsklassificeringer Major or Minor? Sikkerhedskonferencen 2015 7
Sammenhængen mellem CSM og EN 50128 CSM/EN50126 EN50128 ASR assessment rapport til AsBo Sikkerhedskonferencen 2015 8
Klassificering af ændringer (1) Er ændringen signifikant? Om ændringen er signifikant afgøres ud fra CSM forordningens 6 kriterier, og den foreløbige systemdefinition. Det er vigtigt at CSM systemet defineres korrekt, for at afgøre signifikans. Sikkerhedskonferencen 2015 9
Klassificering af ændringer (2) Start Ja Forudbestemt variant: - Ændringen er omfattet af en SVR eller et CoV og systemet er godkendt. - Ændringen foregår isoleret og kan ikke påvirke andre programmer. - Ændringen implementeres efter nogle på forhånd fastlagte procedurer. K1 Er SW funktionen SIL 3-4? Nej K3 Er SW funktionen SIL 1-2? Ja Ja K2 Er SW ændringen en forudset variant? Ja K4 Er SW ændringen en forudset variant? Ja Nej Nej Nej Simplicitet: - Kun et SW modul er berørt. - Modulet er indkapslet i en SW arkitektur som gør at andre. programmer ikke kan berøres. - Ændringen skal kunne testes 100%. K5 Indgår SW i samme computer hvor der findes SIL1-4 SW? Ja K6 Er SW ændringen simpel? Nej Nej Ja Sikkerhedskonferencen 2015 10 SW (ændringen) er MINOR
Ansvarsfordelingen på jernbaneområdet Fabrikantens ansvarsområde Ovenstående figur findes i DV29bis: Kommissionens henstilling af 5. december 2014: (2014/897/EU) Sikkerhedskonferencen 2015 11
Fabrikantens ansvar EN 50128, kapitel 5 I EN 50128 (kapitel 5) stilles der krav til fabrikantens kvalitetsstyringssystem. Dette skal som minimum implementerer de dele af ISO 9001, som handler om organisation og ansvarsfordeling. I standardens bilag B, er der desuden defineret en række personale funktioner og kompetence krav som vedrører SW udvikling/ændring. Fabrikantens QMS skal sikre at det projektteam, som tildeleles en SW udviklings- eller ændringsopgave, varetager de roller der fremgår af EN standarden, og er organiseret i overensstemmelse med standarden. Sikkerhedskonferencen 2015 12
Jernbanevirksomhedens/IF s ansvar Jernbanevirksomheder og infrastrukturforvaltere forventes ikke at have kompetencer til at udvikle/ændre SW i overensstemmelse med EN 50128 (det er fabrikantens ansvar). Det er derimod nødvendigt at Jernbanevirksomheder og infrastrukturforvaltere, sikre sig at ændringer bliver vurderet af kompetente parter, og at Trafik- og Byggestyrelsen involveres når det er påkrævet. Som støtte hertil, har TBST udarbejdet et udkast til en procesmodel for håndtering af SW ændringer. Sikkerhedskonferencen 2015 13
Udkast til Procesmodel Sikkerhedskonferencen 2015 14
Udkast til Procesmodel Sikkerhedskonferencen 2015 15
Udkast til Procesmodel Sikkerhedskonferencen 2015 16
Og nu til luftfart Ændrings styring af Luftfartstjeneste Systemer Sikkerhedskonferencen 2015 17
Organisering af luftfartsområdet Sikkerhedskonferencen 2015 18
Lovgivning på luftfartsområdet. Sikkerhedskonferencen 2015 19
Luftfartstjeneste udstyr Sikkerhedskonferencen 2015 20
SYSTEM - Sikkerhedskrav Sikkerhedskonferencen 2015 21
Risikovurdering-Funktionalitet Sikkerhedskonferencen 2015 22
Notifikation - Sikkerhedskonferencen 2015 23
Softwarefejl-Hazard-Effekt Sandsynligheden ( Ph x Pe ), for, når software fejler kan generere en effekt Ph (PSSA-identificeret) er sandsynligheden for at når softwaren fejler at dette genererer en Hazard. Ph er rimeligheden i evnen for at den resterende del af arkitekturen at mindske softwarefejl; Pe (FHA-identificeret) er sandsynligheden for, at Hazarden genererer en effekt, der har en vis alvorsgrad. Sandsynlighed Pe (mest sandsynlige effekt). Sikkerhedskonferencen 2015 24
Tildeling af SWALværst troværdige senarie Hazard1: Hazard2: Dette software (modul/scci) vil blive tildelt et Swal = SWAL3 da det er det mest stringente Swal niveau - SWAL3 idet For Hazard 1: Værste Troværdig effekt af Hazard 1 = Severity 3 ( FHA resultat ), og Hvis det er "Very Possible, at en SW fejl eller svigt genererer Hazard1 og en virkning, der har en Severity 3, så tildeles SW SWAL3 For Hazard 2: Troværdig effekt af Hazard 2 = Severity 3 ( FHA resultat ), og Hvis det er Very Unlikely, at en SW fejl eller svigt genererer Hazard2 og en virkning, der har en Severity 3, så er denne SW bør tildeles en SWAL4 Sikkerhedskonferencen 2015 25
ED153-SOFTWARE SAFETY ASSURANCE SYSTEM Software Safety Assurance System Overall Objectives - Software Safety Assessment Initiation - Software Safety Assessment Planning - se. Uddrag nedenfor - Software Safety Requirements Specification - Software Safety Assessment Validation, Verification & Process Assurance - Software Safety Assessment Completion
ED153-Hovedprocesser
SSF1(2) OUTPUT Dokumentation Sikkerhedskonferencen 2015 28