Anhang 2.3: Dokumentationsumfang bei der Zulassung gemäß CENELEC

Transkript

1 Schlussbericht Anhang zu AP 2000 Optimierung des Zulassungsprozesses Anhang 2.3: Dokumentationsumfang bei der Zulassung gemäß CENELEC 1. Vorarbeiten und Unterarbeitspaket Beispielhafte Dokumentenlisten ('Best Practice')

2 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Teilbericht AP2200 Dokumentationsumfang bei der Zulassung gemäß CENELEC Vorarbeiten und Unterarbeitspaket Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

3 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Änderungsverfolgung Datum Bearbeiter Version Inhalt Mathias Wagner (Bombardier) 0.2 Erster Entwurf Mathias Wagner (Bombardier) 0.3 Überarbeitung nach weiteren Arbeitsergebnissen der AG Hr. Beck (DB AG) Hr. Czepa (Thales) 0.4 Gemeinsame Überarbeitung nach vorherigem Review. Hr. Griebel (Siemens) Fr. Möller-Neustock (Funkwerk AG, TCC) Hr. Pietz (Pintsch Bamag) Hr. Dr. Priebe (S&B) Hr. Schwencke (DLR) Hr. Wagner (Bombardier) Hr. Czepa (Thales) Hr. Griebel (Siemens) Fr. Möller-Neustock (Funkwerk AG, TCC) Hr. Pietz (Pintsch Bamag) Hr. Dr. Priebe (S&B) Hr. Schwencke (DLR) Hr. Wagner (Bombardier) 1.0 AG3-interne Freigabe nach finalem Review. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 2 von 18

4 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Inhaltsverzeichnis 1 Einleitung Vorgaben Definitionen Rollendefinitionen Spaltentitel Abkürzungen Dokumentenliste Zusammenfassung Version: 1.0, Status: Freigegeben (AG3-intern) Seite 3 von 18

5 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 1 Einleitung Die CENELEC-Normen EN 50126, EN und EN beschreiben die Entwicklung von Bahnanwendungen. Sie lassen dem Anwender einen großen Interpretations- und Handlungsspielraum. So kann er auch relativ frei entscheiden, welche Maßnahmen er zur Entwicklung eines sicheren Systems anwenden möchte. Umfassende Tabellen in den Anhängen der Normen EN und EN geben eine Auswahl von Maßnahmen, die anzuwenden sind. Oftmals soll der Anwender eine geeignete Kombination von Maßnahmen auswählen, wobei nur eingeschränkt spezifiziert ist, unter welchen Umständen eine Auswahl geeignet ist. Ziel der AG ist eine Abstimmung aller Projektpartner über eine einheitliche CENELEC-konforme Dokumentenliste bei der Einreichung zur Zulassung von Projektvorhaben. Auf Basis dieser einheitlichen Liste sollen Best Practice-Beispiele erarbeitet und Interpretationsspielräume der Normen identifiziert und reduziert werden. Zur Erfüllung dieses Arbeitspaketes 2200 wurde die Aufgabenbeschreibung in die folgenden Unterarbeitspakete strukturiert: 1. Erstellung von beispielhafte Dokumentenlisten ('Best Practice') für drei spezifische Anwendungsfälle 2. Dokumentenliste und der Maßnahmenkatalog ('Best Practice') werden als Anhang zum Sektorhandbuch Infrastruktur aufbereitet. (mit dem Stand der aktuell gültigen CENELEC- Normen zwischen den bisherigen Teilnehmern der Arbeitsgruppe abgestimmt) 3. Enge Abstimmung mit der AG2 CSM-VO 4. Nach der Abstimmung mit dem Betreiber soll die seit vorliegende pren in die Dokumentenliste eingearbeitet werden Das vorliegende Dokument zeigt die Ergebnisse der Vorarbeiten zu den oben genannten Unterarbeitspaketen , und Hierzu wurde zwischen den Projektpartnern eine generische, CENELEC-konforme Dokumentenliste abgestimmt. Es ist geplant, eine Abstimmung mit dem Eisenbahn-Bundesamt im Rahmen der Veröffentlichung der Ergebnisse des Fördervorhabens durchzuführen. Das Unterarbeitspaket Enge Abstimmung mit der AG2 CSM-VO wurde bereits abschließend bearbeitet und die Ergebnisse [Ergebnisbericht CSM-VO: NeGSt_Ergebnisbericht_ 2100_CENELEC_ pdf] wurden in die hier vorliegende Dokumentenliste eingearbeitet. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 4 von 18

6 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 2 Vorgaben Die in den Kapiteln 3 und 4 dargestellte generische Dokumentenliste wurde von den Projektpartnern gemeinsam erarbeitet. Grundlage für die Liste waren die folgenden Versionen der CENELEC-Normen: DIN EN 50126:2000 DIN EN 50128:2001 DIN EN 50128:2012 DIN EN 50129:2003 Da die Aufgabenbeschreibung keine Vorgaben hinsichtlich der Safety Integrity Level (SIL) macht, wurde in der Arbeitsgruppe festgelegt, dass für die Dokumentenliste zunächst SIL 4 zugrunde liegt. Eine zukünftige Erweiterung um die Betrachtung von SIL 2 wird angestrebt. Für jedes aufgeführte Dokument wurde festgelegt, Ersteller (Rolle), wer ist der Erstellers des Dokuments (siehe Tabelle 1: Definierte Rollen)? Erste Prüfung (Rolle), von wem wird das Dokument geprüft (siehe Tabelle 1: Definierte Rollen)? Zweite Prüfung (Rolle), falls die erste Prüfung bewertet werden soll 1, von wem (siehe Tabelle 1: Definierte Rollen)? Vorlage bei / Abstimmung mit Betreiber, ist das Dokument dem Betreiber vorzulegen? Prüfung durch Gutachter, ist das Dokument in jedem Fall dem Gutachter vorzulegen? Prüfung durch EBA, ist das Dokument in jedem Fall beim EBA vorzulegen? Ziel der Arbeitsgruppe war dabei, die Vorgaben der CENELEC-Normen im Detail umzusetzen. Der Gutachter und das Eisenbahn-Bundesamt können bei konkreten Projekten andere Vorstellungen zu diesen Punkten haben, die gesondert vereinbart werden müssen. Diese sind dann für das konkrete Projekt zwischen Hersteller auf der einen Seite und Gutachter/Eisenbahn- Bundesamt auf der anderen Seite projektspezifisch abzustimmen. Für einige Dokumente wurden mögliche Dokumentenzusammenfassungen festgelegt. Diese geben an, mit welchen anderen Dokumenten ein Dokument zusammengefasst werden kann (Z). Zusätzlich wurde angegeben, ob das fragliche Dokument Teil eines anderen Dokumentes sein kann (T) oder ob es ein anderes Dokument enthalten kann (E). Bei der Erstellung der Dokumentenliste wurde der Entwicklungsprozess eines Produktes betrachtet. Die Phasen davor und danach wurden nicht betrachtet. Da die Bau-STE nicht in die CENELEC-Normen eingeflossen ist, wurde dieser Aspekt auch nicht in die generische Dokumentenliste aufgenommen. Die oben genannten Versionen der CENELEC-Normen liefern im Gegensatz zur Software für die Hardwareentwicklung keine detaillierten Vorgaben. Da Software im Gegensatz zur Hardware nicht im Sinne eines Ausfalls versagen kann und sich Softwarefehler grundsätzlich als systematische Fehler im Systemverhalten zeigen, wurde der Software die eigene CENELEC-Norm EN gewidmet. Aus Sicht der EN ist es nicht möglich, die Korrektheit von Software allein durch Analysen und Tests nachzuweisen. Deshalb wird in der EN neben Analyse und Test das Augenmerk ganz wesentlich auf den SW-Erstellungsprozess gelegt, um systematische Fehler zu minimieren. 1 In Analogie zum Anhang C der EN wird, wenn nur eine Prüfung durchgeführt wird, diese in einigen Fällen hier vermerkt, insbesondere wenn es sich um Prüfungen durch den Validierer handelt Version: 1.0, Status: Freigegeben (AG3-intern) Seite 5 von 18

7 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Im Gegensatz dazu ist bei der Hardware und auf Systemebene der Nachweis korrekten Verhaltens auf der Basis von Analysen und Tests und der Implementierung geeigneter Maßnahmen auf z.b. physikalischer, konstruktiver, elektrischer Ebene möglich. Deshalb schreibt die CENELEC- Norm für Hardware keinen detaillierten Entwicklungsprozess vor. Die sinngemäße Übertragung des detaillierten SW-Entwicklungsprozesses auf den HW- Entwicklungsprozess würde zu erheblichen Mehraufwänden ohne vertretbaren Nutzen führen und wird deshalb nicht als geeignetes Vorgehen angesehen. Die Hardware-Dokumentation wurde im Rahmen der generischen Dokumentenliste geeignet ergänzt. Im Rahmen der Bearbeitung des Best Practice Neue spezifische Applikation muss eine Differenzierung zwischen den Dokumenten für generische Produkte/Applikationen und spezifische Applikationen durchgeführt werden. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 6 von 18

8 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 3 Definitionen Folgende Rollendefinitionen, Spaltentitel und Abkürzungen werden in Tabelle 4 verwendet. 3.1 Rollendefinitionen Kürzel Rolle Beschreibung AG Auftraggeber AN Auftragnehmer ASR Gutachter s. EN 50128:2012 Anh. B, fasst die Rollen "interner Gutachter", "Prüfleitstelle" und "externer Gutachter" zusammen DES Designer s. EN 50128:2012 Anh. B IMP Implementierer s. EN 50128:2012 Anh. B INT Integrator s. EN 50128:2012 Anh. B PM Projektmanager s. EN 50128:2012 Anh. B RQM Anforderungsmanager s. EN 50128:2012 Anh. B TST Tester s. EN 50128:2012 Anh. B VAL Validierer s. EN 50128:2012 Anh. B VER Verifizierer s. EN 50128:2012, , umfasst die Gruppe der Verifizierer und Reviewer. Ein Reviewer arbeitet im Auftrag des Verifizierers und hat ebenso wie dieser die Aufgabe einer fachlichen Prüfung gemäß Verifikationsplan. Ergebnis eines Reviews oder einer Verifikation ist immer schriftlich dokumentiert. 4A Prüfer nach dem 4-Augen- Prüfung gemäß ISO 9001 Prinzip SM Safety Manager Gemeint ist der Projektmitarbeiter, der nicht zwingend unabhängig vom Projekt sein muss QM Qualitäts-Manager CM Konfigurations-Manager DEV Entwickler (Rollengruppierung) fasst die Rollen DES, IMP und RQM zusammen TES Tester (Rollengruppierung) fasst die Rollen TST und INT zusammen Tabelle 1: Definierte Rollen Version: 1.0, Status: Freigegeben (AG3-intern) Seite 7 von 18

9 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 3.2 Spaltentitel Spalte im Arbeitsblatt "Dokumente" CENELEC-Phase Ersterstellung Erläuterung Phase des CENELEC-Prozesses nach EN 50126, in der das Dokument angelegt wird Mögliche Einträge Zahl zwischen 1 und 14, ggf. auch mehrere mögliche Phasen Dokumentenkürzel Kürzel für den (englischen) Dokumentennamen <Kürzel>, i.d.r. beginnend mit "Pr...", "Sy ", "Sw " oder "Hw..." für Projekt-, System-, Software- und Hardware-Dokumente Dokumentenname englisch/deutsch vollständiger (englischer/deutscher) Name des Dokuments gemäß aktuellster CENELEC-Norm <Name> CENELEC-Verweis EN 5012x:jjjj Wo wird das Dokument in der jeweiligen Norm genannt? Nummern der Unterpunkte der jeweiligen Norm, z. B. " , 6.3 und Anh. D" Ersteller (Rolle) Rolle des Erstellers des Dokuments Kürzel vom Arbeitsblatt "Rollen" Erste Prüfung Von wem wird das Dokument geprüft? <Rolle des Prüfers>, z. B. "VER" Zweite Prüfung Vorlage bei / Abstimmung mit Betreiber Prüfung durch Gutachter Falls die erste Prüfung bewertet werden soll 2, von wem (siehe Tabelle 1: Definierte Rollen) Ist das Dokument dem Betreiber vorzulegen? Ist das Dokument in jedem Fall dem Gutachter vorzulegen? <Rolle des Prüfers>, z. B. "VAL" x = ja, (x) = bei Bedarf / projektabhängig x = ja, (x) = bei Bedarf 2 In Analogie zum Anhang C der EN wird, wenn nur eine Prüfung durchgeführt wird, diese in einigen Fällen hier vermerkt, insbesondere wenn es sich um Prüfungen durch den Validierer handelt Version: 1.0, Status: Freigegeben (AG3-intern) Seite 8 von 18

10 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Prüfung durch EBA Dokumentenhierarchien und mögliche Dokumentenzusammenfassung Ist das Dokument in jedem Fall beim EBA vorzulegen? Mit welchen anderen Dokumenten kann das Dokument zusammengefasst werden? Ist es Bestandteil von anderen Dokumenten oder enthält es andere Dokumente? x = ja, (x) = Prüfbericht zur Qualitätskontrolle Z <Dokumentenkürzel>, T <Dokumentenkürzel>, E <Dokumentenkürzel> Kommentar Tabelle 2: Erklärung der Spaltentitel Gibt es Besonderheiten zum Dokument, die neben den vordefinierten Spalten wichtig zum Verständnis des Dokuments sind? <freier Text> Hinweis zur ersten/zweiten Prüfung: Jedes Dokument unterliegt dem 4-Augen-Prinzip, entweder automatisch durch den 1./2. Prüfer oder durch einen Reviewer. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 9 von 18

11 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 3.3 Abkürzungen Abkürzung Beschreibung AG Arbeitsgruppe AP Arbeitspaket CENELEC Europäisches Komitee für elektrotechnische Normung CSM-VO Verordnung (EG) Nr. 352/2009 über die Festlegung einer gemeinsamen Sicherheitsmethode für die Evaluierung und Bewertung von Risiken DIN Deutsche Industrienorm EBA Eisenbahn-Bundesamt EN Europäische Norm FMEA Ausfalleffektanalyse HW Hardware ISO Internationale Organisation für Normung NeGSt Neue Generation Signaltechnik NTZ Neue Typzulassung pren Vorläufige europäische Norm PT2 Planteil 2 Sb 3 Sachbereich 3 (des Eisenbahn-Bundesamtes) SIL Sicherheitsanforderungsstufe SW Software Tabelle 3: Verwendete Abkürzungen Version: 1.0, Status: Freigegeben (AG3-intern) Seite 10 von 18

12 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 4 Dokumentenliste CENELEC-Phase Ersterstellung Dokumentenkürzel Dokumentenname englisch Dokumentenname deutsch CENELEC-Verweis EN 50126:1999 CENELEC-Verweis EN 50128:2001 CENELEC-Verweis EN 50128:2012 CENELEC-Verweis EN 50129:2003 1/2 Konzept und Systemdefinition --- SyCR Customer Requirements Kundenanforderung AG optionales Dokument; wird u.u. bis inkl. Phase 4 weiter verfeinert 1-2 SyDef System Definition Systemdefinition Pkt AG SyDP Development Plan Entwicklungsplan Pkt d -> ISO 9003 Ersteller (Rolle - keine Person) Erste Prüfung Zweite Prüfung Vorlage bei / Abstimmung mit Betreiber Prüfung durch Gutachter Prüfung durch EBA Dokumentenhierarchien und mögliche Dokumentenzusammenfassungen PM 4A E PrTL ist möglich 1 PrTL Project Timeline Projekt-Zeitplan PM x T SyDP ist möglich 1 PrDL Document List Dokument-Übersicht PM x PrG Glossary Glossar nicht festgelegt 1-2 SySP Safety Plan Sicherheitsplan Pkt SyQMP Quality Management Plan 2-10 SyQMR Quality Management Report 2 SyPVR Planning Verification Report 2-10 SySMR Safety Management Report Sicherheitsmanagementbericht Qualitätssicherungsplan (Pkt d, Pkt ) Qualitätsmanagementbericht Pkt Pkt (für SW- Teil) Pkt , C.1/1 (für SW-Teil) Planungsverifikationsbericht Pkt , Pkt , Pkt , C.1/ Pkt SM 4A --- x kann auch die die RAM- Aspekte enthalten (RAM- Programm aus Kapitel 6.4) Pkt SM (4A) --- x x (50129, 5.5.2) --- T SySC, E HazLog, kann auch die RAM- Aspekte enthalten (RAM- Programm aus Kapitel 6.4) Kommentar Herstellerspezifisches Projektkonzept Z SySMR wird als sinnvoll erachtet (da dort die Prüfungsergebnisse zum SySP stehen) Z SySP wird als sinnvoll erachtet (als zu überprüfendes Dokument), 4-Augen- Prinzip im Falle eines externen Gutachters QM 4A --- x muss nach aktueller Praxis dem Gutachter vorgelegt werden Kap.15 Pkt. 5.2 QM (4A) --- x x (50129, 5.5.2) --- T SySC Z SyQP wird als sinnvoll erachtet (als zu überprüfendes Dokument); enthält Ergebnisse zur Anforderungsverfolgbarkeit - kann eigenständiges Dokument (Anf.verfolgbarkeitsmatrix) oder Teil des Berichtes sein, s. diverse Stellen in der EN 50128: Augen-Prinzip im Falle eines externen Gutachters VER --- VAL - Verifiziert alle Pläne außer dem Validierungsplan. Heißt lt :2012 (Software-) Qualitätssicherungsverifikationsbericht Version: 1.0, Status: Freigegeben (AG3-intern) Seite 11 von 18

13 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 1-2 SyCMP Configuration Management Plan Konfigurationsmanagementplan (Pkt ) Pkt (für SW- Teil) Pkt , C.1/3 (für SW-Teil) 1-2 SyVeP Verification Plan Verifikationsplan (Pkt ) Pkt Pkt ff, C.1/4 (für SW-Teil) 1-2 SyVaP Validation Plan Validierungsplan (Pkt ) Pkt (für SW- Anteil) Pkt , C.1/5 (für den SW- Teil) Pkt , Tabelle E.9 Pkt , Tabelle E.9 CM 4A --- x VER --- SM (x) Enthält den Software-Verifikationsplan. Die Aufgaben sind in der definiert, nicht das Dokument. Im aktuellen Entwurfsstand der neuen werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genauere Angaben zu geforderten Dokumenten macht. VAL SM --- (x) x --- Die Aufgaben sind in der definiert, nicht das Dokument. Im aktuellen Entwurfsstand der neuen werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genauere Angaben zu geforderten Dokumenten macht 1-2 SyTP Test Plan System-Testplan Pkt TES --- VAL (x) x --- Z SwITP, Z SwHwITP 1-2 SyAP Assessment Plan Begutachtungsplan --- Pkt C.1/45 3 Risikoanalyse 3 SyHA Hazard and Risk Analysis Gefährdungs- und Risikoanalyse Pkt , Pkt Anh. D 3 SyHL Hazard Log Gefahrenprotokoll Pkt , Definition in Pkt Systemanforderungen 4 SyRS System Requirements Specification 4 SySRS System Safety Requirements Specification 4 SyTS System Test Specification 4 SyRVR System Requirements Verification Report System- Anforderungsspezifikation System- Sicherheitsanforderungsspezifikation System-Testspezifikation Pkt (für SW) System- Anforderungsverifikationsbericht ASR 4A auch als "Prüfhandbuch" bezeichnet; in der Regel fordert das EBA die Vorlage des SyAP; ist bislang nur für SW verpflichtend. Definiert die Kriterien, Arbeitsweise und den Arbeitsumfang der Prüfleitstelle/des Gutachters Anh. A AG x x In Zukunft gemäß NTZ keine Prüfung durch EBA mehr? Unklar, ob die Revision der (neue 50126) weiterhin Prüfung durch Aufsichtsbehörde fordert Pkt Pkt SM (4A) --- x x --- T SySMR gängiger Begriff ist "Gefährdungslogbuch". 4A-Prüfung im Falle eines externen Gutachters Pkt Anh. A Pkt AG/AN (VER) (VAL) (x) (x) (x) Z SySRS, Z SwRS, Z HwRS Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN Pkt. 6.4 Kap. 8 Pkt AG/AN (VER) (VAL) (x) (x) (x) Z SyRS Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN. Sicherheitskonzept gemäß Mü 8004 kann in diesem Dokument aufgehen. Prüfungen finden statt bei Ersteller AN Pkt , TST VER VAL (x) Z SwOTS enthält neben der Abdeckung der Systemanforderungen Pkt. 5.4 auch noch zusätzliche Pkt C.1/8 VER --- VAL (x) Z SwRVR, Z HwRVR Test zur Gesamtsystemfunktionalität Falls das Lastenheft im Rahmen der Entwicklung erstellt wird, muss es auch verifiziert werden; wenn SwRS und HwRS mit SyRS zusammengelegt, dann auch SwRVR und HwRVR mit SyRVR Version: 1.0, Status: Freigegeben (AG3-intern) Seite 12 von 18

14 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 5 Systementwurf 5 SyAS System Architecture Specification 5-6 SwHwITP SW/HW Integration Test Plan System- Architekturspezifikation 5 SyDS System Design Specification 5 SyADVR System Architecture and Design Verification Report System- Entwurfsspezifikation System-Architektur- und Entwurfsverifikationsbericht C.1/9 Pkt. B.2.1 DEV VER VAL (x) Z SyDS in diesem Dokument können ggf. Subsysteme definiert werden, die entweder in den SW-/HW-Architekturdokumenten beschrieben werden (6.1.2/6.2.2) oder für die wiederum die System-Dokumente angefertigt werden (neuer Prozess) C.1/10 Pkt DEV VER VAL (x) Z SyAS oft wird auch der Begriff "Pflichtenheft" verwendet, s. Kommentar SyAS Pkt C.1/14 VER --- VAL (x) Z Komponentenentwurfsbericht möglich - TODO SW/HW-Integrationstestplan Pkt C.1/13 TES --- VAL (x) Z SyTP, Z SwITP 6 Entwicklung/Konstruktion und Implementierung 6.1 Hardware Zu Kapitel 6.1 s. "Kommentar Hardware" in Kapitel HW-Anforderungen HW-Entwurf 6 HwRS HW Requirements Specification HW- Anforderungsspezifikation DEV 4A Z SyRS, Z SwRS, Z HwDS, Z HwAS, Z HwIS 6 HwDS HW Design Specification HW-Entwurfsspezifikation DEV 4A Z HwRS, Z HwAS, Z HwIS, Z HwCDS 6 HwAS HW Architecture Specifi- HW-Architekturspezifikation DEV 4A Z HwRS, Z 6 HwCDS HW Component Design Specification cation 6 HwIS HW Interface Specification HW-Komponentenentwurf HW- Schnittstellenspezifikation HW- Komponentenentwurfsspezifikation HwDS, Z HwIS DEV 4A --- (x) Z HwRS, Z HwDS, Z HwAS DEV 4A Z HwDS 6 HwCFMEA HW Component FMEA HW-Komponenten-FMEA DEV 4A HwCRC HW Component Reliability Calculations DEV 4A HW-Fertigungsunterlagen 6 HwPD HW Production Documents HW-Komponententest 6 HwCTS HW Component Test Specification 6 HwCTR HW Component Test Report HW Verifikationsbericht entfällt, wenn nur eine Komponente im System vorhanden entfällt, wenn nur eine Komponente im System vorhanden entfällt, wenn nur eine Komponente im System vorhanden HW-Fertigungsunterlagen DEV 4A Layout, Stücklisten, Grundschaltungen, etc. HW-Komponenten- Zuverlässigkeitsberechnungen HW- Komponententestspezifikation HW- Komponententestbericht TES 4A TES 4A HWVR HW Verification Report HW Verifikationsbericht VER --- VAL Verifikationsbericht fasst alle Verifikationsschritte für die HW zusammen. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 13 von 18

15 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 6.2 Software SW-Anforderungen 6 SwOTS SW Overall Test Specification 6 SwRVR SW Requirements Verification Report 6 SwAS SW Architecture Specification 6 SwDS Software Design Specification 6 SwIS SW Interface Specification 6 SwADVR SW Architecture and Design Verification Report 6 SwRS SW Requirements Specification SW- Anforderungsspezifikation Pkt Pkt , C.1/6 SW-Gesamttestspezifikation Pkt Pkt , C.1/7 SW- Anforderungsverifikationsbericht DEV VER VAL Z SyRS, Z HwRS TES VER VAL Z SyTS früher (50128:2003): SW- Anforderungstestspezifikation Pkt VER --- VAL Z SyRVR, Z HwRVR, Aufteilung in SW- Anforderungsverifikationsbericht und SW- Anforderungstestverifikationsbericht wird je nach Projektumfang als sinnvoll erachtet SW-Architekturspezifikation Pkt Pkt DEV VER VAL Z SwDS, Z SwIS SW-Entwurfsspezifikation Pkt Pkt. DEV VER VAL Z SwAS, Z SwIS SW- Pkt. DEV VER VAL Z SwDS, Z Schnittstellenspezifikation SwAS SW-Architektur- und Entwurfsverifikationsbericht Pkt C.1/11 Pkt SwITP SW Integration Test Plan SW-Integrationstestplan Pkt Pkt , C.1/ SW-Komponentenentwurf 6 SwCDS SW Component Design Specification 6 SwCDVR SW Component Design Verification Report SW-Implementierung 6 SwSC SW Sourcecode and Additional Documentation 6 SwSCVR SW Sourcecode Verification Report SW- Komponentenentwurfsspezifikation SW- Komponentenentwurfsverifikationsbericht SW-Quellcode und Hilfsdokumentation SW- Quellcodeverifikationsbericht Pkt Pkt. 7.4 C.1/15 Pkt Pkt Pkt C.1/17 Pkt Pkt. 7.5 C.1/18 VER --- VAL Aufteilung in SW- Architekturverifikationsbericht und SW- Entwurfsverifikationsbericht wird je nach Projektumfang als sinnvoll erachtet TES --- VAL (x) Z SyTP, Z SwHwITP s. Kommentar SyAS s. Kommentar SyDS s. Kommentar SyAS/SyDS DEV VER VAL Früher (50128:2003) "Modul" statt "Komponente" VER --- VAL Z SwSCVR, Z SwCTR Früher (50128:2003) "Modul" statt "Komponente" DEV VER Früher "Zusatzdokumentation" statt "Hilfsdokumentation"; zweite Prüfung gemäß EN 50128:2012 Tabelle C.1 wird nicht immer als sinnvoll erachtet Pkt C.1/19 VER --- VAL Z SwCDVR, Z SwCTR Version: 1.0, Status: Freigegeben (AG3-intern) Seite 14 von 18

16 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC SW-Komponententest 6 SwCTS SW Component Test Specification 6 SwCTR SW Component Test Report 6.3 Integration 6 SwITS SW Integration Test Specification 6 SwHwITS SW/HW Integration Test Specification 6 SwITR SW Integration Test Report 6 SwHwITR SW/HW Integration Test Report 6 SyAPP Application Preparation Plan 6 SyIVR Integration Verification Report 7 Fertigung 7 SyARS Application Requirements Specification 7 SyATS Application Test Specification 7 SyAAD Application Architecture and Design 7 SySCADA Source Code of Application Data/Algorithms 7 SyAPVR Application Preperation Verification Report SW- Komponententestspezifikation SW- Komponententestbericht Pkt Pkt. 7.4 C.1/16 Pkt Pkt C.1/20 SW- Integrationstestspezifikation (Pkt ) Pkt SW/HW- Pkt Pkt. Integrationstestspezifikation SW-Integrationstestbericht Pkt Pkt C.1/21 SW/HW- Pkt Pkt Integrationstestbericht C.1/22 Anwendungs- Pkt. Pkt Generierungsplan C.1/29 Integrationsverifikationsbericht Pkt Anwendungs- Anforderungsspezifikation Pkt C.1/28 Anwendungs- Pkt Testspezifikation C.1/30 Anwendungsarchitektur und -entwurf Pkt C.1/31 Quellcode der Anwendungsdaten-/Algorithmen Anwendungs- Generierungsverifikationsbericht 7 SyATR Application Test Report Anwendungs-Testbericht Pkt SyRDP Release and Deployment Plan 7 SyADAVR Application Data/Algorithms Verification Report Freigabe- und Bereitstellungsplan Anwendungsdaten- /Algorithmen- Verifikationsbericht C.1/34, Pkt , Pkt C.1/33 C.1/36 vom firmenspezifischen Prozess abhängig 7 SyDM Deployment Manual Bereitstellungshandbuch C.1/37 vom firmenspezifischen Prozess abhängig DEV VER Norm alt: Modul --> Norm neu: Komponente DEV VER Z SwCDVR, Z SwSCVR TES VER VAL (x) Z SwHwITS TES VER VAL (x) Z SwITS Der zugehörige Verifikationsbericht ist der SwCDVR TES (x) Z SwHwITR, Z SyTR TES (x) Z SwITR, Z SyTR DEV --- VAL (x) x x entfällt lt. EBA-Tabellen bei generischer Software (nur bei anwend.-spezifisch konfigurierten Systemen); EBA-Vorlage zur Bauaufsichtl. Freigabe/Abnahme Sb 3 Dieser generische Plan beschreibt die Umsetzung in der spezifischen Anwendung (siehe EN 50128: ) VER --- VAL (x) DEV VER VAL x TES VER VAL x DEV VER VAL Ist so in der Norm genannt, Titel ist aber eigentlich unlogisch, da der entsprechende Abschnitt die Datengenerierung und -prüfung beschreibt. DEV VER PT2 x --- x Z. B. Konfigurationsdateien. Zweite Prüfung wird durch PT2-Prüfung abgedeckt. Mit "Prüfung durch EBA" ist hier das örtliche EBA gemeint. VER --- VAL x TES VER VAL x entfällt lt. EBA-Tabellen bei generischer Software (nur bei anwend.-spezifisch konfigurierten Systemen); EBA-Vorlage zur Bauaufsichtl. Freigabe/Abnahme Sb 3 VER --- VAL x Keine expliziten Dokumente für den Entwicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abgedeckt x Keine expliziten Dokumente für den Entwicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abgedeckt Version: 1.0, Status: Freigegeben (AG3-intern) Seite 15 von 18

17 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 7 SyRNs Release Notes Freigabemitteilungen C.1/38 vom firmenspezifischen Prozess abhängig 7 SyRN Release Note Freigabemitteilung , C.1/27 vom firmenspezifischen Prozess abhängig 7 SyDR Deployment Record Bereitstellungsaufzeichnungen C.1/39 vom firmenspezifischen Prozess abhängig 7 SyDVR Deployment Verification Report E SyRN Keine expliziten Dokumente für den Entwicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abgedeckt x T SyRNs Zusammenfassung der ausführlichen Release Notes x Keine expliziten Dokumente für den Entwicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abgedeckt x Keine expliziten Dokumente für den Entwicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abgedeckt Bereitstellungs- Verifikationsbericht 8 Installation/Montage 8 SyPI Preparation Instructions Projektierungsrichtlinie Kap. 8 Pkt. B b) 8 SyM Manual Bedienhandbuch Kap. 8 Pkt. B b) 8 SyTI Test Instructions Prüfanweisungen Hw/Sw Kap. 8 Pkt. B b) 8 SyII Installation Instructions Installationsanleitung Kap. 8 Pkt. B b) C.1/40 vom firmenspezifischen Prozess abhängig DEV 4A SM x x x Inhalte sehr firmenspezifisch: enthält Anleitung zur Projektierung der Anlage, z. B. Anzahl Busteilnehmer, Kabelvorgaben, Fahrstraßentabelle, DEV 4A --- x DEV 4A --- x DEV 4A --- x Validierung 9 SyTR System Test Report System-Testbericht C.1/24 TES --- VAL (x) Z SwITR, Z 9 SyVaR System Validation Report System-Validationsbericht Pkt Pkt C.1/25 9 TVaR Tool Validation Report Werkzeuge- Validierungsbericht SwHwITR VAL x x x E TVaR beinhaltet alle Elemente: Software, Hardware, integriertes System und Tools und Betrachtung von Auflagen/Restfehler, In Zukunft gemäß NTZ keine Prüfung durch EBA mehr C.1/26 VAL x x T SyVaR Kann generisch für die firmenspezifische Toolkette erstellt werden. Enthält die Verweise auf die dortige Nachweisführung. 9 SyTSR Technical Safety Report Technischer Sicherheitsbericht Pkt. 5.4 SM x x x T SySC, E SyDDN 9 SySC Safety Case Sicherheitsnachweis Pkt. 5.1 SM x x E SySMR, E SyQMR, E SyTSR, E "CSM-VO Nachweisdokument" 9 SASC Application Safety Case Anwendungssicherheitsnachweis In Zukunft gemäß NTZ keine Prüfung durch EBA mehr In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. Vorbereitung ab Phase 6. ( ) SM x In Deutschland ist eine Verwendung nicht bekannt. Kann ggf. im Ausland erforderlich sein. Vorbereitungen laut alter ab Phase 6. An dieser Stelle wird nur die "Vorbereitung" des Dokumentes erwähnt; weitere Festlegungen fehlen jedoch. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 16 von 18

18 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 10 Abnahme 10 SyAR Assessment Report System-Gutachten Pkt Pkt , C.1/46 (für 10 SySAR Safety Assessment Report Sicherheitsbewertungsbericht 11 Betrieb / Instandhaltung 12 Erfassung der Leistungsfähigkeit 12 SyPR Performance Report Leistungsfähigkeitsbericht Pkt SW-Teil) ASR x --- x E SySAR Hierunter sind auch Gutachten zu verstehen, die sich nur auf Software oder Hardware beziehen Pkt ASR (x) --- x T SyAR Gutachten zum CSM-VO Nachweisdokument gemäß CSM-VO Abschnitt 5.1. Das Gutachten nach CENELEC erfüllt die Vorgaben der CSM VO, soweit dies die technischen Änderungen betrifft. Trotzdem ist es natürlich ratsam, im Gutachten auf die spezifische Struktur des CSM-Prozesses einzugehen. DEV (x) Rücklauf aus den Protokollen spezifischer Anlagen für zukünftige Änderungen. Durch ISO 9001 abgedeckte Verfahren 13 SyMP Maintenance Plan Wartungsplan Anhang -> 9001??? 13 Änderung / Nachrüstung 13 SyRP Release Plan Releaseplan PM x Aufstellung der geplanten Erweiterungen und Verbesserungen. Durch die CENELEC nicht offiziell gefordertes Dokument! Pkt C.1/41 PM --- VAL x x x Generischer Wartungsprozess (allgemeine Vorgehensweise). Für kleinere Hardwareänderungen gibt es bereits vereinfachtes Verfahren (ohne EBA-Vorlage), Idee: ähnliches für SW? Beinhaltet auch die Release-Planung. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. 13 SyMR Modification Report Änderungsbericht Pkt C.1/42 Pkt DEV SM --- x x x Änderungsbericht für jede Wartungsaktivität. Nur für Änderungen, die keine Spezifikationsänderungen beinhalten - sonst nicht zwingend erforderlich. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. 13 SwMR SW Maintenance Record SW- Wartungsaufzeichnungen 13 SwMVR Software Maintenance SW Wartungsverifikationsbericht Verification Report 14 Stilllegung / Entsorgung 9-14 SyDDN Decommissioning and Disposal Notes Tabelle 4: Dokumentenliste Stilllegungs- und Entsorgungshinweise Pkt Pkt C.1/43 Pkt DEV x VER --- VAL x Pkt. B.5.4 PM SM --- x T SyTSR Hinweis: Verifikationsberichte sind hellgrau markiert. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 17 von 18

19 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 5 Zusammenfassung In der AG3 wurden die firmenspezifischen Sichtweisen auf die Dokumentation des CENELEC- Prozesses diskutiert und in eine einheitliche Sichtweise überführt. Dies erfolgte auch unter Berücksichtigung der neuen Software-Norm DIN EN 50128:2012 und der Ergebnisse der AG2 zur CSM-VO (Unter-Arbeitspaket ). Als Ergebnis liegt eine generische Dokumentenliste vor, die für die folgenden Unter- Arbeitspakete , und als Grundlage dient. Version: 1.0, Status: Freigegeben (AG3-intern) Seite 18 von 18

20 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Ergebnisbericht AP2200 Dokumentationsumfang bei der Zulassung gemäß CENELEC Unterarbeitspaket : Beispielhafte Dokumentenlisten ('Best Practice') Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

21 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Änderungsverfolgung Datum Bearbeiter Version Inhalt Mathias Wagner (Bombardier) 0.1 Erster Entwurf Mathias Wagner (Bombardier) 0.2 Update nach internem AG3-Review Mathias Wagner (Bombardier) 0.3 Update nach internem AG3-Review Mathias Wagner (Bombardier) 0.4 Update des Kapitels 4 Skalierbarkeit nach internem AG3-Review Mathias Wagner (Bombardier) 0.5 Update nach internem AG3-Review Beck (DB AG) 0.6 Erweiterung um SIL 0 und SIL 2 Czepa (Thales) Griebel (Siemens) Möller-Neustock (Funkwerk AG, TCC) Pietz (Pintsch Bamag) Dr. Priebe (S&B) Schwencke (DLR) Wagner (Bombardier) Beck (DB AG) Czepa (Thales) Griebel (Siemens) Möller-Neustock (Funkwerk AG, TCC) Pietz (Pintsch Bamag) Dr. Priebe (S&B) Schwencke (DLR) Wagner (Bombardier) 1.0 Veröffentlicht nach finalem AG3-Review Version: 1.0, Status: Veröffentlicht Seite 2 von 21

22 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Inhaltsverzeichnis 1 Einleitung Definitionen Spaltentitel Abkürzungen Vorgaben Skalierbarkeit Safety Integrity Levels SIL SIL SIL Dokumentenliste Zusammenfassung und Ausblick...21 Version: 1.0, Status: Veröffentlicht Seite 3 von 21

23 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 1 Einleitung Die CENELEC-Normen EN 50126, EN und EN beschreiben die Entwicklung von Bahnanwendungen. Sie lassen dem Anwender einen großen Interpretations- und Handlungsspielraum. So kann er auch relativ frei entscheiden, welche Maßnahmen er zur Entwicklung eines sicheren Systems anwenden möchte. Umfassende Tabellen in den Anhängen der Normen EN und EN geben eine Auswahl von Maßnahmen, die anzuwenden sind. Oftmals soll der Anwender eine geeignete Kombination von Maßnahmen auswählen, wobei nur eingeschränkt spezifiziert ist, unter welchen Umständen eine Auswahl geeignet ist. Ziel der AG ist eine Abstimmung zwischen allen Projektpartnern über eine einheitliche CENELECkonforme Dokumentenliste bei der Einreichung zur Zulassung von Projektvorhaben. Auf Basis dieser einheitlichen Liste sollen Best Practice-Beispiele erarbeitet und Interpretationsspielräume der Normen identifiziert und reduziert werden. Zur Erfüllung dieses Arbeitspaketes 2200 wurde die Aufgabenbeschreibung in die folgenden Unterarbeitspakete strukturiert: 0. Erstellung einer abgestimmten generische CENELEC-Dokumentenliste 1. Erstellung von beispielhaften Dokumentenlisten ('Best Practice') für spezifische Anwendungsfälle a) für SIL 4 b) für SIL 2 c) für SIL 0/no-SIL 2. Dokumentenliste und der Maßnahmenkatalog ('Best Practice') werden als Anhang zum Sektorhandbuch Infrastruktur aufbereitet. 3. Enge Abstimmung mit der AG2 (CSM-VO) 4. Nach der Abstimmung mit dem Betreiber soll die seit vorliegende pren in die Dokumentenliste eingearbeitet werden Das Unterarbeitspaket wurde ausgesetzt, da die NeGSt-Arbeitsgruppe 4 die Bearbeitung des Sektorhandbuches Infrastruktur im Mai 2013 vorerst ausgesetzt hat. Das Unterarbeitspaket wurde bereits im Teilbericht Vorarbeiten und Unterarbeitspaket (NeGSt_Teilbericht_2200.0u3_1.0.pdf) abschließend bearbeitet. Das Unterarbeitspaket wurde ausgesetzt, da es im Mai 2013 mit dem vorliegenden Zwischenstand der pren nicht zielführend scheint, die Dokumentenliste daraufhin anzupassen. Als Ersatz für die Unterarbeitspakete und wurde das optionale Unterarbeitspaket Teil b Einarbeitung von SIL 2 in die Best Practices und Teil c Einarbeitung von SIL 0 in die Best Practices in die Liste der Unterarbeitspakete aufgenommen. Das vorliegende Dokument zeigt die Ergebnisse des Unterarbeitspaketes Teil a bis Teil c Erstellung von beispielhaften Dokumentenlisten ('Best Practice') für vier spezifische Anwendungsfälle für SIL 4 und SIL 2 und SIL 0. Version: 1.0, Status: Veröffentlicht Seite 4 von 21

24 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 2 Definitionen 2.1 Spaltentitel Folgende Spaltentitel werden in Tabelle 4 verwendet. Spalte im Arbeitsblatt "Dokumente" CENELEC-Phase Ersterstellung Dokumentenkürzel Erläuterung Phase des CENELEC-Prozesses nach EN 50126, in der das Dokument angelegt wird Kürzel für den (englischen) Dokumentennamen Dokumentenname vollständiger Name des Dokuments gemäß aktuellster CENELEC-Norm Kommentar Best Practice x: Anwendungsfall Erläuterung BP x Tabelle 1: Erklärung der Spaltentitel Gibt es Besonderheiten zum Dokument, die neben den vordefinierten Spalten wichtig zum Verständnis des Dokuments sind? Definition, ob das Dokument für den jeweilige Anwendungsfall + erzeugt/überarbeitet - nicht erzeugt/nicht überarbeitet +/- eventuell, wird standardmäßig erzeugt/überarbeitet -/+ eventuell, wird standardmäßig nicht erzeugt/nicht überarbeitet werden soll Erläuterungen zu dem jeweiligen Dokument für diesen Anwendungsfall Mögliche Einträge Zahl zwischen 1 und 14, ggf. auch mehrere mögliche Phasen <Kürzel>, i.d.r. beginnend mit "Pr...", "Sy ", "Sw " oder "Hw..." für Projekt-, System-, Software- und Hardware- Dokumente <Name> <freier Text> +, -, +/-, -/+ Version: 1.0, Status: Veröffentlicht Seite 5 von 21

25 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 2.2 Abkürzungen Folgende Abkürzungen werden in diesem Dokument verwendet. Abkürzung Beschreibung AG Arbeitsgruppe AN Auftragnehmer AP Arbeitspaket BP Best Practice CENELEC Europäisches Komitee für elektrotechnische Normung CSM-VO Verordnung (EG) Nr. 352/2009 über die Festlegung einer gemeinsamen Sicherheitsmethode für die Evaluierung und Bewertung von Risiken DIN Deutsche Industrienorm EASA Europäische Agentur für Flugsicherheit EBA Eisenbahn-Bundesamt EN Europäische Norm FMEA Ausfalleffektanalyse HW Hardware ISO Internationale Organisation für Normung NeGSt Neue Generation Signaltechnik NTZ Neue Typzulassung pren Vorläufige europäische Norm PT1 Planteil 1 PT2 Planteil 2 QS Qualitätssicherung RAMS Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit, Sicherheit (im englischen: Reliability, Availability, Maintainability, Safety) Sb 3 Sachbereich 3 (des Eisenbahn-Bundesamtes) SIL Sicherheitsanforderungsstufe SW Software THR Tolerierbare Gefährdungsraten Tabelle 2: Verwendete Abkürzungen Version: 1.0, Status: Veröffentlicht Seite 6 von 21

26 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 3 Vorgaben Auf Basis der Dokumentenliste aus dem Teilbericht Vorarbeiten und Unterarbeitspaket (NeGSt_Teilbericht_2200.0u3_1.0.pdf) wurden Ausprägungen für die folgenden spezifischen Anwendungsfälle erstellt (siehe Kapitel 6): Best Practice 1: SW-Fehlerbehebung Best Practice 2: Systemerweiterung Best Practice 3: Weiterentwicklung einer HW-Steckkarte (als HW-Komponente) Best Practice 4: Neue spezifische Applikation Die spezifischen Anwendungsfälle sind dabei wie folgt definiert: Best Practice Beispiel Best Practice 1: SW-Fehlerbehebung Best Practice 2: Systemerweiterung Best Practice 3: Weiterentwicklung einer HW-Steckkarte (als HW-Kompon.) Best Practice 4: Neue spezifische Applikation Definition Der Anwendungsfall SW-Fehlerbehebung setzt voraus, dass ein Release bereits zugelassen ist. Es wird angenommen, dass die SyCIA ergeben hat, dass in Phase 4 bis inkl. 6.1 keine Änderungen vorzunehmen sind. Pläne (Sicherheits-, Qualitäts-, Verifikations-, Validationplan) sollten grundsätzlich so gestaltet sein, dass sie bei einer SW-Fehlerbehebung nicht geändert werden müssen. Der Anwendungsfall Systemerweiterung setzt voraus, dass ein Release bereits zugelassen ist. Es wird angenommen, dass Änderungen an Hardund Software nötig sind. Die Frage der Kompatibilität zu bestehenden Systemen ist in der SyCIA zu klären. Ggf. müssen Anforderungen zur Kompatibilität aufgenommen werden. Es wird nicht davon ausgegangen, dass alle im Betrieb befindlichen Systeme rückwirkend aktualisiert werden müssen. Der Anwendungsfall HW-Weiterentwicklung setzt voraus, dass ein Release bereits zugelassen ist. Es wird eine kompatible Änderung einer Komponente durchgeführt. Kompatible Änderung bedeutet, dass die Schnittstellen und RAMS- Anforderungen gleich bleiben und somit keine Softwareänderungen nötig sind. Die Änderung ist nötig aufgrund einer Bauteilabkündigung oder - optimierung, nicht aufgrund von entdeckten Fehlern. Der Anwendungsfall Neue spezifische Applikation setzt eine gleichbleibende generische Applikation/ein gleichbleibendes generisches Produkt voraus. Best Practice 4 trifft ebenso auf Änderungen an spezifischen Applikationen zu. Tabelle 3: Definitionen der spezifischen Anwendungsfälle Version: 1.0, Status: Veröffentlicht Seite 7 von 21

27 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Die im Kapitel 6 dargestellte Dokumentenliste basiert auf den folgenden Versionen der CENELEC- Normen: DIN EN 50126:2000 DIN EN 50128:2001 DIN EN 50128:2012 DIN EN 50129:2003 Version: 1.0, Status: Veröffentlicht Seite 8 von 21

28 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 4 Skalierbarkeit Das zu betrachtende System kann aus einer mehr oder weniger komplexen Struktur von System/Subsystemen/HW-Komponenten/SW-Komponenten bestehen (HW- und SW-Komponenten als kleinster autarker Bestandteil der Hard- und Software, der in Bezug auf Architektur und Entwurf über klar definierte Schnittstellen verfügt). Dies trifft in unterschiedlicher Ausprägung und Komplexität für die Kategorien Generisches Produkt, Generische Applikation und Spezifische Applikation zu, welche wiederum aufeinander aufbauen. Für jede Ebene in einer solchen Struktur kann die generische CENELEC-Dokumentenliste aus dem Teilbericht Vorarbeiten und Unterarbeitspaket (NeGSt_Teilbericht_2200.0u3_1.0.pdf) grundsätzlich angewendet werden. Pro Ebene ist dabei eine Teilmenge der Dokumente der generischen Dokumentenliste zu erstellen. Beispielsweise sind am Anfang des Entwicklungsprozesses auf System-Level wahrscheinlich alle Dokumente der Phasen 1-5 zu erstellen. Für die untergeordneten Subsysteme werden dann jeweils die Dokumente der Phasen 4 und 5 erneut und die Dokumente für die folgenden Phasen erstmals erstellt. Ähnlich für die späteren Phasen im V-Modell: Die Dokumente für z.b. Integration, Test, Validation und Assessment werden jeweils für die Subsysteme und erneut für den Systemlevel erstellt. Die Dokumente für die folgenden Phasen wie Abnahme und Betrieb und Instandhaltung werden nur für den Systemlevel erstellt. Es ist essentiell, dass diese Strukturen pro zu betrachtendem System im Detail analysiert, geplant und dokumentiert werden. Die im Kapitel 6 dargestellten spezifischen Anwendungsfälle stellen ausgewählte Beispiele für eine solche Analyse dar. Version: 1.0, Status: Veröffentlicht Seite 9 von 21

29 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 5 Safety Integrity Levels 5.1 SIL 4 Der hier vorliegenden Dokumentenliste (siehe Tabelle 4) wurde der Safety Integrity Level (SIL) 4 zugrunde gelegt. 5.2 SIL 2 Die Betrachtung des Safety Integrity Levels 2 zeigte, dass sich bezüglich der Anzahl und der Titel der Dokumente gegenüber einer SIL 4 Entwicklung keine Änderungen ergeben, siehe DIN EN Tabelle A.1. Unterschiede zwischen SIL 4 und SIL 2 Entwicklungen ergeben sich durch die verschiedenen Techniken und Maßnahmen, wie z. B. in der DIN EN Anhang E dargestellt. Daraus ergibt sich ein unterschiedlicher Umfang des Inhalts der Dokumente wie in den CENELEC-Normen ausführlich dargestellt. 5.3 SIL 0 Den CENELEC-Normen konnte kein konkretes Beispiel entnommen werden, was ein repräsentatives SIL 0-Produkt sein könnte. Keines der beteiligten Unternehmen hat bisher ein Projekt nach SIL 0 aufgesetzt: 1. Offensichtlich nicht sicherheitsrelevante Entwicklungsgegenstände wie z.b. Fahrgastinformationssysteme oder Infotainment-Applikationen werden nicht nach CENELEC entwickelt. Dies erfolgt unter Berücksichtigung der Regeln in DIN EN 50129, die zur Thematik die folgenden wesentlichen Aussagen enthält:» Die Anwendung dieses Sicherheitsmanagementprozesses ist verbindlich für die Sicherheitsanforderungsstufen 1 bis 4 (siehe Anhang A zur Erläuterung der Sicherheitsanforderungsstufen). Jedoch sollten die Tiefe der Darlegungen und der Umfang der begleitenden Dokumentation der Sicherheitsanforderungsstufe des/der betrachteten Systems/Teilsystems/Einrichtung angemessen sein. Die Anforderungen für die Sicherheitsanforderungsstufe 0 (nicht sicherheitsrelevant) liegen außerhalb des Anwendungsbereiches dieser Sicherheitsnorm. In allen Fällen sind Gefährdungsanalyse und Risikobewertungsprozesse, wie in EN definiert, notwendig, um den benötigten Grad an Sicherheitsintegrität jeder einzelnen Situation zu identifizieren. Dies schließt jene Fälle mit ein, wo die Analyse und Bewertung offenbaren, dass die Sicherheitsanforderungsstufe 0 zugeordnet werden darf. Wenn man zu dieser Schlussfolgerung gelangt ist (d. h., die Situation ist nicht sicherheitsrelevant) und feststeht, dass die Stufe 0 bestehen bleibt, dann endet die Anwendbarkeit dieser Sicherheitsnorm. «2. Sicherheitsrelevante Systeme, für die quantitative Risikoanalysen (Risikobewertungen) durchgeführt wurden und für die somit THR ermittelt wurden, sind bisher immer in höheren SI-Level angesiedelt. Die Qualitätssicherung für jeglichen Entwicklungsprozess ist durch die ISO 9000 ff. Normen gegeben, hierfür bedarf es keiner Einhaltung eines besonderen SIL 0-Prozesses. Dies wäre zudem eine unzulässige Vermischung von Qualitätssicherung und Einhaltung eines Safety Integrity Levels. Darüber hinaus erscheint es weder notwendig noch sinnvoll, für die Entwicklung derartiger Systeme Anforderungen festzulegen, die über gängige Industriestandards und -normen hinausgehen. Zum Vergleich mit der Praxis in anderen Industriezweigen kann hier auf die Luftfahrt verwiesen werden. In dem von der EASA herausgegebenen Standard CS-25 1 ), der für die Zertifizierung großer 1 EASA (European Aviation Safety Agency): Certification Specifications for Large Aeroplanes, Amendment 9 vom Version: 1.0, Status: Veröffentlicht Seite 10 von 21

30 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC Passagierflugzeuge Regelungen bezüglich Sicherheitsanforderungen und deren Nachweis enthält, findet sich bereits für die niedrigste von 4 Sicherheitsanforderungsstufen folgende Aussage:» A numerical probability range is provided here as a reference. The applicant is not required to perform a quantitative analysis, nor substantiate by such an analysis, that this numerical criteria has been met for Minor Failure Conditions. Current transport category aeroplane products are regarded as meeting this standard simply by using current commonly-accepted industry practice. «Aus den genannten Gründen hat die AG beschlossen, dass es (zumindest zurzeit) keinen Sinn ergibt, eine Ergänzung der Dokumentenliste für SIL 0 durchzuführen bzw. Best Practices zu beschreiben. Version: 1.0, Status: Veröffentlicht Seite 11 von 21

31 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 6 Dokumentenliste Die folgende Dokumentenliste listet die Dokumente der generischen CENELEC-Dokumentenliste aus dem Teilbericht Vorarbeiten und Unterarbeitspaket (NeGSt_Teilbericht_2200.0u3_1.0.pdf). Für die vier Anwendungsfälle wurden die Spalten Best Practice 1 4 mit jeweils einer zusätzlichen Erläuterungsspalte eingefügt. In diesen wird angegeben, ob das Dokument für den jeweiligen Anwendungsfall erzeugt/überarbeitet werden soll (siehe auch Tabelle 1: Erklärung der Spaltentitel). CENELEC-Phase Ersterstellung Dokumentenkürzel Dokumentenname 1/2 Konzept und Systemdefinition SyCR Kundenanforderung optionales Dokument; wird u.u. bis inkl. Phase 4 weiter verfeinert Kommentar Best Practice 1: SW- Fehlerbehebung Erläuterungen BP1 Best Practice 2: Systemerweiterung Erläuterungen BP2 - +/- Falls sich Anforderungen des Kunden ändern. 1-2 SyDef Systemdefinition - +/- Falls sich Anforderungen des Kunden ändern. 1-2 SyCIA Änderungsauswirkungsanalyse Dokument ist nicht von CENELEC gefordert, wird aber als sinnvoll erachtet. Es ist nur bei Änderungen zu erstellen. Ziel ist zu entscheiden, welche Teile des Prozesses betroffen sind und welche Dokumente und Systembestandteile geändert werden müssen 1 SyDP Entwicklungsplan Herstellerspezifisches Projektkonzept; klärt u.a. den Zusammenhang Zulassungsstrategie - Systemarchitektur - Entwicklungsmodelle (V-Modell) 1 PrTL Projekt-Zeitplan Der Zeitplan sollte für generische Produkte, generische Applikationen und spezifische Applikationen erstellt werden. 1 PrDL Dokument-Übersicht Die Dokumentenübersicht sollte für generische Produkte, generische Applikationen und spezifische Applikationen erstellt werden. + Wenn nicht alle System- und Modultest wiederholt durchgeführt werden sollen, muss dies hier analysiert und begründet werden + Die Frage der Kompatibilität zu bestehenden Systemen ist in der SyCIA zu klären. Ggf. müssen Anforderungen zur Kompatibilität aufgenommen werden. BP 3: Weiterentwicklung einer HW-Steckkarte Erläuterungen BP3 Best Practice 4: neue spezifische Applikation Hier ist festzustellen, dass der Umfang der Änderung nur eine Hardwarekomponente (die Steckkarte) betrifft. Die Frage der Kompatibilität zu bestehenden Systemen ist in der SyCIA zu klären Zeit- und Ressourcenplanung für das Fehlerbehebungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden + Zeit- und Ressourcenplanung für das Änderungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden + Zeit- und Ressourcenplanung für das Änderungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden PrG Glossar Erläuterungen BP4 + Zeit- und Ressourcenplanung für das Projekt/Änderungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden 1-2 SySP Sicherheitsplan Z SySMR wird als sinnvoll erachtet (da dort die Prüfungsergebnisse zum SySP stehen) Version: 1.0, Status: Veröffentlicht Seite 12 von 21

32 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 2-10 SySMR Sicherheitsmanagementbericht Z SySP wird als sinnvoll erachtet (als zu überprüfendes Dokument), 4-Augen- Prinzip im Falle eines externen Gutachters 1-2 SyQMP Qualitätssicherungsplan muss nach aktueller Praxis dem Gutachter vorgelegt werden 2-10 SyQMR Qualitätsmanagementbericht Z SyQP wird als sinnvoll erachtet (als zu überprüfendes Dokument); enthält Ergebnisse zur Anforderungsverfolgbarkeit - kann eigenständiges Dokument (Anf.verfolgbarkeitsmatrix) oder Teil des Berichtes sein, s. diverse Stellen in der DIN EN 50128: Augen-Prinzip im Falle eines externen Gutachters 2 SyPVR Planungsverifikationsbericht Verifiziert alle Pläne außer dem Validierungsplan. Heißt lt. DIN EN 50128:2012 (Software-) Qualitätssicherungsverifikationsbericht 1-2 SyCMP Konfigurationsmanagementplan 1-2 SyVeP Verifikationsplan Enthält den Software-Verifikationsplan. Die Aufgaben sind in der definiert, nicht das Dokument. Im aktuellen Entwurfsstand der neuen werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genauere Angaben zu geforderten Dokumenten macht 1-2 SyVaP Validierungsplan Die Aufgaben sind in der definiert, nicht das Dokument. Im aktuellen Entwurfsstand der neuen werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genauere Angaben zu geforderten Dokumenten macht + Ergänzung + Ergänzung + Ergänzung Ergänzung + Ergänzung + Ergänzung - + Ergänzung des alten Berichts oder komplett neuer Bericht + Ergänzung des alten Berichts oder komplett neuer Bericht + Ergänzung des alten Berichts oder komplett neuer Bericht SyTP System-Testplan - +/- Hängt von Art und Umfang der Änderung ab. 1-2 SyAP Begutachtungsplan auch als "Prüfhandbuch" bezeichnet; in der Regel fordert das EBA die Vorlage des SyAP; ist bislang nur für SW verpflichtend. Definiert die Kriterien, Arbeitsweise und den Arbeitsumfang der Prüfleitstelle/des Gutachters 3 Risikoanalyse 3 SyHA Gefährdungs- und Risikoanalyse In Zukunft gemäß NTZ keine Prüfung durch EBA mehr? Unklar, ob die Revision der (neue 50126) weiterhin Prüfung durch Aufsichtsbehörde fordert Version: 1.0, Status: Veröffentlicht Seite 13 von 21

33 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 3 SyHL Gefahrenprotokoll gängiger Begriff ist "Gefährdungslogbuch". 4A-Prüfung im Falle eines externen Gutachters 4 Systemanforderungen 4 SyRS System- Anforderungsspezifikation 4 SySRS System- Sicherheitsanforderungsspezifikation Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN. Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN. Sicherheitskonzept gemäß Mü 8004 kann in diesem Dokument aufgehen. Prüfungen finden statt bei Ersteller AN 4 SyTS System-Testspezifikation enthält neben der Abdeckung der Systemanforderungen auch noch zusätzliche Test zur Gesamtsystemfunktionalität 4 SyRVR System- Anforderungsverifikationsbericht 5 Systementwurf 5 SyAS System- Architekturspezifikation Falls obige Dokumente im Rahmen der Entwicklung (von AN) erstellt werden, müssen sie auch verifiziert werden; wenn SwRS und HwRS mit SyRS zusammengelegt, dann auch SwRVR und HwRVR mit SyRVR in diesem Dokument können ggf. Subsysteme definiert werden, die entweder in den SW-/HW-Architekturdokumenten beschrieben werden (6.1.2/6.2.2) oder für die wiederum die System-Dokumente angefertigt werden (neuer Prozess) + Fehler muss ergänzt werden, sofern dadurch eine neue Gefährdung verursacht wird + - Da sich aufgrund der Definition des BP keine Änderung aufgrund von Fehlern durchgeführt wird Test-Subset wird ggf. in Änderungsauswirkungsanalyse ausgewählt /- Bei Änderungen von Schnittstellen (innerhalb des Systems und nach außen) SyDS System-Entwurfsspezifikation SyADVR System-Architektur- und Entwurfsverifikationsbericht SwHwITP SW/HW-Integrationstestplan Entwicklung/Konstruktion und Implementierung 6.1 Hardware HW-Anforderungen 6 HwRS HW-Anforderungsspezifikation HW-Entwurf 6 HwDS HW-Entwurfsspezifikation kann entfallen, wenn nur eine Komponente im System vorhanden 6 HwAS HW-Architekturspezifikation kann entfallen, wenn nur eine Komponente im System vorhanden 6 HwIS HW-Schnittstellenspezifikation kann entfallen, wenn nur eine Komponente im System vorhanden Version: 1.0, Status: Veröffentlicht Seite 14 von 21

34 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC HW-Komponentenentwurf 6 HwCDS HW- Komponentenentwurfsspezifikation HwCFMEA HW-Komponenten-FMEA HwCRC HW-Komponenten- Zuverlässigkeitsberechnungen HW-Fertigungsunterlagen 6 HwPD HW-Fertigungsunterlagen Layout, Stücklisten, Grundschaltungen, etc HW-Komponententest 6 HwCTS HW- Komponententestspezifikation HwCTR HW-Komponententestbericht HW Verifikationsbericht 6 HwVR HW-Verifikationsbericht Verifikationsbericht fasst alle Verifikationsschritte für die HW zusammen Software SW-Anforderungen 6 SwRS SW-Anforderungsspezifikation +/- Änderung nur, falls Fehler die SW- Anforderungen betrifft 6 SwOTS SW-Gesamttestspezifikation früher (50128:2003): SW- Anforderungstestspezifikation 6 SwRVR SW- Anforderungsverifikationsbericht +/- Änderung nur, falls Fehler die SW- Anforderungen betrifft +/- Änderung nur, falls Fehler die SW- Anforderungen betrifft SW-Entwurf 6 SwAS SW-Architekturspezifikation s. Kommentar SyAS - +/- Bei Änderungen von Schnittstellen (innerhalb des Systems und 6 SwDS SW-Entwurfsspezifikation s. Kommentar SyDS +/- Änderung nur, falls Fehler den SW-Entwurf betrifft 6 SwIS SW-Schnittstellenspezifikation s. Kommentar SyAS/SyDS +/- Änderung nur, falls Fehler die SW- Schnittstellen betrifft - - nach außen) Version: 1.0, Status: Veröffentlicht Seite 15 von 21

35 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 6 SwADVR SW-Architektur- und Entwurfsverifikationsbericht +/- s. Kommentare SwDS und SwIS SwITP SW-Integrationstestplan SW-Komponentenentwurf 6 SwCDS SW- Komponentenentwurfsspezifikation Früher (50128:2003) "Modul" statt "Komponente" +/- Änderung nur, falls Fehler die SwCDS betrifft SwCDVR SW- Komponentenentwurfsverifikationsbericht Früher (50128:2003) "Modul" statt "Komponente" +/- s. Kommentar SwCDS SW-Implementierung 6 SwSC SW-Quellcode und Hilfsdokumentation 6 SwSCVR SW- Quellcodeverifikationsbericht SW-Komponententest 6 SwCTS SW- Komponententestspezifikation Früher "Zusatzdokumentation" statt "Hilfsdokumentation"; zweite Prüfung gemäß DIN EN 50128:2012 Tabelle C.1 wird nicht immer als sinnvoll erachtet Norm alt: Modul --> Norm neu: Komponente SwCTR SW-Komponententestbericht Der zugehörige Verifikationsbericht ist der SwCDVR 6.3 Integration 6 SwITS SW- Integrationstestspezifikation 6 SwHwITS SW/HW- Integrationstestspezifikation /- Änderung nur, falls Fehler die SW- Schnittstellen betrifft +/- Änderung nur, falls Fehler die SW/HW- Schnittstellen betrifft 6 SwITR SW-Integrationstestbericht +/- Je nach Ergebnis der Änderungsauswirkungsanalyse 6 SwHwITR SW/HW- Integrationstestbericht +/- Je nach Ergebnis der Änderungsauswirkungsanalyse + Prüfung existierender Komponenten nur falls die SyCIA die Notwendigkeit ergibt. + Prüfung existierender Komponenten nur falls die SyCIA die Notwendigkeit ergibt. + Prüfung existierender Komponenten nur falls die SyCIA die Notwendigkeit ergibt. + Prüfung existierender Komponenten nur falls die SyCIA die Notwendigkeit ergibt Version: 1.0, Status: Veröffentlicht Seite 16 von 21

36 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 6 SyAPP Anwendungs- Generierungsplan Dieser generische Plan beschreibt die Umsetzung in der spezifischen Anwendung (siehe DIN EN 50128:2012, Pkt ). Er entfällt lt. EBA-Tabellen bei generischer Software (nur bei anwend.- spezifisch konfigurierten Systemen); EBA-Vorlage zur Bauaufsichtl. Freigabe/Abnahme Sb SyIVR Integrationsverifikationsbericht +/- Änderung nur, falls Fehler Dokumente in der Integrationsphase betrifft 7 Fertigung 7 SyARS Anwendungs- Anforderungsspezifikation entspricht der geprüften PT1 und PT2 7 SyATS Anwendungs-Testspezifikation SyAAD Anwendungsarchitektur und - entwurf In diesem Dokument geht es um das Kombinieren/Konfigurieren der generischen Anwendung zum Erhalt der spezifischen Anwendung (Modulwahl) /+ entspricht im Normalfall der geprüften PT2; nur im Fall besonderer Kombinationen explizit zu erstellen. 7 SySCADA Quellcode der Anwendungsdaten-/Algorithmen 7 SyAPVR Anwendungs- Generierungsverifikationsbericht Z. B. Konfigurationsdateien. Zweite Prüfung wird durch PT2-Prüfung abgedeckt. Mit "Prüfung durch EBA" ist hier das örtliche EBA gemeint. 7 SyATR Anwendungs-Testbericht entfällt lt. EBA-Tabellen bei generischer Software (nur bei anwend.-spezifisch konfigurierten Systemen); EBA-Vorlage zur Bauaufsichtl. Freigabe/Abnahme Sb 3 7 SyRDP Freigabe- und Bereitstellungsplan 7 SyADAVR Anwendungsdaten- /Algorithmen- Verifikationsbericht Kein explizites Dokument für den Entwicklungsprozess, wenn z.b. über QSbzw. ISO 9001 abgedeckt 7 SyDM Bereitstellungshandbuch Kein explizites Dokument für den Entwicklungsprozess, wenn z.b. über QSbzw. ISO 9001 abgedeckt 7 SyRNs Freigabemitteilungen Kein explizites Dokument für den Entwicklungsprozess, wenn z.b. über QSbzw. ISO 9001 abgedeckt 7 SyRN Freigabemitteilung Zusammenfassung der ausführlichen Freigabemitteilungen (Release Notes) Je nach Ergebnis der Auswirkungsanalyse sind für zu aktualisierende Anlagen die relevanten Teile der SyATS Regressionstests durchzuführen. Für neue Anlagen sind alle Teile der SyATS zu testen Version: 1.0, Status: Veröffentlicht Seite 17 von 21

37 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 7 SyDR Bereitstellungsaufzeichnungen 7 SyDVR Bereitstellungs- Verifikationsbericht Kein explizites Dokument für den Entwicklungsprozess, wenn z.b. über QSbzw. ISO 9001 abgedeckt Kein explizites Dokument für den Entwicklungsprozess, wenn z.b. über QSbzw. ISO 9001 abgedeckt 8 Installation/Montage 8 SyPI Projektierungsrichtlinie Inhalte sehr firmenspezifisch: enthält Anleitung zur Projektierung der Anlage, z. B. Anzahl Busteilnehmer, Kabelvorgaben, Fahrstraßentabelle, Ergänzung. Enthält auch die Kompatibilitätsliste (vgl. SyCIA) SyM Bedienhandbuch SyTI Prüfanweisungen Hw/Sw - + Ergänzung + mindestens Ergänzung eines Verweises auf die neue Steckkarte 8 SyII Installationsanleitung - + Ergänzung + mindestens Ergänzung eines Verweises auf die neue Steckkarte 9 Validierung 9 SyTR System-Testbericht + Je nach Ergebnis der Auswirkungsanalyse sind für zu aktualisierende Systembestandteile die relevanten Teile der SyTS Regressionstests durchzuführen. 9 SyVaR System-Validationsbericht beinhaltet alle Elemente: Software, Hardware, integriertes System und Tools und Betrachtung von Auflagen/Restfehler, In Zukunft gemäß NTZ keine Prüfung durch EBA mehr 9 TVaR Werkzeuge- Validierungsbericht Kann generisch für die firmenspezifische Toolkette erstellt werden. Enthält die Verweise auf die dortige Nachweisführung. + Je nach Ergebnis der Auswirkungsanalyse sind für zu aktualisierende Systembestandteile die relevanten Teile der SyTS Regressionstests durchzuführen. + Je nach Ergebnis der Auswirkungsanalyse sind für zu aktualisierende Systembestandteile die relevanten Teile der SyTS Regressionstests durchzuführen SyTSR Technischer Sicherheitsbericht In Zukunft gemäß NTZ keine Prüfung durch EBA mehr 9 SyRAMSD RAMS-Nachweis Manteldokument mit Referenzen auf alle RAMS-Dokumente + Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein. + Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein. + + mindestens Ergänzung eines Verweises auf die neue Steckkarte + + Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein. - - Version: 1.0, Status: Veröffentlicht Seite 18 von 21

38 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 9 SySC Sicherheitsnachweis In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. Vorbereitung ab Phase 6. + Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein. + + Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein. - 9 SASC Anwendungssicherheitsnachweis SASC=Specific Application Safety Case. In Deutschland ist eine Verwendung nicht bekannt. Kann ggf. im Ausland erforderlich sein. Vorbereitungen laut alter ab Phase 6. An dieser Stelle wird nur die "Vorbereitung" des Dokumentes erwähnt; weitere Festlegungen fehlen jedoch. 10 Abnahme 10 SyAR System-Gutachten Hierunter sind auch Gutachten zu verstehen, die sich nur auf Software oder Hardware beziehen 10 SySAR Sicherheitsbewertungsbericht Gutachten zum CSM-VO Nachweisdokument gemäß CSM-VO Abschnitt 5.1. Das Gutachten nach CENELEC erfüllt die Vorgaben der CSM VO, soweit dies die technischen Änderungen betrifft. Trotzdem ist es natürlich ratsam, im Gutachten auf die spezifische Struktur des CSM-Prozesses einzugehen. - Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein. - - Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein Für die spezifische Applikation kein Gutachten im CENELEC-Sinne, sondern Abnahmeniederschrift /+ 11 Betrieb / Instandhaltung 12 Erfassung der Leistungsfähigkeit 12 SyPR Leistungsfähigkeitsbericht Rücklauf aus den Protokollen spezifischer Anlagen für zukünftige Änderungen. Durch ISO 9001 abgedeckte Verfahren 13 Änderung / Nachrüstung 13 SyRP Releaseplan Aufstellung der geplanten Erweiterungen und Verbesserungen. Durch die CENELEC nicht offiziell gefordertes Dokument! 13 SyMP Wartungsplan Generischer Wartungsprozess (allgemeine Vorgehensweise). Für kleinere Hardwareänderungen gibt es bereits vereinfachtes Verfahren (ohne EBA-Vorlage), Idee: ähnliches für SW? Beinhaltet auch die Release-Planung. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. - +/- Abhängig von der Art der Erweiterung - -/+ je nach Firmenprozess nur Start eines SyPR mit Installation der ersten spezifischen Applikation mindestens Ergänzung eines Verweises auf die neue Steckkarte - Version: 1.0, Status: Veröffentlicht Seite 19 von 21

39 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 13 SyMR Änderungsbericht Änderungsbericht für jede Wartungsaktivität. Nur für Änderungen, die keine Spezifikationsänderungen beinhalten - sonst nicht zwingend erforderlich. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. + Beinhaltet eine Auflistung aller geänderten Dokumente und Systembestandteile/Artefakte SwMR SW-Wartungsaufzeichnungen SwMVR SW Wartungsverifikationsbericht Stilllegung / Entsorgung 9-14 SyDDN Stilllegungs- und Entsorgungshinweise Tabelle 4: Dokumentenliste für die vier in Tabelle 3 definierten Anwendungsfälle - - +/- Je nachdem, ob neue Bauteile dies erfordern - Hinweis: Verifikationsberichte sind hellgrau markiert. Version: 1.0, Status: Veröffentlicht Seite 20 von 21

40 AP Dokumentationsumfang bei der Zulassung gemäß CENELEC 7 Zusammenfassung und Ausblick Es wurde von den am Arbeitspaket 2200 beteiligten Projektpartnern Bombardier, DB Netze, DLR, Funkwerk AG TCC, Pintsch Bamag, Scheidt & Bachmann, Siemens und Thales ein gemeinsames Verständnis entwickelt, wie die CENELEC-Normen EN 50126, EN und EN Anwendung finden sollen. Dieses gemeinsame Verständnis ist in die in diesem Ergebnisbericht beschriebenen Arbeitsergebnisse in Form von CENELEC-konformen Dokumentenlisten eingegangen. Damit wurde aus Sicht der beteiligten Projektpartner eine signifikante Verringerung der Interpretationsspielräume der CENELEC-Normen erreicht. Auf Basis der generischen Dokumentenliste aus dem Teilbericht Vorarbeiten und Unterarbeitspaket (NeGSt_Teilbericht_2200.0u3_1.0.pdf) wurden Ausprägungen von Dokumentenlisten für die spezifischen Anwendungsfälle SW-Fehlerbehebung, Systemerweiterung, Weiterentwicklung einer HW-Steckkarte (als HW-Komponente) und Neue spezifische Applikation für SIL 4 erstellt. Mit dem Erstellen der Ausprägungen von Dokumentenlisten für die Best Practices wurde gleichzeitig die generische Dokumentenliste auf ihre Anwendbarkeit für verschiedene praktische Anwendungsfälle hin positiv verifiziert. Außerdem wurde gezeigt, dass die Ergebnisse für SIL 4-Entwicklungen auch für SIL 2- Entwicklungen angewendet werden können. Die hier vorliegenden Ergebnisse stehen als Leitfaden für alle beteiligten Partnerfirmen zur Verfügung und sollten aus Sicht der AG3 breite Anwendung in zukünftigen Projekten finden. Version: 1.0, Status: Veröffentlicht Seite 21 von 21

41 Schlussbericht Anhang zu AP 2000 Optimierung des Zulassungsprozesses Anhang 2.4: Teilberichte der Arbeitsgruppe 5 Umgang mit Komponenten nach IEC (COTS) / Hybriden 1. Vergleich der Zulassungsbedingungen IEC CENELEC 2. Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge 3. Ansätze zur Optimierung toolgestützter Teststrategien 4. Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform 5. Projektierung von COTS-Produkten

42 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Teilbericht AP 2300 Vergleich der Zulassungsbedingungen IEC CENELEC Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

43 Vergleich der Zulassungsbedingungen IEC CENELEC Änderungsverfolgung Datum Bearbeiter Version Inhalt Schaefer (Funkwerk 0.1 Dokumentenstruktur AG) Schaefer (Funkwerk AG) 0.2 Beurteilung der vorliegenden Argumentation; Ansatz für Normenvergleich; Reviewergebnisse Schaefer (Funkwerk 0.3 Allgemeine Anforderungen AG) Schaefer (Funkwerk 0.4 System und Hardware AG) Schaefer (Funkwerk 0.5 Erstellung AG) Schaefer (Funkwerk AG) 0.6 Vergleich des Sicherheitsnachweises; Ausblick und Zusammenfassung umformuliert Möller-Neustock 0.7 Übernahmen Sicht aus Ergebnisbericht Holger Neustock Klaus-Dieter Winkler 1.0 Finalisierung Inhaltsverzeichnis 1 Einleitung Vergleich der Zulassungsbedingungen IEC CENELEC Beurteilung der vorliegenden Argumentation These Argumentationskette Beurteilung der Argumente Ergebnis Normenvergleich Allgemeine Anforderungen System und Hardware Software Sicherheitsnachweis Ausblick und Zusammenfassung Ziele und Schwerpunkte des Berichts Allgemeine Anforderungen Lebenszyklen Dokumentation, Management und RAMS System und Hardware Software Anhang Anhang 1: Referenzen Anhang 2: Abkürzungen...31 Tabellenverzeichnis Tabelle 1: SIL-Klassen in EN Tabelle 2: SIL-Klassen in IEC Version 1.0 Seite 2 von 31

44 Vergleich der Zulassungsbedingungen IEC CENELEC Tabelle 3: Themenauswahl für den Anwendungsbereich Tabelle 4: Auswahl von Fachbegriffen Tabelle 5: Vergleich der Lebenszyklus-Phasen Tabelle 6: Vergleich der Konzept-Anforderungen Tabelle 7: Vergleich der Anforderungen zur Definition des gesamten Geltungsbereiches Tabelle 8: Vergleich der Gefahren- und Risikoanalyse Tabelle 9: Vergleich der Anforderungen an die gesamte Sicherheit Tabelle 10: Vergleich der Zuordnung der Sicherheitsbedingungen Tabelle 11: Vergleich der Entwicklung, Konstruktion, Implementierung und Fertigung Tabelle 12: Vergleich der Installation und Inbetriebsetzung insgesamt Tabelle 13: Vergleich der Validierung der gesamten Sicherheit Tabelle 14: Vergleich des Betriebs und der Instandhaltung Tabelle 15: Vergleich von Lebenszyklus Tabelle 16: Vergleich von Lebenszyklus Tabelle 17: Vergleich von Software Tabelle 18: Vergleich der Software Tabelle 19: Vergleich von Software Tabelle 20: Vergleich von Software Tabelle 21: Vergleich von Software Tabelle 22: Vergleich von Software Tabelle 23: Vergleich von Software Tabelle 24: Vergleich von Software Tabelle 25: Vergleich des Inhalts des Sicherheitsnachweises Version 1.0 Seite 3 von 31

45 Vergleich der Zulassungsbedingungen IEC CENELEC Einleitung 1 Einleitung Elektronische Stellwerke sind weltweit ab etwa Mitte der 80er Jahre im Einsatz. In Deutschland wurden sie ab 1990 in großem Umfang installiert, um die bis dahin eingesetzte Relaistechnik zu ersetzen. Nahezu alle Stellwerkstypen aus der Anfangszeit wurden vollständig von Grund auf in den Firmen entwickelt und gefertigt. Dabei waren die Zukaufteile, also im Grunde Industriestandard, auf elektrische und elektronische Komponenten wie CPU, Speicher, Widerstände und einfache integrierte Schaltkreise begrenzt. Auch selbst entwickelte CPU kamen zum Einsatz. So sollte sichergestellt sein, dass der gesamte Herstellungsprozess in eigener Hand und eigener Kontrolle liegt. Die Erwartungshaltung war, dass durch den Einsatz von Elektronik die Stellwerke baulich kleiner und vor allem kostengünstiger werden. Schon in den 90er Jahren wurde die Normenserie CENELEC 50126/28/29 (im Weiteren als CENE- LEC bezeichnet) zur Entwicklung von Stellwerken entworfen, um den Zulassungsprozess zu standardisieren. Sie sind Fachnormen zur übergeordneten IEC (im Weiteren als IEC bezeichnet), Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme Parallel zur Entwicklung der Stellwerkstechnik waren Industriesteuerungen bereits in den 80 Jahren weit verbreitet und haben die Steuerungen von industriellen Systemen gewandelt. Die Herstellung der Steuerungen wurde von den Betreibern von Kraftwerken, der Automobilindustrie oder der Chemieindustrie auf Hersteller von SPS verlagert. Dabei sieht Siemens sich als Marktführer, andere namhafte Hersteller sind Schneider, Mitsubishi, Pilz und viele andere. Da die Sicherheit in vielen Prozessbereichen von herausragender Bedeutung ist, wurde zur Standardisierung der Bewertung und Zulassung die IEC entworfen. Alle sicherheitsgerichteten Systeme in Industriebereichen wurden nach dieser Norm entwickelt und dokumentiert. Die Signaltechnik hat mit den CENELEC Normen EN 50126/28/29 Fachnormen mit Abweichungen entworfen. So hat sich heute gezeigt, dass die erhofften Einsparungen beim Einsatz von in weiten Teilen selbst entwickelter Elektronik und Software bei den geringen Stückzahlen nicht kosteneffizient wird. So wird vermehrt auf bereits zugelassene Hard- und Software zurückgegriffen. Daraus ergibt sich zwangsweise die Fragestellung bzgl. einer Überleitung der Zulassung nach IEC-Norm in die CENE- LEC-Norm, d. h. unter welchen Voraussetzungen eine Begutachtung nach IEC im Anwendungsbereich Signaltechnik/Bahnsysteme anerkannt werden kann. Die Zielstellung dieses Ergebnisberichts ist, auf Basis eines Normenvergleichs geeignete Ansätze für Maßnahmen aufzuzeigen, wie nach IEC zugelassene Standardindustriekomponenten, zulassungsfähig für einen Einsatz in der LST werden können. Version 1.0 Seite 4 von 31

46 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC 2 Vergleich der Zulassungsbedingungen IEC CENELEC Zulassungen nach IEC werden bisher nicht ohne weiteres vom EBA anerkannt. Auch wenn die CENELEC Normenreihe als Fachnorm auf der IEC basiert, gilt die Fachnorm als verbindlich. Die folgenden Kapitel beleuchten einige der Zulassungsbedingungen in diesem Umfeld. Zusätzlich ist zu berücksichtigen, dass für die größte Anzahl der Zulassungen beim EBA eher Mü8004 als Standard galt und erst jetzt in zunehmendem Maße CENELEC eingesetzt wird. Daher lässt sich mutmaßen, dass in der Umsetzung der CENELEC Normen noch nicht an allen Stellen ein klares Bild besteht. Dabei kann man den grundsätzlichen Unterschied in der Verfahrensweise der Zulassung nach Mü8004 und CENELEC so beschreiben: Mü 8004: Das Prinzip der absoluten Sicherheit. Das Produkt wird vom Hersteller nach vorgegebenen Merkmalen entwickelt und in einem Sicherheitsnachweis dokumentiert. Dieser fokussiert sich auf Fehler- und Ausfallbetrachtungen. Alle denkbaren Fehler müssen abgefangen werden. Es gibt keine Wahrscheinlichkeitsbetrachtungen. Der Entwicklungsprozess wird nur sehr begrenzt betrachtet. Die Mü 8004 gibt nur bedingt Prozesse vor, eher technische Ansätze zur Lösung. Man kann dies auch als regelbasierten Ansatz beschreiben. Die Zulassung erfolgt, wenn den Regeln gefolgt wurde. CENELEC (und auch IEC 61508): Das Prinzip des risikobasierten Ansatzes. Nach der Risikoanalyse wird per Funktion ein Sicherheitsniveau festgelegt. Innerhalb der Grenzen des jeweiligen Sicherheitsniveaus wird das Auftreten von Fehlern und Gefährdungen toleriert. Die Dokumentation umfasst den vollständigen Lebenszyklus des Produktes. Die Norm selbst gibt nahezu ausschließlich Prozesse vor, keine technischen Lösungen. Diesen Ansatz kann man als prozessorientiert beschreiben. Die Zulassung wird erteilt, wenn über den gesamten Lebenszyklus der Prozess gemäß Norm eingehalten und dokumentiert wurde. Es obliegt dem Hersteller den Prozess mit Inhalten zu füllen und für die Sicherheit zu argumentieren. Inhalt dieses Dokuments ist eine Gegenüberstellung der Zulassungsbedingungen für die Normen und IEC [IN] (im Folgenden kurz: Industrienorm ) IEC [BN6], [BN8] und [BN9] (im Folgenden kurz: Bahnnorm ). Das Motiv für diese Betrachtung ist die Frage, wie bahnspezifische Nachweise bei der Bewertung nach der Industrienorm zulassungsfähig für den Einsatz in der Leit- und Sicherungstechnik genutzt werden können. 2.1 Beurteilung der vorliegenden Argumentation Dieses Kapitel stellt die Argumentation der TÜV-Präsentation [SSE] dar und diskutiert verschiedene Aspekte des Vortrags These Die Kernthese des Vortrags ist, dass elektronische Systeme, die nach der Industrienorm zertifiziert sind, mit zusätzlichen Maßnahmen auch nach der Bahnnorm zertifiziert werden können Argumentationskette 1. In einem Schaubild werden die Bahnnormen EN 50126, 50128, als Spezialisierung der Fachgrundnorm IEC dargestellt. 2. Eine Betrachtung der Produktkategorien stellt heraus, dass das Generische Produkt aus den Bahnnormen mit der Industrienorm korreliert. 3. Ein Vergleich der Einteilung von qualitativen Anforderungen stellt für die Industrienorm vier Sicherheitsstufen und für die Bahnnorm zwei Sicherheitsklassen dar. Ferner wird eine Abbildung der Sicherheitsstufen der Industrienorm auf die Sicherheitsstufen der Bahnnorm angegeben. Version 1.0 Seite 5 von 31

47 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC 4. Es werden Kategorien aufgelistet, für die Unterschiede zwischen den Normen betrachtet werden können: Software, Hardware, Dokumentation, Sicherheitsprozess. 5. Eine Folie stellt den Aufbau der Normen aus den jeweiligen Teilnormen dar. a. Die ersten drei Teile der Industrienorm entsprechen den drei Bahnnormen. b. Die übrigen Teile der Industrienorm sind Definitionen, Beispiele, Richtlinien und Techniken. 6. Die Anforderungen zur Kommunikation scheinen ähnlich zu sein. Eine genaue Aussage ist aus der Tabelle mit einem Farbcode aber nicht zu entnehmen. 7. Das Sicherheitsmanagement unterscheidet sich bzgl. notwendiger Dokumentation und Unabhängigkeit der Rollen. 8. Bzgl. komplexer Komponenten ist die Industrienorm spezifischer als die Bahnnorm. 9. Die Anforderungen zur Fehlerbetrachtung sind zu großen Teilen gleichwertig. Lediglich eine Architekturkategorie (Fehlertoleranz 0 + Anteil ungefährlicher Ausfälle 99% könnte im Sinne der Bahnnorm eine Problematik darstellen). 10. Bzgl. der Architekturvorschriften ist die Industrienorm spezifischer als die Bahnnorm. 11. Die Betrachtung von Common Cause Analysen wird in der Industrienorm ausführlicher behandelt. 12. Zum Diagnoseabdeckungsgrad (Fehleroffenbarungswahrscheinlichkeit durch Diagnosetests) finden sich nur in der Industrienorm ausreichende Informationen. Dies wird als größter Unterschied zwischen den Normen EN und IEC bezeichnet. 13. Zur probabilistischen Berechnung von Gefährdungen sagt die Bahnnorm nur wenig aus. Die Industrienorm enthält umfangreiche Beispiele zur Berechnung und berücksichtigt Diagnosemaßnahmen und weitere Faktoren. 14. Ein Berechnungsbeispiel illustriert den Lösungsvorschlag, dass die Bahnnorm das Vorgehen der Industrienorm akzeptiert. 15. Eine Folie von Pilz zeigt: Das reale Ausfallverhalten ist um den Faktor 4-5 geringer als die theoretische Prognose. Damit würden schon heute viele SIL3-Baugruppen die THR für bahntechnische Anwendungen nach SIL4 erfüllen. 16. Der Zusammenhang spezieller, statistischer Werte wird in einer weiteren Folie dargestellt. Die Umrechnung von HR (Hazard Rate) der Bahnnorm in PFH (Probability of a dangerous Failure per Hour) erfolgt mittels der Identität, d.h. HR = PFH. 17. Als Ergebnis des Vergleichs werden einige Bedingungen genannt, bei deren Beachtung eine Anerkennung nach der Bahnnorm möglich sein soll: a. Zertifizierung nach IEC b. Zertifizierung nach IEC oder einer vergleichbaren Norm c. Beachtung der Wahrscheinlichkeitsberechnung d. Unabhängige Validierung e. Zusätzliche Dokumentation 18. Es folgen noch einige Folien mit Anregungen und Vorschlägen, die keine neuen Argumente zur These beitragen. Version 1.0 Seite 6 von 31

48 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Beurteilung der Argumente Spezialisierungshierarchie Die Abbildung für Argument 1 vermittelt einen anschaulichen Überblick, über die Entwicklungsgeschichte der Normen. Zur Darstellung inhaltlicher Zusammenhänge ist sie aber weniger geeignet. Sie legt nahe, die dargestellten Beziehungen als Spezialisierung zu interpretieren. D.h. anzunehmen, die Grundnorm wäre eine abstraktere Formulierung und die abgeleiteten Normen eine Spezialisierung der Grundnorm für bestimmte Bereiche. In diesem Fall sollten die Bedingungen der abstrakten Grundnorm auch für alle Spezialisierungen gelten. Anders herum gelten die Bedingungen einer speziellen Norm nicht unbedingt in einer abstrakteren Weise (und damit auch für alle anderen Ableitungen). Für eine Argumentation im Sinne der Kernthese hilft so eine Spezialisierung aber nicht weiter, da die Anforderungen aus der Industrienorm nicht hinreichend für die Anforderungen der Bahnnormen sind. Es ist sogar so, dass einige Argumente (z.b. 8, 10 und 11) eine Spezialisierung in der anderen Richtung nahelegen. Hilfreicher wäre eine Betrachtung der gemeinsamen Anteile (bzw. eine Abbildung zwischen diesen), sowie eine Darstellung jeweils ergänzender Anforderungen bei einer Überleitung von einer Norm auf die andere Produktkategorien Die Korrelation des Generischen Produkts aus den Bahnnormen mit der Industrienorm wird in der Präsentation nicht konkret beschrieben, ergibt sich zum Teil (auch für GA/SA) aber aus Kapitel 2.2. Mit so einer Korrelation können Aussagen aus der Industrienorm auf die Bahnnormen übertragen werden Einteilung für qualitative Anforderungen Da beide Normen die SIL-Einteilung für qualitative Anforderungen verwenden, ist die dargestellte Zuordnung nachvollziehbar. Die Strukturkategorien Software, Hardware, Dokumentation und Sicherheitsprozess scheinen für einen Vergleich der Normen geeignet zu sein und motivierten auch die Struktur des Vergleichs in Kapitel 2.2. Softwareaspekte und Risikoanalyse werden in der Präsentation nicht betrachtet Aufbau der Normen Die Zuordnung der Normenteile erleichtert den Vergleich und zeigt eine strukturelle Ähnlichkeit der Normen auf. Damit wird eine Argumentation im Sinne der Kernthese vereinfacht. Diese Grundstruktur wurde auch für den Vergleich in Kapitel 2.2 genutzt Kommunikationsanforderungen Der verwendete Farbcode legt nahe, dass sich die Kommunikationsanforderungen der Normen entsprechen sollen. Inhaltlich wird aber kein Argument angegeben. Eine erfolgreiche Argumentation würde aber die Kernthese stützen Sicherheitsmanagement Beim Sicherheitsmanagement werden zwei Unterschiede identifiziert: 1. Die Bahnnorm fordert einen expliziten Sicherheitsnachweis, der bei der Industrienorm lediglich implizit, in Form eines dokumentierten Lebenszyklus gefordert wird. 2. Die Bahnnorm fordert die Unabhängigkeit aller Sicherheitsrollen (gestaffelt nach SIL). Bei der Industrienorm ist die Unabhängigkeit aller Sicherheitsrollen nicht gefordert, aber geübte Praxis. Obwohl die Unterschiede durch den impliziten Sicherheitsnachweis und die geübte Praxis eingeschränkt werden, sind diese Unterschiede doch wesentlich. Die Gleichwertigkeit des dokumentierten Lebenszyklus wird nicht argumentiert, und lediglich praktizierte (aber nicht geforderte) Maßnahmen bei der Vergabe der Rollen werden weder überprüft noch zertifiziert. Version 1.0 Seite 7 von 31

49 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Umfang der Vorgaben Die Argumente 8 und 10 bis 13 vermitteln den Eindruck, dass die Industrienorm konkretere Vorgaben als die Bahnnorm macht, und in diesem Sinne spezieller ist. Dies steht im Widerspruch zur dargestellten Spezialisierungshierarchie (vgl ) Ausfallratenprognose Die Argumentation in 15 ist zwar verständlich, aber nicht unbedingt hilfreich. Wenn es so ist, dass die Bahnnorm eine große Freiheit bei der Wahl der Berechnungsmethode lässt (Argument 13), dann kann man die Untersuchungen zum realen Ausfallverhalten zur formalen Argumentation heranziehen. Falls andererseits eine konkrete Berechnungsvorschrift einzuhalten ist, so nützt es auch nichts, dass Untersuchungen zum realen Ausfallverhalten zu einem niedrigeren Wert kommen. Eine Differenz zwischen dem realen und dem berechneten Ausfallverhalten kann ja, z.b. als rechnerischer Sicherheitsabstand, durchaus erwünscht sein. Bei der Zulassung neuer Komponenten kann diese Argumentation ferner nicht verwendet werden, da keine ausreichende Datenbasis über das reale Ausfallverhalten vorhanden sein muss Umrechnung von Gefährdungsraten Für die untersuchten Begriffe Hazard Rate (HR) und Probability of a dangerous failure per hour (PFH) liegen keine normativen Definitionen vor. Dies erschwert eine Beurteilung der Aussage HR = PFH. Trotz des Namens, wird für die Betrachtung in diesem Dokument für PFH kein dimensionsloser Wahrscheinlichkeitswert angenommen, sondern eine Rate, die in 1/h gemessen wird (vgl. z.b. [ESS]). Für HR wird die folgende Bedeutung angenommen: Die HR gibt an, wie viele Objekte (z.b. Systeme, Teilsysteme oder Funktionen) in einer Zeiteinheit durchschnittlich (d.h. relativ zur Gesamtzahl) mit einem gefährlichen Fehler ausfallen. Bei dieser Betrachtung, macht die Aussage HR = PFH Sinn Abstufung der Sicherheitsniveaus im Vergleich Dieses Kapitel beschreibt vergleichend die Einstufungen der Sicherheitsniveaus beider Normen. Tabelle 1: SIL-Klassen in EN Version 1.0 Seite 8 von 31

50 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Tabelle 2: SIL-Klassen in IEC Allein von den gefährlichen Ausfällen scheinen die Sicherheitsniveaus identisch eingeteilt. Es ist zu beachten, dass die Berechnungsmethoden abweichen, so dass keine direkte 1:1-Beziehung hergestellt werden kann. Als größte Unterschiede wird angegeben, dass Diagnoseabdeckungsgrade in der IEC dezidiert zu berücksichtigen sind, während die CENELEC diese nicht erwähnt. Common Cause failure werden in IEC explizit in die Rechnung aufgenommen, bei CENELEC wird nur eine pauschale Betrachtung gefordert. Berechnungen bei Funkwerk am Beispiel des ESTW-R Alister haben ergeben, dass die Berechnung nach IEC konservativere Werte ergibt als die Berechnung nach CENELEC. Dies ist vor allem auf die Berücksichtigung von Common Cause Failure zurückzuführen Ergebnis Das Ergebnis fasst die Argumente noch einmal zusammen und ist zur bisherigen Argumentation konsistent. Unklar ist, inwiefern eine abgeschlossene Zertifizierung nach der Industrienorm nachträglich zu einer Zertifizierung nach der Bahnnorm überführt werden kann, da der Entwicklungsprozess an dieser Stelle ja bereits abgeschlossen ist. Im Einzelfall kann ein Hersteller durch zusätzliche Prozess-Dokumentation ein normgerechtes Vorgehen nachweisen. Bei einer Neuentwicklung kann das nachfolgende Kapitel nützliche Hinweise geben, welche Anforderungen entwicklungsbegleitend beachtet werden sollten, um eine Zulassung nach beiden Normwerken zu ermöglichen. 2.2 Normenvergleich In diesem Kapitel sollen die Anforderungen der Industrienorm mit denen der Bahnnormen verglichen werden. Strukturell wird dabei die Organisation aus Argument 5 (vgl ) ausgenutzt Allgemeine Anforderungen Hier werden im Wesentlichen die Bedingungen der Industrienorm IEC mit den Bedingungen der Bahnnorm EN verglichen. An den Stellen, an denen die Bereiche von IEC bzw. EN verlassen werden, wird dies ausdrücklich angegeben Anwendungsbereich Die folgende Tabelle beschreibt ausgewählte Themen aus dem Teil der Normen, die den Anwendungsbereich beschreiben. Thema Industrienorm Bahnnorm Domäne Sicherheit Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit, Sicherheit (RAMS) Spezialisierungsbeziehung Technik Ein wichtiges Ziel ist es, die Erstellung sektorspezifischer Normen zu ermöglichen. Elektrische / elektronische / programmierbare, elektronische Systeme Erklärt keine Spezialisierungsbeziehung Keine explizite Einschränkung Version 1.0 Seite 9 von 31

51 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Thema Industrienorm Bahnnorm Systematik Allgemeines Sicherheits-Lebenszyklus- Prozess auf Grundlage des System- Modell Lebenszyklusses zwecks RAMS- Abgrenzung der Angriffssicherheit zur Betriebssicherheit Deckt keine vorbeugenden Maßnahmen ab, um Schaden oder sonstigen nachteiligen Einfluss auf die funktionale Sicherheit durch unbefugte Personen zu verhindern. Tabelle 3: Themenauswahl für den Anwendungsbereich Domäne Management Spezifiziert keine Anforderungen für die Sicherheit im Sinne des Wachschutzes (Security). Obwohl sich beide Normenwerke auf die Betriebssicherheit konzentrieren, gibt es bzgl. der betrachteten Fachgebiete noch Unterschiede. So konzentriert sich die Industrienorm im Anwendungsbereich auf die Domäne Sicherheit, wohingegen die Bahnnorm alle RAMS-Domänen für sich beansprucht. Allein daran ist zu erkennen, dass die Anforderungen der Industrienorm nicht hinreichend für die Bahnnorm sein können Spezialisierung Während die Industrienorm die Gestaltung sektorspezifischer Normen geradezu erwartet, stellt sich die Bahnnorm nicht ausdrücklich als eine solche Spezialisierung dar. Diese Abgrenzung und Eigenständigkeit der Bahnnorm fördert keine Argumentation im Sinne der These (2.1.1). Sowohl im Sinne der betrachteten Fachgebiete (Domänen) als auch im Sinne der betrachteten Technik, stellt sich die Bahnnorm als allgemeiner und eben nicht spezifischer als die Industrienorm dar Systematik Da beide Normenwerke eine ähnliche Systematik verwenden (Lebenszyklus-Modell) findet man hier einen Ansatz für einen weiteren Vergleich, der auch in Abschnitt verfolgt wird Begriffe Tabelle 4 stellt die Definitionen der Normenwerke für ausgewählte Fachbegriffe nebeneinander dar. Die Begriffe der Industrienorm sind in Teil 4 der Norm definiert. Insofern verlässt der Vergleich damit den Bereich von IEC Auch sind bestimmte Definitionen der EN problematisch, so dass an den ausgezeichneten Stellen die Definitionen eines anderen Teils der Bahnnorm verwendet werden. Bemerkenswert ist die Tatsache, dass die Bahnnorm überhaupt unterschiedliche Begriffsdefinitionen in verschiedenen Teilen der Norm verwendet. Begriff Industrienorm Bahnnorm Gefahr Potentielle Quelle für eine direkte oder indirekte (als Folge eines Umweltschadens) physische Verletzung oder einen Gesundheitsschaden an einer Person. Risiko Safety Integrity Kombination der Wahrscheinlichkeit eines Schadens und der Schwere dieses Schadens Wahrscheinlichkeit, dass ein sicherheitsbezogenes System die geforderten Sicherheitsfunktionen unter allen festgelegten Bedingungen innerhalb einer bestimmten Zeitspanne erfüllt. Eine physikalische Situation, die potentiell einen Schaden für den Menschen beinhaltet. Die Wahrscheinlichkeit des Auftretens einer Gefahr, die einen Schaden verursacht, sowie der Schweregrad des Schadens Die Wahrscheinlichkeit dafür, dass ein System die festgelegten Sicherheitsanforderungen unter allen festgelegten Bedingungen innerhalb einer bestimmten Zeitspanne erfüllt. Sicherheit Freiheit von unvertretbaren Risiken Das Nichtvorhandensein eines unzulässigen Schadensrisikos Version 1.0 Seite 10 von 31

52 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Begriff Industrienorm Bahnnorm Sicherheits- Lebenszyklus (Systemlebenszyklus) System (Produkt) Validierung Verifikation Vertretbares Risiko Tabelle 4: Auswahl von Fachbegriffen Notwendige Aktivitäten bei der Implementation sicherheitsbezogener Systeme während einer Zeitspanne, die mit der Konzeptphase eines Projekts beginnt und endet, wenn alle E/E/PE sicherheitsbezogenen Systeme, sonstige sicherheitsbezogener Systeme anderer Technologie und externe Einrichtungen zur Risikominderung nicht mehr für den Gebrauch zur Verfügung stehen. Menge von Elementen, welche gemäß einem Entwurf interagieren. Elemente können hierbei wiederum Systeme (Subsysteme) sein. Sie können kontrollierende oder kontrollierte Systeme sein und können Hardware, Software und menschliche Interaktionen beinhalten. Nachweis, dass das sicherheitsgerichtete System alle spezifizierten Sicherheitsanforderungen erfüllt 2. Nachweis, dass für jede Phase des bestimmten Sicherheits-Lebenszyklus, die aus bestimmten Eingaben abgeleiteten Lieferungen, alle Vorgaben und Anforderungen dieser spezielle Phase erfüllen 2. Das in einem bestimmten Kontext akzeptierte Risiko auf der Grundlage der Werte einer Gesellschaft Die Aktivitäten während einer Zeitspanne, die mit der Konzipierung des Systems beginnt und mit seiner Stilllegung, wenn das System nicht länger für den Gebrauch verfügbar ist, endet. Menge von Elementen, die in einer zur Erfüllung der spezifischen Anforderung geeigneten Art und Weise zu einem System, Subsystem oder Bestandteil einer Einrichtung zusammengeschaltet sind. In dieser Europäischen Norm (EN 50128) kann ein Produkt als ausschließlich aus Software oder Dokumenten aufgebaut angesehen werden 1. Analyse und Testen zur Demonstration, dass das Produkt in allen Belangen seine spezifizierten Anforderungen erfüllt 3. Analyse und Testen, um festzustellen, ob das Ausgangsprodukt jeder Phase des Lebenszyklus die Anforderungen aus der vorherigen Phase erfüllt 3. Der maximale Grad an Risiko durch ein Produkt, der für ein Bahnunternehmen toleriert werden kann Auch wenn Tabelle 4 nur eine kleine Auswahl der Fachbegriffe darstellt, reicht das für den Eindruck aus, dass die beiden Normwerke die gleiche Fachsprache verwenden. Jedenfalls unterscheiden sich die Definitionen oft weniger als unterschiedliche Definitionen eines Begriffs in der gleichen Norm Lebenszyklus Industrienorm Bahnnorm 1: Konzept 1: Konzept 2: Definition des gesamten Geltungsbereiches 2: Systemdefinition Anwendungsvoraussetzungen und Anwendungsbedingungen 3: Gefahren- und Risikoanalyse 3: Risikoanalyse 4: Anforderungen an die gesamte Sicherheit 4: Systemanforderungen 5: Zuordnung der Sicherheitsanforderungen 5: Zuteilung der Systemanforderungen 6: Planung von Betrieb und Instandhaltung insgesamt 7: Fertigung 6: Entwicklung/Konstruktion und Implementierung 7: Planung der Validierung der gesamten Sicherheit 8: Planung der gesamten Installation und Inbetriebsetzung 9: Sicherheitsbezogene Systeme: E/E/PES Realisierung 10: Sicherheitsbezogene Systeme: andere Technologien Realisierung 11: Externe Einrichtungen zur Risikominderung 1 ) Mangels Definition in EN wurde der Begriff anhand der Definition Produkt in EN hergeleitet. 2 ) Berücksichtigt auch die Anmerkungen zur Definition, welche die Begriffsbestimmung verbessern und präzisieren. 3 ) Da die Definitionen aus EN unbrauchbar sind, werden hier die Definitionen aus EN verwendet. Version 1.0 Seite 11 von 31

53 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Bahnnorm Realisierung 12: Installation und Inbetriebsetzung insgesamt 8: Installation/Montage 13: Validierung der gesamten Sicherheit 9: System-Validierung 10: Systemabnahme 14: Betrieb, Instandhaltung und Wartung insgesamt 11: Betrieb und Instandhaltung 12: Erfassung der Leistungsfähigkeit 15: Abänderung und Nachrüstung insgesamt 13: Änderungen und Nachrüstung 16: Außerbetriebsetzung oder Entsorgung 14: Stilllegung und Entsorgung Tabelle 5: Vergleich der Lebenszyklus-Phasen Wie in Tabelle 5 zu sehen ist, lassen sich die verwendeten Lebenszyklen der beiden Normwerke vergleichen. Es gibt eine Beziehung zwischen den Phasen und auch die Reihenfolge der Phasen passt zueinander. In den folgenden Abschnitten werden die einzelnen Phasen miteinander verglichen Konzept Industrienorm Bahnnorm Eingehende Vertrautheit mit den kontrollierten Geräten und ihrer physikalischen Umgebung Umgebung und seinen allgemeinen RAMS Vorstellung vom Zweck des Systems, seiner Mutmaßliche Gefahrenquellen Auswirkungen Informationen über identifizierte Gefahren Informationen über aktuelle Sicherheitsbestimmungen RAMS-Anforderungen ähnlicher Systeme, RAMS-Auswirkungen Sicherheitsgesetzgebung und -politik Gefahren aufgrund von Wechselwirkungen Gefahrenquellen für RAMS-Performance mit anderen kontrollierten Geräten Dokumentation Ergebnisse Tabelle 6: Vergleich der Konzept-Anforderungen Aus Tabelle 6 ist ersichtlich, dass sich die Anforderungen der Konzeptphase durchaus einander zuordnen lassen. Grundsätzlich stellt die Industrienorm aber primär auf die Sicherheit ab, während die Bahnnorm hier den allgemeineren RAMS Begriff verwendet. Wie schon in angemerkt sind die Anforderungen der Industrienorm daher nicht hinreichend für die Bahnnorm Definition des gesamten Geltungsbereiches Industrienorm Bahnnorm Spezifikation der materiellen Ausrüstung a Festlegung des Betriebsaufgaben-Profils c Festlegung des Umfangs der Anwendungsbedingungen Spezifikation externer Ereignisse b Festlegung der Systemgrenzen Spezifikation gefährdeter Subsysteme Spezifikation von Störfalltypen d Festlegung des Umfangs der Gefahrenanalyse b Vorläufige Gefahrenanalyse a Vorläufige RAM-Analyse RAMS-Politik Erstellung des Sicherheitsplans Dokumentation Ergebnisse ( Wiederholung von Anforderungen) Tabelle 7: Vergleich der Anforderungen zur Definition des gesamten Geltungsbereiches Die Zuordnung der Anforderungen in dieser Phase ist nun nicht mehr so vollständig. Die Industrienorm zählt weder eine RAM-Analyse noch eine RAMS-Politik zum Inhalt dieser Phase. Auch die Erstellung eines Sicherheitsplans gehört nicht dazu. Für die übrigen Anforderungen lassen sich Zuordnungen finden. Version 1.0 Seite 12 von 31

54 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Gefahren- und Risikoanalyse In der folgenden Tabelle werden auch Anforderungen aus Softwareteil der Bahnnorm (EN 50128) abgebildet. Die Bezüge zur Bahnnorm werden daher um ein Präfix (N6 = EN 50126, N8 = EN 50128) ergänzt. Industrienorm Gefahren- und Risikoanalyse durchführen Bestimmung von vorhersehbaren Gefahren und gefährlichen Ereignissen Beseitigung von Gefahren erwägen Bestimmung von Ereignisketten für gefährlichen Ereignisse Spezifikation der Wahrscheinlichkeit gefährlicher Ereignisse Bestimmung möglicher Auswirkungen gefährlicher Ereignisse Risikoberechnung oder -abschätzung für jedes gefährliche Ereignis ( Durchführungshinweis) Angemessenheit der Techniken Inhalt der Gefahren- und Risikoanalyse Pflege der Gefahren- und Risikoanalyse Dokumentation N Ergebnisse Tabelle 8: Vergleich der Gefahren- und Risikoanalyse Bahnnorm N a Erkennen von vorhersehbaren Gefahren N Zu berücksichtigende Risiken N b Identifikation von Abläufen, die Gefährdungen bergen N c Ermittlung der Häufigkeit des Eintretens von Gefahren N d Ermittlung des Ausmaßes der Auswirkungen von Gefahren N e Ermittlung des Systemrisikos für jede Gefahr N Festlegung und Klassifizierung von Risiken N Erstellung des Gefahrenprotokolls Die Anforderungen dieser Phase lassen sich, wie in Tabelle 8 beschrieben, einander zuordnen und sind vergleichbar Anforderungen an die gesamte Sicherheit Industrienorm Bahnnorm Spezifikation der Sicherheitsfunktionen Festlegung der RAMS-Anforderungen Übergreifende Anforderungen für Erfüllung RAM-Programm Ergänzung Sicherheitsplan Bestimmung der Risikominderung Verwendung Internationaler Standards zur Risikominderung Nicht sicherheitsbezogene Kontrollsysteme ( Wiederholung) Spezifikation der Anforderungen zur Sicherheitsintegrität Festlegung der RAMS-Anforderungen ( Bezeichnung) Tabelle 9: Vergleich der Anforderungen an die gesamte Sicherheit Bei den Anforderungen an diese Phase setzen die beiden Normenwerke recht unterschiedliche Schwerpunkte. Auf eine Bestimmung der Risikominderung wird in der Bahnnorm in dieser Phase nicht ausdrücklich Wert gelegt. Dafür finden sich in der Industrienorm für diese Phase keine Übergreifenden Anforderungen oder Anforderungen an einen Sicherheitsplan. Erwartungsgemäß, finden sich in der Industrienorm auch keine Angaben zu einem RAM-Programm Zuordnung der Sicherheitsanforderungen In der folgenden Tabelle werden auch Anforderungen aus Softwareteil der Bahnnorm (EN 50128) abgebildet. Die Bezüge zur Bahnnorm werden daher um ein Präfix (N6 = EN 50126, N8 = EN 50128) ergänzt. Version 1.0 Seite 13 von 31

55 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Spezifikation der sicherheitsbezogenen Systeme Prüfung von Fähigkeiten und Ressourcen Verteilung von Sicherheitsfunktionen auf sicherheitsbezogene Systeme Vollständigkeit der Verteilung und Konsistenz mit den Anforderungen zur Sicherheitsintegrität Betriebsweise für die Anforderungen zur Sicherheitsintegrität festlegen Verteilung unter Benutzung geeigneter Techniken zur Kombination von Wahrscheinlichkeiten Verteilung berücksichtigt mögliche Fehler mit gemeinsamer Ursache Unabhängigkeit E/E/PE, andere Sicherheitstechnologien, externe Einrichtungen zur Risikominderung Zuweisung von Sicherheitsanforderungsstufen (SIL) an Sicherheitsfunktionen Systeme mit Sicherheitsfunktionen verschiedener Sicherheitsanforderungsstufen Architekturen einzelner, sicherheitsbezogener E/E/PES Systeme Maximale Sicherheitsanforderungsstufe für einzelne, sicherheitsbezogene E/E/PE Systeme Dokumentation N Ergebnisse Tabelle 10: Vergleich der Zuordnung der Sicherheitsbedingungen Bahnnorm N a Zuordnung der funktionalen Anforderungen N c Spezifizierung der Subsysteme, Komponenten und externen Einrichtungen N b Zuordnung der Sicherheitsanforderungen N d Aktualisierung des RAM-Programms N Überprüfung und Aktualisierung des Sicherheits- und Validierungsplans N Bedingungen für Übereinstimmung der Anforderungen N Festlegung der Software-Sicherheitsanforderungsstufe N Mindest-Software-Sicherheitsanforderungsstufe N Software-Sicherheitsanforderungsstufen N Dokumentation der Software-Sicherheitsanforderungsstufe Im Gegensatz zur Industrienorm beschreibt die Bahnnorm in dieser Phase keine Zuordnung von Sicherheitsanforderungsstufen. Safety Integrity wird hier als RAMS-Konzept beschrieben welches keiner bestimmten Lebenszyklusphase zugeordnet ist Entwicklung, Konstruktion, Implementierung und Fertigung Industrienorm Erstellung des Wartungsplans Wartungsaktivitäten zur Offenbarung unentdeckter Fehler Bestätigung des Wartungsplans durch das Wartungspersonal Erstellung eines Validierungsplans Erstellung eines Installationsplans Erstellung eines Inbetriebsetzungsplans Dokumentation Dokumentation Realisierung E/E/PES: siehe und Bahnnorm Planung nachfolgender Lebenszyklusaufgaben Unterstützende Maßnahmen für Subsysteme und Komponenten a Planung einer Fertigung c Einführung einer RAMS-Prozess-Sicherung Ergebnisse Entwicklung/Konstruktion der Subsysteme und Komponenten Realisierung der Subsysteme und Komponenten Version 1.0 Seite 14 von 31

56 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Realisierung anderer Technologien: nicht im Anwendungsbereich der Industrienorm Realisierung externer Einrichtungen zur Risikominderung: nicht im Anwendungsbereich der Industrienorm Bahnnorm Definition, Verifikation und Erstellung eines Produktionsverfahrens Verifikation und Implementierung des Fertigungsprozesses b Einführung einer Fertigung a Erstellung System-Sicherheitsnachweis b Vorbereitung eines Anwendungssicherheitsnachweises (vgl. auch ) Tabelle 11: Vergleich der Entwicklung, Konstruktion, Implementierung und Fertigung Nicht abgedeckte Anforderungen der Bahnnorm beziehen sich hier auf die Sicherheitsnachweise. Für die übrigen Anforderungen lassen sich Zuordnungen finden. Die Bahnnorm differenziert hier stärker bzgl. der einzelnen Realisierungsschritte. Zu Punkt gibt es innerhalb der Industrienorm Verweise auf die Teile 2 und 3 der Norm. Anders die Bahnnorm, die hier auf Verweise zu den Normen EN und EN verzichtet. Die Teile der Bahnnorm grenzen sich damit stärker, auch gegeneinander ab Installation und Inbetriebsetzung insgesamt Industrienorm Verwendung des Installationsplans Verwendung des Inbetriebsetzungsplans Umfang der Installationsdokumentation Umfang der Inbetriebsetzungsdokumentation Tabelle 12: Vergleich der Installation und Inbetriebsetzung insgesamt Bahnnorm Zusammenbau und Montage Dokumentation des Montageprozesses Überprüfung und Anpassung des Sicherheitsplans Schulung, Arbeitsanweisungen, Lagerhaltung In dieser Phase finden sich für die Überprüfung des Sicherheitsplans, sowie für Schulung, Arbeitsanweisungen und Lagerhaltung keine Entsprechungen in der Industrienorm Validierung der gesamten Sicherheit Industrienorm Verwendung des Validierungsplans Kalibrierung von Werkzeugen für Messungen Dokumentation der Validierung Ergebnisse Dokumentation der Maßnahmen bei Abweichungen Tabelle 13: Vergleich der Validierung der gesamten Sicherheit Bahnnorm Validierung gemäß Validierungsplan Inbetriebsetzung/Betriebserprobung Vorbereitung eines Anwendungssicherheitsnachweises (vgl. auch b) Verfahren zur Ermittlung von Felddaten In dieser Phase finden sich für die Vorbereitung eines Anwendungssicherheitsnachweises, sowie für die Verfahren zur Ermittlung von Felddaten keine Entsprechungen in der Industrienorm. Version 1.0 Seite 15 von 31

57 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Betrieb und Instandhaltung Industrienorm Umsetzung des Wartungsplans und von Wartungsroutinen für Systeme und Software Umsetzung eines Wartungsaktivitätsmodells Chronologische Dokumentation von Betrieb, Wartung und Reparatur (Verweis auf sektorspezifische Normen) Tabelle 14: Vergleich des Betriebs und der Instandhaltung Bahnnorm Überwachung von Systemausführung, sowie von Betriebs- und Instandhaltungsverfahren a Regelmäßige Überprüfung und Anpassung der Betriebs- und Instandhaltungsverfahren b Regelmäßige Überprüfung der Schulungsdokumentation e Einsatz des FRACAS-Systems für die Ausfallerfassung und Korrekturmaßnahmen c Regelmäßige Überprüfung und Anpassung des Gefahrenprotokolls und des Sicherheitsnachweises d Wirksame logistische Unterstützung Leistungserfüllung, RAMS-Statistik und Überprüfung des Sicherheitsnachweises Analyse von Leistungserfüllung und RAMS- Daten Die Formulierungen in der Industrienorm sind für diese Phase etwas abstrakter als in der Bahnnorm. Daher kann hier auch nur eine teilweise und nur wenig präzise Zuordnung der Anforderungen vorgenommen werden Abänderung und Nachrüstung Industrienorm Bahnnorm Planung von Änderungen und Nachrüstungen Erstellung eines Sicherheitsplans Auslösung durch formale Problemmeldungen Prozess für die Lenkung von Änderungen Durchführung einer Auswirkungsanalyse Dokumentation der Auswirkungsanalyse Berücksichtigung der Auswirkungsanalyse Wiederholung geeigneter Lebenszyklusphasen Chronologische Dokumentation Ergebnisse Tabelle 15: Vergleich von Lebenszyklus Die Anforderungen in der Industrienorm sind hier etwas detaillierter, passen aber zu den Anforderungen aus der Bahnnorm Stilllegung und Entsorgung Industrienorm Durchführung einer Auswirkungsanalyse Dokumentation der Auswirkungsanalyse Berücksichtigung der Auswirkungsanalyse Auslösung durch Prozedur zum Management der funktionalen Sicherheit Vorbereitung eines Stilllegung- und Zerlegungsplans Wiederholung geeigneter Lebenszyklusphasen Bahnnorm a Feststellen der Auswirkungen der Stilllegung und Entsorgung b Planung der Stilllegung Erstellung der Analyse der RAMS- Lebenszyklus-Leistungsfähigkeit Chronologische Dokumentation Ergebnisse Tabelle 16: Vergleich von Lebenszyklus Bis auf die RAM-Analyse können hier wieder Anforderungszuordnungen gefunden werden. Version 1.0 Seite 16 von 31

58 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Dokumentation und Management Anforderungen zur Dokumentation und zum Management befinden sich in der Bahnnorm EN In der Industrienorm sind die Anforderungen zu dem Thema auf die Teile 1 und 3 der Norm aufgeteilt. Eine Diskussion der Anforderungen findet daher in statt RAMS für Bahnanlagen und RAMS-Management für Bahnen Diese Abschnitte der Bahnnorm können aus verschiedenen Gründen nur schwer den Abschnitten der Industrienorm zugeordnet werden: Starker Bezug zur Bahndomäne Keine ausdrückliche Kennzeichnung von Anforderungen Allgemeiner, beschreibender Charakter Einleitende Funktion für RAMS-Lebenszyklus Fokus der Industrienorm auf Sicherheitsaspekte Am ehesten könnte man noch versuchen, einzelne Teile den Dokumentationsabschnitten der Industrienorm zuzuordnen. Die eher beschreibende Form und das Fehlen expliziter Anforderungen erschweren jedoch einen systematischen Zugang, so dass ein Zuordnungsversuch hier nicht vorgenommen wird System und Hardware Hier werden im Wesentlichen die Bedingungen der Industrienorm IEC mit den Bedingungen der Bahnnorm EN verglichen. Das Fehlen von expliziten Anforderungen oder ähnlich detaillierter Strukturmerkmalen in der Bahnnorm erschwert hier (wie bereits in ) eine systematische Aufbereitung über Vergleichstabellen. Die Struktur der nachstehenden Abschnitte folgt daher dem Aufbau der Bahnnorm und zählt relevante Anforderungen aus der Industrienorm auf Nachweis des Qualitätsmanagements Einsatz von Techniken und Maßnahmen zur Vermeidung von Fehlern beim Design und bei der Entwicklung von Hardware Eigenschaften der Design-Methode Formalisierung von Wartungsanforderungen Verwendung automatischer Testwerkzeuge und integrierter Entwicklungsumgebungen Planung von E/E/PES Integrationstests Unterscheidung von Aktivitäten, die im Werk oder beim Kunden durchgeführt werden Entwurfseigenschaften zur Kontrolle systematischer Fehler Berücksichtigung von Wartbarkeit und Testbarkeit beim Entwurf und bei der Entwicklung Benutzerfreundliche Schnittstellengestaltung Nachweis des Sicherheitsmanagements Sicherheitslebenszyklus Verwendeter Sicherheitslebenszyklus Parallele Ausführung der Verfahren zum Management der funktionalen Sicherheit Aufteilung der Phasen in Aktivitäten Version 1.0 Seite 17 von 31

59 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Dokumentation der Ausgaben von Phasen Anforderungen für Ausgaben von Phasen Sicherheitsorganisation Sicherheitsplan Gefährdungslogbuch Sicherheitsanforderungsspezifikation Ableitung von E/E/PES Sicherheitsanforderungen Qualitative Anforderungen an Ausdruck und Struktur von E/E/PES Sicherheitsanforderungen Anforderungen für E/E/PES Sicherheitsfunktionen und für die E/E/PES Sicherheitsintegrität sind E/E/PES Sicherheitsanforderungen a Beschreibung aller notwendigen Sicherheitsfunktionen b Mengendurchsatz und Antwortverhalten c System- und Betreiberschnittstellen d Relevante Informationen zur funktionalen Sicherheit mit Auswirkungen auf das Systemdesign e Alle Schnittstellen zwischen E/E/PES sicherheitsgerichteten Systemen und Umsystemen f Alle Relevanten Betriebsmodi der kontrollierten Geräte g Alle notwendigen Verhaltensmodi von E/E/PES sicherheitsgerichteten Systemen h Bedeutung aller Hardware/Software Interaktionen i Grenzen und Bedingungen für E/E/PES sicherheitsgerichtete Systeme j Spezifische Anforderungen zu Start- und Wiederanlaufverfahren a Sicherheitsanforderungsstufe (SIL) für Sicherheitsfunktionen b Betriebsmodus für Sicherheitsfunktionen c Prüfvoraussetzungen Maßnahmen zur Vermeidung von Fehlern bei der Spezifikation der Sicherheitsanforderungen Anforderungen zum Abschätzen der Wahrscheinlichkeit eines Versagens von Sicherheitsfunktionen aufgrund von Hardwarefehlern System-/Teilsystem-/Einrichtungs-Entwurf Übereinstimmung von Entwurf und Sicherheitsanforderungsspezifikation a Übereinstimmung von Entwurf und den Anforderungen der Hardware-Sicherheitsintegrität b Übereinstimmung von Entwurf und den Anforderungen der systematischen Sicherheitsintegrität c Übereinstimmung von Entwurf und den Anforderungen für das Systemverhalten bei Fehleroffenbarung Gemeinsame Implementierung von Sicherheits- und Nicht-Sicherheits-Funktionen Version 1.0 Seite 18 von 31

60 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Sicherheitsintegrationsstufe bei unterschiedlichen Sicherheitsfunktionen Nachweis der Unabhängigkeit von Sicherheitsfunktionen Verfügbarkeit der Anforderungen an sicherheitsgerichtete Software Review der Anforderungen an sicherheitsgerichtete Software und Hardware Notwendige Techniken und Maßnahmen im Lebenszyklus zur Erreichung der Sicherheitsintegrationsstufe Begründung der Auswahl von Techniken und Maßnahmen zur Erreichung der Sicherheitsintegrationsstufe Bedeutung der Hardware und Software-Interaktionen Zerlegung des Entwurfs in Subsysteme Sicherheitsfunktionen zur Vermeidung gefährlicher Ausgangskombination von Subsystemen Einsatz von Derating-Techniken Architektonische Bedingungen für die Hardware-Sicherheitsintegrität Implementation des E/E/PES nach dem Entwurf Identifikation sicherheitsrelevanter Subsysteme a Funktionale Spezifikation von Funktionen und Schnittstellen, die von Sicherheitsfunktionen verwendet werden können b Geschätzte Ausfallraten für gefährliche Fehler, die durch diagnostische Prüfungen offenbart werden c Geschätzte Ausfallraten für gefährliche Fehler, die durch diagnostische Prüfungen nicht offenbart werden d Umweltbedingungen, die beobachtet werden müssen, um die Gültigkeit der geschätzten Ausfallraten zu bestätigen e Lebensdauer, die nicht überschritten werden darf, um die Gültigkeit der geschätzten Ausfallraten zu bestätigen f Periodische Wiederholungsprüfungen und Wartungsanforderungen g Diagnoseniveau h Diagnose-Testintervall i Zusatzinformationen zur Ableitung der mittleren Reparaturzeit j Informationen zur Ableitung des Gesamtanteils sicherer Ausfälle k Hardware Fehlertoleranz l Anwendungsgrenzen zur Vermeidung systematischer Fehler m Höchste Sicherheitsintegritätsstufe für Sicherheitsfunktion n Konfigurationsinformationen o Validierungsnachweise Geschätzte Ausfallrate wegen zufälliger Hardwarefehler Kontrolle von systematischen Fehlern bei Betriebsbewährtheit nicht notwendig Kriterien für Betriebsbewährtheit zuvor entwickelter Subsysteme Version 1.0 Seite 19 von 31

61 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Nachweis ähnlicher Anwendungsbedingungen bei Vergleich von Subsystemen Identifikation unterschiedlicher Anwendungsbedingungen bei Vergleich von Subsystemen Mindestdauer der Betriebsbewährtheit Betriebsbewährtheit nur bei Fehleroffenbarung Faktoren zur Beurteilung Anforderungen für Betriebsbewährtheit Funktionseinschränkung von betriebsbewährten Subsystemen Abschätzung der Wahrscheinlichkeit unentdeckter Fehler bei der Datenkommunikation Parameter für die Abschätzung der Wahrscheinlichkeit von Fehlern bei der Datenkommunikation Sicherheitsreviews Sicherheitsverifikation und -validation Planung des Nachweises der Erfüllung der Sicherheitsanforderungen a Berücksichtigung aller Anforderungen der Sicherheitsanforderungsspezifikation b Verfahren zur Validierung der Sicherheitsfunktionen c Verfahren zur Validierung der Sicherheitsintegrität d Berücksichtigung der Testumgebung e Verfahren zur Testauswertung (mit Begründung) f Testverfahren und Leistungsmerkmale zum Nachweis der elektromagnetischen Störfestigkeit g Richtlinien zur Auflösung bei fehlgeschlagener Validierung Integration nach Entwurf und Test nach spezifizierten Integrationstests Ziel der Systemtests Integration von Hardware und Software Dokumentation von Testergebnissen Änderungen während der Integration und Prüfung Umfang der Testdokumentation Maßnahmen und Techniken zur Vermeidung von Fehlern bei der E/E/PES Integration Übereinstimmung der Validierung mit einem Validierungsplan Kalibrierung der Testumgebung Prüfung aller Sicherheitsfunktionen und aller Verfahren für Betrieb und Wartung Umfang der Sicherheitsvalidierungsdokumentation Dokumentation von Abweichungen Verfügbarkeit der Validierungsergebnisse für Entwickler der kontrollierten Geräte und des Kontrollsystems für kontrollierte Geräte Maßnahmen und Techniken zur Vermeidung von Fehlern bei der E/E/PES Sicherheitsvalidierung Planung und Dokumentation der Verifikation Version 1.0 Seite 20 von 31

62 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Die Verifikationsplanung soll sich auf alle genutzten Argumente, Techniken und Werkzeuge beziehen Spezifikation aller Aktivitäten zur Sicherstellung der Konsistenz zu Produkten und Normen der Phaseneingabe Umfang der Verifikationsplanung Nachweis der Anforderungen der Funktions- und Sicherheitsintegrität Dokumentation der Verifikationsergebnisse Eignung und Widerspruchsfreiheit von Sicherheitsanforderungen Qualitätsmerkmale für Entwurf, Entwicklung und Tests Verifikation der Integration von sicherheitsgerichteten Systemen Dokumentation von Testfällen Sicherheitsbegründung System-/Teilsystem-/Einrichtungsübergabe Betrieb und Instandhaltung Vorbereitung von Verfahren für Betrieb und Wartung Kontinuierliche Aktualisierung der Verfahren für Betrieb und Wartung Systematisch Bestimmung von Routine-Wartungsarbeiten Bewertung von Verfahren für Betrieb und Wartung auf die kontrollierten Geräte Maßnahmen und Techniken zur Vermeidung von Fehlern bei Verfahren für Betrieb und Wartung Stilllegung und Entsorgung Nachweis der funktionalen und technischen Sicherheit Einleitung Nachweis des korrekten funktionalen Verhaltens Ausfallauswirkungen Reaktion bei Fehleroffenbarung in Subsystemen mit Fehlertoleranz Reaktion bei Fehleroffenbarung in Subsystemen ohne Fehlertoleranz bei niedriger Anforderungsrate Reaktion bei Fehleroffenbarung in Subsystemen ohne Fehlertoleranz bei hoher Anforderungsrate oder kontinuierlicher Anforderung Betrieb mit externen Einflüssen d Extreme Umweltbedingungen e Elektromagnetische Störfestigkeit Version 1.0 Seite 21 von 31

63 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Sicherheitsbezogene Anwendungsbedingungen Sicherheitserprobung Sicherheitsanerkennung und -zulassung Sicherheitszulassungsverfahren Nach der Sicherheitszulassung Umfang der Dokumentation bei Änderungsaktivitäten Unterhaltung eines Systems zur Auslösung von Änderungen Beibehaltung des Kompetenz-, Automatisierungs-, Planungs- und Managementgrades bei Änderungen Wiederholungs-Verifizierung und -Validierung Abhängigkeiten zwischen Sicherheitszulassungen Software Hier werden im Wesentlichen die Bedingungen der Industrienorm IEC mit den Bedingungen der Bahnnorm EN verglichen. An den Stellen, an denen die Bereiche von IEC bzw. EN verlassen werden, wird dies ausdrücklich angegeben Dokumentation und Management Da die Anforderungen zu dem Thema auf die Teile 1 und 3 der Industrienorm aufgeteilt sind, findet hier eine gemeinsame Diskussion dieser Teile statt. Die Bezüge werden daher um T1 (Teil 1) bzw. T3 (Teil 3) ergänzt. Industrienorm T Informationen für Lebenszyklusphasen T c Angewendete Lebenszyklusphasen T Lebenszyklusmodell für Softwareentwicklung T Integration von Qualitäts- und Sicherheitsmanagement in das Lebenszyklusmodell T Anpassung von Phasen T Organisation des Softwareprojekts T Ergebnisdokumentation T Wiederholung von Phasen T Aufteilung der Phasen in Aktivitäten T Techniken und Maßnahmen der Phasen T Begründung von Abweichungen in den Bestimmungen der Industrienorm T Ausreichende Verfügbarkeit T Qualitative Anforderungen an Form und Inhalt T Titel, Bezeichner, Index-Organisation T Versionierung T Recherche, Identifikation aktueller Versionen T Aufgaben des Softwarekonfigurationsmanagements T Sektor- und firmenspezifische Arbeitsweisen T Änderungswesen und Qualitätssicherung T a Grundsätze und Strategien zur Erreichung funktionaler Sicherheit Bahnnorm Lebenszyklusmodell für Software-Entwicklung Definition von Aktivitäten einer Phase Geeignete Form für Handhabung, Bearbeitung und Aufbewahrung Struktur für fortlaufende Erweiterung Verfolgbarkeit und Konsistenz Dokumentationsumfang Parallele Durchführung von Qualitätssicherungsverfahren Version 1.0 Seite 22 von 31

64 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm T b Identifikation verantwortlicher Personen, Abteilungen und Organisationen T Informationen zum Management der funktionalen Sicherheit T Informationen zur Durchführung der Bewertung der funktionalen Sicherheit T d Umfang und Struktur der Dokumentation T e Ausgewählte Maßnahmen und Techniken zur Erreichung der Anforderungen von Bestimmungen T f Aktivitäten zu Bewertung der funktionalen Sicherheit T g Verfahren zur Verfolgung von Empfehlungen aus Analyse- und Managementaktivitäten T h Verfahren zur Ermittlung des Schulungsbedarfs T i Verfahren zur Analyse von Gefahrensituationen T j Verfahren zur Analyse der Betriebs- und Wartungsleistung T k Anforderungen für regelmäßige Überprüfungen der funktionalen Sicherheit T l Verfahren zur Einleitung von Änderung an dem sicherheitsgerichteten System T m Notwendige Verfahren und Behörden für die Genehmigung von Änderungen T n Verfahren zum Erhalt korrekter Informationen zu möglichen Gefahren und sicherheitsgerichteten Systemen T o Verfahren zum Konfigurationsmanagement T p Versorgung, Training und Information von Notfalldiensten T Implementation und Überwachung der Aktivitäten aus T T Formale Prüfung durch und Zustimmung von allen betroffenen Organisationen T Information von Management und Funktionsträgern T Übertragung auf Zulieferer T Es gelten die Anforderungen aus T1.6.2 T Planung der funktionalen Sicherheit definiert Strategien für Software-Belange Tabelle 17: Vergleich von Software Softwareanforderungsspezifikation Industrienorm Keine Wiederholung der Softwareanforderungsspezifikation Bahnnorm Ernennung eines unabhängigen Gutachters Autorität des Gutachters Unabhängigkeit beteiligter Gruppen Verantwortliche Parteien Organisation des Gutachters Beschreibung der Verifikationsschritte und Verifikationsberichte Umfang der Dokumentation nach DCRT Kombination von Dokumenten Dokumenten-Cross-Referenz-Tabelle Ausbildung, Erfahrung und Qualifikation Begründung der Ausbildung, Erfahrung und Qualifikation Umfang der Begründung für Ausbildung, Erfahrung und Qualifikation Umsetzung ISO Sicherheitsorganisation Bahnnorm Version 1.0 Seite 23 von 31

65 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Ableitung der Softwareanforderungsspezifikation Detailgrad der Softwareanforderungsspezifikation Review der Softwareanforderungsspezifikation Verfahren zur Lösung von Unstimmigkeiten bei der Zuweisung von Sicherheitsintegrationsstufen Qualitätsmerkmale der Softwareanforderungsspezifikation Spezifikation der Betriebsmodi der kontrollierten Geräte Spezifikation von Sicherheitsbedingungen zwischen Hardware und Software Berücksichtigung von Überwachungs- und Testfunktionen Identifikation von Nicht-Sicherheitsfunktionen Spezifikation der Sicherheitseigenschaften des Produkts Tabelle 18: Vergleich der Software Softwaredesign und -entwicklung Industrienorm Aufteilung der Verantwortung für Designkonformität Eigenschaften der Designmethode Bahnnorm Softwareanforderungsspezifikation für Eigenschaften der Software Schnittstellenspezifikation Qualitätsmerkmale der Softwareanforderungsspezifikation Verständlichkeit der Softwareanforderungsspezifikation Verfolgbarkeit von Anforderungen Umgang mit nicht-verfolgtem Material Darstellung relevanter Betriebsarten Identifikation und Beschreibung von Zwangsbedingungen zwischen Hardware und Software Hinweis auf Umfang von Software-Selbsttests und Hardware-Prüfungen Periodisches Testen von Funktionen Tests von Sicherheitsfunktionen im Betrieb Kennzeichnung von Funktionen ohne Sicherheitsanforderung Beschreibung von relevanten Verhaltensweisen, insbesondere Ausfallverhalten Kennzeichnung von Funktionen zur Erreichung der System-Sicherheitsanforderungsstufe Ableitung einer Software-Anforderungstestspezifikation Testfälle für Software-Anforderungstestspezifikation Bahnnorm Möglichst einfache Umsetzung der Software- Anforderungsspezifikation Festlegung der Strategie für die Softwareentwicklung Merkmale des gewählten Entwurfsverfahren Bildung eines integrierten Satzes von Techniken und Maßnahmen für Software-Anforderungsspezifikation Berücksichtigung von Test- und Wartungsfreundlichkeit Designmethode soll Änderungen erleichtern Eigenschaften zur Erleiterung der Softwarewartung Eindeutigkeit der Darstellungsnotation Detaillierte Beschreibung in der Software- Architekturspezifikation Bedeutung der Wechselwirkungen zwischen Minimierung des sicherheitsrelevanten Anteils Hardware und Software Minimierung des sicherheitsrelevanten Anteils Minimierung von Umfang und Komplexität Version 1.0 Seite 24 von 31

66 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Gemeinsame Implementierung von Sicherheits- und Nicht-Sicherheits-Funktionen Sicherheitsintegrationsstufe bei unterschiedlichen Sicherheitsfunktionen Diagnostische Prüfungen Selbsttests Standard- oder vorher entwickelte Software Gültigkeit für Daten Aufteilung der Verantwortung für Designkonformität Umfang der Entwurfsdokumentation Berücksichtigung von Änderungen der Sicherheitsanforderungen Aufteilung der Verantwortung für Werkzeugkonformität Auswahl von Werkzeugen und Programmiersprachen Bahnnorm Software aus Teilen unterschiedlicher Software- Anforderungsstufe Begründung der Abwägung zwischen fehlervermeidenden und fehlerbeherrschenden Strategien Einschränkungen für die Verwendung von COTS-Software Einsatz von vorher entwickelter Software Bevorzugung von nach Norm entwickelter Software Umfang der Software-Designspezifikation Umfang der Software-Modulspezifikation Angemessene Auswahl von Werkzeugen Automatische Testwerkzeuge und Integrierte Entwicklungswerkzeuge Eigenschaften der ausgewählten Programmiersprache ausgewählten Programmiersprache Merkmale für Compiler oder Übersetzer der Anforderungen an die ausgewählte Programmiersprache Begründung für alternative Programmiersprachche Begründung für alternative Programmierspra Verwendung von Codierstandards Entwicklung und Verwendung von Codierstandards Eigenschaften der Codierstandards und Eigenschaften der Codierstandards und Quellcodedokumentation Quellcodedokumentation Aufteilung der Verantwortung für Detailentwurf-Konformität Voraussetzungen für Detailentwurf Voraussetzungen für den Entwurfsprozess Modulare, testbare und wartungsfreundliche Software Zerlegung der Softwarearchitektur Identifikation aller Softwarekomponenten Software-Entwurf basiert auf Zerlegung in Module Spezifikation von Software-Modultests Inhalt des Software-Integrationsplans Spezifikation geeigneter Software-Systemintegrationstests Qualitative Anforderungen an den Quellcode Jedes Software-Modul muss lesbar, verständlich und testbar sein Review von Softwaremodulen Test von Softwaremodulen Verifikation der Software-Modulentwurfsspezifikation Ziele von Softwaremodultests Dokumentation von Softwaremodultestergebnissen Verfahren zur Korrektur bei fehlgeschlagenen Tests Planung von Software-Integrationstests Inhalt von Software-Integrationstests Integration von Software-Modulen Durchführung von Software-Integrationstests Version 1.0 Seite 25 von 31

67 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Dokumentation der Software-Integrationstestergebisse Durchführung einer Auswirkungsanalyse Tabelle 19: Vergleich von Software Software/Hardwareintegration Industrienorm Spezifikation von Integrationstests Bahnnorm Erstellung eines Software-Integrationstestberichts Verfolgbarkeit von Anforderungen und Entwurfsobjekten Bahnnorm Software/Hardwareintegration Erstellung eines Software/Hardware- Integrationstestplans Inhalt des Integrationstestplans Inhalt von Integrationstests für programmierbare Elektronik Unterscheidung von Aktivitäten, die im Werk Unterscheidung von Aktivitäten, die beim Hersteller oder beim Betreiber durchgeführt werden oder beim Kunden durchgeführt werden Einsatzszenarien für Integrationstests Unterscheidung zwischen Portierung und Systemintegration Fertigstellungstermin für Werkzeuge und Hilfsmittel Verwendung der Integrationstest für die Software Durchführung einer Auswirkungsanalyse Durchführung einer Auswirkungsanalyse Dokumentation von Testfällen und Ergebnissen Dokumentation der Integrationstests; Notwendige Wiederholungsprüfungen bei Änderungen Tabelle 20: Vergleich von Software Planung und Durchführung der Software-Validierung Aufzeichnung von Testfällen Erstellung eines Software/Hardware- Integrationstestberichts Industrienorm Bahnnorm Ziele der Software-Validierungsplanung Erstellung eines Software-Validierungsplans Test gegen Software-Anforderungstestspezifikation Inhalt der Software-Validierungsplanung Inhalt des Software-Validierungsplans Nachbildung von Eingangssignalen bei unterschiedlichen Bedingungen Technische Strategie der Software Zusammenfassung der Validierungsstrategie Validierungsplanung Review der Software-Validierungsplanung Bewertung des Software-Validierungsplans Abstimmung des Software-Validierungsplans Umfang der Erfüllungs- und Ausfallkriterien Keine Wiederholung der Software- Validierung Ausführung der Validierung nach Planung Dokumentation der Ergebnisse der Validierung Dokumentation der Validierungsergebnisse Umfang der Dokumentation für Sicherheitsfunktionen Identität und Konfiguration von Gegenständen Umfang der Validierungsergebnisse der Validierung Dokumentation der Maßnahmen bei Abweichungen Dokumentation gefundener Mängel Anforderungen an die Validierung von sicherheitsgerichteter Software Ergänzende Aktivitäten der Validierung Hauptaktivitäten der Validierung Fähigkeiten von Softwarewerkzeugen Eignung von Softwarewerkzeugen Anforderungen an Validierungsergebnisse Version 1.0 Seite 26 von 31

68 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Tabelle 21: Vergleich von Software Software-Wartung Industrienorm Verfügen von Verfahren zur Softwaremodifikation Bahnnorm Ausführung nach ISO Berücksichtigung von Wartbarkeit beim Entwurf Aufstellen von Verfahren zur Software- Wartung Auslösung durch formalen Änderungsantrag Auditierung von Wartungsaktivitäten Verwendung der Projektumgebung aus der Entwicklung Anwendung auf Altsysteme Handhabung der Software-Qualitätssicherung Inhalt der Sicherheitsplanung Durchführung der Änderung Durchführung einer Auswirkungsanalyse Dokumentation der Auswirkungsanalyse Wiederholung geeigneter Lebenszyklusphasen Dokumentation der Änderung Dokumentation der Änderungsdetails Bewertung der Modifikation Tabelle 22: Vergleich von Software Software-Verifikation Software-Wartungsaufzeichnungen Software-Änderungsbericht Industrienorm Bahnnorm Planung der Software-Verifikation Erstellung eines Software-Verifikationsplans Umfang der Planung der Software Beschreibung von Kriterien, Techniken und Verifikation Werkzeugen für den Verifikationsprozess Inhalt des Software-Verifikationsplans Durchführung der Software-Verifikation nach Plan Dokumentation/Nachweis von Phasenabschlüssetung von Korrektheit und Konsistenz Beschreibung von Aktivitäten zur Gewährleis Dokumentation der Software-Verifikation Dokumentation der Ergebnisse der Verifikation Erstellung von Verifikationsberichten Verifikation wesentlicher Informationen der Phasenübergänge Verifikationsaktivitäten Nachweis der Anforderungen an Funktion, Zuverlässigkeit, Leistung und Sicherheit Verifikation der Software-Sicherheits Verifikation der Software-Anforderungs- anforderungen Verifikation der Software-Architektur Verifikation des Software-Systemdesigns Verifikation der Software-Moduldesignverifikation spezifikation Verifikation der Software-Architektur- und Entwurfsspezifikation Quellcodeverifikation Verifikation des Software-Quellcode Datenverifikation 17 Anwendungsspezifisch konfigurierbare Systeme Durchführung von unabhängiger Stelle Nicht vollständig dokumentierte Tests Tabelle 23: Vergleich von Software Software-Begutachtung Bzgl. der Anforderungen der Industrienorm wird auf Teil 1 verwiesen. Die Bezüge der Industrienorm beziehen sich hier also ohne die Verwendung eines bestimmten Präfixes auf EN Version 1.0 Seite 27 von 31

69 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Berufung zur Bewertung der funktionalen Sicherheit Unabhängigkeit der Sicherheitsbewertung Hinweise zur Unabhängigkeit der Sicherheitsbewertung Hinweise zur Unabhängigkeit der Sicherheitsbewertung Zugriff auf Personen, Informationen und Ausrüstung Sicherheitsbewertung aller Phasen des Lebens- Bahnnorm Spezialfall für Software der Sicherheitsanforderungsstufe Berücksichtigung vorhandener Gutachten Unabhängige Begutachtung der Software Zugang zum Entwurfs- und Entwicklungsprozess und zu allen Projektunterlagen Entscheidung über Verfahren des Software- Lebenszyklus zyklus Ausführung der Sicherheitsbewertung Sicherheitsbewertung von Werkzeugen Berücksichtigung vorheriger Sicherheitsbewertungen, Pläne und Empfehlungen Planung einer konsistenten Sicherheitsbewertung Inhalt der Planung der Sicherheitsbewertung Genehmigung der Planung der Sicherheitsbewertung Abschluss der Sicherheitsbewertung Feststellung des Gutachters Sachkundige Sicherheitsbewertung Zustimmung zu Geltungsbereich und Inhalt des Software-Validierungsplans Zusätzliche Verifikations- und Validierungsschritte Ergebnisbericht jeder Begutachtung Abschließendes Software-Gutachten Keine Angabe technischer Lösungen bei Mängeln Tabelle 24: Vergleich von Software Sicherheitsnachweis Einer der grundlegenden Unterschiede beider Normen ist das Dokument des Sicherheitsnachweises. Dieser wird nach CENELEC als das Dokument gefordert, dass zusammenfassend den gesamten Prozess dokumentiert. In der IEC ist dieses Dokument nicht in dieser Form explizit gefordert. In diesem Abschnitt werden speziell die Anforderungen an den Sicherheitsnachweis verglichen Erstellung Die Bahnnorm sieht die Erstellung eines Anwendungs-Sicherheitsnachweises in der Phase 9 System- Validierung vor (vgl. EN 50126, ). In der Industrienorm wird entsprechend in der Phase 13 Validierung der gesamten Sicherheit die Dokumentation der Sicherheitsvalidierung vorgesehen (vgl. IEC , ). Zusätzlich ist in der Phase 9.2 des Software-Sicherheitslebenszyklus die Planung der Software-Validierung vorgesehen (vgl. IEC , ) Inhalt Industrienorm Plan: Zeitpunkt der Validierung Plan: Durchführende der Validierung Plan: Identifikation relevanter Betriebsmodi der kontrollierten Geräte Bahnnorm Systemüberblick Version 1.0 Seite 28 von 31

70 Vergleich der Zulassungsbedingungen IEC CENELEC Vergleich der Zulassungsbedingungen IEC CENELEC Industrienorm Plan: Identifikation sicherheitsgerichteter Software Plan: Technische Strategie der Validierung Plan: Maßnahmen und Verfahren der Validierung Plan: Verweise auf spezifische Software-Sicherheitsanforderungen Plan: Erforderliche Testumgebung Plan: Erfolgs- und Ausfallkriterien Plan: Richtlinien und Verfahren zur Bewertung der Validierungsergebnisse, speziell von Ausfällen Bericht: Chronologische Dokumentation der Validierungsaktivitäten Bericht: Version der Gesamt- Sicherheitsanforderungsspezifikation Bericht: Validierte Sicherheitsfunktion und Art der Untersuchung (Analyse oder Test) Bericht: Verwendete Werkzeuge und Ausrüstung inkl. Kalibrierungsdaten Bericht: Ergebnis der Validierungsaktivitäten Bericht: Konfigurationsidentifikation des untersuchten Gegenstandes, der angewendeten Validierungsverfahren und der Testumgebung Bericht: Abweichungen zwischen erwarteten und tatsächlichen Ergebnissen Tabelle 25: Vergleich des Inhalts des Sicherheitsnachweises Bahnnorm Zusammenfassung der Sicherheitsbewertung und der Sicherheitsaudits Übersicht über die Sicherheits-Engineering-Techniken Zusammenfassung der Kontrollen des Qualitäts- und Sicherheitsmanagements Zusammenfassung oder Bezug auf die Sicherheitsanforderungen Zusammenfassung der Aufgaben zur Sicherheitsanalyse Nachweis der Erfüllung der Sicherheitsanforderungen Zusammenfassung aller Beschränkungen und Zwänge Der Vergleich zeigt, dass der Inhalt des Sicherheitsnachweises nach der Bahnnorm einen deutlich abstrakteren Charakter hat. Auf eine konkrete Dokumentenstruktur geht die Industrienorm gar nicht ein. Es ist aber anzunehmen, dass zumindest ein Plan und ein Bericht zu erstellen sind. Version 1.0 Seite 29 von 31

71 Vergleich der Zulassungsbedingungen IEC CENELEC Ausblick und Zusammenfassung 3 Ausblick und Zusammenfassung 3.1 Ziele und Schwerpunkte des Berichts Dieser Bericht ist in erster Linie als Hilfestellung für mögliche gemeinsame oder ergänzende Zulassungsprozesse gedacht. Der Schwerpunkt lag auf den formulierten Anforderungen der Normenwerke und einer tabellarischen Darstellung. Die Vergleichstabellen können als Index und Orientierungshilfe bei weiteren Ergänzungs- oder Forschungsvorhaben dienen. 3.2 Allgemeine Anforderungen Lebenszyklen Beide Normenwerke erlauben eine Anpassung der Lebenszyklusphasen (IEC , ; EN 50126, a), erwarten aber eine grundsätzliche Übereinstimmung mit den übrigen Zielen der Norm. Wird ein, zu beiden Normenwerken kompatibler, Lebenszyklus gesucht, dürfte dies am leichtesten nachzuweisen sein, wenn eine Verfeinerung der Zyklusphasen angestrebt wird. Mit Hilfe von Tabelle 5 kann man sehen, dass es ausreicht, lediglich die jeweils feinere Aufteilung der entsprechenden Lebenszyklen für bestimmte Phasen auszuwählen Dokumentation, Management und RAMS Die Industrienorm benennt nur wenige Dokumente und spricht eher allgemein von z.b. Planung oder Dokumentation. Daher ist es für eine kompatible Verwendung hier vermutlich sinnvoll, die Bezeichnungen aus der Bahnnorm zu übernehmen. Ebenso finden sich nur hier ausdrückliche Bezüge zu RAMS, so dass auch hier die Bahnnormen ausschlaggebend sind. 3.3 System und Hardware Hier kann man anhand der fehlenden Zuordnung aus der Industrienorm sehen, an welchen Stellen die Nachweisführung im Sinne der Bahnnorm ergänzt werden muss. Die Darstellung in ist tatsächlich nur für eine Abbildung in Richtung der Bahnnorm geeignet. Für eine Zuordnung in Richtung der Industrienorm müsste eine Kapitelnummerierung entsprechend der Industrienorm aufgebaut werden. 3.4 Software Bei der Betrachtung der Vergleichstabellen sieht man hier streckenweise große Übereinstimmungen, und nur wenige, isolierte Schwerpunkte. Im Sinne einer gemeinsamen Nachweisstruktur, wäre es sinnvoll, hier die Anforderungen beider Normen zu erfüllen und strukturell Themen aus beiden Normwerken einzugliedern. Version 1.0 Seite 30 von 31

72 Vergleich der Zulassungsbedingungen IEC CENELEC Anhang 4 Anhang 4.1 Anhang 1: Referenzen IN BN6 BN8 BN9 SSE ESS Functional safety of electrical/electronic/programmable electronic safety-related systems; Französisch/Englische Fassung CEI/IEC :1998, :2000, :1998, :1998, :1998, :2000, :2000 Bahnanwendungen Spezifikation und Nachweis der Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit und Sicherheit (RAMS); Deutsche Fassung EN 50126:1999 Bahnanwendungen Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme Software für Eisenbahnsteuerungs- und Überwachungssysteme; Deutsche Fassung EN 50128:2001 Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme - Sicherheitsrelevante elektronische Systeme für Signaltechnik; Deutsche Fassung EN 50129:2003 TÜV-Präsentation SPS für den sicherheitsgerichteten Einsatz in der Bahntechnik 5_SPS_für_den_sicherheitsgerichteten_Einsatz.pdf, Version von Josef Börcsök; Elektronische Sicherheitssysteme Hardwarekonzepte, Modelle und Berechnung; Hüthig, Anhang 2: Abkürzungen Abk. Langform / Erläuterung EBA Eisenbahn Bundesamt EN Europäische Norm ESTW Elektronisches Stellwerk FRACAS Failure reporting, analysis and corrective action system GA Generische Applikation HR Hazard Rate IEC International Electrotechnical Commission ISO International Organization for Standardization LST Leit- und Sicherungstechnik PFH Probability of a dangerous Failure per Hour RAMS Reliability Availability, Maintainability, Safety SA Spezifische Applikation SIL Sicherheitsintegritätslevel SPS Speicherprogrammierbare Steuerung THR Tolerierbare Hazard-Rate TÜV Technischer Überwachungsverein Version 1.0 Seite 31 von 31

73 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Teilbericht AP 2300 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

74 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Änderungsverfolgung Datum Bearbeiter Version Inhalt Antje M. Möller-Neustock 0.1 Erstausgabe Vorlage der Anforderungen an alle Verteiler, zur Diskussion und Festlegung des Funktionsumfangs Antje M. Möller-Neustock 0.2 Detaillierung Antje M. Möller-Neustock 0.3 Konzeptdetaillierung Antje M. Möller-Neustock 0.4 Prototyp-Screenshots Antje M. Möller-Neustock 0.5 Fertigstellung theoretische Analyse Gefährdungslogbuch Antje M. Möller-Neustock 0.6 Erstellung Draft-Version zum Review Antje M. Möller-Neustock 0.7 Review und Abschluss Antje M. Möller-Neustock 0.8 Formales Review Matthias Grimm 0.9 Übernahme Ergebnisbericht: Kapitel Konzepte der Nachweisführung Holger Neustock Klaus-Dieter Winkler 1.0 Finalisierung Inhaltsverzeichnis 1 Zielstellung Ausgangssituation Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Konzepte der Nachweisführung Risikoanalyse, Gefährdungsbeherrschung und Risikoakzeptanzkriterien Risikoanalyse und Gefährdungsbeherrschung im Luftverkehr Risikoanalyse und Gefährdungsbeherrschung im Schienenverkehr Sicherheitsnachweisführung Common Cause Analysis Event Tree Analysis Fault Tree Analysis Failure-Mode- and Effect-Analysis Failure-Mode-, Effect- and Criticality-Analysis Hazard and Operability Study Markov-Analyse Preliminary Hazard Analysis Sicherheitskonzept Functional Hazard Assessment Preliminary System Safety Assessment System Safety Assessment Fazit zur Verfahrensübersicht Evaluierung eines ALM-Werkzeuges für die Prozesse der Nachweisführung Grundlegende Betrachtung Vorschlag für einen ALM-Workflow zur Nachweisführung von Änderungen Sonderfall: COTS-Betrachtung Verwaltung eines Gefährdungslogbuchs...45 Version: 1.0 Seite 2 von 51

75 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Ergebnis der Evaluierung Zusammenfassung und Ausblick Anhang Abkürzungen...49 Abbildungs- und Tabellenverzeichnis Abbildung 1: Wechselwirkung zwischen Sicherheits- und Entwicklungsprozess in der Luftfahrt (nach [KNE2001]) Abbildung 2: Bestimmung und Zuteilung der SIL-Anforderungen(nach [DIN EN 50129]) Abbildung 3: Bereiche des ALARP-Prinzips (nach [RSS2007]) Abbildung 4: Akzeptiertes individuelles Risiko in Abhängigkeit von Todesfällen (nach [MIE2004]). 17 Abbildung 5: Abfolge der zu bearbeitenden Schritte einer CCA (nach [SSS1997]) Abbildung 6: ETA-Graph mit binären Entscheidungen (nach [SSS1997]) Abbildung 7: Auswahl der wichtigsten Symbole für FTA-Graphen (nach [VES1981 und SSS1997]). 21 Abbildung 8: FTA-Graph Abbildung 9: Gitternetz für die Bewertung der Ausfallbedeutung Abbildung 10: Ablauf des HAZOP-Prozesses Abbildung 11: Verwendete Zeichen in einem Markov-Graphen Abbildung 12: Markov-Graph Abbildung 13: Fortpflanzung der Auswirkungen eines Versagens (nach WIK1998]) Abbildung 14: RAMS-Prozess Abbildung 15: möglicher Workflow einer FMEA-Umsetzung innerhalb eines ALM-Tools Abbildung 16: Anlegen eines Projekts Abbildung 17: Definition von Rollen Abbildung 18: Definition der Aktivitäten gemäß Phasenmodell Abbildung 19: FMEA-Workflow Abbildung 20: tabellarische Darstellung von Systemanforderungen Abbildung 21: Definition einer Gefährdung Abbildung 22: Generierung einer Verlinkung Risk zu Anforderung Abbildung 23: Darstellung der Verlinkung im Work-Item Abbildung 24: Auszug aus den Daten einer Gefährdung mit Definition einer Aktion Abbildung 25: Ableitung einer Hardware-Anforderung aus einer Aktion Abbildung 26: Übersicht über die Status der Gefährdungen Abbildung 27: Definition COTS Abbildung 28: Deklaration des COTS-Produkts als "Nicht-sichere-Komponente" Abbildung 29: Historie eines Work-Items Abbildung 30: Change Request für ein COTS- Bauteil Abbildung 31: Verlinkung Suspect Abbildung 32: Verlinkung suspect beim Objekt Version: 1.0 Seite 3 von 51

76 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 33: Definition von Work-Item Types Tabelle 1: Gegenüberstellung von THR und SIL (nach [DIN EN 50129]) Tabelle 2: Beschreibung der ALARP-Risikobereiche (nach [AKB2004-1]) Tabelle 3: Auflistung der beschriebenen Verfahren Tabelle 4: Versagensklassen und die zugehörigen DAL-Werte (nach [ARP 4754]) Tabelle 5: Übersicht der beschriebenen Verfahren Version: 1.0 Seite 4 von 51

77 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Zielstellung 1 Zielstellung Mobilität und Verkehr sind zentrale Bestandteile unserer Wirtschafts- und Gesellschaftsordnung. Sie beeinflussen entscheidend die Lebensqualität sowie die Leistungs- und Wettbewerbsfähigkeit der Wirtschaft. Im Fokus des vom BMWi geförderten Projekts NeGSt (Neue Generation Signaltechnik) steht der Schienenverkehr. Er wird als besonders umweltfreundlich eingestuft und spielt eine entscheidende Rolle, um zukünftig die Verlagerung des Verkehrs von der Straße auf andere Verkehrsträger zu stärken. Eine erfolgreiche Verlagerung auf die Schiene setzt jedoch eine leistungsfähige, sichere und zuverlässige Eisenbahninfrastruktur voraus. Dies gilt insbesondere für die Eisenbahn-Leit- und -Sicherungstechnik (LST), die sich einer Vielzahl an wirtschaftlichen und technischen Herausforderungen gegenüber sieht. Ziel des Projektes NeGSt ist es, für drängende Herausforderungen, die für den gesamten deutschen Sektor von Bedeutung sind, Lösungen zu entwickeln, die zur Sicherung der Zukunftsfähigkeit der LST beitragen und somit Mobilität und Verkehr nachhaltig attraktiver und wettbewerbsfähiger gestalten. Insbesondere soll eine einheitliche Vorgehensweise bzgl. der Nachweisführung und Zulassung erstellt werden, die von den beteiligten Instanzen akzeptiert wird. Dazu sollen u.a. Maßnahmen ausgearbeitet werden, die eine einheitliche, verbindliche Anwendung von Normen beschreiben und eine einheitliche Prozesskette darstellen. Die Identifizierung und Beschreibung der Problemstellungen für Unterschiede und Gemeinsamkeiten bei der Zulassung von Systemen nach unterschiedlichen Normen bildet dabei einen Schwerpunkt. Einerseits müssen die Belange der übergeordneten Industrienormen IEC beachtet werden, die wiederum in spezifischen Normen einzelnen Industriezweige, hier die CENELEC-Normreihe für den schienengebundenen Verkehr, münden. Dabei ist festzustellen, dass die Vererbung der einzelnen Normen nicht einheitlich erfolgt. Dies führte auch in der Vergangenheit dazu, dass eine gegenseitige Akzeptanz von Zulassungen nach den einzelnen Normen nicht oder nur sehr schwer zu erreichen war. Eine differenzierte Betrachtung der Unterschiede dieser Normen erfolgt in einem separaten Ergebnisbericht "Vergleich der Zulassungsbedingungen IEC CENELEC". In diesem Teilbericht soll die Möglichkeit der Übertragung von Zulassungen evaluiert werden und somit aufgezeigt werden, wie zumindest Teilaspekte der Zulassungsdokumente für eine neue Zulassung übernommen werden können. Darüber hinaus besteht der Trend, die sogenannten COTS (Commercial off-the-shelf) -Produkte, die entsprechend dem Stand der Technik oder der Industrienormen entwickelt worden sind, übergeordnet in Sicherheitssysteme unterschiedlicher Thematik, sei es in medizinischen, in militärischen oder auch in verkehrstechnischen Systemen, einzusetzen, um die Kosten der Zulassung zu minimieren sowie die Entwicklungszeit dieser komplexen Systeme zu verkürzen. In der Arbeitsgruppe "Umgang mit Komponenten nach IEC (COTS) / Hybriden" soll analysiert werden, wie eine einheitliche Prozesskette aufgesetzt werden muss, die die Aspekte der Sicherheit berücksichtigt und welche Aspekte bzgl. der Nachweisführung dabei zu beachten sind. Zusätzlich sollen die Randbedingungen, die sich durch den Einsatz von COTS-Komponenten evtl. bei der Umsetzung dieser Prozesskette ergeben können, dargelegt werden. Der Schwerpunkt dieses Ergebnisberichts ist die konzeptionelle Betrachtung einer einheitlichen Prozesskette in Hinblick auf Sicherheitsaspekte (Gefährdungsanalyse / Sicherheitskonzept / Fehlerbaumanalyse / FMEA / ) und somit ein Ansatz für eine firmenübergreifende Strategie einer Nachweisführung. Dabei werden Aspekte der Teststrategie prototypisch umgesetzt. Mit diesem Ergebnisbericht stellt die Arbeitsgruppe den Sachverhalt einer einheitlichen Prozesskette des Sicherheitsmanagement-Prozesses dar, unterbreitet sie einen Vorschlag zur Umsetzung und zeigt die Möglichkeiten der Implementation einer einfachen Nachweisführung anhand eines standardisierten Application Lifecycle Management (ALM)-Tools. Version: 1.0 Seite 5 von 51

78 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Zielstellung COTS-Produkte unterliegen einer höheren Obsoleszenz, so dass nur ein straffes Obsoleszenz- Management eine vereinfachte Zulassung nach einem Austausch von Teilkomponenten ermöglicht. Es wird darüber hinaus gezeigt, dass innerhalb des Sicherheitsmanagement-Prozesses besondere Aspekte der Kapselung der COTS-Produkte administriert werden müssen. Version: 1.0 Seite 6 von 51

79 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Ausgangssituation 2 Ausgangssituation Das Zulassungsverfahren beinhaltet als ein Schwerpunktthema die Nachweisführung der Sicherheit und der Sicherheitsziele. Die Definitionen dieser Sicherheit und der Sicherheitsziele hängen dabei stark von den einzelnen technischen Komponenten sowie der Software-technischen Architektur ab, so dass die Nachweisführung in der Regel firmenspezifisch umgesetzt wird, teilweise sogar produktspezifisch. Jedoch kann anhand der CENELEC-Normenreihe erkannt werden, dass bestimmte Methoden bei der Bearbeitung der Nachweisführung der Sicherheit empfohlen oder vorgeschrieben werden und somit je nach Auswahl einheitlich angewandt werden können. Im Folgenden wird die Sicht der Hersteller dargelegt. Eine Diskussion der vorausgehenden Sicherheitsbetrachtungen durch den Betreiber wird nicht aufgenommen, da diese Verfahren der Risikobewertung hinlänglich bei den jeweiligen Betreiber umgesetzt sind und besondere Aspekte, die beachtet werden müssen, in dem Ergebnisberichten CSM-VO (z.b. [NeGSt_CSM]) dargelegt werden. Als Basis für eine Prozessbeschreibung werden exemplarisch folgende Aspekte der CENELEC- Normenreihe genannt. Diese Beispiele verdeutlichen die allgemeinen Aspekte, die unabhängig vom System, Subsystem bzw. von Komponenten zu betrachten sind: DIN EN 50126:1999, Kapitel RAMS-Politik: Darlegung der Strategie von der Umsetzung von funktionalen Anforderungen und unterstützende Leistungsanforderungen einschließlich einer Definition sicherheitsrelevanter funktionaler Anforderungen und Anforderungen für die Einhaltung der Safety Integrity für jede Sicherheitsfunktion. Diese RAMS-Politik wird in vielen Fällen im Sicherheitskonzept beschrieben. Zusätzlich wird die Leistungsfähigkeit des Systems und dessen Abgrenzung definiert und spezielle sicherheitsbezogene Anwendungsbedingungen für die Umsysteme entworfen. RAMS-Programm: Planungen der jeweiligen Techniken/Maßnahmen, die bezogen auf das betrachtete System beachtet werden müssen. Hier werden Techniken bestimmt und ihre Einsatzmöglichkeit auf eine Entwicklung einer Generischen Applikation (GA) bzw. eines Generischen Produkts (GP) und ihre Anwendung während der verschiedenen Phasen innerhalb des Produkterstellungsprozesses festgelegt, z. B. A.4.2 Gefährdungsbeherrschung der COTS, Ursachenanalyse, Common Cause Failure Analysis, Fault Tree Analysis in Verbindung mit Tabelle E.6 "Liste der Techniken/Maßnahmen"). Die Definition kann übergreifend erfolgen oder eine firmenspezifische oder sogar produktspezifische Detaillierung aufweisen. Gegenstand dieses Ergebnisberichts ist eine konzeptionelle Betrachtung des RAMS-Programms. RAMS-Anforderungen: Spezifikation von speziellen Anforderungen aus unterschiedlichen, z.t. vom Produkt unabhängigen Dokumenten, wie dem Entwicklungsplan, der Zulassungsstrategie, der Risikoanalyse oder dem Sicherheitskonzept. Ergänzt werden diese RAMS- Anforderungen um die produktspezifischen Belange aus der Entwicklung, die teilweise erst aufgrund der Detaillierung in den nachgelagerten Entwicklungs-Phasen erfasst werden können. Eine Unterscheidung dieser Anforderungen zu den funktionalen Anforderungen, die sich aus dem Lastenheften etc. ergeben, sollte konzeptionell vorbereitet sein. Diese Anforderungen müssen in den anschließenden Phasen der Entwicklung eines Systems verfolgbar gestaltet werden und unterliegen einer besonderen Nachweisführung der Einhaltung im Sicherheitsnachweis. Version: 1.0 Seite 7 von 51

80 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Ausgangssituation RAMS-Nachweis: Definition von Teststrategien und Testszenarien für die Abnahme im Rahmen der System- und Integrationspläne. Die generellen Aspekte der Verfahren sowie der einzusetzenden Werkzeuge und der Art der Nachweisführung der RAMS-Anforderungen müssen in dem Plan dargelegt werden. Im besten Fall wird diese Art eines Nachweis- und Abnahmeverfahrens sowie der Beurteilungskriterien so definiert, dass diese in dem Prüfplan des Gutachters einfließen können. DIN EN 50129:2003, Kapitel "Nachweis des Sicherheitsmanagements" (Kapitel 5.3) Der Gefährdungsanalyse- sowie Risikobewertungsprozess wird in der Norm DIN EN beschrieben und in dieser Norm bzgl. der Nachweisführung aufgegriffen. Gegenstand ist nicht mehr der Planungs- und Durchführungsprozess, sondern die konkrete Darlegung der einzelnen Umsetzungen und Einhaltungen der Prozesskette im Sicherheitsnachweis. Der Fokus dieser oben beschriebenen Nachweise ist im Gegensatz zu der DIN EN auf die entwicklungsbegleitenden Tätigkeiten gelegt. Dies wird im Bild 5 der DIN EN erkennbar, wenn über die Betrachtung des Entwurfs sowie dessen Validation diskutiert wird. Anzumerken ist somit, dass erstens ein Schwerpunkt die Fehlerbetrachtung generell ist und zweitens die Reflektion bzw. Abhängigkeit dieser Fehlerbetrachtung in der weiteren Entwicklung erfolgen muss. Das Ergebnis des zweiten Aspekts muss wieder in die sicherheitstechnischen Betrachtungen des Sicherheitsnachweises konsolidiert aufgenommen werden. Eine Möglichkeit des Splittings dieser Sicherheitsbetrachtungen und deren unterschiedlichen Modellierungen werden in diesem Ergebnisbericht dargelegt: In diesem Ergebnisbericht wird ein generelles Verfahren zur Betrachtung von systematischen Fehlern entworfen. Bei der Auswahl und der Durchführung der einzelnen Methodiken bzw. Maßnahmen können übergeordnete Vorgehensprozesse beschrieben werden, die von allen beteiligten Rollen akzeptiert werden und somit zu einer beschleunigten Zulassung einzelner Komponenten bzw. (Sub-) Systeme führen können. Aus einem einheitlichen Modell folgt, dass durch die vereinheitlichten Verfahren die Innovationskraft der technischen Entwicklungen und somit auch deren Einsatz in der LST-Technik im schienengebundenen Verkehr einfach zum Tragen kommen. Innerhalb dieses Ergebnisberichts werden Prozessvorschläge entwickelt, die bei einer Nachweisführung unabhängig vom Produkt umgesetzt werden können. Die Umsetzung eines Verfahrens zur Rückverfolgbarkeit (Traceability-Matrix) für Fehlerbetrachtungen vom Entwurf bis zur Nachweisführung in den jeweiligen Testberichten wird im vorliegenden Teil-Ergebnisbericht dargestellt. Am Beispiel des generischen Produkts Alister wird prototypisch eine Umsetzung gezeigt. Die Aspekte der Traceability gemäß A.4.3. "Bestimmung und Behandlung von neuen, aus dem Entwurf hervorgegangenen Gefährdungen" werden betrachtet und die Möglichkeiten eines Nachweises der funktionalen und technischen Sicherheit aufgezeigt. Als zusätzlicher Aspekt wird das Gefährdungslogbuchs aufgegriffen. Es wird diskutiert, in wie weit die heutigen ALM - Tools zur Führung dieses Gefährdungslogbuchs eingesetzt werden können. Entsprechend dem Ergebnisbericht ("Entwicklung von anerkannten Regeln der Technik" - hier NeGSt: Positionspapier der AG1) wurde evaluiert, ob ein ALM-System zur Verwaltung eines Normenmanagementsystems genutzt werden kann. Auf dem Ergebnis der Arbeitsgruppe 1 wird aufgesetzt und eine entsprechende Evaluierung für eine in sich konsistente Datenverwaltung betrachtet. In der Diskussion dieser Verfahren wird unter Beachtung der erforderlichen Dokumentation (siehe für die Software-Aspekte [NeGSt_AG3]) die Sichtweise der Generik - hier nur für die generische Plattform - analysiert. Die Anforderungen der Nachweisführung an eine generische Applikation sowie an die Anwendungsdaten (Spezifische Applikation) können in einem weiteren Fördervorhaben als nächster Schritt betrachtet werden. Version: 1.0 Seite 8 von 51

81 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Ausgangssituation Nur durch den Einsatz von Standard-Komponenten können effektive Lösungen kostengünstig und schnell umgesetzt werden, die die Zukunftsfähigkeit der LST gewährleisten. Bedingt durch diesen verstärkten Einsatz von Standardindustrieprodukten in Systemen, wird ein Schwerpunkt der Evaluierung eines einheitlichen Prozesses die Einbindung von COTS-Produkten in die Nachweisführung sein. Stammten bisher die Systeme und ihre Komponenten größtenteils aus der Entwicklung eines Herstellers, so geht die Tendenz in Richtung hoch modularer Systeme mit Komponenten unterschiedlicher Hersteller. Bei allem Wunsch nach einer schnellen Umsetzung der aktuellen technischen Entwicklungen darf dabei selbstverständlich der Sicherheitsgedanke nicht außer Acht gelassen werden. Eine Möglichkeit der Sicherheitsnachweisführung wurde erarbeitet und wird vorgestellt. Zusätzlich werden die Unterschiede und Gemeinsamkeiten der Prozesse bzgl. Einbindung COTS und Eigenentwicklung betrachtet. Dabei sind Aspekte wie die Entwicklung nach Grundsätzen des Marktes und nicht der Sicherheit, eine Black-Box-Entwicklung und somit der Nicht-Offenlegung der relevanten Entwicklungsdokumentation, die Variabilität der Produkte oder die hohe Innovationskraft zu beachten. Es müssen daher Prozesse aufgesetzt werden, die die dadurch häufig notwendigen Änderungszulassungen flexibel und effizient ermöglichen. Aufgrund der weitgefassten Definition der COTS-Produkte sollte dabei in einem folgenden Forschungsprojekt zwischen dem Einsatz von Third-Party-Produkten der Software und den Einsatz von Standard-Hardware-Komponenten, die keine oder zunächst nur eine Zulassung nach Industrienormen (IEC 61508) aufweisen, unterschieden werden. Diese Problematik ist nicht Gegenstand dieses Ergebnisberichts. Version: 1.0 Seite 9 von 51

82 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge 3 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Die Betrachtung von Zuverlässigkeit, Verfügbarkeit, Pflegbarkeit und Sicherheit (RAMS) und der Nachweis der Einhaltung der daraus abgeleiteten Anforderungen ist der zentrale Punkt, der durch die Sicherheitsorganisation mittels Vorgaben an einzuhaltende Prozesse unterstützt werden muss. Um dies zu ermöglichen, muss ein Verfahren von der Übernahme der Systemdefinition bis zur Übergabe an den Gutachter aufgesetzt werden, in dem die Durchgängigkeit der Nachweisführung effizient möglich ist. Aufgrund der Komplexität der Produkte im Stellwerksbereich wird, unter Beachtung der Vielzahl der technischen Aspekte, der sich daraus ergebenen Sicherheitsfragen sowie der wachsenden Anzahl der Anforderungen und der sich wiederum daraus ergebenden, nachgelagerten Testberichten, eine Vielfalt von Dokumenten, Statistiken und Analysen erstellt, die einen Verlust der Übersichtlichkeit nach sich zieht. Der Einsatz von singulären Tools bedingt, dass nur bestimmte Aspekte der Nachweisführung lokal behandelt und korrekt und vollständig bewiesen werden. Jedoch können durch die fehlenden Durchgängigkeit der Toolkette Probleme in der übersichtlichen Strukturierung der Nachweisführung von der Analyse einer Gefährdung bis zu ihrer korrekten Behandlung (korrektes Fehlerhandling) in der gesamten Prozesslinie auftreten. Durch fehlende Schnittstellen der Tools sowie teilweise unzulänglicher Exportfunktionen können die Daten nicht einfach zwischen den Tools ausgetauscht werden. Diesen Einschränkungen konnte bislang durch eine klar strukturierte Verfahrensdefinition der Sicherheitsorganisation begegnet werden, die firmenspezifisch aufgesetzt worden ist. Aufgrund der Entwicklungsfortschritte der Werkzeuge, hier speziell der ALM-Toolketten, besteht jetzt die Möglichkeit, firmenunabhängige Prozesse zu beschreiben, die eine schnelle Übersichtlichkeit auch für Dritte ermöglicht, unabhängig von firmenspezifischen Know-How bzgl. der jeweiligen Werkzeuge. 3.1 Konzepte der Nachweisführung Risikoanalyse, Gefährdungsbeherrschung und Risikoakzeptanzkriterien Zum Vergleich mit anderen Branchen einige Betrachtungen aus Industriebereichen, in denen Sicherheit ebenfalls eine herausragende Rolle spielt Risikoanalyse und Gefährdungsbeherrschung im Luftverkehr Ein generischer Entwicklungsprozess für Luftfahrzeuge wird in der ARP 4754 [ARP 4754] beschrieben. Die verschiedenen Entwicklungsschritte verlaufen oftmals parallel und sind voneinander abhängig. Einzelne Änderungen können weitere nach sich ziehen und zur Aktualisierung der Risikoanalysen führen. Der Sicherheitsanalyseprozess ist in Abbildung 1 dargestellt. Version: 1.0 Seite 10 von 51

83 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 1: Wechselwirkung zwischen Sicherheits- und Entwicklungsprozess in der Luftfahrt (nach [KNE2001]) Das Flugzeug bildet die oberste Ebene, die aus mehreren Systemen besteht. Zuerst werden im Rahmen eines Functional Hazard Assessments (FHA) die funktionalen Anforderungen auf Flugzeugebene sowie mögliche Versagensarten identifiziert. Entsprechend der Klassifizierung der Versagensarten erfolgt die Einstufung der Development Assurance Level (DAL). Im darauf folgenden Schritt werden die Flugzeugfunktionen den Systemen zugeordnet und jeweils ein System-FHA durchgeführt. Im Anschluss werden im Preliminary System Safety Assessment (PSSA) die zu den im FHA ermittelten Versagensarten gehörenden Ausfälle identifiziert. Das PSSA überprüft ferner die Systemarchitektur darauf, ob die gestellten Anforderungen erreicht werden können. Ist das nicht der Fall, müssen abgeleitete Sicherheitsanforderungen aufgestellt werden. Das gilt ebenso für die Komponentenanforderungen, die der Hard- und Software zugewiesen werden. Für die Überprüfung der Unabhängigkeitsforderungen während des FHA und PSSA wird die Common Cause Analysis (CCA) eingesetzt. Ihre Ergebnisse werden im System Safety Assessment (SSA) zur Verifizierung der Systemimplementierung mit den zuvor aufgestellten Anforderungen genutzt. Innerhalb des FHA und PSSA werden bei Bedarf weitere Methoden angewandt, z. B. eine Fehlerbaumanalyse (FTA), Markov- Analyse oder Fehler-Möglichkeits- und Einfluss-Analyse (FMEA). Die während der FHA identifizierten Versagensarten werden hinsichtlich ihrer Schwere klassifiziert. Diese Klassen reichen von "Keine Sicherheitsauswirkungen" bis zu "Katastrophal". Die Einstufung erfolgt entsprechend der Auswirkungen auf das Flugzeug, die Insassen und die Flugbesatzung woraus die tolerierbare Gefährdungsrate abgeleitet werden kann [2003/2]. Für jede Klassifikationsstufe der Versagensarten wird eine zulässige qualitative und quantitative Wahrscheinlichkeit angegeben. Version: 1.0 Seite 11 von 51

84 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Als Bezugsgröße wird die durchschnittliche Wahrscheinlichkeit je Flugstunde zugrunde gelegt. Die Ermittlung des Wertes für die Klasse Katastrophal wird in [2003/2] beschrieben. Den Ausgangspunkt bildete die aus historischen Werten bestimmte Wahrscheinlichkeit eines schweren Unfalls mit 1 pro 1 Million Flugstunden. Davon wurden 10 % durch Ausfälle von Flugzeugsystemen verursacht. Dieser Wert von 10-7 pro Flugstunde soll für Flugzeugneuentwürfe nicht überschritten werden. Da dieser Wert während des Entwurfs schwer zu ermitteln ist, wird weiterhin angenommen, dass in einem Flugzeug 100 potenzielle katastrophale Versagenszustände existieren. Damit ergibt sich für die durchschnittliche Eintrittswahrscheinlichkeit katastrophaler Versagenszustände ein Grenzwert von 10-9 pro Flugstunde. Dieser Wert wird als Grenze für extrem unwahrscheinlich angenommen. Die Werte für weniger schwerwiegende Versagensarten sind entsprechend geringer Risikoanalyse und Gefährdungsbeherrschung im Schienenverkehr Mit Einführung der DIN EN [DIN EN 50126] im Jahre 1999 wurde der zuvor gültige regelorientierte Sicherheitsansatz durch einen risikoorientierten abgelöst. Während früher die Einhaltung geltender detaillierter Vorschriften nachgewiesen werden musste, ist jetzt der Nachweis der Abwesenheit eines zu hohen Risikos erforderlich. Dafür werden zuvor akzeptable Risiken festgelegt. Dieser, dem technischen Fortschritt gegenüber aufgeschlossener neuer Ansatz, wurde durch die Europäische Union zur Förderung des Wettbewerbs eingeführt. Es wird davon ausgegangen, dass keine absolute Sicherheit erreicht werden kann. Deshalb muss nachgewiesen werden, dass ein vorhandenes Restrisiko den tolerierbaren Wert nicht übersteigt [BRA2006]. Bedingung hierfür ist jedoch das Vorhandensein von entsprechenden Datengrundlagen über die Ausfall- und Fehlerwahrscheinlichkeiten der betrachteten Module. H: Gefährdungsrate eines Systems / Teilsystems THR: Tolerierbare Gefährdungsrate des Systems / Teilsystems Abbildung 2: Bestimmung und Zuteilung der SIL-Anforderungen(nach [DIN EN 50129]) Die Sicherheitsnachweisführung wird in der DIN EN beschrieben. Sie besteht aus den Teilen Risikoanalyse und Gefährdungsbeherrschung. Der Gesamtprozess mit den Verantwortlichkeiten der Eisenbahnverwaltung und Hersteller ist in Abbildung 2 dargestellt. Im Rahmen der Risikoanalyse Version: 1.0 Seite 12 von 51

85 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge werden tolerierbare Gefährdungsraten (THR) aufgestellt. Die Gefährdungsbeherrschung muss aufzeigen, dass die Gefährdungsrate (H) diesen Wert nicht überschreitet Risikoanalyse Die Risikoanalyse eines Systems liegt im Verantwortungsbereich des Betreibers und muss von diesem durchgeführt werden (siehe Abbildung 2). Das Ziel besteht in der Zuordnung der tolerierbaren Gefährdungsraten. Der Prozess kann nach [DIN EN 50129] in die folgenden Schritte unterteilt werden: Systemdefinition Gefährdungsidentifikation Konsequenzanalyse Risikoabschätzung THR-Zuordnung Die ersten beiden Schritte dienen der Systemdefinition und Identifizierung der möglichen Gefährdungen, die aus dem Einsatz des Systems hervorgerufen werden können. Die Systemdefinition erfolgt durch das Aufstellen der erforderlichen Dokumentationen im Rahmen der Systembeschreibung und des Systementwurfs. Die Identifikation der potenziellen Gefährdungen durch den Betrieb des Systems erfolgt in einer empirischen Phase, z. B. durch Checklisten oder existenten Werten aus Wartungsarbeiten und Vorgängersystemen, sowie einer kreativen Phase (z. B. mit Hilfe eines Brainstormings unter entsprechenden Fachleuten). THR [1/St und e F unk t i o n] 10 5 > T HR > T HR > T HR > T HR 10 9 SIL Tabelle 1: Gegenüberstellung von THR und SIL (nach [DIN EN 50129]) Aus Gründen der Übersichtlichkeit sollten die gefundenen Gefährdungen nach ihrer Risikohöhe sortiert werden. Anschließend folgt die Ermittlung der Folgen der Gefährdungen. Diese Schritte können z. B. mit einer FMEA durchgeführt werden. Darüber hinaus ist ein Risikoakzeptanzkriterium zu bestimmen. Die DIN EN stellt an dieser Stelle Kriterien vor, von denen durch die Analysemethode mindestens eines zu erfüllen ist. Auf Grundlage dessen sind die THR abzuleiten und den Gefährdungen zuzuordnen. Explizite Abschätzung des individuellen, resultierenden Risikos Ableitung der THR über einen Vergleich der Leistungsfähigkeit bereits existierender Systeme Ableitung der THR durch anerkannte Regeln der Technik mit Hilfe von statistischen oder analytischen Methoden Ableitung der THR aus anderen qualitativen Verfahren, falls hierdurch eine Liste von Gefährdungen und entsprechenden THR erzeugt wird Berücksichtigung von CSM in der Risikoanalyse Laut CSM-Verordnung (Verordnung Nr. 352/2009, gemeinsame Sicherheitsmethode) ist jede Änderung einer Funktion einer Risikoanalyse zu unterziehen. Dabei sind Änderungen der Funktionen als Version: 1.0 Seite 13 von 51

86 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Änderungen an den Anforderungen zu verstehen und liegen somit meist in der Verantwortung des Betreibers. Für Ausführungen wird auf den Ergebnisbericht von AG 2 verwiesen. Nach den Ergebnissen von AG 2 kann man feststellen, dass die CSM-Verordnung keinen Einfluss auf die Wahl der technischen Realisierung hier also COTS-Komponenten hat. Es wird ausschließlich die Änderung der Funktion, nicht aber der technischen Realisierung betrachtet Gefährdungsbeherrschung Die Aufgabe des Herstellers liegt in der Gefährdungsbeherrschung. Er muss nachweisen, dass sein System die aufgestellten THRs erfüllt. Die Gefährdungsbeherrschung (siehe Abbildung 2) wird in drei Schritten durchgeführt [DIN EN 50129]: Ursachenanalyse Common-Cause-Analyse SIL-Zuordnung Im Rahmen der Ursachenanalyse erfolgt zuerst, falls noch nicht geschehen, für jede Gefährdung die Zuordnung der THR zu einer Systemfunktion. Die Zuweisung der entsprechenden SIL erfolgt auf Basis der SIL-Tabelle (siehe Tabelle 1). Die Stufe vier steht für die höchsten Anforderungen. Ist die THR 10 5 wird die Sicherheitsanforderungsstufe 0 zugewiesen. Für ein Teilsystem mit mehreren sicherheitsrelevanten Funktionen ist die höchste SIL-Einstufung maßgebend. Zur Reduzierung der daraus entstehenden Erfordernisse, können die Funktionen und Subsysteme getrennt werden. In diesem Fall ist ein Nachweis der Unabhängigkeit erforderlich. Der zweite Teil der Ursachenanalyse beinhaltet die Zuordnung der Ausfallraten zu den Elementen. In der Ursachenanalyse können z. B. Fehlerbäume, Zuverlässigkeitsblockdiagramme oder Markov-Modelle genutzt werden. Zum Nachweis der physikalischen, funktionalen und prozessmäßigen Unabhängigkeit der Funktionen muss eine Common-Cause-Analyse durchgeführt werden. Während des Entwurfs können neue Gefährdungen identifiziert werden, die ebenfalls bewertet werden müssen. Für jede neue Gefährdung muss eine THR bestimmt werden. Falls erforderlich, muss eine Aktualisierung der Anforderungen erfolgen. Es müssen alle aufgestellten THR eingehalten werden. Andernfalls muss der Hersteller an seinem Systementwurf Nachbesserungen vornehmen Risikoakzeptanzkriterien Für den Schienenverkehr wird weder von den Zulassungsbehörden noch von den Normen oder Richtlinien ein Risikoakzeptanzkriterium vorgegeben. Die DIN EN führt drei Risikogrundsätze als Beispiel an: As Low As Reasonably Practicable (ALARP), Globalement Au Moins Equivalent (GAME) / Globalement Au Moins Aussi Bon (GAMAB), Minimum Endogenous Mortality (MEM). Die Erfahrungen und allgemeine Akzeptanz der Verfahren sind dabei sehr verschieden. Die Auswahl eines Kriteriums wird letztlich der nationalen Behörde überlassen. Es muss jedoch sowohl den europäischen als auch den nationalen Anforderungen entsprechen. Deshalb wird an dieser Stelle als viertes Prinzip [BRA2004] noch das Kriterium der " Mindestens gleichen Sicherheit (MGS)" aufgeführt, dass auf der Eisenbahnbetriebsordnung (EBO) basiert. Darüber hinaus gibt es noch weitere Verfahren zur Ermittlung der Risikoakzeptanzkriterien, wie z.b. ALARA oder SFAIRP. Da diese allerdings im Bereich der Zulassung von Eisenbahnsystemen nach Literaturrecherchen [HSE2001, EHS2003, SAL2008] keine Anwendung finden, werden diese im Folgenden nur kurz erläutert. Eine Vereinheitlichung der Risikoakzeptanzkriterien ist bislang auf internationaler Ebene - sowohl europäisch als auch weltweit - nicht erreicht worden [BRA2006]. Inwieweit hier eine Angleichung oder Harmonisierung zustande kommen wird, ist nicht absehbar. Version: 1.0 Seite 14 von 51

87 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge ALARP Das ALARP-Prinzip beschreibt eine Vorgehensweise in der Risikominderung von technischen Systemen, indem eine Kosten-Nutzen-Rechnung der Sicherheitstechnik durchgeführt wird [BRA2006]. Damit wird das von dem System ausgehende Risiko wirtschaftlich bewertet, was eine monetäre Umrechnung von Personenschäden voraussetzt und damit eher einen volkswirtschaftlichen Schaden in den Vordergrund stellt. Insbesondere hierdurch ist das ALARP-Prinzip direkt angreifbar und entsprechend umstritten. Das ALARP-Prinzip findet innerhalb Europas in Großbritannien (nahezu alle Bereiche von technischen Systemen [HSE2001, DEF STAN 00-56]) und den Niederlanden Anwendung [MIE2004]. Abbildung 3: Bereiche des ALARP-Prinzips (nach [RSS2007]) Im ALARP-Prinzip werden drei Risikobereiche aufgebaut (siehe Abbildung 3) die den erforderlichen Handlungsbedarf bezüglich einer Risikominderung definieren. Die Beschreibungen für die drei Bereiche sind in der Tabelle 2 aufgelistet. Sind die Risiken gering und die notwendigen Aufwendungen zur weiteren Reduzierung im Verhältnis unangemessen hoch, können sie auf diesem Stand belassen werden. Risikobereich Inakzeptables Risiko Toleriertes Risiko oder ALARP-Bereich Beschreibung Das vom System ausgehende Risiko kann nicht akzeptiert werden. Es sind entsprechende Maßnahmen zur Risikominderung durchzuführen oder das System muss stillgelegt werden. Es muss überprüft werden, inwieweit eine Minderung des entstehenden Risikos möglich ist. Die identifizierten Maßnahmen zur Risikominimierung werden jedoch einer Kosten-Nutzen-Analyse unterzogen. Es werden nur solche Maßnahmen durchgeführt, die wirtschaftlich sinnvoll sind. Version: 1.0 Seite 15 von 51

88 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Risikobereich Akzeptiertes Risiko Beschreibung Eine weitere Herabsetzung des Risikos ist nicht erforderlich. Es muss lediglich über Wartung und Instandhaltung sichergestellt werden, dass das ausgehende Risiko nicht ansteigt. Tabelle 2: Beschreibung der ALARP-Risikobereiche (nach [AKB2004-1]) Im ALARP-Bereich werden Risiken akzeptiert, wenn die Kosten für eine Minderung zu hoch wären. Das Risiko an sich muss aber noch vertretbar sein. Sind die aus den Risiken resultierenden Ereignisse nicht mehr zu rechtfertigen, gelten sie als inakzeptabel und müssen vermieden werden [DEF STAN 00-56]. Der Nachweis des ALARP-Kriteriums kann durch die Anwendung von bewährten Normen und Verfahren erfolgen. Andernfalls muss ein Kostenvorteil verglichen mit dem Wert des Lebens aufgezeigt werden. GAME / GAMAB Das GAME/GAMAB-Prinzip setzt den derzeitigen Sicherheitsstand als Mindestanforderung, es wird also ein Referenzsystem für die Betrachtung vorausgesetzt [LIG2008-1]. In [AKB2004-1] werden die Ziele des GAME-Prinzips folgendermaßen umschrieben: " [...] All new guided transport systems must offer a level of risk globally at least as good as the one offered by any equivalent existing system. [...] " Neue Systeme müssen demnach mindestens die gleiche Sicherheit bieten, wie es derzeit durch gleichwertige Systeme realisiert ist. Damit ähnelt das GAME/GAMAB-Prinzip stark dem deutschen MGS- Prinzip. Es wird im Vergleich zum ALARP-Prinzip kein spezielles Risiko das von dem Systeme ausgeht zu Grunde gelegt, sondern es erfolgt eine globale Betrachtung der Sicherheit der verwendeten Technik [BRA2006, DIN EN 50126]. Das GAME/GAMAB-Prinzip wird vor allem in Frankreich angewendet [MIE2004]. MEM Dem Prinzip der minimalen endogenen Sterblichkeit liegt die Annahme zugrunde, dass es für einen Menschen jederzeit eine bestimmte statistische Wahrscheinlichkeit eines natürlichen Todes gibt (Todesfälle durch Krankheit oder angeborene Gesundheitsschäden zählen nicht dazu). Dieser Wert ist abhängig von der Altersgruppe. Am niedrigsten ist die Wahrscheinlichkeit bei Jugendlichen im Alter zwischen 5 und 15 Jahren. Danach wurde der Wert für die minimale endogene Sterblichkeit festgelegt [DIN EN 50126]. Dieser Wert beruht alleinig auf statistischen Werten und kann so in Bezug auf Sicherheitsnachweise eher als willkürlich gewählt angesehen werden. Diese Zahl darf durch ein einzuführendes technisches System nicht mehr als 5 % erhöht werden, wodurch das Risiko durch ein einzelnes technisches System nicht höher als 10-5 liegen darf [BRA2006]. Der Faktor der angegebenen 5 % entsteht aus der fiktiven Annahme, dass ein Mensch ständig von 20 technischen Systemen umgeben ist, die auf die Sterblichkeit Einfluss haben. Mit dem MEM-Prinzip ist gleichzeitig ein weiterer Faktor eingeführt geworden, der als " Differential Risk Aversion (DRA)" bezeichnet wird, wodurch die Akzeptanz-Schwelle für Todesfälle sinkt. Diese Aversion begründet sich in der gesellschaftlichen Inakzeptanz gegenüber Unfällen mit hohem Personenschaden. Je mehr Todesfälle durch Unfälle mit einem technischen System hervorgerufen werden, desto geringer ist das tolerierte, individuelle Risiko, das ein Nutzer eingeht. Das akzeptierte Risiko nach dem MEM-Prinzip unter Einbeziehung des DRA-Faktors ist in Abbildung 4 dargestellt. Version: 1.0 Seite 16 von 51

89 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 4: Akzeptiertes individuelles Risiko in Abhängigkeit von Todesfällen (nach [MIE2004]) In der Praxis wurde dieses Prinzip im Eisenbahnwesen bisher lediglich zu Forschungszwecken genutzt aber noch nicht in der Zulassung von Seriensystemen angewandt [BRA2006, MIE2004]. MGS Das Prinzip des Nachweises der mindestens gleichen Sicherheit basiert auf der Forderung der EBO nach der Einhaltung der anerkannten Regeln der Technik bzw. dem Nachweise mindestens der gleichen Sicherheit wie bei Einhaltung dieser. Dieses Prinzip der Ermittlung der Risikoakzeptanzkriterien wird nicht in der DIN EN aufgeführt. Als Vergleichsbasis für die Risikoakzeptanz nach MGS werden die anerkannten Regeln der Technik zugrunde gelegt. Es ähnelt damit dem GAME-Kriterium, welches das globale System betrachtet. Beiden ist jedoch gleich, dass sie keine festen Werte haben, sondern den derzeit existierenden Stand als Referenzwert heranziehen, der nicht unterschritten werden darf. Damit wird bei technischem Fortschritt meist auch der Bezugswert erhöht, da die nachzuweisende Sicherheit des einzuführenden Systems bei der Zulassung über dem liegen muss, was derzeit im Einsatz befindlich ist. [EBO, BRA2004] ALARA Das ALARA-Prinzip wird als Verfahren zur Identifikation und Bewertung von Potenzialen zur Risikominimierung empfohlen [HSE2001]. Allerdings findet es vorrangig in der Arbeitssicherheit im Bereich von strahlungsintensiven Systemen, wie zum Beispiel der Nukleartechnik [EHS2003] oder der Radiologie innerhalb der Medizin [HLH2005] Anwendung. SFAIRP In Großbritannien [HSE2001] und Australien [SAL2008] wird das SFAIRP-Prinzip als ein anwendbares Verfahren beschrieben, um die Risikoakzeptanz eines technischen Systems zu bewerten. Das britische Health and Safety Executive schlägt dies Verfahren gleichrangig zu ALARP und ALARA für alle Bereiche vor. Die australische National Transport Commission definiert das SFAIRP-Prinzip in [SAL2008] als das zu nutzende Verfahren für die Risikobewertung des Eisenbahnbetriebs. Kern des SFAIRP-Prinzips ist die Gegenüberstellung der vorhandenen Risiken und deren Folgen eines technischen Systems mit den erforderlichen Aufwänden, diese reduzieren zu können. Auch hier gilt, wie schon beim ALARP-Prinzip, dass eine solche Risikominderung proportional zu den entstehenden Mehrkosten stehen muss. Damit ist das SFAIRP-Prinzip mit dem ALARP-Prinzip vergleichbar. Dies sowohl in den positiven, als auch in den negativen Punkten. Version: 1.0 Seite 17 von 51

90 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Sicherheitsnachweisführung Eine wichtige Voraussetzung für die Zulassung von Verkehrsmitteln ist der Nachweis der Aufgabenerfüllung. Zu diesem Zweck können verschiedene Methoden angewendet werden. Sie sollen es ermöglichen, Ausfälle, Gefährdungen und die Auswirkungen sowie die Verbindungen untereinander zu identifizieren. Diese Analysen gestatten die Bewertung der betrachteten Systeme. Die Methoden verfolgen zwei verschiedene Analyseansätze: Induktive Verfahren: Die induktiven Verfahren werden auch als Bottom-Up-Verfahren bezeichnet. Sie gehen vom speziellen zum allgemeinen. Dazu zählt die Untersuchung der Auswirkungen eines bestimmten Ereignisses, z. B. Versagen. Beispiele für induktive Methoden sind die Ereignisbaumanalyse. Deduktive Verfahren: Die deduktiven oder auch Top-Down-Verfahren folgen dem entgegen gesetzten Weg. Die Untersuchung geht vom allgemeinen zum speziellen. Sie werden z. B. zur Identifizierung der Ursachen eines Ausfalls genutzt. Ein Vertreter dieser Art ist die Fehlerbaumanalyse. Weiterhin wird noch zwischen qualitativen und quantitativen Ansätzen unterschieden [2003/2, VIL1992]. Qualitative Verfahren: Qualitative Analysen betrachten ein System in einer nicht- numerischen Art. Sie modellieren das System mit den verschiedenen Ereignissen. In einem qualitativen Verfahren wird oft verbal oder über einfache Zahlenwerte, wie der Risikoprioritätszahl bewertet, wie wahrscheinlich ein Ereignis ist. Die Systemmodellierung mit einem qualitativen Verfahren ist häufig die Voraussetzung für die Durchführung einer quantitativen Betrachtung [FAA2000]. Beispiel für qualitative Methoden ist die Fehler-Möglichkeits- und Einfluss-Analyse. Quantitative Verfahren: Quantitative Analysen betrachten ein System in einer mathematischen Vorgehensweise. Hierfür ist eine ausreichende Datenbasis von Fehler- oder Ausfallwahrscheinlichkeiten erforderlich. Mit Hilfe von quantitativen Verfahren wird eine statistische Bewertung eines Systems vorgenommen und als Ergebnis z. B. eine Ausfallrate errechnet. Als Beispiel für quantitative Verfahren ist die Fehler- Möglichkeits-, Einfluss- und Kritikalitätsberechnung zu nennen. Die Auswahl geeigneter Nachweisverfahren ist abhängig von den Zielsetzungen, dem Systemumfang und den betrachteten Bereichen. Die Methoden können in unterschiedlichen Phasen des Lebenszyklus angewandt werden. Dabei gilt, je früher Probleme erkannt werden, umso leichter und kostengünstiger können sie behoben werden. Viele Methoden wurden ursprünglich in Bereichen mit hohen Sicherheitsanforderungen entwickelt, wie dem Militär, der chemische Industrie, dem Luftverkehr oder der Kernenergie. Später wurden sie auch von anderen Bereichen übernommen. Verfahren Anwendungsbereich Eisenbahn Luftfahrt Literaturquellen Common Cause Analyse 2003/2, ARP4754, DIN EN 50129, FAA2000, FAA2005, SSS1997 Event Tree Analysis DIN EN 50128, FAA2005, SSS1997 Fault Tree Analysis 2003/2, DIN 25424, FAA2005, SSS1997, VES2002, VIL1992 Failure Mode and Effect Analysis AMB2001, DIN 60812, FAA2005, SSS1997, VDA 4.2 Failure Mode, Effect and Criticality Analysis ( AMB2001, SSS1997 Hazard and Operability Study FAA2005, SSS1997 Markov-Analyse 2003/2, LIG2008-2, SSS1997 Version: 1.0 Seite 18 von 51

91 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Verfahren Anwendungsbereich Eisenbahn Luftfahrt Literaturquellen Preliminary Hazard Analysis AMB2001, FAA2000, SSS1997, VES2002, VIL1992 Sicherheitskonzept VDV161/1 Functional Hazard Analysis 2003/2, ARP4754, WER2002, WIK1998 Preliminary System Safety ARP4754, DAW1999 System Safety Assessment ARP4754 Tabelle 3: Auflistung der beschriebenen Verfahren Die Auswahl der in diesem Abschnitt vorgestellten Methoden erfolgte auf Grundlage ihrer Erwähnung in den Vorgaben zum Sicherheitsnachweis in den Normen ARP 4754 (Luftfahrt) und DIN EN (Eisenbahn). Weiter werden einige Verfahren aufgelistet, die mehrfach in diesem Zusammenhang in der Literatur aufgeführt werden. Die untersuchten Verfahren finden zum Teil sowohl im Luft- als auch Schienenverkehr Anwendung. Einige andere Methoden stammen direkt aus dem Luftverkehr. Eine Aufstellung der in diesem Kapitel vorgestellten Methoden, sowie deren Literaturquellen ist in Tabelle 3 enthalten. Die meisten der im Folgenden vorgestellten Methoden werden nicht nur in der Luftfahrt und im Schienenverkehr sondern auch in vielen anderen Bereichen angewandt und entstammen auch nicht immer grundlegend einer der beiden Bereiche. Die Methoden Functional Hazard Assessment (FHA) Preliminary System Safety Assessment (PSSA) System Safety Assessment (SSA) entstammen dem Luftverkehr und finden im Rahmen des Sicherheitsnachweisprozesses nach [ARP 4754] Anwendung Common Cause Analysis Die Common Cause Analysis (CCA) dient der Überprüfung der Unabhängigkeitsforderungen, die während der Sicherheitsanalysen von diversen Methoden vorausgesetzt werden. Sie wird sowohl in der ARP 4754 für den Luftverkehr als auch in der DIN EN für Bahnanwendungen angeführt. Bei Systemen oder Komponenten gleicher Ausführung, Verwendung gleicher Komponenten oder physischer Nähe können Ausfälle infolge gemeinsamer Ursachen (Common Cause Failures) auftreten. Die CCA identifiziert derartige Ausfälle und liefert Ansätze zur Korrektur und Fehlereindämmung. Dies kann durch Trennung der Backup- und Schutzsysteme oder unterschiedlicher Umsetzungen erreicht werden. Diese Methode sollte frühzeitig in der Entwicklung angewandt werden, da in diesen frühen Phasen eine Umgestaltung des Systems relativ unproblematisch erfolgen kann. An einigen Stellen werden die notwendigen Daten jedoch erst später zur Verfügung stehen, was die Durchführung deutlich behindert. Die Common Cause Analysis wird in fünf Schritte unterteilt, die in Abbildung 5 dargestellt sind. Version: 1.0 Seite 19 von 51

92 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 5: Abfolge der zu bearbeitenden Schritte einer CCA (nach [SSS1997]) Die CCA selbst besteht nach ARP 4754 aus drei Teil-Methoden, für die jeweils die zuvor aufgeführten Schritte durchgeführt werden müssen: Zonal Safety Analysis (ZSA) Particular Risk Assessment (PRA) Common Mode Analysis (CMA) Zonal Safety Analysis Die Zonal Safety Analysis betrachtet die Einhaltung der Sicherheitsanforderungen innerhalb einzelner Zonen und untereinander. Sie prüft, ob die Unabhängigkeitsanforderungen nicht durch physische Einflüsse oder Einrichtungen verletzt werden. Das Ziel der ZSA ist die Identifizierung der Quellen gemeinsamer Fehler sowie ihrer Auswirkungen auf Nachbarkomponenten Particular Risk Analysis Während des Particular Risk Assessment werden die sicherheitsbeeinträchtigen den Auswirkungen und Einflüsse bestimmter Gefahren (z. B. Blitzeinschlag, Feuer, geplatzte Reifen) betrachtet. Für jede einzelne Gefahr muss eine eigene Untersuchung durchgeführt werden. Im Gegensatz zur ZSA werden Ereignisse über mehrere Zonen hinweg betrachtet. Die hier ermittelten Ergebnisse können die Grundlage für spezifische Anforderungen (z. B. Lufttüchtigkeitsanforderungen) bilden Common Mode Analysis Die Common Mode Analysis beschäftigt sich mit den Auswirkungen der Ereignisse, die noch nicht während der Particular Risk Assessment (PRA) berücksichtigt wurden (z. B. Fehler in den Anforderungen, der Instandhaltung, der Umgebung, des Entwurfs, der Spezifikationen). Es wird die Unabhängigkeit der Ereignisse, die als Versagensarten betrachtet wurden, überprüft. Dabei erfolgt die Durchführung der CMA in vier Schritten: Erstellen von Checklisten Identifizierung der Anforderungen an die CMA Analyse des Entwurfs zum Nachweis der Anforderungen Dokumentation der Ergebnisse Event Tree Analysis Die Event Tree Analysis (ETA) ermöglicht es, Reihen von Ereignissen zu modellieren, die von dem betrachteten Ursprungsereignis ausgehen. Bei Vorhandensein der Wahrscheinlichkeiten für die einzelnen Ereignisse kann neben der qualitativen Betrachtung auch eine quantitative erfolgen. Ein Beispiel für einen Ereignisbaum ist in Abbildung 6 dargestellt. Zuerst wird ein Ausgangsereignis, z. B. eine Gefährdung, definiert. Für jede mögliche Konsequenz wird ein Zweig für das Eintreten (Erfolg) und Ausbleiben (Versagen) eröffnet. Version: 1.0 Seite 20 von 51

93 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Anschließend erfolgt für jeden Zweig wieder die Betrachtung der möglichen Konsequenzen. Die Entscheidungen müssen nicht binär sein. Ebenso kann unterschieden werden, wie viel Komponenten eines Systems einen Defekt erleiden und hieraus der Baum aufgebaut werden. Für die Durchführung ist eine gute Systemkenntnis erforderlich. Der Umfang, Aufwand und die Unübersichtlichkeit der Analyse nehmen mit der Komplexität des betrachteten Systems deutlich zu. Abbildung 6: ETA-Graph mit binären Entscheidungen (nach [SSS1997]) Fault Tree Analysis Die Fault Tree Analysis (FTA) ist eine deduktive graphische Methode zur Identifizierung der Ursachen für ein unerwünschtes Ereignis. Sie wurde zuerst in der Telekommunikationsindustrie angewandt und später auch in der Luft- und Raumfahrt sowie Kernenergie. In den letzten Jahren erfolgten Anpassungen, um die Erzeugung dynamischer Fehlerbäume und die Nutzung für Software zu erleichtern [VES2002]. Abbildung 7: Auswahl der wichtigsten Symbole für FTA-Graphen (nach [VES1981 und SSS1997]) Die FTA kann in allen Entwicklungsphasen angewandt werden, dennoch ist der Einsatz in der Entwicklung am effektivsten. Aufgrund ihres Umfangs ist allerdings eine vorherige Selektion der näher zu betrachtenden Ereignisse (z. B. mit Hilfe einer FHA, FMEA) sinnvoll. Für die Durchführung ist ein umfangreiches Systemwissen und -verständnis sowie Erfahrung unabdingbar. Trotz der Schwierigkeit, alle Möglichkeiten aufzuspüren, sollten alle denkbaren und vernünftigen Varianten identifiziert werden. Mit der FTA lassen sich Fehlerkombinationen und Bedienfehler darstellen, was sowohl für technische, mechanische und auch Software Systeme anwendbar ist. Das Ergebnis ist eine graphische Aufschlüsselung der Fehlerketten. Hierfür sind feste Symbole definiert worden, wie in Abbildung 7 dargestellt. Am Anfang wird das Ereignis festgelegt. Alle untergeordneten Ereignisse, die jenes auslösen können, werden im Fehlerbaum verzeichnet. Dies wird soweit fortgesetzt, bis alle Ursachen gefunden wurden. Durch die Verknüpfungen mit booleschen Operatoren, wie UND bzw. ODER (siehe Abbildung 7), ist die Darstellung von Fehlerkombinationen möglich, die das Top-Ereignis auslösen können. Die kleinsten Fehlerkombinationen können durch eine Reduzierung der bisherigen Wege gefunden werden. Abbildung 8 zeigt die allgemeine Darstellung eines Fehlerbaums. Version: 1.0 Seite 21 von 51

94 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 8: FTA-Graph Sind die Wahrscheinlichkeiten der einzelnen Ereignisse bekannt und unabhängig voneinander, kann zusätzlich eine quantitative Auswertung erfolgen. Sobald mehr als die UND- bzw. ODER- Verknüpfungen enthalten sind, wird die Auswertung schwieriger. Das trifft ebenfalls auf reparierbare Systeme zu. Ferner sind Bedien- und Softwarefehler quantitativ nur sehr schwer darstellbar. Anstelle der Fehlerbaumanalyse kann auch eine Markov-Analyse durchgeführt werden Failure-Mode- and Effect-Analysis Die Failure-Mode- and Effect-Analysis (FMEA) ist eine induktive Methode zur Identifizierung von Gefährdungen und ihrer Auswirkungen im Entwurf. Sie kann bei der Suche nach Korrektur- oder Überwachungsmaßnahmen helfen. Die bereits 1949 vom amerikanischen Militär entwickelte Methode wird in vielen verschiedenen Industriezweigen angewandt. Die FMEA kann ab der Entwicklungsphase eingesetzt werden und ist auf mechanische und elektrische Systeme anwendbar. Der menschliche Faktor wird nicht berücksichtigt. Die Darstellung der Ergebnisse der FMEA erfolgt in einer Tabelle, deren Spalten u. a. Bauteile, Funktionen, Ausfallarten, Auswirkungen und anzuwendenden Maßnahmen enthalten. Abhängig von der Komplexität des betrachteten Systems sollte die FMEA von einer interdisziplinären Gruppe durchgeführt werden, um möglichst alle wichtigen Risiken zu identifizieren Vorgehensweise FMEA Eine FMEA gliedert sich in fünf Teilphasen: Strukturanalyse Funktionsanalyse Fehleranalyse Risikobewertung Optimierung Zu Beginn einer FMEA sind Informationen zum Aufbau und der Funktion des zu betrachtenden Systems aus folgenden systemspezifischen Unterlagen zu ermitteln: Systemspezifikation Funktionsbeschreibung Zeichnungen Beschreibung der Einsatzbedingungen (z. B. Umweltbedingungen) Version: 1.0 Seite 22 von 51

95 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Wesentliche Schnittstellen Strukturanalyse Am Anfang der Erarbeitung einer FMEA steht die Analyse der grundsätzlichen Struktur des zu betrachtenden Systems. Dies erfolgt anhand der oben aufgeführten Dokumente. Hieraus lässt sich ableiten, welche Informationen über Systemgrenzen und Schnittstellen zwischen den angrenzenden Systemen ausgetauscht werden. Die gewonnenen Zusammenhänge werden in einer Baumstruktur dargestellt. In der vorgestellten Methodik wird die Identifikation der Schnittstellen gegenüber der nach Verband der Automobilindustrie (VDA) vorgeschlagenen Vorgehensweise erweitert. Um eine Verzahnung der FMEA mit der Sicherheitsbetrachtung zu erlangen wird die Auflistung der Schnittstellen und deren Funktion in der Struktur- und Funktionsanalyse unterschieden in ein- und ausgehende Verbindungen. Die derart aufgegliederten Informationen können direkt in die funktionale Sicherheitsbetrachtung übernommen werden Funktionsanalyse Nach erfolgter Ermittlung der dem System zugrunde liegende Struktur, wird im zweiten Schritt die Funktionsanalyse durchgeführt. Es werden jedem Strukturelement die spezifikationsgemäß auszuführenden Funktionen zugeordnet. Dabei dienen die Ergebnisse der Strukturanalyse als Eingangsinformationen für die Funktionsanalyse. Die identifizierten Funktionen des Systems werden wiederum grafisch aufbereitet, indem die Darstellung der Strukturanalyse um die Auflistung und Zuordnung der identifizierten Funktionen gemäß der Struktur eingefügt wird Fehleranalyse In einem dritten Schritt gilt es die verschiedenen Ausfallarten des Systems, welche im Allgemeinen aus den oben aufgeführten Unterlagen abzuleiten sind, und deren Auswirkungen auf das System (oder die Umgebung) zu ermitteln. Hierzu werden die Ausgangsinformationen der Funktionsanalyse herangezogen. Die Analyse der möglichen Fehlerzustände des Systems erfolgt durch Negieren der zuvor identifizierten Funktionen. Dabei bildet jede Negierung einen separat zu betrachtenden Fehler. Alle so erhaltenen Fehler werden in einem Formblatt gesammelt aufgelistet, wie z.b. durch die DIN EN vorgeschlagen Risikobewertung Auch wenn sich Ausfälle immer nachteilig auf die Zuverlässigkeit eines Systems auswirken, so haben nur einige spezielle Ausfälle negativen Einfluss auf die Sicherheit, die im Rahmen einer FMEA betrachtet werden soll [EN 50126]. Daher wird auf der Grundlage der Fehleranalyse eine Bewertung der mit einer Fehlerursache verbundenen Risiken vorgenommen. Hierbei werden bereits im Entwurf des betrachteten Systems enthaltenen Maßnahmen bezüglich Vermeidung und Verbesserung der Entdeckung von Fehlern herangezogen und mit bewertet. Die unterschiedlichen Ausfallarten können nach verschiedenen Kriterien (z. B. Sicherheit, Zuverlässigkeit, Kosten, Terminverzug etc.) bewertet werden. Diese Bewertung bzw. Ausfallbedeutungsanalyse kann z. B. mittels Bewertungsgitternetzen durchgeführt werden. Abbildung 9 zeigt ein solches Gitternetz, welches aus Gründen der Normkonformität an die Begrifflichkeiten der CENELEC [EN 50126] angepasst wurde. Version: 1.0 Seite 23 von 51

96 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 9: Gitternetz für die Bewertung der Ausfallbedeutung In dem Gitternetz wird die Eintrittshäufigkeit gegen die entstehende Auswirkung eines Fehlers aufgetragen. Der spezifikationsgemäße Zustand eines Systems kann im Ursprung des Gitternetzes gefunden werden. Ein in der Fehleranalyse identifizierter Ausfall wird auf seine Eintrittswahrscheinlichkeit hin bewertet und in eine der sechs dargestellten Stufen eingruppiert. Danach erfolgt eine Bewertung der Auswirkungen des aufgetretenen Fehlers in den vier gezeigten Kategorien. Jetzt kann ein identifizierter Fehler in das Gitternetz eingetragen werden. Dabei kann nun die Bedeutung des Fehlers abgelesen werden. Je weiter die Einordnung des Fehlers in den oberen rechten Quadranten erfolgt, umso gefährlicher ist der Fehler und umso dringender sind Maßnahmen zur Verhinderung des Ausfalls zu treffen Optimierung Wurden die verschiedenen Ausfälle hinsichtlich ihrer Kritikalität bewertet, können für die erkannten Risiken entsprechende Vermeidungs- und Entdeckungsmaßnahmen erarbeitet werden, um so das System zu optimieren. Die Optimierung eines durch eine FMEA untersuchten und bewerteten Systems obliegt dem Hersteller, dem Betreiber und der zulassenden Stelle in gegenseitiger Absprache und kann z. B. durch einen geänderten Entwurf des technischen Systems oder durch das Aufstellen von Handlungsregeln für den Betrieb erfolgen. Die ergriffenen Maßnahmen werden in der FMEA-Tabelle festgehalten und es findet eine erneute Risikobewertung statt. Hierüber kann die Wirksamkeit der Optimierung festgestellt werden. Liegt auch nach erfolgter Optimierung die Risikoprioritätszahl zu hoch, müssen weitere Verbesserungsmaßnahmen entwickelt und umgesetzt werden Failure-Mode-, Effect- and Criticality-Analysis Die Failure-Mode-, Effect- and Criticality-Analysis (FMECA) ist die Erweiterung einer FMEA um eine Kritikalitäts-Analyse. Sie dient der Identifizierung und Bewertung der Auswirkungen von Gefährdungen durch die Bildung einer Risikoprioritätszahl (RPZ), die sich aus der Bedeutung, der Auftretenswahrscheinlichkeit und der Entdeckungswahrscheinlichkeit eines Fehlers zusammensetzt. Bei der Auswertung der Ergebnisse muss das Zustandekommen des RPZ-Wertes berücksichtigt werden. Derselbe Wert für eine RPZ kann aus einem ungefährlichen Ereignis mit einer hohen Auftretenswahrscheinlichkeit sowie aus einer kritischen Auswirkung mit einer geringen Auftretenswahrscheinlichkeit gebildet werden. Besonders die RPZ bei Ausfallarten mit kritischen oder katastrophalen Effekten müssen verringert werden. Dies kann durch Änderungen des Entwurfs oder Maßnahmen zur Früherkennung erreicht werden. Version: 1.0 Seite 24 von 51

97 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Die Methode sollte deshalb bereits zeitig in der Entwicklung angewandt werden, sobald ausreichend Daten vorhanden sind. Die FMECA berücksichtigt Bedienfehler durch den Menschen ebenso wenig wie die FMEA Hazard and Operability Study Die Hazard and Operability Study (HAZOP) ist eine qualitative Methode zur Identifizierung von Gefährdungen und potentiellen operationellen Problemen in Systemen mit menschlichen Anwendern. Sie wurde zuerst in der chemischen Industrie angewandt. Die HAZOP wird von einer Gruppe aus vier bis acht Mitgliedern durchgeführt, die verschiedene Bereiche repräsentieren sollen (u. a. Manager, Ingenieure, technisches Personal, Anwender, Experten für Human Factors und Gesundheit). Diese Mischung soll eine ausführliche und genaue Betrachtung gewährleisten. Die HAZOP kann bereits in der zeitigen Entwicklungsphase angewandt werden, sobald ausreichend Material vorliegt. Damit soll erreicht werden, dass frühzeitig erkannte Gefährdungen mit geringeren Kosten behoben oder reduziert werden können. Die HAZOP wird als eine Art strukturiertes Brainstorming durchgeführt. Sie betrachtet das System als eine Ansammlung von Knoten und verbindenden Flüssen. Es betrachtet Abweichungen von erwarteten Werten, welche selbst allerdings nicht überprüft werden. Die Beschreibung der Differenzen erfolgt mittels zuvor definierter Leitwörter (z. B. mehr, weniger, früher, umgekehrt). Der allgemeine Ablauf einer HAZOP ist in Abbildung 10 dargestellt und folgt dabei sieben Teilaufgaben: Abbildung 10: Ablauf des HAZOP-Prozesses Definition der Prozesselemente Bestimmung der erwarteten Werte für jedes Element Bestimmung der Abweichungen von den Planwerten und Beschreibung mit den zuvor definierten Leitwörtern Bestimmung der Auswirkungen der Abweichungen Identifizierung der Ursachen Identifizierung der Schutzmaßnahmen Identifizierung unzureichender oder fehlender Maßnahmen Die Dokumentation der Ergebnisse einer HAZOP kann in einer Tabelle erfolgen, die damit wiederum als Eingangswerte für andere Methoden, z. B. FTA oder ETA, genutzt werden. Version: 1.0 Seite 25 von 51

98 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Markov-Analyse Die Markov-Analyse ist eine graphische, quantitative Methode zur Darstellung der Systemzustände und Ereignisse sowie ihrer Verbindungen untereinander. Sie kann an Stelle einer FTA angewandt werden. Abbildung 11: Verwendete Zeichen in einem Markov-Graphen Die Systemzustände werden in der Markov-Analyse als Knoten, die Ausfall- (λ) und Reparaturraten (µ) als Übergänge zwischen den Knoten dargestellt (siehe Abbildung 11). Damit ist es möglich, auch redundante Systeme und Reparaturen darzustellen. Bei redundanten Komponenten lassen sich die verschiedenen Systemzustände zeigen, (z. B. alle Einheiten funktionstüchtig, eine Einheit defekt, alle Einheiten defekt, etc.). Die Markov-Graphen liefern eine graphische Modellierung, werden aber durch die Belegung der Zustandsübergänge mit Wahrscheinlichkeitswerten vorrangig für eine quantitative Auswertung genutzt. Abbildung 12: Markov-Graph Die Markov-Analyse ist als Analysemethode für allgemein akzeptiert, allerdings wird sie als Methode zur Erstellung von Sicherheitsnachweisen nicht anerkannt [SSS1997] Preliminary Hazard Analysis Die Preliminary Hazard Analysis (PHA) dient der Identifizierung möglicher Gefährdungen und ihrer Ursachen sowie der Folgenbewertung. Zugleich müssen bei schwerwiegenden Risiken Vorbeugemaßnahmen identifiziert und bestimmt werden. Die Anwendung der PHA sollte möglichst frühzeitig in der Entwicklung erfolgen, sobald ausreichend Daten vorhanden sind und bei Verfügbarkeit weiterer Daten und Identifizierung neuer Gefährdungen aktualisiert werden. Die Durchführung erfolgt in den nachstehenden Schritten: Identifizierung der möglichen Gefährdungen Beschreibung der Gefährdungen und der Folgen Identifizierung möglicher Ursachen der Gefahren Schwereklassifikation für die Gefährdung mit ihren Folgen Bei zu hohen Risiken Festlegen von Vorbeugemaßnahmen Die Identifizierung der gefährlichen Einheiten und Situationen kann anhand von Checklisten abgearbeitet werden. Die Gefährdungsidentifizierung und -bewertung sollte nach [FAA2000] zumindest die folgenden Punkte berücksichtigen: Version: 1.0 Seite 26 von 51

99 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Gefährliche Komponenten (z. B. Treibstoffe, Giftstoffe, Drucksysteme) Sicherheitsrelevante Elementschnittstellen (z. B. Materialkompatibilität, Elektromagnetische Interferenzen) Umweltbedingungen (z. B. extreme Temperaturen, Blitzeinschlag, Feuer) Verfahren für Betrieb, Tests, Instandhaltung und Notfälle (z. B. Analyse von Bedienfehlern, Lebensrettungsanforderungen) Einrichtungen, Anlagen und Training (z. B. Lagerung brennbarer Materialien, Lärmquellen) Sicherheitsrelevante Anlagen, Schutzvorrichtungen, Alternativen (z. B. Systemredundanz, Branderkennung und -bekämpfung) Mit Hilfe der in der PHA identifizierten Gefährdungen können Schwerpunkte für eine weitere Beobachtung, z. B. mit einer Fehlerbaumanalyse (FTA), gesetzt werden. Die Dokumentation einer PHA erfolgt in tabellarischer Form Sicherheitskonzept Die VDV-Schrift 161 schlägt als Mittel zur Untersuchung der funktionalen Sicherheit eines Gesamtsystems im Sinne der Empfehlung handelt es sich hierbei um ein schienengebundenes Fahrzeug die Erarbeitung eines Sicherheitskonzeptes vor. Das Sicherheitskonzept dient der Identifizierung und Bewertung von Gefahrenpotenzialen, die durch Fehlfunktionen im Gesamtsystem hervorgerufen werden können. Die zu untersuchenden Funktionen des Gesamtsystems werden im Vorfeld zwischen Betreiber, Hersteller und zulassender Stelle abgestimmt und festgelegt. Die VDV-Schrift 161 gibt hierfür eine Liste mit Funktionen, die im Rahmen des Sicherheitskonzepts untersucht werden sollten. Diese Liste ist lediglich als Empfehlung anzusehen Funktionalitäten In einem ersten Schritt werden im Rahmen der Erstellung des Sicherheitskonzeptes die zu untersuchenden Funktionen beschrieben. Der Sinn der Funktion innerhalb des Gesamtsystems und die Ausführung der jeweiligen Aktionen werden beschrieben. Dies geschieht anhand der Systemdokumentationen, aus denen diese Informationen zu extrahieren sind. Im Schritt II.1 wird daher die allgemeine Funktionalität beschrieben ohne an dieser Stelle auf etwaige Ausfälle bzw. Störungen und deren Auswirkungen oder Risiken einzugehen. Eine derartige Betrachtung wird im Schritt II.3 des Sicherheitskonzeptes durchgeführt. Nach- dem die allgemeine Funktionalität behandelt und die grundsätzlich im Gesamtsystem realisierte Sicherheitsphilosophie dargestellt wurde, kann im Schritt drei auf die möglichen Risiken, die durch Fehler in der Ausführung der Funktion entstehen können, eingegangen werden. Es wird analog zu der Gliederung in Schritt II.1 eine Ausfall- bzw. Störungsanalyse durchgeführt. Die Folgen der identifizierten Gefährdungen werden entsprechend dokumentiert, so dass im Rahmen der Erstellung des Risikographen der Worst-Case ausgewählt und weitergehend betrachtet werden kann Sicherheitsphilosophie Ziel des Sicherheitskonzeptes ist es sicherzustellen, dass das System im Falle eines eintretenden Fehlers immer in einen sicheren Zustand übergeht. Die Reaktionen, die vom System ausgeführt werden, sollten im Idealfall automatisch erfolgen. Das bedeutet für das Beispiel der Betrachtung eines Eisenbahnfahrzeuges, dass die zum Zugverband gehörenden Fahrzeuge jederzeit sicher zum Stillstand gebracht werden können. Die Maßnahmen zur Absicherung des Systems gegenüber Fehlern sind im Rahmen der Dokumentation der Sicherheitsphilosophie zu beschreiben. Die Sicherheitsphilosophie wird durch diverse Sicherheitsziele erreicht, die durch die Implementierung des Systems umgesetzt werden. Als Sicherheitsziele sind unter anderem anzusehen: Version: 1.0 Seite 27 von 51

100 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Die Systemkonstruktion ist ständig während des gesamten Entwicklungsprozesses auf das anzuwendende Sicherheitskriterium hin zu überprüfen. Gefährdungen sind so weit möglich durch den Einsatz von fail-safe "-Konzepten zu vermeiden. Gefährdungen sind durch den Einsatz von redundanten Architekturen (Zweikanalige Auslegung, diversitäre physikalische Konzepte) zu minimieren. Gefährdungen sind durch festgelegte Prüfzyklen (im Handbuch beschrieben) zu minimieren. Die Sicherheitsanforderungen in Design, Herstellung, Montage, Test, Inbetriebnahme und Betrieb einfließen lassen und diese erreichen. Identifizierte Gefährdungen sind zu unterbinden oder zu vermeiden, indem entsprechende Maßnahmen in Design und Handhabung implementiert werden. Gefährdungen, die aus besonderen Umgebungsbedingungen hervorgehen, minimieren. Gefährdungen, die aus Fehlhandlungen entstehen können, durch einheitliche Bedienung oder detaillierte Beschreibungen (Handbuch) über den gesamten Lebenszyklus des Systems minimieren. Die Gefahr von Unfällen zu minimieren. Die Folgen von Unfällen zu mindern Risikograph In einem vierten Schritt wird im Rahmen der Erstellung des Sicherheitskonzepts die zu untersuchenden und im Schritt II.1 und II.3 beschriebenen Funktionen auf Grundlage einer qualitativen Bewertung in Anforderungsklassen (AK) oder Safety Integrity Level (SIL) eingestuft. Die Einstufung erfolgt anhand von vier Parametern: Schadensausmaß (S) Aufenthaltsdauer von Personen im Gefahrenbereich (A) Gefahrenabwehr (G) Wahrscheinlichkeit des unerwünschten Ereignisses (W) Mit Hilfe dieser vier Parameter kann eine Risikobewertung stattfinden. Um die Wahl der unterschiedlichen Parameterausprägungen zu vereinfachen, bietet die [VDV 161/1] für ausgewählte Stufen Hilfen an, in welchen Fällen diese anzunehmen sind. Die angenommen Parameter werden in einen Entscheidungsbaum übertragen, aus dessen Pfaden sich direkt die abzuleitende Risikostufe ergibt. Aus der Übertragung der Risikobewertung in die Einstufung gemäß Safety Integrity Level kann bei Bedarf eine quasi-quantitative Bewertung des Risikos nach [IEC 61508] und [DIN EN 50126] erfolgen. Eine Quantifizierung ist jedoch durch [VDV 161/1] nicht vorgesehen. Auch im Rahmen der hier angewandten Methodik ist die Quasi-Quantifizierung lediglich als Option vorgesehen, um so einen Vergleich zwischen der sicherheitstechnischer Anforderung an die Teilsysteme und der spezifizierten Implementierung der Teilsysteme zu erlangen. Bei der Nutzung der hier vorgeschlagenen Quasi-Quantifizierung muss ergänzt werden, dass die Umsetzung der nach VDV angesetzten Anforderungsklassen in die Sicherheitsintegritätslevel auf der Basis der IEC erfolgt Functional Hazard Assessment Die Functional Hazard Assessment (FHA) ist eine qualitative Methode aus dem Luftverkehrsbereich. Sie dient der Identifizierung funktionaler Ausfälle. Ferner werden die Gefährdungen entsprechend ihrer Versagensarten klassifiziert. Gleichzeitig werden Schwerpunkte für weitere Untersuchungen gesetzt. Die Anwendung des FHA erfolgt zeitig in der Entwicklung. Bei Identifizierung neuer Funkti- Version: 1.0 Seite 28 von 51

101 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge onen oder Versagensarten muss sie aktualisiert werden. Die Darstellung der Ergebnisse erfolgt in einer Tabelle, die ebenfalls Vorsorgemaßnahmen enthalten sollte: Identifizierung der Funktionen Ermittlung der Versagensarten Ermittlung der Folgen Klassifikation der Versagensarten Ermittlung der Sicherheitsanforderungsstufen (DAL) Klassifizierung nach ARP No safety effect Minor Major Hazardous / Severe Major Catastrophic DAL E D C B A Tabelle 4: Versagensklassen und die zugehörigen DAL-Werte (nach [ARP 4754]) FHA wird in zwei Stufen durchgeführt, zuerst auf Flugzeugebene, anschließend auf der unter- geordneten Systemebene. Die Anwendung erfolgt auf beiden Ebenen ähnlich: Die Ermittlung der Versagensarten und ihrer Klassifizierung erfolgt durch Experten der verschiedenen Bereiche. Die Konsequenzenidentifizierung soll die Fähigkeiten der Flugbesatzung, ihre Aufgaben ordnungsgemäß auszuführen, berücksichtigen. Dazu zählen z. B. Hinweise oder Alarmmeldungen für die Piloten bei Problemen oder auch eingeschränkte Sicht bei Rauch. Abbildung 13: Fortpflanzung der Auswirkungen eines Versagens (nach WIK1998]) Die Klassifizierung der Versagensarten erfolgt anhand der Auswirkungen auf das Flugzeug, die Insassen und die Flugbesatzung, die in Tabelle 4 beschrieben sind. Bei den Bewertungen muss ferner die Betriebsphase, z. B. Rollen, Start oder Reiseflug berücksichtigt werden, in dem das Versagen auftritt. Bei unterschiedlichen Auswirkungen müssen getrennte Betrachtungen der Phasen erfolgen. Im Rahmen der Flugzeug-FHA erfolgt außerdem die Zuweisung der DAL anhand Tabelle 4. Die Klassifizierung keine Sicherheitsauswirkungen mit der DAL E, werden in der ARP 4754 eingeführt. Durch die CS-25 werden lediglich die vier übrigen Klassen genannt. In der zweiten Stufe, der System-FHA, wird die FHA für jedes einzelne Flugzeugsystem durchgeführt. Der Umfang ist abhängig von der Komplexität des Systems. Für einfache Systeme wird meist eine Überprüfung des Entwurfs ausreichend sein. Bei komplexeren Systemen sollte eine qualitative Top- Down-Methode ausgehend von der Flugzeugebene gewählt werden. Ein Flugzeug wird in mehrere Version: 1.0 Seite 29 von 51

102 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Systeme unterteilt, die wiederum diverse Subsysteme beinhalten. Das wird in Abbildung 13 am Beispiel einer Triebwerkssteuerung verdeutlicht. Diese gehört zum System Triebwerk, das zum Antrieb, welches wiederum ein Subsystem des Flugzeugs ist. Die Schwierigkeit liegt in der Identifizierung der Versagensauswirkungen durch alle Schichten hindurch, in der Trennung der Auswirkungen der Steuerung und der anderer Subsysteme. Eine Auswahl bekannter Probleme bei der Anwendung einer FHA werden in Wilkinson u. Kelly [WIK1998] aufgeführt und beschrieben Preliminary System Safety Assessment Das Preliminary System Safety Assessment (PSSA) ist eine iterative Methode aus dem Luftverkehr. Es wird in der ARP 4754 beschrieben. Das Ziel des PSSA besteht in der Überprüfung und der daraus resultierenden Gewährleistung, dass alle Versagensarten zuvor in der FHA erkannt wurden. Weiterhin sollen die Sicherheitsanforderungen um die abgeleiteten Sicherheitsanforderungen vervollständigt und die Notwendigkeit weiterer Vorsorgemaßnahmen ermittelt werden. Als Drittes soll aufgezeigt werden, wie die Systemarchitektur die Anforderungen bezüglich der Gefährdungen erreichen soll. Das PSSA kann zur Bewertung verschiedener Systementwürfe und zur Vermeidung zu hoher Anforderungen genutzt werden [DAW1999]. Während des PSSA werden die zu den identifizierten Ausfallarten gehörenden Ausfälle und Ausfallkombinationen ermittelt. Für diese Aufgabe kann z. B. eine FTA oder eine Markov-Analyse genutzt werden. Der Unabhängigkeitsnachweis der Separierungs- und Isolationsanforderungen kann mit einer CCA erfolgen. In dieser Phase müssen neben Hard- und Software-Fehlern auch operationelle Fehler berücksichtigt werden. Ist nach qualitativen oder quantitativen Analysen nicht zu erwarten, dass die Vorgaben erfüllt werden können, müssen alternative Vorsorgemaßnahmen aufgestellt werden. Sind zur Einhaltung der Bestimmungen weitere Auflagen erforderlich, müssen zu diesem Zweck abgeleitete Sicherheitsanforderungen definiert und beschrieben werden. Bei der Berechnung der Eintrittswahrscheinlichkeiten der Versagensarten muss die Dauer latenter Ausfälle und der Betrieb mit ausgefallenen Komponenten oder Systemen sowie die Möglichkeiten ihrer Entdeckung betrachtet werden. Oftmals können Ausfälle bereits durch die Flugbesatzung im normalen Betrieb entdeckt werden. In anderen Fällen können sie jedoch nur durch spezielle Untersuchungen aufgespürt werden. Durch das Aufstellen entsprechender Wartungs- und Instandhaltungsprogramme soll das rechtzeitige Auffinden der Ausfälle sichergestellt werden. Die Aufgaben und Intervalle dieser abgeleiteten Sicherheitsanforderungen werden im nachfolgend ausgeführten System Safety Assessment (SSA) verifiziert System Safety Assessment Das System Safety Assessment (SSA) verifiziert die Implementierung der Sicherheitsfunktionen mit den während des Functional Hazard Assessments (FHA) und des Preliminary System Safety Assessment (PSSA) aufgestellten Anforderungen, deren Ergebnisse hier als Eingangsdaten verwendet werden. Das SSA kann die folgenden Dinge enthalten: abgestimmte Wahrscheinlichkeiten externer Ereignisse Systembeschreibung mit seinen Funktionen und Schnittstellen Auflistung der Versagensarten Ergebnisse der CCA Ergebnisse qualitativer und quantitativer Analysen der Versagensarten Auflistung der sicherheitsrelevanten Instandhaltungsaufgaben und -intervalle Bestätigung über Berücksichtigung aller Gefährdungen der Implementierung des Systems mit anderen Systemen Version: 1.0 Seite 30 von 51

103 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Fazit zur Verfahrensübersicht Aus den Erläuterungen kann geschlossen werden, dass insbesondere im Hinblick auf die Nutzbarkeit der Verfahren für die Sicherheitsnachweisführung (letzte Spalte in Tabelle 5) nur sechs der insgesamt 13 betrachteten Verfahren als geeignet eingestuft wurden, wobei eines dieser Verfahren - die FHA - bislang ausschließlich für den Luftfahrtbereich eingesetzt wird und das Sicherheitskonzept lediglich im Eisenbahnbereich Anwendung findet. + gut geeignet, O bedingt geeignet, - schlecht geeignet Tabelle 5: Übersicht der beschriebenen Verfahren Für den Eisenbahnbereich sind lediglich die Verfahren ETA, FTA, FMEA/FMECA sowie das Sicherheitskonzept sinnvoll einsetzbar. Unterstützt wird diese Einstufung auch durch den vorhandenen Analyseansatz, der jeweils sowohl qualitativ als auch quantitativ erfolgen kann. Damit sind diese drei bzw. vier Verfahren - vom Grunde her sind FMEA und FMECA verfahrenstechnisch gesehen gleichzusetzen - aus der getroffenen Auswahl für eine weitere Verwendung zu nutzen. Es muss allerdings auch erwähnt werden, dass die ETA und FTA auf Grund des grafischen Ansatzes für eine Darstellung von komplexen Systemen nicht geeignet erscheinen. Die Abbildung eines komplexen Systems mit Sicherheitsverantwortung wird schnell unübersichtlich und ist nicht mehr beherrschbar. Daher kann hier zwar die grundsätzliche Vorgehensweise der Event Tree Analysis und der Fault Tree Analysis als verwendbar angesehen werden, die Darstellungsform ist zu verändern und im Hinblick auf die Abbildung von komplexen Systemen zu optimieren. Die übrigen Verfahren sind nach der hier getroffenen Einstufung nicht oder nur bedingt nutzbar und werden daher für den Aufbau einer Methodik nicht weiter betrachtet. Der Aufbau der Methodik erfolgt damit unter Zuhilfenahme der Verfahren Event Tree Analysis (ETA) Fault Tree Analysis (FTA) Failure Mode and Effect Analysis (FMEA) bzw. Failure Mode, Effect and Criticality Analysis (FMECA) Sicherheitskonzept 3.2 Evaluierung eines ALM-Werkzeuges für die Prozesse der Nachweisführung Grundlegende Betrachtung Die sicherheitstechnischen Analysen der Sicherheitsorganisation entsprechen der Detaillierung gemäß den jeweiligen Entwicklungsstufen. Basierend auf der Risikoanalyse werden die RAMS-Aspekte und Version: 1.0 Seite 31 von 51

104 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Darlegungen der Sicherheit auf den jeweiligen Betrachtungseinheiten durchgeführt. Die folgende Abbildung 14 verdeutlicht die einzelnen Analysestufen (siehe auch DIN EN 50126, Bild 9). Der Prozess des RAMS-Engineerings und -Managements wird in der DIN EN 50126, Bild 12, dargestellt. Wie den dort dargestellten Prozessketten zu entnehmen ist, sind die einzelnen Aspekte des Engineerings dediziert zu betrachten. Der Themenblock der Ausbildung und technischen Kompetenz wird in diesem Ergebnisbericht nicht näher betrachtet, da diese Maßnahmen individuell und firmenspezifisch umgesetzt werden und diese Kenntnis auch sehr vom Produkt bzw. der firmenspezifischen Verfahren abhängig sind. Der Fokus dieses Ergebnisberichts liegt in der Methodik. Es soll evaluiert werden, inwieweit die beschriebenen Methodiken durch eine geeignete "Tool-Box", basierend auf Standard-Werkzeugen, umgesetzt werden können, so dass eine vollständige und nachvollziehbare Beweiskette der Einhaltung der definierten Sicherheitsziele erreicht werden kann. Version: 1.0 Seite 32 von 51

105 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Exemplarisches Standardflußdiagramm RAMS Dokumente 1) Inhalte Risikoanalyse (SyHA) - Vorgaben des Betreibers - Ermittlung / Zuordnung THR - Anwendung CSM-VO -... Gefänrdungsanalyse (Gefänrdungsbeherrschung) (SyHA) - Ableitung / Bewertung der Gefährdungen/Risiken (betriebliche Sicht) - Durchführung der Gefährdungsanalyse - Beginn des Gefährdungslogbuchs (Hazard Log) - Vorgaben für das Sicherheitskonzept des generischen Typs -... Sicherheitskonzept (SySRS) - Definition der Sicherheitsziele - Umgang mit den Gefährdungen zur Garantie der Sicherheit - Umgang mit systemimmanenten Fehlern - Umgang mit system-externen Umgebungsbedingungen - Berücksichtigung Regelwerke -... Normenmanagementsystem 2) (NMS) Fault Tree Analysis (FTA) (z.b. SyTSR) Failure Modes and Effects Analysis (HwCFMEA) Zuverlässigkeits- / Verfügbarkeits- Berechnungen (MTBF, MTTR, etc.) (HwCRC) Sonstige Nachweisführungsmethodiken / Instandhaltungskonzept Sicherheitstechnische (RAMS) Anforderungen (teilweise SySRS, SyDS,...) Hinweise ) Abkürzungen gemäß Maßnahmenkatalog siehe Ergebnisbericht AG 3 NeGSt_Teilbericht_2200.0u3_1.0 2) Beschreibung eines Konzepts NMS siehe Ergebnisbericht AG 1 NeGSt_Positionspapier_AG1 Abbildung 14: RAMS-Prozess Version: 1.0 Seite 33 von 51

106 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Während die theoretischen mathematischen Modelle des RAMS-Engineerings bzgl. RAMS-Theorie / mathematischer Modelle von Seiten der Forschung analysiert und entsprechend abgeleitete Vorgehensmodelle bewertet worden sind, wurden die Anforderungen an den Managementprozess bislang noch sehr allgemeingültig beschrieben. Die Modellierung von Risiken und Fehlern, die zu einer Gefährdung führen, sei es in der Theorie sowie aufgrund von Unfällen, stand dabei im Fokus der bisherigen Forschung und Normierung. Anhand der konkreten Szenarien und vorgekommenen Ereignisse konnten allgemein gültige Klassifizierungen aufgesetzt werden. Dies zeigt sich u.a. in den Ergebnisberichten der AG2 "CSM-VO" und der "Bewertung der AVR" (siehe [NeGSt_CSM_Signifkanz], [NeGSt_CSM_AVR]). Zusätzlich wurden mathematische Modelle für die Berechnung einzelner System- bzw. Hardware- Szenarien entworfen, so dass eine theoretischen Berechnung eines Fehlerfalls sowie des verbleibenden Restrisikos möglich wurden. Diese Methoden und Techniken, wie z.b. Fehlerbaumanalyse oder FMEA, konnten in allgemein gültige und anerkannte Verfahren überführt werden, die nicht nur im Eisenbahnwesen, sondern auch in anderen sicherheitsrelevanten Systemen wie der Fahrzeugtechnik zum Einsatz kommen. Als Beispiel für die Modellierung von Risiken und Fehlereinschätzungen sei hier stellvertretend für den Stand der Publikationen genannt: Sicherheitstechnische Vorgehensweisen in Signaltechnik und Luftfahrt (Jens Braband, Hans- Joachim Reder), Signal+Draht, 2003, (Einheitliche Vorgehensmodell in der Sicherheitsindustrie) On the relationship of CENELEC and other safety standards (Jens Braband, Yuji Hirao und Jonathan F. Luedecke), Signal+Draht, 2003 Anwendung der Methode STAMP 1 auf den Eisenbahnunfall Brühl, Herr cand. Ing. Christian Brinkmann, 2003 Experience with quantified safety analysis (Jens Braband, Harald Peters), Signal+Draht, 2003 (Methodikvergleich quantitativer Sicherheitsanalysen) Systemvalidierung des EBICAB 2000 gemäß CENELEC (Ullrich Rentsch, Adam Moik), Signal+Draht, 2003 (Methodik V-Modell - Schwerpunkt Testen) Studienarbeit im Vertiefungsfach Spurgeführter Verkehr, Bewertung der Eignung der Safety Screening Technique im Eisenbahnwesen, Herr cand.-wirtschn.-ing. Nicolas Petrek, 2009 Security und Safety, ein neues Verfahren zur automatisierten Erkennung von Hindernissen im Bahnsteiggleis (Jörg Schütte, Hans-Christian Kaiser), hier: Kapitel 4 Sicherheit und Verfügbarkeit ((System-/Hardware-) FMEA, FTA Quellcode-Proof-Reading), Signal+Draht, 12, 2012 Methodiken für den Managementprozess wurden bislang aufgrund der nicht existierenden oder unzureichenden Werkzeuge nicht weiter betrachtet. Diese Managementprozesse wurden, abgeleitet aus den Normen, firmenspezifisch entwickelt und umgesetzt. Dies führte dazu, dass durch die internen manuellen Tätigkeiten die Erzeugung einer transparenten Übersichtlichkeit über die gesamte Prozesskette für Dritte schwer zu erkennen war bzw. nur durch das firmenspezifische Know-How schnell und effektiv zu gewinnen ist. Außerdem mussten externe Institutionen, seien es die Gutachter oder die Zulassungsbehörde, sich ein Verständnis für die jeweiligen firmenspezifischen Unterlagen erarbeiten. Dies führt auf beiden Seiten, der des Antragstellers sowie der Zulassungsbehörde, zu erheblichen Aufwänden. Ansätze, diesen Management-Prozess zu steuern, können den Publikationen entnommen werden, in denen die ersten Schritte der Einbindung dieser Prozesse in eine integrierte Toolkette diskutiert werden: Sicherheitsbezogene Anwendungsbedingungen - Gratwanderung zwischen Sicherheit und Aufwand (Friedemann Bitsch, Huw Gough), Signal+Draht, 11, STAMP - Systems Theory Accident Modeling and Process Version: 1.0 Seite 34 von 51

107 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Thema der safe.tech 2013: Komplexitätsbeherrschung in der sicherheitskritischen Software-Entwicklung durch agile Methoden im Umfeld der Bahntechnik (ITK Engineering AG (Dr. Robert Eschbach)): Ableitung und Umsetzung funktionaler und risikobeherrschender Maßnahmen bei der Betrachtung von zufälligen Systemausfällen und systematischen Fehlern in der Software Future is Now: werkzeuggestützte Formalisierung an Anforderung zur ganzheitlichen Verifikation sicherheitsrelevanter Systeme (BTS Embedded Systems AG (Dr. Tom Bienmüller, Dr. Udo Brockmeyer)): Unterstützung der Prozesse Spezifizierung, Test, Validation Aufgrund der Entwicklung einer domänenspezifischen Variante der ISO der AUTOSIG 2 wurden SPICE als Bewertungsrichtlinie der Unternehmensprozesse, mit dem ursprünglichen Schwerpunkt auf den Software-Erstellungsprozess, etabliert. Dieses Modell beschäftigt sich vorrangig mit der Prozess-Assessment-Modellierung und -Dimensionierung und ermöglicht eine Fähigkeits- oder Reifegrad-Bewertung. Seit 2006 wurde diese Norm zur Bewertung des Managementverfahrens in einen internationalen Standard ISO/IEC vollständig überführt. Gegenstand dieser Norm wurden dabei u.a. die Forderungen nach unterschiedlichen Traceability-Matrizen, die aufgrund von Spezifikationstools wie Doors heute State-of-the-Art sind. Eine besondere Betrachtung der Verfolgbarkeit der Sicherheitsvorgaben wurde nicht aufgenommen. Dies erfolgt vsl. in der ISO Part 10 "Safety extension", der sich allerdings noch in der Erstellung befindet. Methodiken für den Managementprozess können jetzt aufgrund des Fortschrittes der ALM-Tools in den Fokus der Umsetzung gesetzt werden. Am Beispiel des ALM-Tools Polarion wird im folgenden Kapitel gezeigt, dass für die bestehenden Standard-Work-Items wie o Rollendefinition, o Anforderungsmanagementsystem, o Aktivitäten-/Workflow-Planung, o Testfallmanagementsystem, o Definition der Prozesskette (Life Cycle Items), o Fehlermanagementsystem / Changemanagement maximal Anpassungen in Bezug auf Sicherheitsanforderungen notwendig sind. Dies und die intrinsische Unterstützung der FMEA in Polarion bietet damit eine geschlossene Toolkette für den RAMS-Managementprozess. Die folgende Abbildung verdeutlicht den Workflow gemäß FMEA innerhalb des Tools Polarion (Quelle: Polarionelibrary_FMEA Risk_FMEA How-To.pdf): 2 Die Unterschiedlichkeit zum allgemeinen Standard CMMI zur Bewertung der Unternehmensprozesse und dessen Reifegrad wird nicht betrachtet, da aufgrund der Thematik die Normierung innerhalb der sicherheitsrelevanten Systeme dies betrachtet wird. Version: 1.0 Seite 35 von 51

108 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 15: möglicher Workflow einer FMEA-Umsetzung innerhalb eines ALM-Tools Es ist zu erkennen, dass der Schwerpunkt der Toolentwicklung auf die Umsetzung von schon erfolgten Standardisierungen der RAMS-Methodiken, wie die Definition der FMEA-Technik DIN EN 60812, gelegt wird. Weitere standardisierte Workflows, wie sie u.a. in den theoretischen Grundlagen der RAMS-Berechnungsmethodiken (siehe Ergebnisbericht NeGSt_Ergebnisbericht_2500_Feinkonzept_Diagnose.doc) entnommen werden können, müssen dabei noch innerhalb der Toolkette entwickelt werden. Ob weitere Normen wie die deduktiven Verfahren FTA DIN oder weitere induktiven Verfahren wie HAZOP IEC (PAAG-Verfahren) oder Ereignisbaumanalysen DIN in diese ALM-Tools eingebunden werden, kann aus heutiger Sicht noch nicht abschließend bewertet werden. Jedoch kann zum jetzigen Zeitpunkt der Workflow schon evaluiert werden, da z.b. Grafiken wie Fehlerbäume etc. zu einzelnen Konzeptdokumenten hinzugefügt werden können. Als Beispiel für eine Evaluierung einer Prozesskette wurde die Klassifizierung von Anforderungen, die sich aus der FMEA ergeben, als Sicherheitsanforderungen (in Polarion Work-Item: FMEA Risk) herangezogen. Ein spezieller Workflow kann aufgestellt werden, der standardmäßig bestimmte Attribute, Traces etc. enthält. Durch die vorgegebenen Attribute können u.a. die Schwere, die Häufigkeit und die Art der Offenbarung pro FMEA-Artefakt eingegeben werden. Diese Attribute werden aufgrund der Einstufung des Risikos, der Wahrscheinlichkeit des Eintritts und der Häufigkeitseinschätzung sowie der Transparenz und zeitlichen Strukturierung der Offenbarung gepflegt. Ggf. können über eine Import/Export-Funktionalität (z.b. via Office-Excel) die Ergebnisse einer unabhängig durchgeführten FMEA in das Tool überführt werden. Durch die Implementierung der RAMS-Methoden in ein ALM-Tool ist der erste Schritt zu einer integrierten Toolkette inklusive des Risk-Management-Prozesses umgesetzt worden. Weitere Schritte bzgl. der Umsetzung werden im folgenden Kapitel dargelegt, in dem die Modellierung und Abhängigkeitsbetrachtung von Sicherheitsmanagement-Definitionen/Anforderungen/Fehlerbetrachtungen in einem ALM-System evaluiert werden. Zu erkennen ist, dass durch die Möglichkeiten der toolunterstützten Prozesskette die Nachvollziehbarkeit der Sicherheitsaspekte einfacher möglich ist und so bei Änderungen von Komponenten, die aufgrund des Einsatzes von COTS-Elementen öfter auftreten können, die Erstellung eines Änderungsberichts effektiv und flexibel umgesetzt werden kann. Es sollte auf standardisierte Schnittstellen einzelner Komponenten innerhalb der Prozesskette (wie Anforderungs-, Testmanagement oder Aufgabenverfolgung) geachtet werden, so dass Daten unterschiedlicher ALM-Tool-Hersteller ausgetauscht werden können. Erste Ansätze einer Standardisierung dieser Interoperabilität kommen aus der Automobil-Industrie. Ein Austausch von Anforderungen inklusive Anhänge und Attribute kann heute mittels des Standards RIF (Requirements Interchange Format) zwischen unterschiedlichen ALM-Tools erfolgen. Im Gegensatz zur Verwendung von Standard- Office-Komponenten, wie Word-, Excel- oder PDF-Dateien, ermöglicht dieser Standard den verlustfreien Datenaustausch aller relevanten Daten inklusive Traceability zwischen den Tools. Da das nur durch ein gemeinsames Datenmodell möglich ist, muss der Prozess der Standardisierung des Datenaustausch einerseits und des Datenmodells andererseits zentral aufgesetzt werden, um die Interoperabilität zukünftig sicherzustellen. Dies sollte in einem weiteren Fördervorhaben konkretisiert werden Vorschlag für einen ALM-Workflow zur Nachweisführung von Änderungen Gemäß dem Ergebnisbericht der AG1 dieses Fördervorhabens kann festgehalten werden, dass die "unternehmensinterne Prozessregelungen und Arbeitsanweisungen immer schon der kritischen Bewertung unterzogen gewesen (Anmerkung: sind), die effektiv Einfluss auf die Qualität und Sicherheit der Produkte im Produktlebenszyklus hatten. Die Erfahrung und Fachkompetenz spiegelt sich in den Qualitätshandbüchern der beteiligten Unternehmen wider. Der Erhalt der Qualität und Sicherheit der Produkte im Produktlebenszyklus wird durch die ständige Kontrolle im Rahmen von Auditierungen sichergestellt. Über diese externen Auditierungen wird abgesichert, dass die unternehmensinternen Prozessregelungen und Arbeitsanweisungen auch jeweils den aktuellen Stand der Normung berücksichtigen" Version: 1.0 Seite 36 von 51

109 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge In diesem Kapitel wird dargelegt, dass durch den Einsatz von ALM-Tools ein einheitlicher integrierter Workflow für sicherheitsrelevante Anwendungen aufgestellt werden kann. Damit ist es für Dritte möglich, dass Qualität und Sicherheit nicht nur mittels einzelner Audits überprüft werden können, sondern auch die Datenbasis der Nachweisführung firmenübergreifend in standardisierten Formaten zur Verfügung steht. Im ersten Schritt werden dazu die standardmäßig vorhandenen Attributierungen, die vom Tool angeboten werden, initialisiert. Zunächst wird ein Projekt angelegt. Abbildung 16: Anlegen eines Projekts Als nächster Schritt werden die besonderen Rollen, die gemäß Normen erforderlich sind, angelegt. Als Beispiel sei hier die Rolle des Safety-Managers genannt. Abbildung 17: Definition von Rollen Daraufhin müssen die speziellen Aktivitäten, die normativ vorgegeben worden sind, definiert werden, falls diese Prozesse nicht schon Bestandteil des Tools sind. Bei der Evaluierung der ALM-Tools hat sich herausgestellt, dass die normativ vorgegebenen Artefakte der einzelnen Phasen standardmäßig von den Toolherstellern angeboten werden. So können die Dokumente, die pro V-Modell- bzw. CE- NELEC-Phase vorgeschrieben sind, über diese Workflows schnell erstellt werden. Besonders hervorzuheben ist, dass in einigen ALM-Tools auch die Integration nicht nur der Software- Aktivitäten sondern auch die der Hardware-Entwicklung vorbereitet sind. So werden standardmäßig von einem Hersteller die elektro-/mechanischen Spezifikationen als Workflow angeboten. Die Evaluierung hat gezeigt, dass die Trennung der PLM-Workflows (Managementprozess für den gesamten Lebenszyklus eines Produkts von der Konzeption über das Design und der Fertigung bis hin zur Instandhaltung) und der ALM-Workflows (Prozessbeschreibung der IT und Software-Erstellung) aufgehoben wird. Version: 1.0 Seite 37 von 51

110 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 18: Definition der Aktivitäten gemäß Phasenmodell Als nächster Schritt sind die Aktivitäten des RAMS-Prozesses, wie sie in den vorherigen Kapiteln beschrieben worden sind, zu definieren. Am Beispiel eines FMEA-Workflows, der von einem ALM- Tool-Hersteller angeboten wird, wird gezeigt, dass dieser Workflow in eine Prozesskette eingebunden werden kann. Version: 1.0 Seite 38 von 51

111 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 19: FMEA-Workflow Basis jeder Betrachtung bilden die Systemanforderungen. Diese werden häufig in einem Office- Dokument toolgestützt formuliert. Die Attributierungen, wie z.b. die Verlinkung, erfolgen innerhalb der definierten projektspezifischen Work-Items. Im Folgenden wird eine Ausgabe der Systemanforderungen in Tabellenform gezeigt. Abbildung 20: tabellarische Darstellung von Systemanforderungen Version: 1.0 Seite 39 von 51

112 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Basierend auf den Systemanforderungen können die Aktivitäten des RAMS-Prozesses gestartet werden. Z. B. werden einzelne Risiken sowie die daraus abgeleiteten Anforderungen definiert. In der Abbildung sind dabei besondere Attribute zu erkennen, die nicht Gegenstand einer "normalen" Systemanforderung sind, wie die Einschätzung der Risk-Priority. Abbildung 21: Definition einer Gefährdung Als nächster Schritt ist die Traceability einer Gefährdung zu den abgeleiteten Anforderungen nachzuweisen, In dem folgenden Beispiel wird eine Gefährdung zu einer Systemanforderung verlinkt. Dies kann durch einen Workflow definiert werden. In einem realen Projekt würde diese Traceability jedoch auf eine Verlinkung zum Sicherheitskonzept erweitert werden müssen. Durch diese verschiedenen Traceability-Matrizen würde dann der nachgelagerte Prozess der Nachweisführung auf einfache Weise sowohl die fachlichen als auch die sicherheitsrelevanten Zusammenhänge aufzeigen. Die Hardwarewie die Software-Entwicklung können somit schnell alle Vorgaben erkennen und entsprechend in der weiteren Detaillierung aufgreifen. Version: 1.0 Seite 40 von 51

113 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 22: Generierung einer Verlinkung Gefährdung ( Risk ) zu Anforderung Abbildung 23: Darstellung der Verlinkung im Work-Item Als Ergebnis kann damit für den RAMS-Manager eine Übersicht erstellt werden, die klar aufzeigt, welche Gefährdungen/Risiken analysiert worden sind. Die Besonderheit bei diesem Workflow ist, dass neben der Verlinkung auch speziellen Aktionen einer Gefährdung zugeordnet werden können, die ebenfalls für alle nachfolgenden Aktivitäten angezeigt werden. Die folgende Abbildung zeigt eine tabellarische Übersicht über die angenommenen Risiken. Abbildung 24: Auszug aus den Daten einer Gefährdung mit Definition einer Aktion Zusätzlich zu speziellen Aktionen, die zugeordnet werden können, können auch nachrangige Designentscheidungen mit der Gefährdung verlinkt werden. Als Beispiel wurde das Risiko mit einer Anforderung des Typs "mechanische Entwicklung" verlinkt (hier: ein spezieller Filter muss eingebaut werden). Version: 1.0 Seite 41 von 51

114 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 25: Ableitung einer Hardware-Anforderung aus einer Aktion In der Nachweisführung ist durch die Auswahl von diesen genannten Traceability-Matrizen u.a. jederzeit eine Übersicht über die Durchführung der erforderlichen Aktionen möglich. Zeitgleich kann innerhalb des Workflows noch definiert werden, welche Prüfungen/Reviews bzw. Status die einzelnen Artefakte durchlaufen müssen. Entsprechend wird der RAMS-Manager automatisch informiert, wenn er bestimmte Überprüfungen verifizieren muss bzw. wenn entsprechende Nachweisführungen, relevant für die speziellen Technischen Sicherheitsberichte, zu seiner Bewertung vorliegen. Anbei wird in der Übersicht gezeigt, dass die Aufgabe des Einbaus eines Filters erfüllt wurde und ein entsprechender Review-Bericht vorliegt. Abbildung 26: Übersicht über die Status der Gefährdungen Sonderfall: COTS-Betrachtung Standardindustriekomponenten zeichnen stetige Produktverbesserungen aus. Damit diese Innovationen in zugelassenen Systemen zeitnah zum Einsatz kommen können, sollten im Workflow die Aspekte wie Flexibilität oder einfache Erstellung von Änderungsberichten und Nachweisdokumenten berücksichtigt werden. Das "Verfahren zur Vereinfachung des Zulassungsverfahrens bei Änderungen von bereits nach EN zugelassenen Hardware-Komponenten" zeigt schon auf, dass durch die Wahl bestimmter Klassifizierungen der einzelnen Hardware-Komponenten einfache und zeitlich kurzfristige Änderungszulassungen erreicht werden können. Als erste Schritte in der Klassifizierung sollten folgende Analysen im Design berücksichtigt werden: Version: 1.0 Seite 42 von 51

115 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Definition des COTS-Produktes, Darlegung der Klassifizierung in sichere und nicht-sichere Komponenten, Spezifikation der Funktionalitäten, die die Sicherheit garantieren, Darlegung der Rückwirkungsfreiheit, abgeleitete Aktionen zur Kapselung von Fehlern etc., sowie weitere RAMS-Betrachtungen. Durch die im vorangegangenen Kapitel genannten Workflows bzw. Traceability-Matrizen können die oben genannten Kriterien schnell und flexibel umgesetzt werden. Neben der allgemeinen Definition des Workflows müssen somit zu Projektstart generelle Attribute der einzelnen Artefakte definiert werden, damit diese Daten entsprechend vorliegen. Im folgenden Beispiel wird der Filter als COTS- Komponente (siehe Attribut: Categories) gesetzt. Abbildung 27: Definition COTS Durch ein weiteres Attribut Changes allowed, kann der RAMS-Manager für alle Prozessbeteiligten nachvollziehbar festlegen, dass eine Änderung dieses Bauteils keine Auswirkung auf die Sicherheit des Systems hat. Abbildung 28: Deklaration des COTS-Produkts als "Nicht-sichere-Komponente" Der Releasemanager kann sich jederzeit über die Änderungen des Produkts informieren und entsprechend dem Zulassungsverfahren die angezeigten Veränderungen gemäß den hinterlegten Workflows initiieren. Version: 1.0 Seite 43 von 51

116 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 29: Historie eines Work-Items Als nächstes Beispiel ist ein Workflow für den Wechsel eines Bauteils definiert worden. Eine Freigabe durch den RAMS-Manager ist Bestandteil dieses Workflows. Abbildung 30: Change Request für ein COTS- Bauteil Durch die Verlinkung kann erkannt werden, dass Prüfaktivitäten erforderlich sind. Version: 1.0 Seite 44 von 51

117 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Abbildung 31: Verlinkung Suspect Abbildung 32: Verlinkung suspect beim Objekt Verwaltung eines Gefährdungslogbuchs Das Gefährdungslogbuch sowie das Aufsetzen eines entsprechenden Prozesses stellen eine besondere Herausforderung für die Nachweisführung im Zulassungsprozess dar. Das Gefährdungslogbuch wird Version: 1.0 Seite 45 von 51

118 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge zu Projektbeginn aufgesetzt und wird bis zum Projektende von ggf. unterschiedlichen Instanzen fortgeschrieben. Die Definition eines Gefährdungslogbuchs kann zu Projektbeginn in Analogie zur Definition von sicherheitsbezogene Anwendungsbedingungen erfolgen. Abbildung 33: Definition von Work-Item Types Durch Definitionen von sogenannten Round-Trips, d.h. Export von Daten (inklusive Attributierungen) an Dritte, nachvollziehbares Einarbeiten von Änderungen durch Dritte, sowie Re-Import der bearbeiteten Daten über etablierte Standard-Schnittstellen ergibt sich eine Möglichkeit, die Gefährdungslogbücher einzelner Firmen zentral bei Betreiber bzw. Aufsichtsbehörde zu verwalten. Ob diese Möglichkeit praktisch umgesetzt werden kann, sollte mit den beteiligten Organisationen außerhalb dieses Fördervorhabens NeGSt diskutiert werden Ergebnis der Evaluierung Das oben behandelte Beispiel zeigt, dass die Änderung eines COTS-Bauteils durch die konsequente Einbindung in eine Tool-gestützte Prozesskette für nicht-sichere Komponenten einfach und nachvollziehbar gestaltet werden kann. Eine Prozessbeschreibung, die einen normgerechten Umgang mit sicheren Komponenten hinsichtlich der erforderlichen Nachweisführung gewährleistet, sollte als Workflow ebenfalls einfach umgesetzt werden können. Zu erkennen ist, dass eine Prozesskette bzgl. der Punkte Planung der erforderlichen Änderungen, einfache Zusammenarbeit der unterschiedlichen Rollen gemäß CENELEC EN 50126, Umsetzung der Vorschriften durch Rückverfolgbarkeit über den gesamten Lebenszyklus, Etablierung der Grundlagen für laufende Funktionsverbesserungen durch flexible, regelbasierte Prozessumsetzung, Echtzeitberichte und integrierte Best Practices sowie Version: 1.0 Seite 46 von 51

119 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Sicherung der Flexibilität durch die Anpassung bewährter Verfahren an Teams jeder Größenordnung oder Zusammenstellung einfach in einem ALM-Standardtool implementiert werden kann. Zusammenfassend kann festgestellt werden, dass eine Evaluierung des Einsatzes von COTS- Produkten nicht nur innerhalb des zu erstellenden Produkts erfolgen sollte, sondern dass aktuell auch der Einsatz von Standardtools in der Prozesskette für ein Zulassungsverfahren geprüft werden sollte. Die Evaluierung des ALM-Tools Polarion hat gezeigt, dass die Anforderungen der unterschiedlichen Normen, z.b. die Industrienorm IEC oder Bahnnormen CENELEC, in Prozess-Workflows hinterlegt werden können, die zusätzlichen Anforderungen der CENELEC-Normen durch Add-Ins in den ALM-Tools abgedeckt werden können, mit dem Ziel, die teilweise vorhandene Zertifizierung nach IEC in eine nach CENELEC zu überführen spezielle Workflows definiert werden können, die eine Harmonisierung über die unterschiedlichen Normen (Industrienorm sowie Bahnnorm CENELEC) ermöglicht die Workflows differenziert in Abhängigkeit, welche Sicherheitsverantwortung die jeweilige COTS-Komponente trägt, definiert werden können. Basis der Definition dieser Workflows ist neben den Definitionen der Anforderungen aus den Normen die Festlegung der erforderlichen Work-Items von Seiten des Betreibers, des Gutachters bzw. der Aufsichtsbehörde. Zusätzlich dazu werden Add-ins für ALM-Tools von Dritten unterstützend angeboten. Die Zusammenführung dieser Artefakte sollte in einem weiteren Fördervorhaben evaluiert werden, damit durch standardisierte Work-Items/-Flows ein vereinfachtes Zulassungsverfahren resultieren kann. Angesichts des vermehrten Einsatzes von COTS-Produkten (Hardware sowie Software und auch zwischenzeitlich Mischformen) und der daraus resultierenden Obsolezenz-Problematik kann durch Aufsetzen eines standardisierten Workflows der erforderliche notwendige Managementaufwand minimiert werden. Die bisherigen Analysen fokussierten sich auf den RAMS-Prozess unter besondere Betrachtung von COTS-Produkten. Die daraus hergeleiteten Prozesse sollten auch von den nachgelagerten Entwicklungsprozessen Hardware wie Software betreffend übernommen werden. Eine Nachweisführung der Einhaltung der RAMS- bzw. COTS-Vorgaben muss dabei so aufgesetzt werden, dass von der Designphase bis zur Integration eine durchgängige Verfolgung der Anforderungen aus Fehlerbetrachtungen, aus dem Sicherheitskonzept, der Gefährdungsanalyse, der Fehlerkapselung von COTS-Produkten und FTA-/FMEA einfach, schnell und kostengünstig möglich ist. Die diesbezüglichen Analysen können dem Ergebnisbericht NeGSt_Ergebnisbericht_2300AG5_Ansätze zur Optimierung toolgestützter Teststrategien entnommen werden. Version: 1.0 Seite 47 von 51

120 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Zusammenfassung und Ausblick 4 Zusammenfassung und Ausblick Zusammenfassend können folgende Punkte festgehalten werden: Stand der Technik ist es, dass heute schon eine Standardisierung der erforderlichen Dokumentation weit fortgeschritten ist. Die Erkenntnisse der AG3 zeigen, dass ein einheitlicher Maßnahmenkatalog für die Dokumentation firmenübergreifend erstellt werden kann. Die normativen Anforderungen an den Managementprozess sind in einer Reihe von ALM-Tools bereits berücksichtigt und hinreichend abgedeckt. In Bezug auf die Bahnnorm sind Anpassungen und Ergänzungen notwendig und möglich, wie hier prototypisch gezeigt. COTS-Produkte benötigen im Konzept des Sicherheitsmanagements von Beginn an eine gesonderte Fehlerbetrachtung und -strategie bzgl. der Kapselung. Durch Attributierung der sich daraus ergebenden Anforderungen kann ein Standard-Prozess definiert werden, der ein einfaches Zulassungsverfahren ermöglicht, so dass der Austausch der COTS-Komponenten kein Hinderungsgrund für dessen Einsatz mehr sein sollte. Eine Erhöhung der Innovationsfähigkeit kann erreicht werden, wenn die Kompatibilitätsprobleme der Normen durch eine prozessbezogene Anforderungsspezifikation und eine Strategie zur einer Fehlerbehebung/-kapselung von vornherein geplant wird. Dedizierte Workflows wie die Führung eines Gefährdungslogbuchs können implementiert werden. Über standardisierte Schnittstellen könnten Gefährdungslogbücher zentral verwaltet werden. Diese Möglichkeit muss allerdings noch näher evaluiert werden. Die von der Arbeitsgruppe aus VDB, DB Netz AG und EBA erstellte Fassung des Entwurfes der VV NTZ (ÜGR Stufe 2) stellt u.a. die Erfordernisse an die Prozesskette in den Fokus. Aufgeführt seien hier einige Zitate: "Dabei ist insbesondere zu beachten, dass die Anforderungsbeschreibung ein die Anforderungen vollständig umfassender iterativer Prozess über den gesamten Lebenszyklus ist. Die dabei zu berücksichtigenden Abhängigkeiten schließen in den jeweiligen Schritten auch die Integrationsbetrachtungen bis zur Integration in den Bahnbetrieb mit ein." "Der dazu notwendige Analyse- und Entscheidungsprozess muss strukturiert, nachvollziehbar und ohne besonderes technisches Hilfsmittel auf Zuverlässigkeit prüfbar dokumentiert sein." "Dabei wird nachdrücklich auf die enorme Bedeutung der verantwortlichen Prüfung auf Systemebene und die explizite Erklärung für das Produkt als Basis für Folgeprozesse hingewiesen." "Während der Phase Pflichtenheft werden vom Hersteller die einzelnen Prozessschritte zur Behandlung des Betrachtungsgegenstandes festgelegt und die Verantwortlichkeiten geregelt." "Sind bei allen Neu- und Änderungsentwicklungen nach CENELEC geeignete quantitative Sicherheitsanforderungen definiert und nachgewiesen worden?. Sind bei Anwendung Sicherheitsziele vorhanden (Risikoanalyse) und die getroffenen Annahmen nachvollziehbar und korrekt?" Aus dieser Betrachtung der Arbeitsgruppe NTZ sowie den Ergebnissen der AG5 kann abgleitet werden, dass neben der Definition der firmenspezifischen Projektabwicklung eine durchgehende Prozesskette mittels eines ALM-Tools aufgestellt werden sollte. Durch diese Definitionen allgemeiner Workflows können die Prozesse optimiert werden, was wiederum zu einer vereinfachten und terminlich verkürzten Zulassung bzw. Änderungszulassung führen kann. Aufbauend auf den Ergebnissen dieses Fördervorhabens sollte eine Definition dieser Prozesse und deren Optimierungen erfolgen. Version: 1.0 Seite 48 von 51

121 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Anhang 5 Anhang 5.1 Anhang 1: Referenzen AKB AMB2001 ARP 4754 BRA2004 BRA2006 Alran, Dominique; Berg, Paul van den; Kuijlen, Hans (2004): European Commission Fifth Framework Programme SAMRAIL - D.2.3: Common Safety Methods, Report. SAMRAIL Consortium Amberkar, Sanket; Czerny, Barbare J.; D Ambrosio, Joseph G.; Demerly, Jon D.; Murray, Brian T. (2001): A Comprehensive Hazard Analysis Technique for Safety-Critical Automotive Systems. SAE Technical Paper Series, SAE 2001 World Congress - Papernumber , bis , Detroit, Michigan, SAE International - The Engineering Society for Advancing Mobility Land Sea Air and Space, ISSN: SAE ARP 4754: Certification Considerations for Highly-Integrated or Complex Aircraft Systems. Stand: April 1996, Systems Integration Requirements Task Group (AS-1C, ASD) - Society of Automotive Engineers (SAE) Braband, Jens (2004): Risikoakzeptanzkriterien und -bewertungsmethoden Ein systematischer Vergleich. Signal+Draht, Volume 96, Ausgabe 4/2004, Seiten 6-9, Eurailpress Tetzlaff-Hestra GmbH und Co. KG, Hamburg Braband, Jens; Brehmke, Bernd-E.; Griebel, Stephan; Peters, Harald; Suwe, Karl-Heinz (2006): Die CENELEC-Normen zur Funktionalen Sicherheit. Edition Signal+Draht - Eurailpress Tetzlaff-Hestra GmbH und Co. KG, Hamburg, ISBN DAW1999 Dawkins, S. K.; Kelly, T. P.; McDermid, J. A.; Murdoch, J.; Pumfrey, D. J. (1999): Issues in the Conduct of PSSA. Proceedings of the 17th International System Safety Conference (ISSC), Seiten 77-86, System Safety Society (SAE) DEF STAN EHS2003 FAA2000 FAA2005 HLH2005 HSE2001 KNE2001 LIG LIG MIE2004 NeGSt_AG3 NeGSt_CSM "Ministry of Defence - Defence Standard Safety Management Requirements for Defence Systems - Part 1 - Requirements - Issue 4" in der Version vom , Defence Equipment and Support, UK Defence Standardization, Glasgow Environmental Health and Safety - University of Washington (1999/2003): Radiation Safety Manual - Section 7: ALARA Program. Radiation Safety Office - Environmental Health and Safety (EH+S) der Universität Washington, Seattle Federal Aviation Administration (2000): FAA System Safety Handbook. Internetquelle: management/ss handbook (Stand: Januar 2009) Federal Aviation Administration / EUROCONTROL (2005): FAA / EU- RO- CONTROL ATM Safety Techniques and Toolbox - Safety Action Plan-15. Version 1.0 vom Hlinomazová, Z.; Hrazdira, I. (2005): ALARA - Principle and Safety Problems of Diagnostic Ultrasound. SCRIPTA MEDICA, Volume 78, Ausgabe 6/2005, Seiten , Faculty of Medicine, Masaryk University, Brno Health and Safety Executive (2001) - Reducing risks, protecting people - HSE s decision-making process. HSE Books, ISBN Knepper, Roger (2001): Technische Sicherheit - Der Sicherheits- und Zuverlässigkeitsprozess in der zivilen Luftfahrt. In: Achtes Kolloquium Luftverkehrs an der Technischen Universität Darmstadt, Wintersemester 2000/2001, Seiten , Arbeitskreis Luftverkehr der Technischen Universität Darmstadt [Hrsg.], Darmstadt, ISBN Liggesmeyer, Peter (2008): Safety and Reliability of Embedded Systems - Risikoakzeptanz-Verfahren. Vorlesungsunterlagen, Wintersemester 2008, Technische Universität Kaiserslautern Liggesmeyer, Peter (2008): Safety and Reliability of Embedded Systems - Safety and Reliability Analysis Models: Overview. Vorlesungsunterlagen, Wintersemester 2008, Technische Universität Kaiserslautern Mihm, Peter; Eckel, Andreas (2004): European Commission Fifth Framework Programme SAMRAIL - WP 2.4 Acceptabel Risk Level - Final Report. SAM- RAIL Consortium NeGSt_Teilbericht_2200.0u3_1.0.pdf NeGSt_Ergebnisbericht_2100_AUM_ pdf Version: 1.0 Seite 49 von 51

122 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Anhang NeGSt_CSM_Signifkanz NeGSt_Ergebnisbericht_2100_Signifikanz_ pdf NeGSt_CSM_AVR NeGSt_Ergebnisbericht_2100_AVR_ pdf RSS2007 Rail Safety and Standards Board [Hrsg.] (2007): Engineering Safety Management (The Yellow Book) - Volumes 1 and 2 - Fundamentals and Guidance. 4. Auflage, London, ISBN SAL2008 Salter, Paul (2008): National Rail Safety Guideline - Meaning of Duty to Ensure Safety - So Far As Is Reasonably Practicable. National Transport Commission Australia, Melbourne, ISBN SSS1997 System Safety Society, New Mexiko Chapter (1997): System Safety Analysis Handbook. Albuquerque, Library of Congress Catalog Card Number (CD-ROM Version) VDA 4.2 VDA-Band 4.2: "Qualitätsmanagement in der Automobilindustrie - System FMEA", Stand: August 2006, Verband der Automobilindustrie e.v. (VDA) VDV 161/1 VDV-Schriften 161/1: Sicherheitstechnische Anforderungen an die elektrische Ausrüstung von Stadt- und U-Bahn-Fahrzeugen, Teil 1: Grundlagen, Stand: 04/2005, Verband Deutscher Verkehrsunternehmen (VDV) VES2002 Vesley, William; Stamatelatos, Michael; Dugan, Joanne; Fragola, Joseph; Minarick, Joseph; Railsback, Jan (2002): Fault Tree Handbook with Aerospace Applications. NASA Office of Safety and Mission Assurance, Washington, D.C. VIL1992 Villemeur, Alain (1992): Reliability, availability, maintainability and safety assessment - Volume 1: Methods and Techniques. John Wiley and Sons Ltd, Chichester, ISBN WER2002 Wery, Sten (2002): Anwendung der Functional Hazard Analysis (FHA) in der Eisenbahnsignaltechnik am Beispiel ETCS Level 2. Diplomarbeit an der Technischen Universität Dresden, Fakultät Verkehrswissenschaften Friedrich List, Institut für Verkehrssystemtechnik WIK1998 Wilkinson, P. J.; Kelly, T. P. (1998): Funtional Hazard Analysis for Highly Integrated Aerospace. Systems. Certification of Ground/Air Systems Seminar (Ref. No. 1998/255), Seiten 4/1-4/6, London 5.2 Anhang 2: Abkürzungen Abk. Langform / Erläuterung ALARA As low as reasonably achievable ALARP As low as reasonably practicable ALM Application Livecycle Management ARP Aerospace recommended practice BMWi Bundeswirtschaftsministerium CCA Common Cause Analysis CENELEC Comité Européen de Normalisation Électrotechnique CMA Common Mode Analysis COTS Commercial off the shelf DAL Development Assurance Level DIN Deutsches Institut für Normung DRA Differential Risk Aversion EBICAB ist eine Familie signaltechnisch sicherer Zugbeeinflussungssysteme EBO Eisenbahn- Bau- und Betriebsordnung EN Europäische Norm Version: 1.0 Seite 50 von 51

123 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge Anhang ETA FHA FMEA FMECA FTA GAMAB GAME HAZOP HR IEC ISO LST MEM MGS PHA PRA PSSA RAMS ReqIF/RIF RPZ SFAIRP SIL SPICE SSA THR VDV ZSA Event Tree Analysis Functional Hazard Assessment Failure Mode and Effects Analysis Failure Mode, Effects and Criticality Analysis Fault Tree Analysis Globalement au moins aussi bon Globalement au moins equivalent Hazard and Operability Study Hazard-Rate International Electrotechnical Commission International Organization for Standardization Leit- und Sicherungstechnik Minimum endogenous mortality Mindestens gleicher Sicherheit Preliminary Hazard Analysis Particular Risk Assessment Preliminary System Safety Assessment Reliability, Availability, Maintainability, Safety Requirements Interchange Format Risikoprioritätszahl So far as is reasonably practicable Sicherheitsintegritätslevel Software Process Improvement and Capability Determination System Safety Assessment Tolerierbare Hazard-Rate Verbund Deutscher Verkehrsunternehmen Zonal Safety Analysis Version: 1.0 Seite 51 von 51

124 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Teilbericht AP 2300 Ansätze zur Optimierung toolgestützter Teststrategien Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

125 Ansätze zur Optimierung toolgestützter Teststrategien Änderungsverfolgung Datum Bearbeiter Version Inhalt Suter 0.1 Erstellung Grobkonzept Suter 0.2 Erstellung Feinkonzept Suter 0.3 Erste Ausgabe Suter 0.4 Abschluss Möller-Neustock 0.5 Review Suter 0.6 Abschluss Neustock 0.7 Review Neustock Winkler 1.0 Finalisierung Inhaltsverzeichnis 1 Einleitung Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement Fehlerdefinition Gefährdungsklassen FMEA Grundlagen Sicherheitsintegritätslevel (SIL) Fehlerbaumanalyse (FTA) Fehlererkennung Ausfallbetrachtungen Bauteilbetrachtung Maßnahmen zu einer höheren Wahrscheinlichkeit zur Aufdeckung von Fehlern Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien Überblick über die Zielplattform Toolchain Testvorgaben Testkonzept für das Generische Produkt Schritt 1: Erstellen der Prüffallspezifikation für eine Steuereinheit Schritt 2: Prüffalldurchführung am Realsystem Schritt 3: Prüffalldurchführung am Simulationssystem Schritt 4: Vergleich von Original- und Simulationssystem Ansatzpunkte für Prozess- und Tooloptimierungen Modellierungstool Testerstellung und -verwaltung Evaluierung eines ALM-Tools Grundkonzept Positive Feststellungen aus der Evaluation Negative Feststellungen aus der Evaluation Fazit und Ausblick...17 Version 1.0 Seite 2 von 18

126 Ansätze zur Optimierung toolgestützter Teststrategien 5 Anhang Anhang 1: Referenzen Anhang 2: Abkürzungen...18 Abbildungsverzeichnis Abbildung 1: Überblick Systemkonzept... 7 Abbildung 2: Generisches Produkt... 8 Abbildung 3: Schnittstellen der Teilsysteme GA und GP... 8 Abbildung 4: Beispielprüffall inklusive aller Schnittstellen und Werte Abbildung 5: Beschreibung des Verhaltens der Zustandsmaschinen während des Prüffalls Abbildung 6: Grundkonzept der Testanbindung an Polarion Abbildung 7: Anstoßen von Testfällen Abbildung 8: Rückgabe von Testergebnissen Tabellenverzeichnis Tabelle 1: Einteilung der Sicherheitsintegritätslevel... 5 Tabelle 2: Testkategorien... 9 Version 1.0 Seite 3 von 18

127 Ansätze zur Optimierung toolgestützter Teststrategien Einleitung 1 Einleitung Innerhalb des Ergebnisberichts "NeGSt_Ergebnisbericht_2300AG5_Prozess der RAMS- Nachweisführung und unterstützende Werkzeuge" [NeGSt_Teilbericht] wurde dargelegt, dass die Beachtung der Sicherheitsanforderungen im gesamten RAMS-Prozess durchgängig, mögöochst toolgestützt, nachgewiesen werden muss. Es wurde festgestellt, dass die globalen Sicherheitsanforderungen des RAMS-Prozess ab der Phase des Designs einer Untersuchung, sowie einer Detaillierung unterliegen. Ab dieser Phase muss somit sichergestellt sein, dass die durchgängige Nachweiskette bis zur Erstellung des Sicherheitsnachweises eingehalten wird. In diesem Dokument wird die Fehlerverfolgung parallel zum Entwicklungsprozess betrachtet, also bereits ab der Design- und Entwurfsphase, über das eng damit verbundene Thema Erstellen, Durchführen und Verwalten von Tests bis zur Nachweisdarlegung im Sicherheitsnachweis (TSB). Im Folgenden wird nicht die besondere Klassifizierung der Sicherheitsanforderungen gemäß [NeGSt_Teilbericht] thematisiert, sondern ein generelles Konzept der Fehlerverfolgung, unabhängig von der Klassifizierung, erstellt. Weitere Analysen, inwieweit die Fehlerverfolgung gemäß RAMS- Anforderungen erfolgen kann (z.b. über eine spezielle Attribuierung), sollten in einer weitergehenden Evaluierung erfolgen. Eine optimale Abstimmung der angewandten Prozesse und der verwendeten Tools wird im Sinne der sicherheitsorientierten Entwicklung angestrebt und spielt auch aus wirtschaftlicher Sicht, bezogen auf Aufwand, Kosten und nachhaltige Effizienz, eine wichtige Rolle. Nachfolgend soll beispielhaft das Testkonzept der Firma Funkwerk für das Projekt Lindaunis (ein ESTW-R vom Typ Alister 2.0) vorgestellt werden. Es sollen Möglichkeiten für Verbesserungen im Testkonzept sowie in der Toolchain herausgearbeitet werden. Zusätzlich erfolgt eine Evaluierung des modernen Application Lifecycle Management (ALM) Tools Polarion, um die Aspekte des Managements von Fehlern zu betrachten. Version 1.0 Seite 4 von 18

128 Ansätze zur Optimierung toolgestützter Teststrategien Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement 2 Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement 2.1 Fehlerdefinition Ein Fehler (Ausfall) wird laut dem Deutschen Institut für Normung als ein Merkmalswert, der die vorgegebenen Forderungen nicht erfüllt und als Nichterfüllung einer Anforderung definiert. Die Anforderung wird hierbei als Erfordernis oder Erwartung, welche festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist definiert. Unterschieden werden erwartete Fehler und unerwartete Fehler. Ein Fehler kann systematisch sein, d.h. er hängt von Fehlervoraussetzungen ab. Beim Fehlerauftreten unter bekannten Fehlervoraussetzungen, kann der Fehler reproduziert werden. Ein Fehler kann nur vermieden werden, wenn die Fehlerursache bekannt ist. Da die Folgen eines Fehlers generell unerwünscht sind, wird er häufig als Schaden betrachtet, denn er tritt oft abrupt oder von Beginn an auf. Zur besseren Beurteilung eines Fehlers, wird dieser Gefährdungsklassen zugeordnet. In der Technik sind Fehler überwiegend auf menschliche Fehler in der Konstruktionsphase oder im Produktionsprozess zurückzuführen. Die FMEA (Failure Mode and Effects Analysis oder Auswirkungsanalyse) versucht alle möglichen Fehler, die Fehlerfolgen und die schlimmsten möglichen Fehlerverkettungen systematisch zu erkennen und zu bewerten, um entsprechende Maßnahmen rechtzeitig vorzunehmen. 2.2 Gefährdungsklassen Gefährdungsklassen dienen der Klassifizierung von relativen Auswirkungen eines technischen Fehlers. Durch eine genaue Definition der Gefährdungsklasse und der Umsetzungen aus der definierten Fehlerstrategie ist eine rechtzeitige Reaktion auf den Fehler sichergestellt und es ist möglich, die Art des Fehlers zu beurteilen. Es gibt folgende hier in Ansatz gebrachte Klassifizierungsmöglichkeiten: Klasse 1 (nicht gefährliche Ausfälle, Werte müssen in den Sicherheitsberechnungen nicht mit betrachtet werden; sie sind nicht relevant) Klasse 2 (gefährliche Ausfälle, sind relevante Werte für die Sicherheitsberechnung) 2.3 FMEA Die FMEA dient dazu, Schwächen frühzeitig zu erkennen und liefert eine Rangliste von Ausfallarten, welche verschiedene Auswirkungen auf das System haben. Diese Betrachtungen fließen dann in die RAMS-Berechnungen eines Systems mit ein. 2.4 Grundlagen Sicherheitsintegritätslevel (SIL) Das Sicherheits-Integritätslevel SIL (Safety Integrity Level) gibt die Ausfallgrenzwerte für eine Sicherheitsfunktion, die in der Betriebsart mit hoher Anforderungsrate oder in der Betriebsart mit kontinuierlicher Anforderung betrieben wird an. Sicherheits- Integritätslevel Rate gefahrbringender Ausfälle der Sicherheitsfunktion Tabelle 1: Einteilung der Sicherheitsintegritätslevel Version 1.0 Seite 5 von 18

129 Ansätze zur Optimierung toolgestützter Teststrategien Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement Fehlerbaumanalyse (FTA) Die Fehlerbaumanalyse (FTA) ist ein ableitendes bzw. fortführendes Verfahren, welches ein System, bezogen auf seinen Komponenten, in einem booleschen Modell darstellt. Diese Darstellung dient dazu, die Wahrscheinlichkeit eines System-Ausfalls zu bestimmen. 2.5 Fehlererkennung In der heutigen Zeit wird eine hohe Zuverlässigkeit von einem Gerät dadurch erzielt, dass es durch ein gutes Konzept, durch hohe Qualität der verwendeten Komponenten und durch einen gut überlegten Systemaufbau entwickelt worden ist. Dazu ist es besonders hilfreich, wenn Fehler schon in der Entwicklungsphase erkannt werden, um Schwachstellen rechtzeitig beheben zu können Ausfallbetrachtungen Durch RAMS-Nachweisdokumentationen wird dargelegt, wie Fehler rechtzeitig erkannt und behoben werden. Die RAMS-Prozesse (Reliability-Zuverlässigkeit, Availability-Verfügbarkeit, Maintainability-Instandhaltbarkeit und Safety-Sicherheit) beschreiben den Systemlebenszyklus und beinhalten zum einen die Ergebnisse aus den Berechnungen der Zuverlässigkeit und der Sicherheit und zum anderen die Ergebnisse aus den Verfügbarkeits- und Instandhaltbarkeitsbetrachtungen. Die Untersuchung der Ausfallraten (Anzahl der (gefährlichen) Ausfälle je Zeiteinheit) von Komponenten eines Systems hat hierbei eine große Bedeutung. Sie hilft dabei, rechnerisch eine Zuverlässigkeit vorauszusagen. Es ist somit möglich, einen Fehler durch vorsorgliche Reparatur oder Austausch zu vermeiden. Die Ausfallrate einer Baugruppe (System) wird mit Hilfe der FMEA oder der Siemens- Norm SN ermittelt. Die Ausfallraten für die verwendeten Bauteile werden vom Hersteller angegeben oder mit Hilfe der Daten aus der Siemens-Norm bestimmt. Die Fehlerbaumanalyse (FTA) dient zur Bestimmung der Wahrscheinlichkeit eines Systems-Ausfalls. Wichtig ist auch die Betrachtung der Ursache für den Fehler und die Häufigkeit seines Auftretens. Daraus sind präventive Maßnahmen, wie z.b. einen neuen Aufbau des Systems, eine rechtzeitig durchgeführte Reparatur oder ein Geräteaustausch, abzuleiten Bauteilbetrachtung Bauteile eines Systems werden gemäß ihrer Funktion zu Funktionsblöcken zusammengesetzt. Diese werden dann nach Beteiligung einer bestimmten Funktion in Serie oder parallel redundant zusammengeschaltet Maßnahmen zu einer höheren Wahrscheinlichkeit zur Aufdeckung von Fehlern Eine Maßnahme zur Vereinfachung von Fehlerermittlungen und behebung ist ein Diagnosesystem, welches technische Betriebsdaten systematisch und vollständig protokolliert. Eine entsprechende Diagnoseschnittstelle dient dazu, Störungsdaten zu erfassen, aufzubereiten und statisch auszuwerten. Die dazu notwendigen Informationen vom Stellwerk und der Bedieneroberfläche sollen sowohl aktuell als auch aus archiviertem Datenbestand dem Servicepersonal der LST zur Verfügung stehen. Darüber hinaus soll eine gut strukturierte Übersicht und Klassifizierung der Störungsarten geschaffen werden. Eine wichtige Hilfestellung dafür ist, dass die möglichen betroffenen Bauteile zu der aufgetretenen Störung angezeigt werden und somit eine schnelle Reparatur oder ein schneller Austausch des Bauteils bzw. der Baugruppe vorgenommen werden kann. Version 1.0 Seite 6 von 18

130 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien 3 Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien In diesem Abschnitt soll ein Überblick über die im Projekt ESTW-R Lindaunis angewandte Teststrategie zur Fehlererkennung und management gegeben werden. Die Ideen für verbesserte Konzepte, Prozesse und Tools sollen aus den Erfahrungen, die im Projekt ESTW-R Lindaunis gesammelt wurden, zusammengetragen werden. Um die Anforderungen an die Testumgebung besser nachvollziehen zu können, soll das Projekt, dessen Architektur und Toolchain kurz beschrieben werden. 3.1 Überblick über die Zielplattform Beim Projekt handelt es sich um ein ESTW-R vom Typ Alister 2.0, ein auf speicherprogrammierbaren Steuerrungen (SPS) basierendes Stellwerk aus Standardindustriekomponenten (Commercial off-the- Shelf - COTS). Konkret besteht die Stellwerksplattform aus F30-HiMatrixsystemen der Firma Hima. Man unterscheidet hier zunächst zwischen zwei Teilsystemen, dem Subsystem eines technisch verfahrensgesicherten Bedienplatzes und dem Subsystem Stellwerkskern. Abbildung 1: Überblick Systemkonzept Der Stellwerkskern ist wiederum in die Teilsysteme Generisches Produkt (GP) und Generische Applikation (GA) unterteilt. Das Generische Produkt besteht im Wesentlichen aus dem Stellwerkskern (SPS) und den Anschaltbaugruppen (xcm) zu Ansteuerung der Außenelemente. Das GP umfasst auch die Treiberebene für Version 1.0 Seite 7 von 18

131 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien die Außenelemente und soll die Stellwerkslogik der GA von den jeweils eingesetzten Hardwarekomponenten entkoppeln. Abbildung 2: Generisches Produkt Der GA-Teil beinhaltet hauptsächlich die Stellwerkslogik, wie z.b. das Einstellen und Auflösen von Fahrstrassen und ist für jedes Stellwerk gleich. Die Anpassung auf die örtlichen Gegebenheiten erfolgt, gemäß dem generischen Ansatz durch Parametrisierung über einen SA-Anteil. SA definiert eine Spezifische Applikation und beinhaltet zum Beispiel die örtlichen Stellwerkselemente sowie die einzelnen Fahrstraßen. Abbildung 3: Schnittstellen der Teilsysteme GA und GP Version 1.0 Seite 8 von 18

132 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien 3.2 Toolchain Die Softwarekomponenten des Stellwerkskerns (GA und GP) werden funktional zum größten Teil in der Unified Modeling Language (UML) spezifiziert. Die Zustandsdiagramme werden toolunterstützt entwickelt und sind eingebettet in Worddokumente, welche die Systemanforderungen über ein Anforderungsmanagementtool einbetten und die Traceability zu Anforderungen, Versionen, etc. herstellt. Die Programmierung erfolgt grafisch mit ELOP II Factory und die Versionskontrolle erfolgt ebenfalls toolgestützt. Für das Management von Fehlern, Defects und Testcases wird ein Testmanagementtool verwendet. 3.3 Testvorgaben Um Aussagen zum Testkonzept treffen zu können, muss zwischen den einzelnen Teilsystemen des Stellwerkes unterschieden werden. Begriff Bedienplatz - Squish Tests GA - automatisierte Modultests Beschreibung GP - atomare Modultests (Überprüfung der korrekten Funktion einzelner Module bzw. Zustandsmaschinen) - Integrationsprüffälle Überprüfung der Funktionalität jeder Steuereinheit einzeln und im Zusammenwirken. Eine Teilmenge sind Prüffälle, die aus Betrachtungen der FMEA entstammen oder bestimmte Hardwareausfallszenarien testen. Schnittstellentests - GA/GP Prüffälle, die das korrekte Zusammenspiel der beiden Komponenten des Stellwerkkerns überprüfen - Kommunikationstestbett eine Java basierte Testumgebung, die die Schnittstelle zwischen den Rechnern des Bedienplatzes und dem Stellwerkskern überprüft. Systemintegrationstests - Überprüfen die korrekte Funktion aller Teilsysteme im Zusammenspiel Tabelle 2: Testkategorien Wie in Tabelle 2 dargestellt, sind die Testkategorien genauso vielfältig wie ihre Durchführung und Verwaltung. Die bisher eingesetzten IBM-Tools boten intrinsisch jedoch noch keine einheitliche, durchgängige Handhabung der Testcases und ihres Managements. Darüber hinaus fehlt häufig die Möglichkeit einer Einbindung von proprietären 3rd Party Tools. Daher war es notwendig, die Toolchain durch eigene Entwicklungen bzw. Anpassungen zu ergänzen. 3.4 Testkonzept für das Generische Produkt Am Beispiel der GP Prüffälle soll ein konkretes Testkonzept für ein Teilsystem des Stellwerks dargestellt werden. Es werden Ansatzpunkte für eine Verbesserung bzgl. Verwaltung, Effizienz und Transparenz dargestellt, mit der Intension, die unterschiedlichen Rollen in der Nachweisführung gemäß CENELEC signifikant zu unterstützen Schritt 1: Erstellen der Prüffallspezifikation für eine Steuereinheit GP Prüffälle definieren ein bestimmtes Prüfszenario für eine Steuereinheit, z.b. eine Weiche. Ein solches Prüfszenario wäre beispielsweise das Umstellen der Weiche von links nach rechts. Hierbei han- Version 1.0 Seite 9 von 18

133 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien delt es sich um einen Regelprüffall, also einen Prüffall, der eine Standardfunktion der Weiche, mit fehlerfreiem Verlauf, beschreibt. Zum gesamten Umfang der Prüffälle gehört natürlich auch die Definition möglicher Fehlerfälle. Die Tabellenform wurde gewählt, weil sich so ein eindeutiger Ablauf des Prüffalls inklusive aller Teilschritte abbilden lässt. Hierbei wird ein eindeutiger Bezug zwischen korrekter Funktion der Steuereinheit, dem Verhalten der Software inkl. der Dokumentation auf Zustandsebene, der physikalischen Schnittstellen, der Schnittstellen zum Teilsystem GA und Die Nachweisführung fordert, dass alle bekannten Regel- und Fehlerszenarien sowie jeder mögliche Zustandsübergang abzudecken sind Schritt 2: Prüffalldurchführung am Realsystem Wenn eine Prüffallspezifikation fertig gestellt ist, d.h. die gesamte zu testende Funktionalität einer Steuereinheit spezifiziert so implementiert ist, werden die Prüffälle mit der originalen Hardware im Testlabor durchgeführt und dokumentiert. Voraussetzung ist, dass eine verifizierte und freigegebene Softwareversion der Steuereinheit verwendet wird, die wiederum eine verifizierte Version der Softwareanforderungsspezifikation voraussetzt. Für die Dokumentation wird ein Datenlogger verwendet, der an den physikalischen Ein- und Ausgängen angeschlossen wird Schritt 3: Prüffalldurchführung am Simulationssystem Die Messdaten unter allen bekannten Funktionsszenarien dienen gleichzeitig als Grundlage für die Beschreibung eines simulierten Außensystems. Unter Anderem aus Kosten- und Platzgründen ist es schwer möglich, ein komplettes Testsystem unter Verwendung aller tatsächlichen Hardwarekomponenten aufzubauen. Dennoch bestehen der Wunsch und die Notwendigkeit nach einer solchen Testanlage. Die Umsetzung ist möglich, indem man z.b. die Vielzahl aller Steuereinheiten wie Bahnübergänge, Weichen, Signale, etc. simuliert. Dieses Simulationssystem basiert ebenfalls auf einer SPS mit digitalen Ein- und Ausgängen. Ein simuliertes Außenelement besitzt ein Regel- sowie Fehlerverhalten, dass dem originalen Außenelement entspricht. Das Verhalten wird über Skripte beschrieben und kann leicht angepasst werden. Dies bietet auch den Vorteil, dass sich somit bestimmte komplexe Testszenarien und Zeitverhalten einstellen und testen lassen, die am Realsystem nur schwer einzustellen sind. Die Simulation bietet nicht nur die Möglichkeit, ein ganzes Element zu simulieren, sondern auch Schnittstellen, um einzelne SW-Module bzw. Zustandsmaschinen zu testen. Diese atomaren Tests ermöglichen also auch, innere Zustände des Stellwerkskerns zu überprüfen. Ein weiterer Vorteil des Simulationssystems ist die Speicherung von detaillierten Log-Dateien, um eine korrekte Prüffalldurchführung und deren Verlauf zu dokumentieren bzw. belegbar nachzuweisen Schritt 4: Vergleich von Original- und Simulationssystem Um das Simulationssystem verwenden zu können, muss zuvor der Nachweis erbracht werden, dass sich die Simulation im Regelverhalten genauso verhält wie die originale Außenanlage. Dafür werden alle Prüffälle, die bereits mit den originalen Außenelementen durchgeführt wurden am Simulationssystem wiederholt. Dies erfolgt skriptgesteuert. Anschließend werden die Logdateien toolgestützt mit den Messungen der Außenanlage verglichen. Den Vergleich übernimmt das eigens dafür entwickelte und auf Java/Eclipse basierende Tool AutoPruV. AutoPruV bietet ebenfalls die Möglichkeit, die Logdateien der Prüffälle mit den Vorgaben der Prüffallspezifikation und sogar der SW-Anforderungsspezifikation, d.h. den Zustandsdiagrammen, zu vergleichen. Version 1.0 Seite 10 von 18

134 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien Damit wird erreicht, dass Abweichungen von der Anforderungsspezifikation und Fehler offenbart werden. Generell wird für jeden der zuvor angegebenen Schritte ein Bericht über die Durchführung angefertigt, welcher Randbedingungen und Ergebnisse dokumentiert. Gleichzeitig fließen diese Berichte in das Konfigurationsmanagement (KM) ein, und bilden zusammen mit den entsprechenden Dateien (Skripte, Logs, etc.) einen Versionsstand, der gegen eine weitere Bearbeitung geschützt wird. Festzustellen ist, dass die eingesetzte Tool Suite zusammen mit den selbstentwickelten Ergänzungen und Schnittstellen ein erster Schritt in Richtung ALM sind. 3.5 Ansatzpunkte für Prozess- und Tooloptimierungen Die eingesetzte IBM Rational Suite, also die gesamte Anzahl der einzelnen Applikationen dieser Suite, bietet bereits viele gemeinsame Schnittstellen und Abhängigkeiten, die für eine CENELECkonforme Entwicklung notwendig oder mindestens hilfreich sind, wie z.b. Versionierung und Traceability. Gerade im Bereich der Testverwaltung offenbaren sich für den Bereich der Stellwerksentwicklung jedoch Grenzen. Es ist grundsätzlich möglich, Testsuiten und Testcases anzulegen und/oder mit Anforderung oder Defekten zu verknüpfen. Eclipse-basierenden Tools sind jedoch stark auf das Testen von objektorientierten Anwendungen, wie z.b. in Java erstellte Projekte, ausgelegt. Somit wird z.b. ReqPro zwar formal für die Erstellung von Testcases und für die Verlinkung zu Anforderungen eingesetzt, eine direkte Verknüpfung zu den Testergebnissen und den dazugehörigen Daten ist aber nicht intrinsisch umsetzbar. Zusätzlich fehlt die Möglichkeit, die proprietären Testumgebungen direkt zu triggern. So ist es z.b. nicht möglich, automatisierte Regressionstests zu starten, auszuwerten und im definierten Fehlerfall Folgereaktionen auszulösen. Dies könnte z.b. die Erstellung eines Defekts beinhalten. Ein Ansatzpunkt wäre also alternative Verwaltungstools einzusetzen. Die Möglichkeit eines modernen Application Lifecycle Management Systems (ALM) soll die Evaluierung eines Tools im Kapitel 3.6aufzeigen. Grundsätzlich hat sich das oben vorgestellte Testkonzept als praktisch und zielgerichtet erwiesen. Die Bearbeitung der Prüffälle, die Durchführung und Dokumentation hat sich jedoch als sehr zeitaufwändig herausgestellt. Wiederholte Durchläufe, bedingt durch Änderungen an Spezifikation, Software und Prüffallspezifikationen wirken sich somit besonders negativ auf Entwicklungszeit und kosten aus. Besonders die Fragmentierung der vielen einzelnen eingesetzten Tools und die Menge an händisch durchzuführenden Arbeitsschritten sollen einen weiteren Ansatzpunkt bieten: ein höherer Automatisierungsgrad und die Erarbeitung eines zentralen Testmanagement Systems. Wie bereits zuvor erwähnt, wird bei der Auswertung der Prüffälle ebenfalls die Spezifikation mit einbezogen. Dies soll auch gleichzeitig den letzten zu nennenden Ansatzpunkt darstellen. Da auch die Modellierungstools eher für objektorientierte Anwendungen ausgelegt sind, sind auch bei der Modellierung im Bereich der Stellwerkstechnik auf SPS-Basis Einschränkungen hinzunehmen. Da objektorientierte Hochsprachen wie C++ oder Java in diesem Umfeld nicht zulässig sind und kein bislang evaluiertes Modellierungstool die volle angestrebte Funktionalität bietet, hat sich Funkwerk dafür entschieden, eine eigene Modellierungssprache, eine Domain Specific Language, zu erarbeiten. Diese wird in dem Forschungsprojekt MENGES, in Zusammenarbeit mit der Universität Kiel und einem weiteren Industriepartner entwickelt und sei an dieser Stelle nur erwähnt. Denkbar wäre, direkt aus dem Modell den Code zu generieren ( Model-Driven Development, ebenfalls evaluiert im MENGES-Förderprojekt). Dies setzt jedoch eine Akzeptanz in der Sicherheitsnachweisführung gemäß CENELEC voraus. Für SIL 4 Stellwerke ist dies nicht zeitnah geplant, es gibt aber durchaus erste beachtliche Erfolge im SIL0 / SIL2 Bereich Modellierungstool Eine vollständige und eindeutige Modellierung bzw. UML-Spezifikation hätte den Vorteil, dass daraus automatisiert gültige Templates für die Prüffallerstellung generiert werden könnten. Schnittstellensignale, Initialisierungswerte und die Zustandsmaschinen sind immerhin bekannt. Dies bedeutet zum Einen, dass keine Fehler bzw. Inkonsistenzen, wie bei der händischen Erstellung entstehen können und Version 1.0 Seite 11 von 18

135 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien zum Anderen die Effizienz steigt. Bestimmte Fehler in der Spezifikation würden außerdem frühzeitig, d.h. während der Prüffallerstellung aufgedeckt werden. Aus einer absolut eindeutigen UML-Spezifikation oder einer formalen Spezifikation, die programmtechnisch weiterverarbeitet werden kann, lassen sich auch automatisiert atomare Tests, also Schnittstellentests auf Modulebene, generieren und zwar für alle relevanten Permutationen der Zustandsübergänge unter Berücksichtigung, dass aus einer formalen Spezifikation automatisch Äquivalenzklassen für Prüffälle gebildet werden. Diese Anzahl von Prüffällen wäre von Hand nicht wirtschaftlich zu erstellen und auch nicht in der geforderten Qualität. Diese Maßnahme könnte zusätzlich die Softwareverifikation unterstützen bzw. diese auch ersetzten. Die 1:1 Umsetzung der UML-Spezifikation könnte somit nachgewiesen werden Testerstellung und -verwaltung Zentraler Angelpunkt für ein gut integriertes Testmanagementsystem sollte eine zentral angelegte Testdatenbank sein. Sie sollte alle Prüffälle, sowie alle weiteren relevanten Daten, wie Ergebnisse, Logdateien, Messungen, Informationen zur Durchführung, Versionierung und Verifikation enthalten. Um auf der Datenbank arbeiten zu können, muss eine Client-Anwendung, eine Art Editor, entwickelt werden. Wie bereits zuvor erwähnt, sollten automatisch aus den Spezifikationen der Steuereinheiten Template-Informationen extrahiert werden, welche die Grundlage für die Maske des Editors bilden könnten. Abbildung 4 und Abbildung 5 zeigen beispielhaft Auszüge einer Prüffallspezifikation der Steuereinheit Weiche. Die Informationen werden bislang von Hand eingetragen. Der Inhalt einer solchen Prüffallspezifikation umfasst teilweise, je nach Komplexität der Steuereinheit, mehr als einhundert Prüffälle. Nicht nur die Prüffallerstellung sollte automatisiert erfolgen, sondern auch Prüffalldurchführungen und Simulationsnachweise sollten direkt mit den Prüffällen verknüpft werden. Umwelttests, wie Salznebel-, Rüttel- und ähnliche Tests, sollten hier nicht ausgegrenzt sondern ebenfalls auf diese Weise erfasst werden. Externe Prüftools wie AutoPruV sollten angepasst und integriert werden. Teilweise könnten Sie als Services permanent im Hintergrund laufen oder bei Bedarf manuell getriggert werden. Abbildung 4: Beispielprüffall inklusive aller Schnittstellen und Werte Version 1.0 Seite 12 von 18

136 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien Nach heutigem Kenntnisstand gibt es kein marktgängiges Werkzeug, welches die hier aufgeführten Anforderungen vollständig umsetzt. Abbildung 5: Beschreibung des Verhaltens der Zustandsmaschinen während des Prüffalls Ziel sollte es sein, die erworbenen Erkenntnisse aufzusetzen. Vielmehr sollen Prozesse und Tools im evolutionär entwickelt werden, die Aufgaben automatisieren, erleichtern, beschleunigen und weniger fehlerträchtig machen. Auch die Verfahren zur Erstellung der Prüfberichte einschließlich ihrer Formate können so in Abstimmung zwischen allen Rollen gemäß CENELEC abgestimmt werden. Es wäre denkbar, dass Verifizierer ebenfalls auf dem Datenbestand arbeiten und bestimmte Inhalte direkt und eindeutig beurteilen. Dafür müssten natürlich verschiedene Rollen im Testmanagement-Tool geschaffen werden. Eine weitere Funktionalität, die in diesem Zusammenhang angestrebt werden sollte, ist die Generierung von Dokumenten. Also die automatische Erzeugung von Dokumenten anhand von Information aus der Datenbank. Formale Vorgaben könnten durch Templates realisiert werden. Die automatisierte Dokumentengenerierung wäre auf viele Arten von Dokumenten des ganzen Entwicklungsprozesses anwendbar, wie unter anderem für Prüffallspezifikationen, Berichte zur Durchführung von Prüfungen, Checklisten und Verifikationen. 3.6 Evaluierung eines ALM-Tools Ziel der Evaluierung ist die Erfassung der Möglichkeiten, die bestehenden Testtools besser in den Entwicklungs- und Nachweisprozess einzubinden und Abhängigkeiten zu schaffen. Hierbei handelt es sich aber nicht um eine allgemeine Beurteilung zur grundsätzlichen Eignung eines ALM-Tools für ein IT-Unternehmen, sondern es wird eine klare Abgrenzung zur Evaluation für den Einsatz in der Entwicklung von Stellwerksprojekten definiert. In den nachfolgenden Unterkapiteln erfolgt eine gezielte Zusammenstellung von Informationen und ersten Erfahrungen im Umgang mit Polarion als möglicherweise geeignetes ALM-Tool. Für die Evaluierung wurde die Polarion Version Stand April 2013 verwendet. Version 1.0 Seite 13 von 18

137 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien Grundkonzept Grundsätzlich geht es um die Anbindung von externen, bereits bestehenden Testtools, die im Weiteren zusammengefasst bezeichnet werden als Test Automation Server (TAS). Abbildung 6: Grundkonzept der Testanbindung an Polarion Abbildung 6 zeigt das Grundkonzept des Datenaustausches zwischen einem Polarion Server und einem Test Automation Server (TAS). Für die meisten Endanwender sind beide Server getrennte Systeme. In unserem Fall besteht der TAS aus einer geeigneten Testanlage, gekoppelt mit einem Simulationssystem. Eine wichtige Voraussetzung ist, dass der TAS eine Art Test Agent enthält, der eingehende Anfragen von einem externen Tool (hier vom Polarion-Server) entgegen nimmt. Dies ist wichtig, weil in der Testdurchführung oft komplexe 3rd Party Tools aufgerufen werden, welche in der Durchführungsumgebung verfügbar sein müssen Aufrufen eines Builds Um den Prozess der gemeinsamen Nutzung von Informationen zwischen Polarion QA (dem Collaborative Test Management) und einem Test Automation Server zu starten, besteht die Möglichkeit den Build-Prozess mit einem der folgenden Tools aufrufen: Jenkins Integration Server (wird bei Funkwerk u.a. bereits eingesetzt) Hudson ANT (wird bei Funkwerk u.a. bereits eingesetzt) MAVEN (wird bei Funkwerk u.a. bereits eingesetzt) Polarion Build Hinweis: Derzeit sind diese Anwendungen noch nicht für die SIL4-Stellwerksentwicklung akzeptiert Austausch von Testdaten Sobald das entsprechende Build-Tool aufgerufen wurde, müssen entsprechende Skripte definiert und ausgeführt werden: 1. Testfälle von Polarion QA, für das was getestet werden soll, holen 2. zugehörige Test-Skripte für die Durchführung holen 3. Tests zum Test Automation Server senden Version 1.0 Seite 14 von 18

138 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien Testfalldurchführung Für die Durchführung ist der TAS verantwortlich. Nachdem Polarion die Testdaten geliefert und den Test gestartet hat, wartet es nur auf die Ergebnisse. Die Ergebnisse werden vom TAS generiert und auf lokale bzw. Laufwerke im Netzwerk kopiert, auf welche Polarion nach jeder Testfalldurchführung zugreifen kann. Angestoßen wird der Prozess durch das Senden von Test-Skripten; Abbildung 7 soll dies verdeutlichen. Abbildung 7: Anstoßen von Testfällen Empfang von Ergebnissen Mit dem Polarion Server ist es wie oben gezeigt möglich, externe Testtools einzubinden. Polarion ist darüber hinaus geeignet, die Traceability über alle Testartefakte nachzuweisen. Zum Beispiel kann Eclipse-TPTP für automatisierte Last- und Performance-Tests und Selenium für automatisierte Tests der Benutzeroberfläche verwendet werden, um Ergebnisse jeder Testdurchführung zu Polarion zu importieren und dort für alle Rollen geeignet darzustellen. Polarion kann auf diese Weise mit einem externen Tool, das die Testergebnisse in xunit XML- Formate exportieren kann, zusammenarbeiten. Um Testergebnisse von einem externen Test-Tool mit Polarion zu integrieren, muss jedes externe Tool so konfiguriert werden, dass eine xunit Datei entsteht und in einen für Polarion zugänglichen Ordner geschrieben wird. Polarion wiederum wird so konfiguriert, dass jeder Ordner auf das Vorhandensein einer Testergebnis- Datei regelmäßig überprüft wird. Ein geplanter Job namens xunitfileimport ist in Polarion vorgesehen, der diese Aufgaben übernimmt. Version 1.0 Seite 15 von 18

139 Ansätze zur Optimierung toolgestützter Teststrategien Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien Abbildung 8: Rückgabe von Testergebnissen Abbildung 8 zeigt die erforderliche Architektur für den Import der Testergebnisse. Man kann sehen, dass die Datei xunit_results.xml ursprünglich auf dem TAS in einem gültigen xunit-format erstellt ist. Hat der TAS die Lieferung der Daten abgeschlossen, dann kann auf die Ergebnisse zugegriffen werden. Der Abgleich der Daten erfolgt automatisiert und wird konfigurierbar in festen Intervallen durchgeführt. Dabei wird geprüft, ob neue xml Ergebnisse auf der angegebenen Datenablage vorhanden sind. Der Import der Ergebnisse kann ebenfalls manuell angestoßen werden. Es wird für jede gültige xml-datei im angegebenen Verzeichnis erfolgreich ein neuer Testdurchlauf erzeugt. Defect type Work Items werden für die Entwickler automatisch erzeugt, wenn Tests fehlschlagen. Am Ende wird die xml Datei (-en) automatisch gelöscht Positive Feststellungen aus der Evaluation Die getestete Performance der lokal installierten Anwendung war durchgängig akzeptabel. Zur Performance bei der Verwendung eines Servers im Netzwerk können noch keine Aussagen getroffen werden. Die lokale Installation war vollkommen problemlos. Testcases/Testruns sind importierbar und exportierbar im Excelformat. Damit besteht eine einfache Möglichkeit von Offlinetests. Dies könnten zum Beispiel Tests an den Installationsorten des Stellwerkes sein oder Tests, die von externen Stellen durchgeführt werden. Riskmanagement (bzw. dokumentation) und FMEA sind in das Tool integriert und mit Tests verlinkbar. Bestimmte Testcases können direkt mit dem Tool erstellt und editiert werden (z.b. Systemintegrationstests und Checklisten). Schnittstellen zu externen Testservern sind implementiert. Neueste Erweiterung: Integration mit Matlab/Simulink Negative Feststellungen aus der Evaluation Es traten vereinzelt Hänger im IE-Browser aus; Speichern war dabei nicht möglich; nicht nachvollziehbare Fehlermeldungen traten auf Eine fehlende Verzeichnisstruktur erscheint behindernd für Attachments. Spezielle Tests wie ITG Prüffälle oder atomare Prüffälle können nicht direkt abgebildet werden sondern müssen über externe Tools verwaltet werden. Die externen Tools könnten aber mit Polarion verknüpft werden (siehe xunit framework + xml format). Version 1.0 Seite 16 von 18

140 Ansätze zur Optimierung toolgestützter Teststrategien Fazit und Ausblick 4 Fazit und Ausblick Im Laufe des Entwicklungsprozesses elektronischer Stellwerke wurden viele Erfahrungen in den Bereichen Fehlererkennung und Teststrategie im Rahmen des Sicherheitsnachweises gesammelt. Aktuell werden verschiedene Tools oder Toolsuiten verwendet und auf die CENELEC-Prozesse angepasst und optimiert. Die interne Toollandschaft hat Konzepte der heutigen ALM-Werkzeuge bereits vorgegriffen. Festzustellen bleibt jedoch auch, dass bei der Integration dieser Tools noch bestimmte Automatismen fehlen. Nach einer Evaluierungsphase lässt sich feststellen, dass sich einige dieser Lücken durch die Verwendung des ALM-Tools Polarion schließen lassen. Eine vereinfachte Nachweisführung der Einhaltung aller RAMS-Anforderungen ist generell machbar und wirkt sich effizienzsteigernd auf die Gestaltung des Sicherheitsnachweises aus. Ein besonderer Schwerpunkt der Betrachtung waren die Schnittstellen zu externen, proprietären Testsystemen. Diese ermöglichen die direkte Verknüpfung von Tests, Testsuiten und Fehlermanagement zu bestehenden RAMS-Anforderungen. Diese Möglichkeiten, insbesondere die Handhabung von verteilten Anforderungen, erscheinen besonders wichtig im Hinblick auf den Einsatz in einem geplanten DB AG Testlabor (siehe AP Entwicklung eines Testkonzeptes ), welches eine zentrale Rolle in der Optimierung des Zulassungsprozesses für die DB AG einnehmen soll. Ein weiteres Beispiel für einen praktischen Einsatz wäre die bereits im Kapitel skizzierte Anbindung an eine Diagnosedatenbank (siehe Teilergebnisbericht "NeGSt_Ergebnisbericht_2300AG5_Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform"). Version 1.0 Seite 17 von 18

141 Ansätze zur Optimierung toolgestützter Teststrategien Anhang 5 Anhang 5.1 Anhang 1: Referenzen Polarion 2013 User Guide [1] Polarion QA for Test Managers [2] User-Guide-Automated-Test-Execution-with-Polarion [3] 5.2 Anhang 2: Abkürzungen Abk. Langform / Erläuterung ALM Application Lifecycle Management CENELEC European Committee for Electrotechnical Standardization COTS Commercial off-the-shelf ESTW-R ESTW-Regional FMEA Fehler-Möglichkeits- und Einfluss-Analyse FTA Failure Tree Analysis (Fehlerbaumanalyse) GA Generische Applikation GP Generisches Produkt ITG Integrationsprüffälle KM Konfigurationsmanagement LST Leit- und Sicherungstechnik RAMS Reliability, Availability, Maintainability, Safety ReqPro (IBM-Tool) Rational Requisite Pro SA Spezifische Applikation SIL Safety Integration Level SPS Speicher Programmierbare Steuerungstechnik SRS Safety Requirements Specification SW Software TAS Test Automation Server TSB Technischer Sicherheitsbericht UML Unified Modelierung Language XML Extensible Markup Language Version 1.0 Seite 18 von 18

142 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Teilbericht AP 2300 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

143 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Änderungsverfolgung Datum Bearbeiter Version Inhalt Sven Markus 0.1 Entwurf Antje M. Möller-Neustock 0.2 Übernahme theoretischen Grundlagen Antje M. Möller-Neustock 0.3 Übernahme Fehlerbetrachtung / Vorgehensweise Prototyp Michael Keste 0.4 Übernahme Konzept-Dokument Diagnose Sven Markus 0.5 Aufnahme Erkenntnisse Prototyping Antje M. Möller-Neustock 0.6 Erweiterung theoretische Grundlagen Antje M. Möller-Neustock 0.7 Ausblick/allgemeine Entwicklung Antje M. Möller-Neustock 0.8 Abschluss nach fachlichen Review Antje M. Möller-Neustock 0.9 Korrekturen nach Vorstellung der Ergebnisberichts Holger Neustock Klaus-Dieter Winkler 1.0 Finalisierung Inhaltsverzeichnis 1 Einleitung Theoretische Grundlagen Definition der Verfügbarkeit Definition der Instandhaltbarkeit Definition der Zuverlässigkeit Grundlagen der Zuverlässigkeitsanalyse Wichtige Größen und Formeln zur Berechnung der Zuverlässigkeit Begriffe und Einheiten Berechnung von MTTF-Werten Grundlagen Zuverlässigkeitsblockdiagramme Anmerkungen zur MTTF-Berechnung Arten der MTTF-Ermittlung Zusammenhang Part-count-Methode Redundanz Redundanz beim 1oo2 (1 out of 2) -System (ohne Reparatur) Redundanz beim 2oo3 (2 out of 3) -System (ohne Reparatur) Gleichzeitige Fehler in mehreren Komponenten (redundante Systeme mit Reparatur) Wichtige Größen und Formeln zur Berechnung der Sicherheit Begriffe und Größen: Common-Cause-Anteil Kanalbezogene mittlere Ausfallzeit Wichtige Formeln zur Berechnung von PFH Für 1oo1-Systeme Für 1oo2-Systeme FMEA...18 Version: 1.0 Seite 2 von 42

144 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform 2.8 Zusammenhang zwischen Siemens-Norm, FMEA, Zuverlässigkeit, Sicherheit und RAMS- Nachweisdokumenten Fehlerbaumanalyse Qualitative Fehlerbaumanalyse Quantitative Fehlerbaumanalyse Mathematische Vorgehensweisen bei der Fehlerbaumanalyse Berechnung der Ausfallwahrscheinlichkeit im Fehlerbaum Common-Cause-Fehler-Analyse in einem Fehlerbaum Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis Anforderungen für die Diagnose archivierter Daten Anforderungen für die Diagnose aktueller Daten RAMS Anforderungen Abfrage der Diagnoseinformationen Architekturentwurf für die Diagnose Übersicht Diagnose-Netzwerk Beschreibung Diagnose-Datenströme Beschreibung Störungsermittlung Bedienzentrale Analyse von Architekturen gemäß bestehender Systeme Anforderungen an den Prototypen Ergebnis aus den prototypischen Betrachtungen Eine beispielhafte Betrachtung der Fehlermöglichkeiten Quelle der Fehlermöglichkeiten Darstellung der Fehlermöglichkeiten Analysemöglichkeiten Motivation Applikationen NeGSt-Client Nutzer des NeGSt-Clients Administration Aktuelle Informationen Auswertung Wartungsinformationen Ausblick zum Client Zusammenfassung und Ausblick Anhang Anhang 1: Referenzen Anhang 2: Abkürzungen...42 Abbildungs- und Tabellenverzeichnis Abbildung 1: FMEA-Analyse Version: 1.0 Seite 3 von 42

145 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Abbildung 2: Grafische Darstellung der Zusammenhänge Abbildung 3: Grafische Darstellung von logischen Verknüpfungen in einem Fehlerbaum Abbildung 4: Grafische Darstellung der zu analysierenden Schaltung als Zuverlässigkeits- Blockdiagramm Abbildung 5: Zusammenhang zwischen quantitativer und qualitativer FTA Abbildung 6: Aufbau des Diagnose-Netzwerkes Abbildung 7: Fehlerklassifizierung am Beispiel RBLK (Alister) Abbildung 8: Rechte und Anzahl der Nutzer vom Client Abbildung 9: Darstellung der aktuellen Informationen ohne Festlegung von Auswahlkriterien Abbildung 10: beispielhafte Darstellung der aktuellen Informationen nach Festlegung möglicher Auswahlkriterien Abbildung 11: Darstellung vom Bereich "Auswertung" mit Beispiel-Daten Abbildung 12: Darstellung des Registers Wartungsinformationen mit einer Beispiel-Störung mit editierbaren Informationen für das Wartungspersonal Abbildung 13: Darstellung des Registers Wartungsinformationen mit einer Beispiel-Störung mit editierbaren Informationen für das Wartungspersonal und dem RAMS-Manager Tabelle 1: FTA-Symbole Tabelle 2: Ausfallraten Tabelle 3: Fehlermöglichkeiten am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren Tabelle 4: beispielhafte Fehlerbetrachtung am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren Version: 1.0 Seite 4 von 42

146 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Einleitung 1 Einleitung Im Rahmen des Forschungsprojekts NeGSt soll neben einer Analyse von Diagnosemeldungen evaluiert werden, inwieweit der RAMS-Prozess bzgl. der Phase 12 "Erfassung der Leistungsfähigkeit" optimiert werden kann. Dazu soll eine Auswerteplattform prototypisch entwickelt werden, um zu zeigen, dass eine Nachweisführung bzgl. der Verifikation von RAMS-Analysen mittels Ist-Daten des Produkts im Betrieb möglich ist. Zu diesem Zweck wird in diesem Dokument ein Feinkonzept erstellt. Die allgemeingültigen Anforderungen werden in diesem Dokument mit ANF gekennzeichnet. Dabei ist die Zielstellung, eine vom Stellwerkshersteller unabhängige Einsatzmöglichkeit zur zentralisierten Diagnose von Störungen und Fehlern sowie deren statistische Auswertung durch das Servicepersonal der LST zu schaffen. Die Diagnoseinformationen vom Stellwerk und der Bedieneroberfläche sollen sowohl aus aktuellen als auch aus archiviertem Datenbestand dem Servicepersonal der LST zur Verfügung stehen. Version: 1.0 Seite 5 von 42

147 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen 2 Theoretische Grundlagen 2.1 Definition der Verfügbarkeit Verfügbarkeit bezeichnet die zeitliche Wahrscheinlichkeit, dass sich ein Gerät in einem Zustand befindet, in dem die geforderten äußeren Umgebungsvariablen bereitstehen und es unter vorgegebenen Bedingungen zu (bzw. während) einem vorgegeben Zeitpunkt eine geforderte Funktion ausführen kann. Die Betrachtungen der Verfügbarkeit dienen dazu: - Stillstandzeiten von Systemen zu minimieren, - gegebenenfalls Rückfallebenen zu schaffen und - präventive Maßnahmen zur Vermeidung von down Zeiten zu entwickeln und zu implementieren. 2.2 Definition der Instandhaltbarkeit Die Instandhaltung soll unter festgelegten Bedingungen, festgelegten Verfahren und festgelegtem Einsatz von Hilfsmitteln erfolgen. Die Systemeigenschaft, dass bei einem Gerät unter gegeben Einsatzbedingungen innerhalb eines festgelegten Zeitraumes eine bestimmte Instandhaltungsmaßnahme durchgeführt werden kann, bezeichnet man als Instandhaltbarkeit. Die Betrachtungen der Instandhaltbarkeit dienen dazu: - die Wartung zu planen, - die Stillstandzeiten durch Wartung zu reduzieren, - eine Instandhaltung zu vereinfachen und - präventive Maßnahmen zur Vermeidung von Fehlern bei der Instandhaltung zu entwickeln und zu implementieren. 2.3 Definition der Zuverlässigkeit Die Eigenschaft, eines Systems, die angibt, wie verlässlich eine dem System zugewiesene Funktion erfüllt wird, nennt man Zuverlässigkeit. 2.4 Grundlagen der Zuverlässigkeitsanalyse In der heutigen Zeit wird eine hohe Zuverlässigkeit eines Systems (oder Teilsystems) dadurch erzielt, dass es durch ein gutes Konzept, durch hohe Qualität der verwendeten Komponenten und durch einen gut überlegten Systemaufbau entwickelt worden ist. Die Zuverlässigkeitsanalyse ist besonders hilfreich in der Entwicklungsphase, um rechtzeitig Schwachstellen zu erkennen und zu beheben. Die Untersuchung der Ausfallraten von Komponenten eines Systems hat dabei eine große Bedeutung. Sie hilft dabei rechnerisch eine vorausgesagte Zuverlässigkeit zu ermitteln. In den nachfolgenden Betrachtungen wird davon ausgegangen, dass das jeweilige Bauteil (bzw. die Komponente oder das System) entweder im Zustand defekt (funktionsunfähig) oder intakt (funktionsfähig bzw. eingeschränkt funktionsfähig) ist. Lebensdauer Die zufällige Zeitspanne von der Inbetriebnahme bis zum ersten Ausfall der Komponente wird als Lebensdauer T der Komponente bezeichnet. Sie kann sinngemäß nur positive Werte annehmen, da das Lebensalter t nur positive Werte annimmt. Offenbarungszeit Version: 1.0 Seite 6 von 42

148 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Es sei die Offenbarungszeit. Sie gibt die Zeit zwischen dem Auftreten und dem Erkennen eines Ausfalles an. Ausfallwahrscheinlichkeit Es sei die Verteilungsfunktion der Lebensdauer T für alle. Diese Verteilungsfunktion beschreibt die Ausfallwahrscheinlichkeit. Des Weiteren gelten folgende Bedingungen: D.h. zum Zeitpunkt ist die betrachtete Komponente funktionsfähig und nach unendlich langer Zeit ist sie mit Sicherheit ausgefallen. Eigenschaften der Verteilungsfunktion Die Verteilungsfunktion besitzt im Punkt τ einen Sprung, falls. So gilt für den reinen Sprunganteil und den stetigen Anteil der Verteilungsfunktion mit n : D.h. es kann jede Verteilung in einen reinen Sprunganteil und in einen stetigen Anteil zerlegt werden: Der stetige Anteil ist wiederum zerlegbar, nämlich in einen singulären Anteil absolut stetigen Anteil. Daher gilt: und einen. Es existiert eine Dichte für den absolut stetigen Anteil so, dass Daraus ergibt sich für die Verteilungsfunktion: mit. für. Version: 1.0 Seite 7 von 42

149 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen In der Zuverlässigkeitsanalyse werden überwiegend absolute stetige Modelle untersucht, deshalb gilt: Dies führt zu der Bedingung:,. für. Zuverlässigkeitsfunktion (Survivalfunktion oder Überlebenswahrscheinlichkeit) Ist die Wahrscheinlichkeit, dass eine Komponente im Zeitintervall nicht ausfällt. Es gilt: Ausfalldichte Die Ausfall- oder Lebensdauerdichte wird definiert, als die Ableitung für den Fall, dass die Ausfallwahrscheinlichkeit F(t) eine absolut stetige Funktion ist:.. Die Ausfalldichte hat folgende Eigenschaften:,,,. Ausfallrate (Hazardrate) Es wird hierfür die Abhängigkeit der Ausfallwahrscheinlichkeit von der Lebensdauer betrachtet. Dazu wird eine Komponente, die das Lebensalter t erreicht und eine Lebensdauer T hat, berechnet. Es reicht nicht aus, die bedingte Wahrscheinlichkeit, d.h. die Wahrscheinlichkeit, dass die betrachtete Komponente innerhalb des nächsten Intervalls t ausfällt, zu betrachten, da diese von der beliebig wählbaren Länge abhängt. Die Ausfallrate wird daher wie folgt definiert: Wenn der Limes Version: 1.0 Seite 8 von 42

150 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen existiert, dann heißt die Funktion Ausfallrate, wobei ist. D.h. also, die Ausfallrate ist die Anzahl der Ausfälle je Zeiteinheit. Die Hazard-Rate gibt die Anzahl der gefährlichen Ausfälle an. Die Ausfallrate wird in FIT angegeben, wobei 1FIT = ist. Die Ausfallrate ist keine Wahrscheinlichkeit, jedoch ist näherungsweise die Wahrscheinlichkeit für einen Ausfall im Intervall, wenn bis zu diesem Zeitpunkt die Komponente funktionsfähig ist. Ausfallfunktion Für absolut stetige Verteilungsfunktionen gilt also: Integriert man nun, so erhält man die kumulierte (integrierte) Ausfallfunktion:. Aus der Bedingung folgt nun:. D.h. die Verteilung einer Zufallsvariablen kann angegeben werden: durch die Verteilungsfunktion F, durch die Zuverlässigkeitsfunktion R, durch die Ausfalldichte f oder durch die Hazard-Rate λ. Es sind alle Angaben äquivalent zueinander. Exponentialverteilung Die Zuverlässigkeitsverteilung für die Exponentialverteilung wird wie folgt berechnet. Es sei T (Lebensdauer) eine einparametrisch exponentialverteilte Zufallsgröße mit dem Parameter, so gilt für ihre Verteilungsfunktion: Version: 1.0 Seite 9 von 42

151 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen, für. Die Exponentialverteilung ist gedächtnislos, denn es gilt: Es sei die Restlebensdauer, dann folgt:. Die Exponentialverteilung ist die einzige Gleichverteilung mit konstanter Ausfallrate. Weiterhin erhalten wir: Dichte: Zuverlässigkeit: Erwartungswert (MTTF): Varianz: Ausfallrate: Ausfallfunktion: Der Erwartungswert wird für allgemein wie folgt berechnet: 2.5 Wichtige Größen und Formeln zur Berechnung der Zuverlässigkeit Begriffe und Einheiten MTTF (Mean time to failure): ist die mittlere Dauer bis zum Ausfall bzw. der Erwartungswert der Lebensdauer und wird bei Geräten genutzt, die bei einem Ausfall nicht repariert werden können, sondern ausgetauscht werden müssen. Die Maßeinheit ist a (Jahre). Version: 1.0 Seite 10 von 42

152 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen MTBF (Mean time between failures): ist die mittlere Dauer zwischen den Ausfällen und wird bei Geräten genutzt, die bei einem Ausfall repariert werden können. Die Maßeinheit ist a (Jahre). MTTR (Mean time to repair): ist die mittlere Reparaturzeit und wird in h (Stunden) angegeben. 1-aus-1-System (1001-, 1v1-System): Das System ist funktionsfähig, solange die eine Komponente dies ist. 1-aus-2-System (1oo2-,1v2-System): Das System ist funktionsfähig, solange eine der zwei vorhandenen parallel geschalteten Komponenten dies ist. 2-aus-2-System (2002-, 2v2-System): Das System ist funktionsfähig, solange die beiden Komponenten dies sind. 2-aus-3-System (2oo3-,2v3-System): Das System ist funktionsfähig, solange zwei der drei vorhandenen parallel geschalteten Komponenten dies sind Berechnung von MTTF-Werten Grundlagen Die Zuverlässigkeits-Kennwerte von Baugruppen (Systeme) werden grundsätzlich mit Hilfe einer FMEA und der Siemens-Norm SN ermittelt. Die Ausfallraten für die verwendeten Bauteile werden vom Hersteller gegeben oder mit Hilfe der Daten aus der Siemens-Norm SN bestimmt. Laut Norm werden die Ausfallraten als Erwartungswerte, bei angegebenen Referenzbedingungen, für einen gegebenen Zeitraum (>3000 h) definiert. Weiterhin wird der Sicherheitsfaktor S (gibt an, welcher Anteil der auftretenden Ausfälle sicherheitskritisch ist) für jedes einzelne Bauteil in Prozent festgelegt. Um den MTTF-Wert einer Baugruppe zu bestimmen, wird jede Baugruppe in Funktionsblöcke, d.h. in ihre Bauteile (z. B. Stellrelais, Überspannungsschutz usw. deren MTTF-Werte aus der Siemens-Norm kommen) aufgeteilt. Eine Komponente kann aus einem einzelnen Funktionsblock oder mehreren Funktionsblöcken bestehen. Mit Hilfe der System- und Bauteil-FMEA werden für jede Komponente die möglichen Fehlererkennungsmaßnahmen (Selbsttest, wie z. B. Rücklesen, Walking-Bit-Test usw.) von sicherheitskritischen Ausfällen analysiert. Die Fehlererkennungsmaßnahmen werden durch den Fehleraufdeckungsfaktor DC (diagnostic coverage factor) bewertet, wobei man sich an den Spannweiten der Tabelle A.1 aus IEC Faults or failures to be detected during operation or to be analysed in the derivation of safe failure fraction und der Tabelle C.2 aus IEC Diagnostic coverage and effectiveness for different subsystems orientiert Zuverlässigkeitsblockdiagramme Ein Funktionsblock wird nach der Funktion, der einzelnen Bauteile eines Systems zusammengesetzt. In Form eines Flussdiagramms werden die Funktionsblöcke, die zur Erfüllung einer bestimmten Funktion beteiligt sind in Serie (Reihe) und die redundanten Blöcke parallel, in einem Zuverlässigkeitsblockdiagramm zusammengeschaltet. Da das Zuverlässigkeitsblockdiagramm ein Ereignisdiagramm ist, existieren für jeden Funktionsblock nur die Zustände: intakt Version: 1.0 Seite 11 von 42

153 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen defekt Anmerkungen zur MTTF-Berechnung Grundlegende Voraussetzungen für die Berechnung: Der Einfluss der Leiterplatte wird berücksichtigt. Bauteile, deren Fehler nur bei Vorhandensein eines weiteren Fehlers bei einem anderen Bauteil zu einem kritischen Zustand des Systems führen, können als nicht relevant angenommen werden, da die Wahrscheinlichkeit der beiden unabhängigen Ereignisse vernachlässigbar gering ist. Für die Berechnung des MTTF-Wertes eines Systems werden sowohl die sicherheitsrelevanten Komponenten als auch die nicht sicherheitsrelevanten Komponenten berücksichtigt. Dafür werden die Ausfallraten der einzelnen Funktionsblöcke und deren MTTF-Werte nach der Part-count- Methode bestimmt Arten der MTTF-Ermittlung Analyse (rückblickende Untersuchung) Untersu- Prognose (vorausschauende chung) Vorteile Randbedingungen, Annahmen und Untersuchungszeiträume sind klar definiert, denn es handelt sich hier um rückblickende Untersuchungen. Zur Verfügung stehen Normen und Datenbankwerte, welche durch Herstellerangaben erweitert werden können. Nachteile In vielen Fällen sind nicht genug und geeignete Felddaten vorhanden. Es besteht eine gewisse Ungenauigkeit, denn es müssen Annahmen zugrunde gelegt werden, deren Zutreffen noch nicht bestätigt ist. Folglich ergeben verschiedene Standards unterschiedliche Ergebnisse Zusammenhang - R(t) und λ=const.: mit (für ), wobei die Wahrscheinlichkeit bezeichnet, dass das Gerät nach der Zeit t ausgefallen ist. MTTF und λ: MTTF und MTBF: MTBF=MTTF+MTTR (Da der MTTR-Wert gegenüber dem MTTF-Wert sehr klein ist, kann in den Berechnungen davon ausgegangen werden, dass MTTF MTBF gilt) Version: 1.0 Seite 12 von 42

154 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen MTTF und R(t): MTTF und λ=const.: Part-count-Methode Als Part-count-Methode bezeichnet man die Ermittlung einer Ausfallrate durch Addition der Ausfallraten von Bauteilen (z.b. nach der Siemens-Norm). Ein System soll zum Beispiel aus n Komponenten bestehen. Für das gesamte System gilt die Lebensdauer : wobei die Lebensdauern der einzelnen Komponenten unabhängig sind. Hieraus ergibt sich für das gesamte System die Zuverlässigkeit : Mit folgt: D.h. die Ausfallfunktion für das gesamte System ist gegeben durch: Weiterhin gilt: D.h. für die Ausfallrate des gesamten Systems gilt: Version: 1.0 Seite 13 von 42

155 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Für die MTTF-Werte gilt dann entsprechend: Redundanz Ein System, welches noch funktionsfähig ist, obwohl nicht alle seine Komponenten funktionsfähig sind, bezeichnet man als redundant Redundanz beim 1oo2 (1 out of 2) -System (ohne Reparatur) Wahrscheinlichkeit, dass zum Zeitpunkt t beide Komponenten ausgefallen sind: Wahrscheinlichkeit, dass zum Zeitpunkt t nicht beide Komponenten ausgefallen sind: Berechnung der MTTF: Redundanz beim 2oo3 (2 out of 3) -System (ohne Reparatur) Wahrscheinlichkeit, dass zum Zeitpunkt t alle drei Komponenten ausgefallen sind: Wahrscheinlichkeit, dass zum Zeitpunkt t zwei von drei Komponenten ausgefallen sind: Wahrscheinlichkeit, dass zum Zeitpunkt t eine von drei Komponenten ausgefallen ist: Wahrscheinlichkeit, dass zum Zeitpunkt t alle drei Komponenten nicht ausgefallen sind: Wahrscheinlichkeit, dass das System funktionsfähig ist, d.h. wenn mindestens zwei Komponenten intakt sind: Version: 1.0 Seite 14 von 42

156 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Berechnung der MTTF: Gleichzeitige Fehler in mehreren Komponenten (redundante Systeme mit Reparatur) Es werden hier in den folgenden Berechnungen wiederholt Fälle betrachtet, bei denen nur der gleichzeitige Ausfall von mehreren Komponenten zu einem Fehler führen kann. Es sind für die Berechnung der zugehörigen Fehlerraten die MTTF-Werte der beteiligten Komponenten und die MTTR von Bedeutung. Für zwei Komponenten gelten für die resultierenden Werte der MTTF und der MTTR die Literaturformeln: und Diese Formeln beziehen sich auf Fehler, die sich sofort nach ihrem Auftreten offenbaren. Dann ist die Reparaturzeit MTTR gleichzeitig die Zeitdauer, für die der Fehler besteht. Wenn dagegen unentdeckte gefährliche Fehler betrachtet werden, ist stattdessen die Summe aus der Fehleroffenbarungszeit T* und der Reparaturzeit MTTR maßgeblich. Bei Fehlern, die durch Dynamisierung oder andere regelmäßige Tests aufgedeckt werden, ist dies im statistischen Mittel das halbe Zeitintervall zwischen den Tests. (Wenn keine besonderen Tests zur Fehleraufdeckung stattfinden, ist es die halbe System- Lebensdauer.) Im Folgenden wird für alle Komponenten derselbe Wert für die mittlere Fehler-Lebensdauer angenommen und mit T/2 bezeichnet. Des Weiteren wird ausschließlich mit Ausfallraten (λ-werten) als Kehrwert der MTTF-Werte gearbeitet. Somit ergeben sich für zwei Komponenten folgende Formeln: und. Diese Formeln lassen sich auf mehr als zwei Komponenten verallgemeinern. Für den gleichzeitigen Ausfall von n Komponenten erhält man so als resultierende Ausfallrate: und. Version: 1.0 Seite 15 von 42

157 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen 2.6 Wichtige Größen und Formeln zur Berechnung der Sicherheit Die FMEA identifiziert die sicheren und gefährlichen Ausfallarten, den Anteil der gefährlichen Ausfälle und den Anteil der Common-Cause-Fehler (Ausfälle aufgrund gemeinsamer Ursache) und die Siemens-Norm liefert die Basis-Ausfallraten der Bauelemente Begriffe und Größen: Sicherheitsfaktor S: gibt den Anteil der gefährlichen Ausfälle an. Es gilt:. Diagnostic Coverage DC: gibt den Anteil der entdeckbaren gefährlichen Ausfälle an. Es gilt:. : ist die Basisausfallrate. : ist die Rate der sicheren Ausfälle. : ist die Rate der gefährlichen Ausfälle. Man unterscheidet in erkennbare (dangerous, detected) und in nicht erkennbare (dangerous, undetected) gefährliche Ausfälle. : ist der Anteil der entdeckbaren Common-Cause-Fehler. β: ist der Anteil der nicht entdeckbaren Common-Cause-Fehler. : gibt die Kanalbezogene (für eine Teilkomponente) mittlere Ausfallzeit an. PFH: ist die Rate von (gefährlichen, unerkannten) Fehlern. Sicherheits-Integritätslevel: Das Sicherheits-Integritätslevel SIL (Safety Integrity Level) gibt die Ausfallgrenzwerte für eine Sicherheitsfunktion, die in der Betriebsart mit hoher Anforderungsrate oder in der Betriebsart mit kontinuierlicher Anforderung betrieben wird an. Sicherheits- Integritätslevel Rate gefahrbringender Ausfälle der Sicherheitsfunktion Ausfallratenberechnung auf Funktionsblockebene Version: 1.0 Seite 16 von 42

158 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Die Ausfallraten,,, des Funktionsblockes werden wie folgt bestimmt: Es wird jedem Funktionsblock nach entsprechender Analyse (z.b. durch FMEA) der Schaltung ein Sicherheitsfaktor S und ein Fehleraufdeckungsfaktor DC zugeordnet. Mit der Part-count-Methode, d.h. durch Addition der Basisausfallraten der einzelnen Bauteile (gegeben vom Hersteller oder durch die Siemens-Norm) eines Funktionsblockes, kann eine Basisausfallrate für den entsprechenden Funktionsblock bestimmt werden: Die weiteren Ausfallraten bestimmen sich wie folgt: Rate der sicheren Ausfälle Rate der gefährlichen Ausfälle Rate der erkennbaren sicherheitskritischen Ausfälle Rate der nicht erkennbaren sicherheitskritischen Ausfälle Common-Cause-Anteil Kanalbezogene mittlere Ausfallzeit Diese Formel gilt nur für ein 1002-System Wichtige Formeln zur Berechnung von PFH Für 1oo1-Systeme Für 1oo2-Systeme Version: 1.0 Seite 17 von 42

159 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen 2.7 FMEA Die FMEA (Failure Mode and Effects Analysis) oder Auswirkungsanalyse ist ein wichtiger Bestandteil des RAMS-Prozesses. Sie ermittelt systematisch mögliche Fehlerzustände, ihre Ursachen und ihre Auswirkungen auf das Verhalten des Systems. Es gibt drei Arten der FMEA: System-FMEA (bzw. Bauteil-FMEA), Konstruktions-FMEA und Prozess-FMEA. Die System-FMEA wird auf Systemebene in der Produktentwicklung durchgeführt, um auftretende Fehler oder Schwachstellen rechtzeitig zu identifizieren und somit die Funktionalität des Systems zu gewährleisten. Die Konstruktions-FMEA hingegen dient dazu mögliche Entwicklungs- bzw. Prozessfehler zu identifizieren, um diese dann durch vorsorgliche Maßnahmen zu verhindern oder zu beheben. Dazu werden einzelne Bauteile, Produkte oder deren Entwurf auf eventuelle Schwachstellen in der Gestaltung oder Auslegung analysiert. In der Prozess-FMEA werden die Eignung, die Sicherheit des Herstellungsverfahrens, die Qualitätsund Prozessfähigkeit betrachtet und die Realisierungsrisiken identifiziert, um bessere Maßnahmen für die Durchführung der Fertigungsprozesse bereit zu stellen. Die FMEA besteht aus vier Hauptstufen: Planung, Terminierung, Teambildung Es wird zunächst ein Team aus Experten und Fachleuten gebildet. Dann werden der untersuchte Gegenstand, das Ziel und die erwarteten Ergebnisse definiert. Um eine rechtzeitig durchgeführte Analyse zu gewährleisten werden Zwischenziele vereinbart und es werden Maßnahmen festgelegt, die für die Überwachung und Dokumentation der FMEA dienen. Durchführung der Analyse Die folgende grafische Darstellung stellt den Ablauf der Analyse dar: Abbildung 1: FMEA-Analyse Bericht, Ergebnisse Die Zeichnungen, die Systemarchitektur und die Funktion des untersuchten Gegenstandes werden beschrieben. Dazu werden vorab getroffene Definitionen und Festlegungen verwendet. Ein detailliertes Protokoll der Durchführung wird erstellt und es werden Ausfälle mit schwerwiegenden Auswirkungen angegeben. Weiterhin werden die Änderungen, die während der Erstellung der FMEA entstanden sind, beschrieben. Empfehlungen/Aktionen für Konstrukteure, Instandhaltungspersonal, Planer und Anwender werden angefertigt. Der Schluss des Ergebnisberichtes besteht aus einer Zusammenfassung der Analyse. Fortschreiben der FMEA Die FMEA wird überarbeitet bzw. fortgeschrieben bzgl. Änderungen des Entwicklungs- Prozesses, wie z.b. leicht geänderter Systeme oder Änderungen nach Umsetzung von festgelegten Maßnahmen. Die Ziele der FMEA sind das Erkennen von (gefährlichen) Ausfällen eines Systems und eine Beurteilung durch eine Klassifizierung bzgl. Erkennbarkeit, Prüfbarkeit, Diagnosefähigkeit, Reparatur und Version: 1.0 Seite 18 von 42

160 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Instandhaltung. Zusätzlich wird eine Verbesserung der Instandhaltbarkeit des Systems, der Sicherheit oder der Systemfunktionsfähigkeit erreicht, in dem z.b. ein Entwurfsverbesserungsplan und ein effektiver Instandhaltungsplan zur Vermeidung von Ausfällen entwickelt werden. 2.8 Zusammenhang zwischen Siemens-Norm, FMEA, Zuverlässigkeit, Sicherheit und RAMS-Nachweisdokumenten Siemens-Norm Die Siemens-Norm beinhaltet die Basis-Ausfallraten der Bauelemente, den Anteil der gefährlichen und nicht gefährlichen Ausfälle und den Anteil der Common-cause-Fehler, d.h. sie liefert Grundlagen für die Berechnungen der Zuverlässigkeit und der Sicherheit (siehe Pfeil a). FMEA Die FMEA dient dazu Schwächen frühzeitig zu erkennen und liefert eine Rangliste von Ausfallarten, welche verschiedene Auswirkungen auf das System haben. Diese Betrachtungen fließen dann in die Berechnungen der Zuverlässigkeit und der Sicherheit mit ein (siehe Pfeil b). Zuverlässigkeit Mit Hilfe der Zuverlässigkeit ist es möglich Funktions- und Sicherheitsausfälle von Systemen einigermaßen vorherzusagen. Die Ergebnisse der Zuverlässigkeit (die MTTF- und MTBF- Werte sowie die Zuverlässigkeitsfunktion) bilden eine Grundlage für die Sicherheitsberechnungen und fließen in die RAMS-Nachweisdokumente mit ein (siehe Pfeil c+d). Sicherheit Die Sicherheitsberechnungen dienen dazu, die Folgen der Ausfälle von Komponenten (Systemen) soweit wie möglich vorherzusagen, zu analysieren und zu beherrschen, d.h. Maßnahmen zu entwickeln, um schwerwiegende Folgen von Ausfällen zu vermeiden. Sie liefern die Hazard-Rate (Anteil der gefährlichen Ausfälle) und gibt somit an, welche Sicherheitsintegritätsstufe das System besitzt. Da die Zuverlässigkeit und die Sicherheit voneinander abhängige Größen (siehe Pfeil c) sind, liefert die Sicherheit auch Grundlagen zur Berechnung der Zuverlässigkeit (PFH-Werte). RAMS-Nachweisdokumente RAMS (Systemlebenszyklus) beinhaltet zum einen die Ergebnisse aus den Berechnungen der Zuverlässigkeit und der Sicherheit (siehe Pfeil d+e) und zum anderen die Ergebnisse aus den Verfügbarkeits- und Instandhaltbarkeitsbetrachtungen. In der folgenden Abbildung werden die einzelnen Zusammenhänge dargestellt. Version: 1.0 Seite 19 von 42

161 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Siemens-Norm b FMEA a a Zuverlässigkeit d c Sicherheit b e RAMS-Nachweisdokumentation Abbildung 2: Grafische Darstellung der Zusammenhänge 2.9 Fehlerbaumanalyse Die Fehlerbaumanalyse (FTA) ist ein ableitendes bzw. fortführendes Verfahren, welches ein System bezogen auf seine Komponenten in einem booleschen Modell darstellt. Diese Darstellung dient dazu, die Wahrscheinlichkeit des System-Ausfalls zu bestimmen. Den Anfang der Analyse macht immer ein unerwünschtes (gefährliches) Ereignis (Hauptereignis). Von dem Hauptereignis aus verlaufen alle kritischen Pfade (Kombinationen von Komponentenausfällen des Systems), die dieses verursachen können. Diese werden als Ausfallereignisse (das zum Hauptereignis führt) oder Basisereignis bezeichnet. In der Fehlerbaumdarstellung werden für eine Reihenschaltung OR-Gatter (das Ausgangsereignis tritt nur dann ein, falls irgendeines der Eingangsereignisse eintritt) und für eine Parallelschaltung AND-Gatter (das Ausgangsereignis tritt nur dann ein, falls alle Eingangsereignisse eintreten) verwendet. Die folgenden Abbildungen zeigen diesen Zusammenhang. Version: 1.0 Seite 20 von 42

162 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Hauptereignis z.b. Ausfall der Schaltung: Signal wird nicht korrekt übertragen OR Block A Ausfallereignis das zum Hauptereignis führt (unterbricht das Signal) Die Blöcke B und C unterbrechen das Signal AND Block B Ausfallereignis das ein Basisereignis ist (unterbricht das Signal) Block C Ausfallereignis das ein Basisereignis ist (unterbricht das Signal) Abbildung 3: Grafische Darstellung von logischen Verknüpfungen in einem Fehlerbaum. Version: 1.0 Seite 21 von 42

163 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Abbildung 4: Grafische Darstellung der zu analysierenden Schaltung als Zuverlässigkeits-Blockdiagramm Die folgende Tabelle erklärt die meist verwendeten Symbole. Tabelle 1: FTA-Symbole Symbol Name Beschreibung Grundereignis OR-Gatter AND-Gatter Transfer-Gatter Sind Ereignisse, für die Angaben zur Eintrittswahrscheinlichkeit und Zuverlässigkeit vorliegen Das Ausgangsereignis tritt nur dann ein, wenn irgendeines der Eingangsereignisse eintritt Das Ausgangsereignis tritt nur dann ein, wenn alle Eingangsereignisse eintreten Wird verwendet, wenn sich der Fehlerbaum über mehrere Seiten erstreckt oder Elemente des Baumes wiederholt werden. Version: 1.0 Seite 22 von 42

164 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen Bei der FTA wird zwischen qualitative und quantitative FTA unterschieden, wobei die quantitative FTA die qualitative FTA enthält. Quantitative FTA Qualitative FTA Abbildung 5: Zusammenhang zwischen quantitativer und qualitativer FTA Qualitative Fehlerbaumanalyse Die qualitative FTA verwendet man zu folgenden Zwecken: Identifikation der relevanten Ausfallarten der Komponente und des Systems, d.h. der Systemaufbau wird analysiert und bewertet. Nachweis, dass die qualitative Anforderung, ein Einzelausfall führt nicht zu einem gefährlichen Ereignis, erfüllt ist Quantitative Fehlerbaumanalyse Die quantitative FTA ist eine Erweiterung der qualitativen FTA. Sie wird verwendet um zusätzlich: die Ausfallwahrscheinlichkeit und Ausfallrate eines Hauptereignisses zu ermitteln, nachzuweisen, dass die quantitativen Sicherheitsziele erfüllt sind, und ein quantitative Zuteilung der SIL an die Komponenten vorzunehmen Mathematische Vorgehensweisen bei der Fehlerbaumanalyse Berechnung der Ausfallwahrscheinlichkeit im Fehlerbaum Angenommen das System besteht aus zwei Komponenten. Dann gilt für die Ausfallwahrscheinlichkeit des Systems : - wenn Komponente 1 oder Komponente 2 ausfällt, so fällt auch das ganze System aus - wenn Komponente 1 und Komponente 2 ausfallen, so fällt auch das ganze System aus Version: 1.0 Seite 23 von 42

165 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Theoretische Grundlagen D.h. für ein System aus n-komponenten, wobei die Ausfallraten der einzelnen Komponenten konstant sind und die Fehleroffenbarungszeit haben, gilt dann: Tabelle 2: Ausfallraten Common-Cause-Fehler-Analyse in einem Fehlerbaum Bei der CCF-Analyse wird die Unabhängigkeit der Komponenten untersucht und, falls man die Unabhängigkeit nicht vollständig nachweisen kann, wird in der CCF-Analyse der CCF in einer geeigneten Genauigkeitsebene modelliert. D.h. die CCF-Analyse ist eine Maßnahme, um die Ausfallwahrscheinlichkeit, welche hervorgerufen wird durch gemeinsame Ursachen der Komponenten, zu verringern. In der Fehlerbaumdarstellung wird der CCF durch eine logische AND-Verknüpfung gekennzeichnet. Version: 1.0 Seite 24 von 42

166 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis 3 Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis 3.1 Anforderungen für die Diagnose archivierter Daten Eine Server-Applikation im Stellwerksnetz soll sicherstellen, dass die aktuellen Stellwerks- und Bedienplatzinformationen (Kommandos, Meldungen, Störungen und Fehler) sowie der Kommunikationsschnittstellen geloggt und an autorisierte Abnehmer verteilt werden. Des Weiteren muss diese Server-Applikation dafür sorgen, dass die Logdateien geeignet zentral archiviert, abgelegt werden und an die autorisierten Abnehmer verteilen. Für den Logging-Mechanismus sind mindestens folgende formale Anforderungen zu realisieren. [ANF1] Logdateien protokollieren die aktuellen Zustandsänderungen sowie Störungen und Fehler der Stellwerkselemente kontinuierlich jeweils für einen per Konfiguration festgelegten Zeitzyklus. [ANF2] In Stellwerkskonfigurationen mit Bedienzentrale werden die Bedienplatzinformationen kontinuierlich mit festgelegtem Zeitzyklus protokolliert. [ANF3] Zusatzinformationen zu Stör- und Fehlerzustände sind durch manuelle Eingaben am Bedienerarbeitsplatz in der Bedienzentrale oder bei der Erfassung von Reparaturtätigkeiten bei der Wartung durch ein User Interface (siehe Prototyp) möglich. Diese werden für eine nachfolgende Auswertung mitprotokolliert. [ANF4] Die protokollierten Daten (ANF1-ANF3) werden rückwirkungsfrei auf das Stellwerk zentral erfasst und bereitgestellt. [ANF5] Es ist sicherzustellen, dass auf dem Logsystem die korrekte Systemzeit vorliegt, damit die protokollierten Ereignisse eindeutig zuzuordnen sind. 3.2 Anforderungen für die Diagnose aktueller Daten Als aktuelle Daten werden die Daten betrachtet, die noch nicht erfasst und archiviert wurden. Die aktuellen Informationen des Stellwerks, des Bedienplatzes und der Kommunikationsschnittstellen werden autorisierten Abnehmern zur Verfügung gestellt. Je nach Erfassung der Daten, ist es möglich, dass eine Unterscheidung zu archivierten Daten nicht notwendig ist, da alle Daten sofort zentral erfasst werden. Für die Datenübertragung und das Format sowie den Inhalt der Telegramme sind folgende formale Anforderungen zu realisieren: [ANF6] Die Datenübertragung zur Diagnose Auswerteplattform muss rückwirkungsfrei auf das Stellwerksnetzwerk sein. Dazu ist ein geeigneter Datenbus mit entsprechendem Übertragungsprotokoll zu wählen. [ANF7] Die Datentelegramme werden mit einem Zeitstempel für den Erfassungszeitpunkt der Meldung gesendet. [ANF8] Der Aufbau des Datentelegramms soll für die Diagnose so allgemein sein, dass es unabhängig von Stellwerk, Schnittstellensignal oder Bedienkommando ist. [ANF9] Optional soll es für Meldungen vom Bedienplatz den Bearbeitungsstatus für die Meldung beinhalten. Version: 1.0 Seite 25 von 42

167 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis 3.3 RAMS Anforderungen [ANF10] Der Ablageort der Logdateien muss festgelegt sein und es müssen Maßnahmen zur sicheren Speicherung getroffen sein. [ANF11] Die Bestätigung der Berechnungen der MTBF-Werte, auf die die Berechnungen des RAMS-Managements basieren (siehe Kapitel 2), soll damit möglich sein. Eine Vorhersage für die Lebenszeit von Baugruppen und die Veranlassung eines vorsorglichen Austausches von Baugruppen soll damit basierend auf konkreten technischen Daten nachweislich möglich sein. [ANF12] Um Verfälschungen von Inhalten der Logdateien beim Speichern oder der Datenübertragung erkennen zu können, sind geeignete Maßnahmen zu ergreifen (z.b. CRC- Prüfsumme). [ANF13] Die Auswertung der Diagnosedaten aus dem archivierten Datenbestand soll den Anspruch erfüllen, die technische Zuverlässigkeit und Verfügbarkeit des betrachteten Stellwerkssystems nachweisen zu können. 3.4 Abfrage der Diagnoseinformationen Die Diagnose basiert auf dem zentral auf der Diagnose Auswerteplattform bereitgestellten Datenbestand und den aktuellen Meldungen der Stellwerke und Bedienplätze. Der Datenbestand kann vorzugsweise in einer Datenbank organisiert sein. Der Datenbestand sollte außerdem eine Verlinkung von Handlungsanweisungen des Wartungsbedienhandbuchs sowie projektierte Fehler- und Störungstexten zu festgelegten Kombinationen von Werten der Schnittstellensignale enthalten. Ein Serverprozess auf der Diagnose Auswerteplattform soll die folgenden Anforderungen erfüllen: [ANF14] Verwaltung der Nutzer der Diagnose Auswerteplattform, die sich beim Serverprozess anmelden können (Servicepersonal der LST). [ANF15] Entgegennahme von Diagnoseabfragen eines autorisierten Clients, Ermitteln und Senden der Abfrageergebnisse an einen autorisierten Client. [ANF16] Die Auswertung der Diagnosedaten aus dem archivierten Datenbestand soll den Anspruch erfüllen, die technische Zuverlässigkeit und Verfügbarkeit des betrachteten Stellwerkssystems nachweisen zu können. 3.5 Architekturentwurf für die Diagnose In diesem Kapitel soll grob die Struktur eines Diagnose-Netzwerkes basierend auf einem Alister Stellwerk aufgezeigt werden. Version: 1.0 Seite 26 von 42

168 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis Übersicht Diagnose-Netzwerk D D Bedienzentrale Diagnosezentrale Switch D D D D Ethernet Ethernet Ethernet Ethernet lok. Diagn. Modas Modas lok. Diagn. lok. Diagn. lok. Diagn. Modbus Modbus Modbus Modbus TS Stellwerk Stellwerk Stw-Kern Stw-Kern Stellwerk Stellwerk V24 Ethernet Ethernet Ethernet Ethernet P Switch P P P räumlich zusammen P Prozessdaten D Diagnosedaten Funkverbindung Abbildung 6: Aufbau des Diagnose-Netzwerkes Version: 1.0 Seite 27 von 42

169 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis Beschreibung Diagnose-Datenströme In Abbildung 6 wird im oberen Teil ein möglicher Aufbau eines Diagnose-Netzwerkes dargestellt. Die mit "Stellwerk" bezeichneten Elemente repräsentieren ein Stellwerk mit all seinen Außenanlagen. Die Netzwerkverbindungen mit den Prozessdaten P sollen hier nicht von Belang sein. P und D sind physikalisch getrennte Netzwerke. Das Element "lok. Diagn." (lokale Diagnose) stellt ein eigenständiges Diagnosesystem dar, welches die aktuellen Zustands-/Diagnosedaten der einzelnen Stellwerkselemente entgegen nimmt und darstellt. Empfangen werden die Rohdaten rückwirkungsfrei von einer Schnittstelle, z.b. Modbus- Schnittstelle, im Stellwerk. Die Rohdaten werden zudem über eine Ethernet-Schnittstelle D zu einer Diagnose-Zentrale gemeldet. Um bei Verbindungsunterbrechungen keine Daten zu verlieren, werden die Rohdaten auch auf dem lokalen Diagnosesystem archiviert. Wird nach einer Verbindungsunterbrechung die Verbindung zur Diagnose-Zentrale wieder hergestellt, so werden die lokal archivierten Daten für den Zeitraum der Unterbrechung nachgesendet. Über eine Funkverbindung können Diagnosedaten von entfernten Umsystemen, die keine Diagnosemeldungen an ein Stellwerk melden, abgerufen werden. Bei dieser Art des Zugriffs handelt es sich jedoch um zeitlich begrenzte, d. h. keine permanente Verbindung. In der Diagnose-Zentrale können die Zustands-/Diagnosedaten der einzelnen Stellwerke online dargestellt werden. So haben die LST-Techniker von der Zentrale aus die Möglichkeit, eine erste Analyse von Störungen durchzuführen. Werden Störungen angezeigt, die durch geplante Wartungsarbeiten auftreten, so können diese entsprechend gekennzeichnet (1) werden, z.b. durch ein integriertes "Störungsbuch". Des Weiteren werden die empfangenen Daten archiviert. Mit den Archivdaten wäre dann eine statistische Auswertung möglich, um die Werte der Verfügbarkeit zu verifizieren. Hierbei werden die gekennzeichneten Störungen (1) nicht in die Verfügbarkeitsberechnung einbezogen. Für den rückwirkungsfreien Anschluss der Bedienzentrale an das Diagnose-System wird eine serielle Verbindung verwendet D, die über einen Terminalserver an das Diagnose-Netzwerk angeschlossen ist. Die Archivierung wird analog zu den Stellwerken durchgeführt Beschreibung Störungsermittlung Bedienzentrale In der Bedienzentrale sollte ein Prozess installiert werden, welcher die ermittelten Stör/Diagnose- Daten z.b. via V24-Schnittstelle an die Diagnose-Zentrale übermittelt. Zu diesen Stör- bzw. Diagnose- Daten gehören CPU-Last, Speicherauslastung, Plattenplatz und Netzwerk-Aktivität etc Analyse von Architekturen gemäß bestehender Systeme Den Veröffentlichungen bzgl. Diagnose kann entnommen werden, dass die Lösungsansätze bzgl. des oben dargestellten Konzepts schon umgesetzt werden bzw. sich in der Umsetzung befinden. Als Beispiele seien einige Veröffentlichung von 2013 genannt: Moderne Internetdienste in Diagnose und Instandhaltung (T. Giesen, M. Rieder), Signal & Draht 4/2013: Aufnahme der Diagnosemeldung/Ferndiagnose via GSM- oder GSM-R unter Nutzung von verschlüsselten paketorientierter Datenverbindungen Wie Bahnen länger fahren: Früh- und Ferndiagnose steigern die Verfügbarkeit (J. Knogler), Signal & Draht 5/2013: IT- und Mobilfunk-gestützter Service und "zustandsorientierten" Diagnosestrategie Visualisierung Maschinentechnischer Anlagen, Signal & Draht 05/2013: Einbindung von Informationen von maschinentechnischer Anlagen in ein Leit- und Visualisierungssystem Ziel vorab zitierten Konzepte ist eine verbesserte Anbindung und Bereitstellung von Diagnosemöglichkeiten sowie eine Effizienzsteigerung im Bereich der Instandhaltung und Wartung. Man erkennt, dass jedoch der weitere Schritt zur Bestätigung der sicherheitsgerichteten Annahmen konzeptionell Version: 1.0 Seite 28 von 42

170 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis nicht in einem Diagnosesystem aufgegriffen wird. Ziel sollte jedoch sein, dass nicht nur die LST konzeptionell von einem Diagnosesystem unterstützt werden soll. Auch die Belange eines RAMS- Prozesses sollten bei der Erstellung eines übergreifenden Konzepts mit aufgegriffen werden. Durch die Auswertung der Daten aus dem Ist-Prozess und einem Vergleich mit den theoretisch berechneten Werten können die Zusammenhänge für den Betreiber und das EBA besser aufbereitet werden und eine verbesserte Bewertung des Risikomanagementprozesses von der Risikoanalyse bis zum Installationsprozess kann aufgesetzt werden. Anhand des Prototyps soll gezeigt werden, ob diese Anwendung einer durchgängigen Prozesskette (von einer Berechnung im Rahmen der Nachweisführung bis zur Bestätigung anhand von Ist-Daten) wirtschaftlich vertretbar durch Anwendung aktuelle Technologien umgesetzt werden kann. Version: 1.0 Seite 29 von 42

171 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anforderungen an den Prototypen 4 Anforderungen an den Prototypen Der Prototyp für die Diagnose Auswerteplattform soll die Anforderungen [ANF1] [ANF16] am Beispiel der Stellwerksprojekte ESTW-R abdecken. Im Dokument NeGSt_Ergebnisbericht_2500_Feinkonzept_Diagnose_Prototypvorgaben können die aus diesen übergeordneten Anforderungen abgeleiteten Vorgaben für die Erstellung eines Prototyps entnommen werden. Version: 1.0 Seite 30 von 42

172 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen 5 Ergebnis aus den prototypischen Betrachtungen 5.1 Eine beispielhafte Betrachtung der Fehlermöglichkeiten Die Ermittlung der Fehlermöglichkeiten und das Berechnen der gefährlichen Ausfälle (Hazard-Rate) des Systems wird hier beispielhaft an der Blockschnittstelle Eckernförde Gettorf, d. h. anhand einer Betrachtungseinheit aus dem Pilotprojekt der Funkwerk AG, dargelegt Quelle der Fehlermöglichkeiten Die Prüfspezifikation liefert die auftretenden Fehlermöglichkeiten, die hier am Beispiel des Relaisblocks erläutert sind. Diese Fehlermöglichkeiten sind grau markiert. Diese grau markierten Felder können jedoch auch einfach nur allgemeine Zustandswechsel darstellen und müssen nicht unbedingt Fehler anzeigen. Dies zeigt der folgende Auszug der Prüfspezifikation. Abbildung 7: Fehlerklassifizierung am Beispiel RBLK (Alister) Version: 1.0 Seite 31 von 42

173 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen Darstellung der Fehlermöglichkeiten Für eine bessere Übersicht über die Fehlermöglichkeiten stellt man diese in einer weiteren Tabelle dar. 400 Umschaltung des Motorinduktors Erlaubnis vorhanden X Prüffall ID Prüffall Beschreibung Prüffallablauf mit Beschreibung GP_A GP_UE FS_A FS_UE HM_A HM_UE Ea_A Ea_UE MU_A MU_UE 401 Erlaubnis nicht vorhanden Fehlermöglichkeiten am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren. Tabelle 3: Es sind die nicht gefährlichen Ausfälle grün und die gefährlichen Ausfälle rot gekennzeichnet. Ein gefährlicher Ausfall tritt z.b. ein, wenn: eine Meldung zeitlich früher als erwartet kommt oder sich Varianten überschneiden, bei antivalent meldenden Bauteilen beide ausfallen und die Störung daher nicht erkannt wird oder ein doppelter Fehler auftritt, der nicht erkannt werden kann, z. B. A geht aus und Ü geht an. Der nächste Schritt besteht nun darin, mit Hilfe der System-Aufbau-Zeichnung zu analysieren, wie die einzelnen Bauteile zusammengesetzt sind und wie groß die Anzahl der einzelnen Bauteile ist. Darauf basierend kann man eine neue Fehlerbetrachtung machen, die alle Bauteile enthält. Hier ein Auszug einer möglichen Fehlerbetrachtungstabelle: X Relais GP A Relais GP UE Relais GP A Relais GP UE 2 Relais H4135A Komponente oder Funktionsblock Anzahl der Kontakte λ_1 [1/h] λ_14 [1/h] λ_15 [1/h] λ_16 [1/h] λ_17 [1/h] Fehlermöglichkeiten 2 X X λ_18 [1/h] λ_19 [1/h] λ_20 [1/h] λ_45 [1/h] 2 X X 1 X 1 X X Tabelle 4: beispielhafte Fehlerbetrachtung am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren. Aus den einzelnen Berechnungen und Analysen, die in den vorherigen Tabellen dargelegt worden sind, ist zu erkennen, dass das System ausfällt, wenn: alle Relais einer Baugruppe ausfallen (wie in der Spalte λ_1), Version: 1.0 Seite 32 von 42

174 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen ein Relais mit der dazu gehörigen F3DIO (wie in den Spalten λ_19 und λ_20) ausfällt, jeweils einzeln alle F3DIO, beide Relais H4135A oder die F30 ausfallen (wie in den Spalten λ_45, λ_15 und λ_16) oder das Bauteil Safe Ethernet (wie in der Spalte λ_14) ausfällt. In diesem Fall stehen nur die Ausfallraten der Bauteile F3DIO, Relais H4135A und der F30 als Herstellerangaben zu Verfügung, d.h. es sind noch die Ausfallraten der Relais-Bauteile zu berechnen (siehe obige Tabelle Blockschnittstelle Eckernförde - Gettorf). Diese Daten werden zur Berechnung der Ausfallraten herangezogen. Den berechneten PFH-Wert der Relais verwendet man anschließend in der Berechnung für die Hazard-Rate. Die Ausfallrate der Relais HvBI A und HvBl UE fließen z.b. nicht in den Wert der Hazard- Rate mit ein, da diese nur zu einem nicht gefährlichen Ausfall führen. Diese Werte können gesonderte markiert werden, damit auch optisch festgehalten wird, dass diese Werte nicht relevant sind. Das Ergebnis der Berechnung wird anschließend in die entsprechende RAMS-Dokumentation übertragen. 5.2 Analysemöglichkeiten Motivation Die Angaben vom Wartungspersonal zur Störungsursache (Umwelt, Wartungsarbeiten, Geräteausfall usw.) sowie der Dauer der Entstörung und die vom RAMS-Manager angegebene Einschätzung der Art der Gefährdung (relevant oder nicht relevant für die Sicherheitsbetrachtung des gesamten Systems) bilden die Datenbasis für dedizierte statistische Auswertungen in Hinblick auf die oben behandelten RAMS-Parameter. Anhand einer statistischen Analyse der aufgetretenen Störungen soll es dem RAMS-Manager möglich sein, (auch immer wiederkehrende) Störungen rechtzeitig zu erkennen und zu beheben. Eine Server-Applikation soll als Hilfsmittel dienen, um vom Stellwerkshersteller unabhängige Störungsbetrachtungen und Störungsermittlungen, sowie deren Behebungen und statistische Auswertungen durch das Servicepersonal der LST zu erstellen und zu vereinfachen. Die dazu notwendigen Informationen vom Stellwerk und der Bedieneroberfläche sollen sowohl aktuell als auch aus archiviertem Datenbestand dem Servicepersonal der LST zur Verfügung stehen. Dies soll durch eine gut strukturierte Übersicht und Klassifizierung der Störungsarten geschaffen werden. Eine wichtige Hilfestellung dafür ist z. B., dass dem Wartungspersonal aus dem Datenbestand der Server-Applikation die möglichen betroffenen Bauteile zu der aufgetretenen Störung angezeigt werden und somit eine gezielte Reparatur oder ein schneller Austausch des Bauteils bzw. der Bauteile vorgenommen werden kann Applikationen Die Server-Applikation im Stellwerksnetz soll sicherstellen, dass die aktuellen Stellwerks- und Bedienplatzinformationen (Kommandos, Meldungen, Störungen und Fehler) und der Daten der Kommunikationsschnittstellen geloggt werden. D.h. die Applikation schreibt die Zustandsänderungen, Fehler und Störmeldungen der Schnittstellensignale (Stellwerkselemente) in Log-Dateien (survey-dateien) in komprimierter Form. Die zentrale StwStatistik-Applikation der Auswerteplattform sorgt dafür, dass die Log-Dateien zur Verbesserung der Abfragemöglichkeiten geeignet in eine relationale Datenbank archiviert werden. Diese Transformation wird momentan im Prototypen noch manuell durch das Aufrufen einer Kommando-Datei Start_Transformation durchgeführt und sollte im Zielsystem automatisch im Hintergrund ablaufen. Version: 1.0 Seite 33 von 42

175 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen Eine Auswertung der Daten aus der Datenbank durch autorisierte Nutzer wird mit dem NeGSt-Client ermöglicht. Diese Applikation ist firmenunabhängig und befindet sich ebenfalls auf der Auswerteplattform. Die Analyse des Auftretens von Störungen und deren Ursachen sowie deren Behebung werden mit den Abfragemöglichkeiten einer relationalen Datenbank und den statistischen Auswertungen im Hintergrund vereinfacht. Die Idee einer zentralen, herstellerunabhängigen Auswerteplattform er-leichtert dem LST-Personal die Servicearbeiten für verschiedene Stellwerksbauformen NeGSt-Client Im NeGSt-Client gibt es die Register Administration, aktuelle Informationen, Auswertung und Wartungsinformationen. Für eine Auswertung der Log-Dateien sind die Register aktuelle Informationen, Auswertung und Wartungsinformationen vorgesehen. Änderungen in den Registern aktuelle Informationen und Wartungsinformationen können durch einen Doppelklick in den Tabellen schnell und einfach vorgenommen werden. D. h. mit dem Doppelklick steht eine einfache Navigation zur Bearbeitung der Daten zu Verfügung. Ein Doppelklick in einer Zeile im Register aktuelle Informationen führt zur automatischen Navigation ins Register Wartungsinformationen mit Übernahme der Daten. Im Register Wartungsinformationen kann durch Doppelklick in der Wartungsinformationszeile eine Vorbelegung der Eingabeschaltflächen für Änderungen in der Wartungstabelle erfolgen. Beendet werden kann der Client durch Beenden vom Menüpunkt Programm Nutzer des NeGSt-Clients Die Nutzer des Clients werden in die Rollen Administrator, Wartungspersonal (untergliedert in LST und Maintenance ) und RAMS-Manager unterteilt. Durch diese Rollen werden grundsätzlich auch die Rechte der einzelnen Nutzer festgelegt. Für den Administrator sind alle Informationen, die es im Client zu den Daten aus der Datenbank gibt, einsehbar. Er kann neue Nutzer anlegen, ändern und deren Nutzungsrechte festlegen. Für das Wartungspersonal sind nur die Informationen einsehbar, die zur Wartung notwendig sind. Das Wartungspersonal kann diese Informationen jeder Zeit bearbeiten und erweitern. Die Daten für eine statistische Betrachtung bzw. Auswertung der Störungen sind für den RAMS- Manager einsehbar. Er kann diese Informationen zu jeder Zeit bearbeiten oder erweitern. Zusammenfassend kann festgehalten werden, dass jeder Nutzer nur die spezifische Nutzungsrechte, welche in der Datenbank hinterlegt sind, hat. Es ist somit erforderlich, dass sich der Nutzer beim Starten des Clients anmeldet Administration Dieses Register steht nur dem Administrator und dem RAMS-Manager zu Verfügung. Es wird hier angezeigt, wie viele Nutzergruppen es gibt (im Prototyp wurden 4 verschiedene Rollen definiert) und welche Rechte der Nutzer hat. Diese Rechte kann nur der Administrator festlegen. Version: 1.0 Seite 34 von 42

176 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen Abbildung 8: Rechte und Anzahl der Nutzer vom Client Aktuelle Informationen Dieses Register ist für alle Nutzer sichtbar. Hier werden alle auszuwertenden Log-Daten und die Anzahl der auswertbaren Datensätze ausgegeben. Für eine Filterung ist es möglich, eine Auswahl des Stellwerks, des Elementtyps, des Elements oder des Störungszeitraums vorzunehmen. Des Weiteren besteht die Möglichkeit, eine Auswahl zwischen Fehler und Elementstatus zu treffen. Sind alle gewünschten Auswahlmöglichkeiten getroffen und wird Abfrage gestartet, so werden nur die Informationen gemäß der getroffenen Filterung angezeigt. Die Detailinformation erklärt die Störungsart. Abbildung 9: Darstellung der aktuellen Informationen ohne Festlegung von Auswahlkriterien. Version: 1.0 Seite 35 von 42

177 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen Abbildung 10: beispielhafte Darstellung der aktuellen Informationen nach Festlegung möglicher Auswahlkriterien Auswertung Dieses Register ist für das Wartungspersonal nicht relevant und somit auch nicht sichtbar. Diese Daten stehen dem RAMS-Manager zur Verfügung; es werden hier Angaben zu den relevanten Störungen (also Störungen von Komponenten) ausgegeben: zur Anzahl der Ausfälle (wie oft das betroffene Bauteil ausfällt, d.h. der RAMS-Manager kann bei ausreichend hoher Anzahl von Beobachtungen überprüfen, ob die vom Hersteller angegebene Lebensdauer zutrifft), zum Bauteil (welches Bauteil war betroffen, falls es mehrere gibt, dann ist eine Selektion möglich) zur MTTR (die mittlere Reparaturzeit) und zur MTTF (die Ausfallrate des betroffenen Gerätes, die vom Hersteller angegeben oder aufgrund von früheren Betrachtungen berechnet wurde) Fällt ein Gerät am gleichen Standort zu einem späteren Zeitpunkt nochmals aus (Störungsursache ist das Gerät), dann werden folgende Angaben in diesem Register dargestellt: Standort (Stellwerk, in dem das Gerät noch einmal ausgefallen ist), Gerät (betroffenes Bauteil), Störung (Zeitpunkt des erstmaligen Auftretens der Störung mit dem betroffenen Gerät) und Laufzeit (Zeitraum vom ersten bis zum zweiten Ausfall (Betriebslaufzeit)). Diese Informationen liefert das Wartungspersonal, indem es nach der Behebung der Störung diese Informationen im Bereich Wartungsinformation hinzufügt. Der RAMS-Manager kann dadurch ggf. RAMS-Berechnungen (die theoretischen Grundlagen dazu sind in den oberen Kapiteln zu finden) verifizieren. Es können somit rechtzeitig präventive Maßnahmen zur Vermeidung von Ausfällen getroffen werden. Version: 1.0 Seite 36 von 42

178 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen Abbildung 11: Darstellung vom Bereich "Auswertung" mit Beispiel-Daten Wartungsinformationen Dieses Register ist für alle Nutzer sichtbar. Es wird hier die Anzahl der schon behobenen Störungen und Detailinformationen zu der aufgetretenen Störungsart angegeben. Diese Störungsart wurde bei aktuelle Informationen durch das Wartungspersonal ausgewählt und durch betätigen der Hinzu Schaltfläche oder durch Doppelklick in diesen Bereich übertragen. Es wurden dabei die Informationen Stellwerk, Element, Elementtyp, Störungszeitraum und die dazu gehörenden Informationen, welche vom Wartungspersonal angegeben werden, zur Störungsursache, Reparaturzeit und dem Bauteil zu der Störung übernommen. Für das Wartungspersonal werden hier zusätzliche Eingabemöglichkeiten zu der Störung, wie die Ursache der Störung (Umwelt, Unfall, Wartungsarbeiten, Instandhaltung, Baumaßnahmen und Gerätestörung) bereitgestellt. Das Wartungspersonal hat also die Aufgabe, diese Informationen und die Reparaturzeit nach dem Beheben der Störung anzugeben und mit der Hinzu Schaltfläche oder, falls er Korrekturen an den Informationen vorgenommen hat, mit der Ändern Schaltfläche zu speichern. Die Reparaturzeit wird im Prototypen nur in Stunden als ganzzahliger Wert für das betroffene Bauteil angegeben und fließt in das Bis-Datum der Wartungstabelle zur Störung mit ein. Falls es zu einer Störung mehrere betroffene Bauteile gibt, dann kann das Wartungspersonal die Störung ein weiteres Mal in die Wartungsliste mit den dazu gehörenden eingegebenen Informationen durch die Hinzu Schaltfläche aufnehmen und speichern. Die Applikation passt die Wartungsinformationen im Register aktuelle Informationen an, wenn der Störungszeitraum geändert wurde. Durch die Entfernen Schaltfläche kann die ausgewählte Störung auch jeder Zeit wieder aus dem Bereich der Wartungsinformationen entfernt werden und somit werden die Störungen im Register aktuelle Informationen wieder sichtbar. Die Speichern Schaltfläche dient zum Datenexport und zur Weitergabe der Informationen in Excel-Format. Das Wartungspersonal ist dafür zuständig, dass jeder Austausch und jede Reparatur festgehalten wird. Es sorgt damit dafür, dass ein aktueller Überblick zu Störungen geliefert wird und dem RAMS- Manager diese Informationen zur Verfügung stehen. Angaben zur Gefährdung oder Ausfallrate sind für das Wartungspersonal nicht möglich. Diese Angaben und Berechnungen obliegen dem RAMS- Manager; daher ist der Bereich mit diesen Angaben für das Wartungspersonal grau hinterlegt und nicht für Veränderungen zugänglich. Version: 1.0 Seite 37 von 42

179 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen Für zusätzliche Informationen zur Störung, die von jedem Nutzer angegeben werden können, gibt es den Bereich Detailinformationen. Abbildung 12: Darstellung des Registers Wartungsinformationen mit einer Beispiel-Störung mit editierbaren Informationen für das Wartungspersonal. Abbildung 13: Darstellung des Registers Wartungsinformationen mit einer Beispiel-Störung mit editierbaren Informationen für das Wartungspersonal und dem RAMS-Manager. Der RAMS-Manager nutzt die vom Wartungspersonal bereitgestellten Informationen. Er hat die Möglichkeit, Änderungen bei der Gefährdung (ist die Störung relevant für die Sicherheitsbetrachtung des gesamten Systems oder nicht (relevant nur, wenn die Gefährdungsursache beim Gerät liegt)) und der (empirischen) Ausfallrate (hat sich die Ausfallrate des Bauteils auf Grund einer hohen Zahl von Störungen geändert oder gelten die Herstellerangaben) Version: 1.0 Seite 38 von 42

180 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Ergebnis aus den prototypischen Betrachtungen vorzunehmen. Der RAMS-Manager muss die Ausfallrate (falls die Daten dazu vorhanden sind) angeben. Durch Aktivierung des Kontrollkastens Herstellerangaben wird dokumentiert, dass die Ausfallrate durch den Hersteller oder aus den Informationen des Datenblattes gegeben ist. Eine Deaktivierung (Defaultwert) zeigt, dass der RAMS-Manager die Ausfallrate berechnet hat. Ist das Eingabefeld Ausfallrate leer, dann existieren keine Daten dazu Ausblick zum Client Anhand des beschriebenen Prototypen und seiner Vorstellung gegenüber Fachexperten verschiedener Rollen ergab sich eine Reihe von Anregungen zu Funktionserweiterungen. Folgende Verbesserung sollten in einem weiteren Schritt evaluiert werden: Die Rechte von dem Wartungspersonal LST und Reparatur werden in feinerer Granularität festgelegt. Die betriebliche Beanspruchung einer Komponente, wie z. B. die Anzahl der Weichenumläufe, wird mit ausgegeben, um mögliche neue RAMS-Betrachtungen bzgl. der betrieblichen Belastung durchzuführen. Bislang wurde nur die Verifikation der technischen Daten der einzelnen Bauteile bzw. Komponenten betrachtet. Die Wartungs- und Instandhaltungshandbücher werden als Hyperlink in die für die Wartung relevante Tabelle integriert, um eine effizientere Wartung zur ermöglichen. In das Auswertungsregister werden Daten der Betriebszeit aufgenommen (z. B. die Laufzeit einer Baugruppe seit einem definierten Startpunkt), um die berechneten Verfügbarkeitswerte zu hinterlegen. Spezifische statistische Modellierungen werden integriert. Die Basis dieser Modellierungen ergibt sich aus den Anforderungen aus dem RAMS-Prozess und ggf. Anforderungen von Seiten des Betreibers. Ein Register Fehlerbäume wird für eine grafische Darstellung der Systemstrukturen und für eine bessere Auswertungsmöglichkeit für die RAMS-Berechnungen hinzugefügt. Ziel dieser möglichen Erweiterungen der Applikation sollte neben der Verbesserung des Systems die bessere Akzeptanz durch die Nutzer, aber auch die effektivere und detailliertere Nachweisführung der RAMS-Berechnung sein. Version: 1.0 Seite 39 von 42

181 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Zusammenfassung und Ausblick 6 Zusammenfassung und Ausblick Im Rahmen NeGSt sollte das Konzept der Nachweisführung in Hinblick auf Sicherheitsaspekte analysiert werden und anhand von Best-Practises gezeigt werden, dass durch eine einheitliche Umsetzung der Prozesse der Nachweisführung eine Optimierung des Zulassungsprozesses resultieren kann. Dieser Ergebnisbericht hat sich dabei mit dem RAMS-Prozess während der Phase 12 "Erfassung der Leistungsfähigkeit" gemäß der CENELEC-Norm befasst und untersucht, inwieweit Daten aus der nachgelagerten Prozesskette dazu beitragen können, den voran gelagerten Nachweisprozess effizienter zu gestalten. Dabei lag der Fokus auf der Überprüfung der theoretischen prognostischen Annahmen der RAMS-Berechnungen durch eine Untersetzung mit technischen Ist-Werten. Aufgrund der Struktur der Arbeitsgruppe (Mitarbeit weiterer Bahnindustrieunternehmen wurde vorzeitig eingestellt) konnte nicht auf ein Austausch und eine Bewertung firmenübergreifender Best- Practise-Beispiele zurückgegriffen werden. Als Alternative wurde ein Prototyp entwickelt, der die Möglichkeiten einer Erhärtung der errechneten RAMS-Werte durch eine Erfassung von laufenden Betriebsdaten des Stellwerks aufzeigt. Ziel des implementierten Prototyps war es zu zeigen, dass durch eine verbesserte Bereitstellung von Diagnosemöglichkeiten und einfachen Erfassungsmöglichkeiten von Störungsinformationen neben einer Effizienzsteigerung im Bereich der Instandhaltung und Wartung auch der Zulassungsprozess besser gestaltbar ist. Der Prototyp zeigt, dass die erforderlichen Daten für den Nachweis der Einhaltung der im Zulassungsprozess errechneten RAMS-Werte durch einen bedarfsgerechten Client mit geringem Aufwand erfasst werden können. Eine zentrale Speicherung der Daten ermöglicht den Aufruf von Standardabfragen, aber auch AdHoc-Abfragen des RAMS-Managers. Die durch derartige statistische Auswertungen erhärteten bzw. angepassten RAMS-Berechnungen sollten einer Verifikation leichter standhalten und auch so die Zulassung vereinfachen. Es sollten bei der Definition von übergeordneten, firmenunabhängigen RAMS-Prozessen relevante Datenklassen der Instandhaltung von Seiten des Betreibers bzw. der Aufsichtbehörde definiert werden. Durch die aufgenommenen Betriebsdaten können die Abhängigkeiten zwischen RAMS-Werten und Störungen einzelner Komponenten besser dokumentiert werden. Daraus resultiert eine transparente Bewertung des Risikomanagementprozesses beginnend bei der Risikoanalyse bis hin zur Betriebsphase. Die Schaffung eines durchgängigen werkzeuggestützten Prozesses ist ein wichtiger Aspekt in der Kosten- und Zeitoptimierung bei Neu- bzw. Änderungszulassung. Version: 1.0 Seite 40 von 42

182 Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform Anhang 7 Anhang 7.1 Anhang 1: Referenzen [1] NeGSt_Ergebnisbericht_2300AG5_Feinkonzept_Diagnose_Prototypvorgaben.doc 7.2 Anhang 2: Abkürzungen Abk. ANF CCF CENELEC CRC EBA ESTW-R FMEA FTA IEC LST MTBF MTTF MTTR PFH RAMS SIL Langform / Erläuterung Anforderung Common-Cause-Fehler Comité Européen de Normalisation Électrotechnique Cyclic redundancy check (Zyklische Redundanzprüfung) Eisenbahn Bundesamt ESTW-Regional Failure Mode and Effects Analysis Fault Tree Analysis International Electrotechnical Commission Leit- und Sicherungstechnik Mean time between failures Mean time to failure Mean time to repair Probability of a dangerous Failure per Hour Reliability, Availability, Maintainability, Safety Safety Integration Level Version: 1.0 Seite 41 von 42

183 Neue Generation Signaltechnik Sektorweite Initiative zur Sicherung der Zukunftsfähigkeit der Leit- und Sicherungstechnik Teilbericht AP 2300 Projektierung von COTS-Produkten Laufzeit: Projektträger: TÜV Rheinland Consulting GmbH

184 Projektierung von COTS-Produkten Änderungsverfolgung Datum Bearbeiter Version Inhalt Sascha Stöckel 0.1 Erster Draft nach Prototyping Antje M. Möller- 0.2 Review Neustock Sascha Stöckel 0.3 Einstellen abschließende Version zum Review Antje M. Möller- 0.4 Review Neustock Holger Neustock Klaus-Dieter Winkler 1.0 Finalisierung Inhaltsverzeichnis 1 Einleitung Gründe für die Anwendung von COTS-Produkten Projektierung von COTS-Produkten Allgemeines Ist-Analyse Konzepterstellung Besondere Aspekte der COTS-Projektierung in einen Infrastruktureditor Fazit Anhang Abkürzungen...25 Abbildungsverzeichnis Abbildung 1: Systemarchitektur einer SIL2 Depotsteuerung... 8 Abbildung 2: exemplarische Klassifizierung von steuerbaren Elementen... 9 Abbildung 3: Prinzipanschaltung Ausfahrsignal Abbildung 4: Simatic S7-300 mit (v.l.n.r) SPS, Schnittstellen Modul und Ein-/Ausgabemodulen Abbildung 5: Beispielsymbole für ein Ausfahrsignal U Abbildung 6: Simatic Selection Tool Abbildung 7: SPS SA Projektierung (Auszug) Abbildung 8: Projektierungsschritte der SPS Steuerung Abbildung 9: Frauscher ACS2000 Vorderseite (Sicherungsbaugruppen, Zählbaugruppen und Auswertebaugruppen) Abbildung 10: Frauscher ACS2000 Rückseite (Busplatinen) Abbildung 11: Sys-Sys Richtung Radsensor Abbildung 12: Top-Down Modell Projektierung Abbildung 13: Infrastrukturansicht Abbildung 14: Funkwerk AG Infrastruktureditor Abbildung 15: Anpassung des AMBER Modells Abbildung 16: Auswahldialog Exportfunktionen Abbildung 17: Quellcodeauszug Symboltabellenprojektierung Version 1.0 Seite 2 von 25

185 Projektierung von COTS-Produkten Abbildung 18: Richtungseinstellung für die Achszählsystemprojektierung (Auszug) Abbildung 19: Steckerprojektierung der Frei-/Belegtmeldung für die Achszählsystemprojektierung.. 21 Abbildung 20: Anpassung des AMBER Modells für die Serverprojektierung (Auszug) Abbildung 21: Objekte und Prädikate für die SPS Softwareprojektierung (Auszug) Version 1.0 Seite 3 von 25

186 Projektierung von COTS-Produkten Einleitung 1 Einleitung Die Nutzung von COTS-Produkte bei der Erstellung von Stellwerken bietet Vorteile, wie Kostenersparnis und eine schnelle Implementation. Die verschiedenen COTS-Produkte erfordern allerdings verschiedene Projektierungen mit jeweils eigenem Verfahren. Einhergehend mit diesen Verfahren ist auch ein angepasstes Zulassungsverfahren verbunden. Die folgenden Kapitel analysieren die Vorteile von COTS-Produkten und die Anwendung der verbundenen Projektierungsverfahren. Es wird auf die Änderungen im Zulassungsverfahren eingegangen sowie ein Konzept vorgestellt und evaluiert, welches den Erstellungsprozess optimiert und die Zulassung unterstützt. Version 1.0 Seite 4 von 25

187 Projektierung von COTS-Produkten Gründe für die Anwendung von COTS-Produkten 2 Gründe für die Anwendung von COTS-Produkten Individuelle bzw. proprietäre Problemlösungen werden während einer Produktentwicklung oder Projektabwicklung vermehrt durch eine Integration von COTS-Produkten abgelöst. Diese COTS-Produkte lösen innerhalb eines Systems jeweils spezifische Aufgaben. Die Gründe für die Nutzung von COTS-Produkten liegen in der Notwendigkeit, den steigenden Anforderungen hinsichtlich kürzer werdender Produktzyklen bzw. Projektlaufzeiten sowie den hohen Konkurrenz- und Kostendruck gerecht zu werden. COTS-Produkte bieten dabei Vorteile in vielerlei Hinsicht. Vorteil: schnelle Zulassungsfähigkeit COTS-Produkte können als abgegrenzte Systeme betrachtet werden, die eine eigene Zulassung besitzen können. Durch Verwendung zugelassener COTS-Produkte kann ein eigenes Zulassungsverfahren beschleunigt werden, da nur die Projektierungen und die Schnittstellen zwischen den COTS- Komponenten betrachtet werden müssen. Definierte Verfahren der Hersteller zur Projektierung von COTS-Produkten und eine Unterstützung mit Werkzeugen, z.b. Projektierungssoftware, machen eine Projektierung für den Zulassungsprozess transparent und vereinfacht eine dedizierte Nachweisführung der Änderungen des schon zugelassenen Systems. Vorteil: Produktvielfalt und Qualität Ein weiterer Vorteil ist, dass Anforderungen und Erfahrungen vieler Marktteilnehmer in die COTS- Produkte einfließen. Konkurrenz zwischen den Anbietern einer Produktklasse führt zu einer hohen Produktvielfalt und die Qualität wird gesteigert. Dabei erfährt nicht nur die Qualität von Hard- oder Software mehr Aufmerksamkeit durch den vielfältigen Einsatz der Komponenten in den Produkten unterschiedlicher Hersteller, sondern auch die Qualität der Dokumentation der Komponenten wird gesteigert. Vorteil: Lieferfähigkeit Variationen einer Produktklasse werden von verschiedenen Herstellern angeboten, wodurch eine Technologie in vielen Ausprägungen verfügbar ist. Etablierte und häufig eingesetzte COTS-Produkte besitzen, aufgrund eines hohen Bedarfs und damit entsprechender Produktionskapazitäten, geringe Lieferzeiten. Außerdem sind Ersatzteile durch den Hersteller kostengünstig und in hoher Zahl verfügbar. Positiv auf die Verfügbarkeit wirken sich auch die langen Produktlebenszyklen einer Produktlinie und die ständige Weiterentwicklung aus. So ist z.b. die bei Funkwerk eingesetzte Siemens Simatic S7 Produktlinie mit ständiger Weiterentwicklung seit 1994 auf dem Markt. Die vorherige Produktlinie Simatic S5 wurde von 1979 bis 1995 ständig weiterentwickelt und ist bis 2015 noch teilweise verfügbar. (Quelle: Version: 30. Dezember 2012 / 12:15 Uhr) Vorteil: Skalierbarkeit und Flexibilität Hersteller von COTS-Produkten versuchen eine breite Marktabdeckung zu erreichen. Die Produkte sind daher häufig so ausgelegt, dass sie modular und schnell den jeweiligen Anforderungen anpassbar sind. Spätere Anpassungen sind daher leicht möglich, da entsprechende Module nur hinzugefügt werden müssen. Zum Beispiel lässt sich das Achszählsystem ACS2000 der Firma Frauscher durch Austausch einer Busplatine und durch Hinzufügen von Schnittstellenkarten um weitere Achszähler erweitern. Bestehende Systemkomponenten können weiter verwendet werden. Version 1.0 Seite 5 von 25

188 Projektierung von COTS-Produkten Gründe für die Anwendung von COTS-Produkten Vorteil: Personal Die vielfältigen Disziplinen, die für die Entwicklung von Produkten notwendig und durch COTS- Produkte abgedeckt sind, können personell nur schwer in Breite und Tiefe durch ein Unternehmen vorgehalten werden. Die Anwendung von COTS-Produkten erhöht dagegen auf Grund der hohen Verbreitung, die Chancen qualifiziertes Personal zu finden, welches ein entsprechendes Produkt bereits eingesetzt hat. Insbesondere vor dem Hintergrund des demographischen Wandels und Fachkräftemangel ist dies von Vorteil. Bezogen darauf erhöht sich die Konkurrenz auf Arbeitsmarkt. Dies führt ebenfalls zu sinkenden Kosten. Neben den genannten Vorteilen sollen auch folgende Nachteile erwähnt werden. Nachteil: Konfigurierbarkeit von Komponenten Die Konfigurierbarkeit von Komponenten erfordert Verfahren zur Projektierung. Diese Verfahren müssen definiert und in der Nachweisführung berücksichtigt werden. Bei einer großen Anzahl verschiedener COTS-Produkte in einem System bedeutet dies einen hohen Aufwand. Nachteil: Variabilität der Produkte Der technische Fortschritt und die hohe Innovationsgeschwindigkeit führen zu verschieden Versionen ein und desselben COTS-Produkts. Diese neuen Versionen sind in der Regel abwärtskompatibel zu ihren Vorgängerversionen. Aufwände entstehen hier bei der Umsetzung eines vereinfachten Zulassungsverfahrens sowie des dadurch erforderlichen Produktvariantenmanagements. Das Produktvariantenmanagement erfasst dabei zentral, welche Komponenten mit ihren jeweiligen Versions- und Konfigurationsständen in einem System ausgeliefert wurden, und verfolgt Versionsstände bei Austausch von Komponenten nach Reparatur oder Erweiterungen. Nachteil: Neue Anforderungen an das Zulassungsverfahren Die Industrienorm IEC wurde als übergeordnete Norm für sicherheitsgerichtet Systeme entwickelt. Von dieser Norm abgeleitet etablierten sich für spezielle Industriezweige eigenständige Normen, wie die CENELEC-Normenreihe DIN EN 5012x, die Norm für Straßenfahrzeuge ISO oder die Norm IEC für die Prozessindustrie wie Chemie. Aufgrund der Anwendungsfälle, die diese Normen abdecken sollen (von der Fahrzeugzulassung: große Verbreitung eines zugelassenen Typ bis hin zur Chemieanlagenzulassung: eine Zulassung in einem großen Zeitraum), ist eine gegenseitige Akzeptanz der Zulassungen schwierig. Damit können einzelne Teile, die Bestandteil mehrere Industriezweige sind, nicht einfach bzgl. ihrer Nachweisdokumente übertragen werden. Aufwände bzgl. der Übertragung dieser Zulassungsdokumente bzw. -nachweisführungen müssen somit eingeplant werden. Version 1.0 Seite 6 von 25

189 Projektierung von COTS-Produkten Projektierung von COTS-Produkten 3 Projektierung von COTS-Produkten 3.1 Allgemeines Die Projektierung von COTS-Produkten stellt eine wesentliche Aufgabe im Entwicklungsprozess dar. Diese folgt nach dem Festlegen der Systemanforderungen und der Systemarchitektur in der Phase der Systemspezifikation. Eine Projektierung legt die Art der Anwendung eines COTS-Produkts im Gesamtsystem fest und definiert Parameter, unter denen ein COTS-Produkt betrieben werden darf. Der Projektierungsvorgang und die zu definierenden Parameter sind produktspezifisch. Dabei bezieht sich der Projektierungsvorgang nicht nur auf die Erstellung neuer Systeme, sondern auch auf die Anpassung, Erweiterung und Rückbau von Bestandssystemen. Rahmenbedingungen für eine Projektierung werden durch die Anforderungen definiert. Die Quellen dieser Anforderungen sind verschieden ausgeprägt. Im Bereich der Signaltechnik sind hier vorrangig zu nennen: betriebliche Abläufe, Planungsunterlagen wie Verschlusstabellen, geographische Lagepläne oder schematische Übersichtspläne (z.b. PT1-Planung des Kunden), Anforderungen des spezifischen Projekts (Lastenhefte der Kunden), gesetzliche Vorgaben, Normen und Standards, Regelwerke der Kunden, Vorgaben durch die Hersteller von COTS-Produkten wie Anwendungsbedingungen oder Projektierungsvorgaben, In-Haus Standards und Vorgaben der Zulassung/Zertifizierung. Eine wechselseitige Beziehung zwischen den Anforderungen und einem COTS-Produkt gibt es mit Auswahl und Projektierung der COTS-Produkte. Im Rahmen der Möglichkeiten können Anforderungen angepasst werden, um eine optimale Integration im Gesamtsystem zu erreichen. Die Ergebnisse einer Projektierung dokumentieren sich in Spezifikationen und Projektierungsdaten, die dann auf die COTS-Produkte angewendet werden. Für ein COTS-Produkt kann zum Beispiel das hardwareseitige Setzen einer Lötbrücke spezifiziert sein. Projektierungsdaten werden evtl. auf ein COTS-Produkt mittels Beschreiben einer Speicherkarte angewendet. Bei der Anwendung einer Spezifikation und Projektierungsdaten haben sich für Hardware und Software typische Methoden durchgesetzt. Für Hardwareprojektierungen sind dies: Setzen von Lötbrücken, Steckbrücken (Jumper), DIP Schalter, Konfiguration von Programmiersteckern, Beschreiben von Speichermedien (z.b. Speicherkarten, ID Plugs), Konfiguration per webbasierten Dialogen, Konfiguration mittels Programmierkabel, Vorgaben für die Projektierung der Hardware-Komponenten in der ProRil und Vorgaben zur Auswahl von Hardware-Komponenten (z.b. Mindestanforderungen an den Speicher oder der Vorgabe für Monitore). Bei Softwareprojektierungen werden folgende Methoden angewendet: Version 1.0 Seite 7 von 25

190 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Setzen von Parametern in Konfigurations- und Projektierungsdateien zur Steuerung von Programmabläufen und zur Kommunikation, Anpassen von Datenbankeinträgen, Anwendung von Generatoren zur Erststellung spezifischer Programmlogiken und Umsetzung in eigene hardwarenahe Programmierung (PLD-Programmierung) 1. Um ein bestehendes System ohne großen Eingriff auf neue Anforderungen anzupassen, können eine Änderung der Projektierung und ein Durchführen der genannten Methoden ausreichen. So kann eine Auswirkungsanalyse normalerweise ergeben, dass die Anpassung an neue Hardware-Komponenten eine Verbesserung der technischen Werte beinhaltet und so ein Austausch der Komponenten auch ohne Gefährdung der Sicherheit möglich ist. Änderungen lassen sich mit einer Differenzbetrachtung zwischen ursprünglicher und geänderter Spezifikation einfach nachvollziehen. Bei einer Differenzbetrachtung kann Software zur Visualisierung der Änderungen angewendet werden. Eine Änderungszulassung kann so beschleunigt werden. Die Individualität der COTS-Produkte bei der Projektierung ist für ein zulassungsfähiges Verfahren zu berücksichtigen. Einerseits muss ein solches Verfahren die Freiheit gewähren, alle möglichen und notwendigen Projektierungsschritte durchzuführen und andererseits sicher stellen, dass die Anforderungen aus den oben genannten Quellen erfüllt werden und dass der Projektierungsvorgang nachvollziehbar ist. Letzteres macht die Projektierung für Planprüfer und Zulassungsstellen transparent. 3.2 Ist-Analyse COTS-Produkte finden bei der Funkwerk AG TCC ihren wesentlichen Einsatz in der Signaltechnik zur Umsetzung von elektronischen Stellwerken. Als Beispiel soll die typische Projektierung einer Alister SIL2 Rangier-/Depotsteuerung dienen. Anlagen dieser Kategorie finden häufig ihre Anwendung in Abstell-, Instandsetzung- oder in Be-/Entladebereichen. Bedienplatzrechner Serverrechner SPS Regelsystem Anpassbaugruppe Signale Anpassbaugruppe Weichen Achszählsystem Systemüberwachung Signale Weichenantriebe Radsensor Abbildung 1: Systemarchitektur einer SIL2 Depotsteuerung 1 Die PLD-Programmierung stellt ein Sonderfall dar und wird in einigen Firmen aufgrund ihrer besonderen Struktur als Hardware-Bestandteil definiert. Die genauen Prozesse müssen also firmenspezifisch evaluiert werden. Version 1.0 Seite 8 von 25

191 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Das SPS Regelsystem, die Systemüberwachung, die Anpassbaugruppen Signale und Weichen sowie das Achszählsystem befinden sich in den Schaltschränken mit Kabelabschlussgestell und Stromversorgung. Optional sind die Bedienplatz- und der Serverrechner. Diese werden je nach konkreter Ausprägung dem System hinzugefügt. Ebenso kann das Achszählsystem durch ein Gleiskreissystem ersetzt sein. Ein wesentliches COTS-Produkt ist die SPS Steuerung, die bislang vorrangig bei der Steuerung industrieller Maschinen und Anlagen zum Einsatz gekommen ist und nun im Bahnbereich Steuerungssysteme auf Relaisbasis oder proprietäre Logiksysteme ablöst. Die Durchführung einer Projektierung einer solchen Depotsteuerung wird im folgendem näher erläutert. Die Projektierung beginnt mit der Analyse der Planungsunterlagen. Aus den Planungsunterlagen geht hervor, welche Elemente durch das System gesteuert werden sollen. Die zu steuernden Elemente werden entsprechend ihrer Typen klassifiziert. Planungsunterlagen Weicheantrieb Signal Freimeldeabschnitt 7-Draht Vorziehsignal (H3) Gleiskreis 4-Draht Ausfahrsignal (H0/H4) Achszählkreis Weichenlagemelder Abbildung 2: exemplarische Klassifizierung von steuerbaren Elementen Für die definierten Klassen werden im Rahmen der Projektierung des Schaltschranks Prinzipanschaltungen erstellt. Diese stellen dar, wie die Elemente, Komponenten und Systeme des Schaltschranks in typischer Weise elektrisch angeschlossen werden. Eine Prinzipanschaltung wird auf alle Elemente einer Klasse angewendet. Daraus ergeben sich Schnittstellen und Mengengerüste, die für eine Projektierung notwendig sind. Die Projektierung erfolgt unter der Maßgabe bei der Auswahl der Komponenten vorrangig (COTS-) Produkte einzusetzen, mit denen bereits positive Erfahrungen gesammelt wurden. Der Einsatz bereits bekannter und verwendeter Produkte vermeidet Fehler bei der Projektierung und vereinfacht die Ersatzteilhaltung. Zum Beispiel wurde als Prinzipschaltung für das Ausfahrsignal folgende Anschaltung definiert: Version 1.0 Seite 9 von 25

192 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Abbildung 3: Prinzipanschaltung Ausfahrsignal Für jedes Ausfahrsignal ergeben sich als Schnittstelle zwei Kontakte (DO) zur Ansteuerung der Signalaspekte Halt (H0) und Vorziehen (H4) und zwei Kontakte (DI) zum Rücklesen der Ansteuerung. Die Rücklesekontakte dienen zur Erkennung von Fehlern bei der Ansteuerung, die z.b. durch defekte Leuchtmittel ausgelöst werden. Projektierung der SPS Steuerung Für die Depotsteuerung wird derzeit das Siemens Simatic S7-300 System, mit zentraler Speicherprogrammierbaren Steuerung (SPS) und dezentraler Peripherie, eingesetzt. Bei diesem modularem System werden aneinanderreihbare Ein-/Ausgabemodule per Schnittstellen Modul und Kommunikationsstrecke mit der SPS verbunden. Abbildung 4: Simatic S7-300 mit (v.l.n.r) SPS, Schnittstellen Modul und Ein-/Ausgabemodulen (Bildquelle: Siemens AG 2013, Alle Rechte vorbehalten) In einer konkreten Projektierung werden jedem zu steuernden Element Kontakte entsprechend der Prinzipschaltung zugeordnet. Daraus resultieren erhebliche Mengen an Kontakten, die durch die SPS gesteuert werden müssen. Entsprechend muss die dezentrale Peripherie mit verschiedene Ein- /Ausgabemodulen projektiert werden. Außerdem wird eine Zuordnungstabelle erstellt, die alle durch die SPS zu nutzende Kontakte eineindeutig benennt und per Adressierung einem Modul zuordnet. Diese Zuordnungstabelle wird als Symboltabelle bezeichnet. Der eineindeutige Name eines Kontakts wird als Symbol bezeichnet und später im SPS Programm verwendet, um ein konkreten Kontakt anzusprechen. Für die Erstellung dieser Tabelle kommt ein einfacher Texteditor zum Einsatz. Bei der Projektierung der dezentralen Peripherie und der Symboltabelle ist es sinnvoll, Gruppen zu bilden und Reserven einzuplanen. Version 1.0 Seite 10 von 25

193 Projektierung von COTS-Produkten Projektierung von COTS-Produkten U42_SI_H0 U42_SI_H4 U42_SI_H0r U42_SI_H4r Q 7.0 BOOL Haltbegriff H0 Q 7.1 BOOL Fahrtbegriff H4 I 8.0 BOOL Rueckmelder Haltbegriff H0 I 8.1 BOOL Rueckmelder Fahrtbegriff H4 Abbildung 5: Beispielsymbole für ein Ausfahrsignal U42 Neben dem symbolischen Namen und der Adressierung besteht ein Eintrag in der Symboltabelle noch aus dem Eingangstyp (I) bzw. dem Ausgangstyp (Q), dem Datentyp (BOOL) sowie einem beschreibenden Kommentar. Die Symboltabelle steht dabei in wechselseitiger Beziehung mit der Projektierung der dezentrale Peripherie. Verwendeter Modultyp und die Zuordnung eines Symbols zu einem Modul haben jeweils wechselseitig Einfluss. Die Projektierung der dezentralen Peripherie erfolgt mit dem Software Simatic Selection Tool. Die Software unterstützt den Projektant bei der Zusammenstellung der SPS Komponenten. Das Tool bietet dazu einen Produktkatalog mit Produktinformationen zur Auswahl an. Es gibt vielfältige Typen von Ein-/Ausgabemodulen mit unterschiedlicher Anzahl von Signalkontakten, verschiedenen Bauformen, Module mit Sicherheitsfunktion, Relais-, Analog- und Digitalmodule. Ungültige Kombinationen von Komponenten werden durch das Tool während der Projektierung ausgeblendet, sodass die Auswahl nur gültiger Komponenten möglich ist. Zudem kann die Einhaltung von Systemgrenzen geprüft werden. Beispielsweise wird auf Basis der projektierten Ein-/Ausgabemodule der Strombedarf berechnet und bei Überschreitung maximaler Grenzen ein Warnhinweis gegeben. Für die Ein-/Ausgabemodule können außerdem die jeweiligen Moduladressen in der Software festegelegt werden. Die folgende Abbildung zeigt beispielhaft die Zusammenstellung dezentraler Peripherie in der Software der Software Simatic Selection Tool. Abbildung 6: Simatic Selection Tool Version 1.0 Seite 11 von 25

194 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Die Projektierungsdaten der Symboltabelle und die Projektierungsdaten aus dem Simatic Selection Tool fließen in die Softwareentwicklungsumgebung Simatic Step7 ein. Mit Hilfe dieser Software wird ein lauffähiges SPS Programm erzeugt. Neben der Projektierung der Hardwareansteuerung fließt hier der Programmquellcode ein. Der Quellcode wird dabei in spezifische Applikation (SA) und generische Applikation (GA) unterschieden. Die SA enthält alle Informationen eines spezifischen Stellwerks. Die konkreten Elemente und weitere Projektierungsinformationen, wie Fahrstrassen und Relationen zw. Elementen, werden hier mit der Steuerungslogik der GA verknüpft. Die GA bildet die generische Geschäftslogik ab und beschreibt damit, wie ein Stellwerk arbeitet. Über verschiedene Stellwerke ist die GA identisch, wenn diese Stellwerke identisch arbeiten sollen. Die GA wird als Zustandsautomat definiert und dann in den GA Quellcode übernommen. Zu Erstellung des SA Quellcodes wird ein Codegenerator eingesetzt. Der Codegenerator erzeugt aus einer SA Projektierung lauffähigen Quellcode. Die SA Projektierung, wie in folgendem Beispiel zu sehen, besteht aus den Projektierungen der Elemente und den Relationen zwischen diesen. OBJECT rsig U42 240; PREDICATE RSigFs(U42,FS085); Abbildung 7: SPS SA Projektierung (Auszug) Eine Elementprojektierung wird durch das Schlüsselwort OBJECT eingeleitet und von Elementeigenschaften, wie z.b. der Elementklassifikation oder dem Elementnamen, gefolgt. Die Relationen zwischen den Elementen werden durch das Schlüsselwort PREDICATE eingeleitet. Es folgen ebenfalls die spezifischen Eigenschaften, wie Typ der Relation und die zu verknüpfenden Elemente. Projektiert wird per einfachen Texteditor. Der gesamte Prozess zur Erstellung der SPS Projektierung wird in der folgenden Ansicht zusammengefasst. Planungsunterlagen Elemente Klassifikation Prinzipanschaltung Symboltabelle Simatic Selection Tool SA Projektierung Projektierung der dez. Peripherie Codegenerator SA Quellcode Step7 GA Quellcode Projektierung Projektierungswerkzeug SPS Software Abbildung 8: Projektierungsschritte der SPS Steuerung Version 1.0 Seite 12 von 25

195 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Projektierung des Serverrechners Der Serverrechner ist das Bindeglied zwischen dem SPS Regelsystem und den Bedienrechnern. Der Serverrechner verfügt über ein Serverprogramm, welches mit der SPS und den einzelnen Bedienrechnern kommuniziert. Das Serverprogramm setzt die Informationen zwischen der SPS und den Bedienrechnern um, koordiniert die Ausführung von Kommandos und protokolliert Bedienaktionen und Fehlerzustände. Die Informationen in der Projektierung sind vergleichbar mit den Daten der SA Projektierung für die SPS Software. Spezifisch für das Serverprogramm werden ebenfalls die zu nutzenden Elemente, wie Weichen und Signale sowie deren Beziehungen projektiert. Zusätzlich sind Informationen zu den Kommunikationspartnern (SPS und Bedienrechner) und zum Übertragungsprotokoll projektiert. Die Erstellung der Projektierung erfolgt per Texteditor. Änderungen in der Projektierung können durch Differenzprüfung der Textdatei zu einer Vorgängerversion festgestellt werden. Eine Prüfung für den Sicherheitsnachweis erfolgt durch Verifikation. Projektierung des Achszählsystems Das im Bereich der Alister Rangierstellwerke typischerweise eingesetzte COTS-Achszählsystem ist das Frauscher ACS2000. Das System registriert Züge per Radsensoren. Dabei entspricht ein gezähltes Rad einer Achse. Es werden Freimeldeabschnitte (FMA) definiert, die durch Radsensoren begrenzt werden. Durch Zählen der Räder beim Ein- bzw. Ausfahren wird die Belegung eines Bereichs ermittelt. Befinden sich gezählte Achsen im Freimeldeabschnitt, gilt dieser als belegt. Sind keine Achsen gezählt, gilt der Freimeldeabschnitt als frei. Das ACS2000 ist modular und wird in einem 19Zoll Baugruppenträger eingebaut. Jedem Freimeldeabschnitt werden verschiedene Komponenten zugeordnet. Neben einer Sicherungsbaugruppe (SIB) zur Stromversorgung gehören zu jedem Freimeldeabschnitt eine Zählbaugruppe (ACB) und eine Busplatine (ABP). Zu jedem Radsensor gehört außerdem eine Auswertebaugruppe (IMC). SIB, ACB und IMC sind Einschubkarten, die mittels Kontaktstecker mit der ABP verbunden werden. Die ABP verbindet die einzelnen Komponenten untereinander. Die ABP ist mit DIP-Schalter bestückt, die während der Projektierung des Achszählsystems im Wesentlichen zu berücksichtigen sind. Abbildung 9: Frauscher ACS2000 Vorderseite (Sicherungsbaugruppen, Zählbaugruppen und Auswertebaugruppen) (Bildquelle: Frauscher) Version 1.0 Seite 13 von 25

196 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Abbildung 10: Frauscher ACS2000 Rückseite (Busplatinen) (Bildquelle: Frauscher) Die Projektierung des Achszählsystems erfolgt ohne Unterstützung spezieller Projektierungswerkzeuge. Die Projektierung wird als Dokument erstellt und beim Aufbau des Achszählsystems hardwareseitig, z.b. durch Setzen der DIP Schalterstellung, angewendet. Eine dieser DIP Schalterstellung gibt dem System Auskunft über die Lage des Radsensors im Gleis. Ein Radsensor besitzt zur Ermittelung der Bewegungsrichtung intern zwei unabhängige Systeme. Das System 1 (Sys1) und das System 2 (Sys2) werden nacheinander durch ein Rad aktiviert. Projektiert wird die Reihenfolge, die zum Einzählen in den Achszählkreis vom System zu erwarten ist. Der Achszähler kann, je nach baulichen Gegebenheiten, am linken oder rechten Schienenprofil montiert sein. Die Richtung wechselt je nach Montageseite von Sys1-Sys2 nach Sys2-Sys1. Abbildung 11: Sys-Sys Richtung Radsensor (Bildquelle: Frauscher) Versionierung und Rückverfolgbarkeit Der Einsatz von COTS-Produkten in einer Depotsteuerung, die sich über viele Jahrzehnte im Einsatz befindet, macht Mechanismen zur Versionskontrolle notwendig. Notwendig wird die Versionskontrolle durch Softwareänderungen im Fall von Fehlerkorrekturen, bei Änderungen der Projektierung durch Um- oder Rückbau und beim Einsatz von Ersatzteilen, die durch Obsoleszenz nur noch in einer neueren, aber funktionskompatiblen Produktvariante vorliegen. Die Rückverfolgbarkeit von Änderungen in den Projektierungsdaten und von Softwareänderungen lassen sich leicht durch dateibasierte Versionskontrollsysteme, wie ClearCase oder CVS, erreichen. In einem Versionskontrollsystem werden alle erstellten Varianten einer Datei archiviert und versioniert. Diese Dateien können aus Projektierungstools gespeicherte Datendateien oder Projektierungsdokumente sein. Hardwarekomponenten unterliegen ebenfalls stetigen Änderungen. Dies betrifft die in einer Komponente verbauten Teile ebenso wie die in Hardware zunehmend verwendete eingebettete Software. Für diese COTS-Produkte gestaltet sich die Versionierung und Rückverfolgbarkeit schwierig. Bei Lieferung eines Systems, wie einer Depotsteuerung, werden Typen und Versionen dokumentiert. Der Sicherheitsnachweis wird einzeln bzw. im Gesamtsystem erbracht. Der identische Austausch defekter Komponenten kann, sofern erhältlich, aus einer Neubeschaffung oder aus einem Lagerbestand erfolgen. In diesem Fall ist kein neuer Sicherheitsnachweis notwendig. Jedoch ist dies, bedingt durch Obsoleszenz, nicht immer möglich. Ersatzkomponenten sind in der Regel zum Zeitpunkt des Sicherheitsnachweises nicht bekannt, sodass diese nicht durch den Sicherheitsnachweis abgedeckt sind. Die Nutzung andere Komponenten als die durch den Sicherheitsnachweis abgedeckten Komponenten kann zum Erlöschen der Betriebserlaubnis führen. Gegebenenfalls ist es möglich, abwärtskompatible Produkte als Ersatz zu verwenden, sofern durch den Sicherheitsnachweis akzeptiert. Die abwärtskompatible Produkte bieten dabei mindestens die gleichen Eigenschaften wie die ursprünglich verwendeten Produkte. Die Überwachung anwendbarer und die Dokumentation angewendeter kompatibler Versionen über eine Vielzahl von Anlagen setzt eine Versionskontrolle mit Möglichkeiten zur Rückverfol- Version 1.0 Seite 14 von 25

197 Projektierung von COTS-Produkten Projektierung von COTS-Produkten gung voraus. Entsprechend müssen durch den Hersteller bzw. durch den Betreiber Prozesse etabliert werden. Datenaustausch Der Datenaustausch zwischen den verschieden eingesetzten Systemen ist in der Regel nicht möglich. Lediglich bei Systemlösungen wie Simatic ist eine Interoperabilität gegeben. Fehlende Standards, unveröffentlichte oder unzureichende Dokumentation von Dateiformaten machen eine systemübergreifende Nutzung der projektierten Daten z.b. durch Import, Export oder Konvertierungsfunktionen nahezu unmöglich. Nur in wenigen Fällen lässt sich die syntaktische und semantische Bedeutung der Inhalte einer Projektierungsdatei ermitteln. Führung des Sicherheitsnachweises Die im Vorfeld beschriebenen Verfahren werden zur Erlangung des Sicherheitsnachweises gemäß CENELEC durchgeführt und dokumentiert. Die Projektierungsergebnisse werden typischerweise durch Verifikation der Projektierung bzw. der Dokumentation der einzelnen Projektierungen geprüft. Die hier beschriebenen Projektierungsverfahren und die angewendeten Verfahren zur Erstellung eines Stellwerks sind durch Betreiber und Zulassungsstellen akzeptiert. Wie sich in der Praxis gezeigt hat, unterliegen COTS-Produkte einem anderen Produktzyklus als die bisherigen Hardware-Produkte der Stellwerkshersteller. Der Produktzyklus ist, bedingt durch Innovationen und durch das Abkündigen von Bauteilen, kürzer. Im Detail zeigt sich häufig, dass die Produkte in leicht geänderter und kompatibler Form weiterhin erhältlich sind, sodass sich das Aufkommen dieser kompatiblen Nachfolger Produkte als Produktevolution verstehen lässt. Während der langen Betriebsdauer einer Anlage spielen die kompatiblen COTS-Produkte insbesondere als Ersatzteile eine Rolle. Der Sicherheitsnachweis erfasst nur die zum Zeitpunkt der Erstellung vorhanden Bauteile. Bauteile neueren Datums sind nicht erfasst. Dies stellt ein großes Problem dahingehend dar, dass durch Nutzung neuerer, aber kompatibler Bauteile die Betriebserlaubnis erlischt. Ziel muss es aus diesem Grund sein, auch kompatible Bauteile durch den Sicherheitsnachweis zu erfassen. Dies kann zum Beispiel durch die Auflage erfolgen, dass nur kompatible Bauteile, die gleichen Eigenschaften hinsichtlich Funktion, Bauform, Schnittstelle und Fehlerraten haben, eingesetzt werden dürfen. Anderenfalls ist eine Nachweisführung über die Änderungen notwendig. 3.3 Konzepterstellung In den vorhergehenden Kapiteln wurden verschiedene Verfahren im Rahmen der Projektierung vorgestellt. Diese Verfahren werden sehr unterschiedlich durch Werkzeuge unterstützt. In der Regel sind diese Werkzeuge produkt- oder herstellerspezifisch und eine Interoperabilität ist oft nicht gegeben. Aufgrund der diversen Werkzeugen und Verfahren entstehen Aufwände für Schulung bzw. Einarbeitung. Doppeleingaben von Daten sind die Regel. Die Anwendung der Projektierungsverfahren, insbesondere bei nicht alltäglicher Anwendung, und Dateninkonsistenzen stellen große Fehlerquellen dar. Als Folge erhöhen diese Probleme die Fehlerraten bei der Projektierung und erhöht den Aufwand der Planprüfung. Um diesen Problemen entgegenzuwirken und um die Projektierung zu vereinfachen, sollten alle für eine Projektierung notwendigen betrieblichen Daten in einer vereinheitlichten Bedienoberfläche für den Projektant und den Planprüfer erfasst und als gemeinsamer Datenbestand verwaltet werden. Anschließend müssen die Daten entsprechend der Projektierungsverfahren so transformiert werden, dass eine konkrete Projektierung als Ergebnis vorliegt. Es lassen sich so doppelte Eingaben von Daten und somit Inkonsistenzen vermeiden. Die Transformation von Daten in eine Projektierung entspricht dem Verfahrensweg aus dem bisherigen Projektierungsverfahren. Eine solche Implementierung ist deterministisch und verhindert Fehler, die durch eine nicht korrekte Anwendung von Projektierungsverfahren entstehen können. Version 1.0 Seite 15 von 25

198 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Planungsunterlagen Datenerfassung im einheitlichen Projektierungstool Datentransformation auf einer gemeinsamen Datenbasis Projektierungen Schaltschrank Projektierungen SPS Steuerung Projektierungen Achszählsystem Klemmleisten- Konfiguration für Außenelemente Symboltabelle Mengengerüst SA Projektierung DIP Schalterkonfiguration Steckerkontaktierung Abbildung 12: Top-Down Modell Projektierung Die Trennung von Datenbestand und den Verfahren zur Projektierung ist vergleichbar mit der aus der CENELEC Norm bekannten, spezifischen Anwendung (SA=Datenbestand) und der generischen Applikation (Projektierungsverfahren). Datenmodell Das Datenmodell legt fest, welche Daten abgebildet werden und wie diese strukturiert sind. Dieses Modell muss sehr flexibel sein, um die verschiedenen bekannten Typen von Infrastrukturelementen und deren spezifische Eigenschaften abzubilden. Eine weitere Herausforderung ist es die Flexibilität des Modells so zu erhalten, dass es leicht um neue Typen zu erweitern ist. Datenmodelle, die die Anforderungen von Eisenbahnanwendungen erfüllen, waren bereits Thema von Forschungsprojekten und Entwicklungen. Das Advanced Model-Based Environment for Railways (AMBER) ist ein durch die Funkwerk AG entwickeltes Datenmodell, welches den oben genannten Anforderungen gerecht wird. Dieses Modell nutzt Erfahrungen und Ergebnisse, die durch das geförderte Forschungsprojekt MENGES (Modellbasierte Entwurfsmethoden für eine neue Generation elektronischer Stellwerke) hervorgebracht wurden. Ein weiteres Datenmodell ist railml ( ein Extensible Markup Language (XML) basiertes Datenmodell, welches durch verschiedene Industrie- und Forschungspartner entwickelt wurde, um Interoperabilität zwischen verschiedenen Bahnanwendungen herzustellen. Durch dieses Modell können Infrastrukturdaten, Fahrplandaten und Daten des Rollmaterials verwaltet werden. Transformation Durch die Transformation werden die Daten, die nach dem Datenmodell abgelegt sind, verarbeitet und in eine Ausgabe umgewandelt. Die Transformation bildet die während der Projektierung angewendeten Verfahren und Regeln ab. Die Ausgabe einer Transformation kann je nach abgebildetem Projektierungsverfahren sehr unterschiedlich sein. Dies können einfache Textdaten, XML-Daten oder auch komplexe Binär- oder Bilddaten sein. Vorstellbar ist auch die Erstellung von Schaltplänen auf Basis einer Prinzipanschaltung. Entsprechend flexibel und mächtig müssen die Transformationen sein. Version 1.0 Seite 16 von 25

199 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Einheitliche Bedienoberfläche Die Bedienoberfläche (BOF) stellt die Schnittstelle zwischen dem Projektant oder dem Planprüfer und dem Datenmodell bzw. den Transformationen her. Die Bedienoberfläche vereinheitlicht, im Vergleich zu den verschiedenen bisher eingesetzten Werkzeugen, die Eingabe und Prüfung der Daten. Schulungsaufwände und Fehlerrate sollen durch diesen ganzheitlichen Ansatz reduziert und werden. Dabei soll die intuitive Benutzung der Bedienoberfläche im Fokus stehen. Neben den üblichen graphischen Benutzerschnittstellen wie Menüleiste, Dialoge und Eingabefelder nimmt der Infrastruktureditor für schematische Übersichtspläne eine zentrale Rolle ein. Alle wesentlichen Elemente der Infrastruktur wie Gleise, Weichen, Signale, Achszähler, Bahnübergänge usw. werden hier editiert und die spezifischen Eigenschaften der Elemente werden festgelegt. Abbildung 13: Infrastrukturansicht Die Bedienoberfläche soll den Nutzer während der Erstellung einer Projektierung unterstützen, automatisch fehlerhafte Daten zu erkennen. Insbesondere sind hier folgende Anforderungen an die Projektierung zu nennen: - Vollständigkeit, - Konsistenz und Abhängigkeiten, - Korrektheit sowie - Einhalten von Projektierungsrichtlinen (z.b. Namenskonventionen, Wertebereiche). Diese automatisierte Prüfung der betrieblichen Daten unterstützt die Führung des Sicherheitsnachweises. Ein Sicherheitsnachweis gemäß CENELEC erfordert zudem die Verifikation der eingegebenen Daten. Vorstellbar ist, den Verifikationsprozess durch die Bedienoberfläche zu unterstützen. Eine Änderungsverfolgung, die Änderungen zwischen zwei Versionen eines Infrastrukturmodells (Differenzbetrachtung) anzeigt, und das Erzeugen von Berichten für eine Verifikation kommen hierbei in Betracht. Bei einer Verifikation durch Differenzbetrachtung werden die Unterschiede sichtbar gemacht, die zwischen einer zuvor geprüften und einer angepassten Version entstanden sind. Dies vereinfacht die Verifikation großer Datenmengen. Verifiziert werden nur die Änderungen auf ihre Vollständigkeit und Korrektheit, ohne dass das gesamte Infrastrukturmodell geprüft werden muss. Das Erzeugen von Berichten für eine Verifikation ermöglicht einen fokussierten Blick auf das Infrastrukturmodell. Zum Beispiel lassen sich alle Weichen inklusive Eigenschaften tabellarisch in einer Liste übersichtlicher darstellen, als dies in einer Infrastrukturansicht möglich ist. Fehler können dadurch einfacher und schneller erkannt werden. Ermüdungserscheinungen bei einer Verifikation können reduziert werden. Version 1.0 Seite 17 von 25

200 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Die Differenzbetrachtung und die Berichte können somit einen Gewinn für die Sicherheit darstellen. Damit wirkt sich die Verifikation des Infrastrukturmodells und die automatisierte Prüfung der betrieblichen Daten direkt auf die Projektierungen der Hardware und Software aus. Dabei führt ein korrektes Infrastrukturmodell auch zu korrekten Projektierungen. Fazit Die Nutzung von Transformationen und die einheitliche Bedienoberfläche bieten das Potential, die Geschwindigkeit in der Erstellung eines Stellwerks zu steigern und den Zulassungsprozess zu unterstützen. Durch die zentrale Datenhaltung können Änderungen leichter nachvollziehbar gemacht werden. 3.4 Besondere Aspekte der COTS-Projektierung in einen Infrastruktureditor Im vorherigen Kapitel wurde das Konzept eines einheitlichen Projektierungswerkzeugs vorgestellt. Die Umsetzung des Konzepts befindet sich bei der Funkwerk AG TCC in der Realisierung. Es entstand eine Softwareprodukt, welches das AMBER Datenmodell und einen Infrastruktureditor integriert. Das AMBER Modell lässt sich um neue Elemente oder Eigenschaften, wie z.b. spezielle Signaltypen, erweitern. Ebenfalls ist die Anwendung von Transformationen und einer Fehlerprüfung vorgesehen. Gegenüber dem Konzept ist es derzeit allerdings noch nicht möglich, eine automatisierte Differenzbetrachtung von Änderungen auf den Infrastrukturdaten durchzuführen. Abbildung 14: Funkwerk AG Infrastruktureditor Version 1.0 Seite 18 von 25

201 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Im Rahmen des NeGSt Projekts fand eine Evaluierung der Anwendbarkeit des Konzepts auf die Projektierung von COTS-Produkten statt. Es wurde die Software exemplarisch erweitert, sodass Teilaspekte verschiedener COTS-Projektierungen softwaregestützt erstellt werden können. Für die praxisnahe Evaluierung wird, als Beispiel, ein SIL2 Stellwerk mit 34 Weichen, 52 Signalen und 74 Achszählpunkten im Infrastruktureditor abgebildet. Im ersten Schritt ist dabei das AMBER Modell um die Elementtypen zu erweitern, die bisher nicht existierten. Die Erweiterung erfolgt graphisch in der Unified Modeling Language (UML). Als Elementtypen wurden z.b. ein Schnittstellentyp, ein Ausfahr- und ein Vorziehsignal definiert. Die Signaltypen wurden während der Erstellung der Infrastruktur entsprechend der Planungsunterlagen angewendet. Sie dienen als Start- bzw. Zielpunkte der Fahrstrassen. Der Schnittstellentyp definiert einen Übergang zu einem Nachbarstellwerk. Im Beispiel ist dies ein Spurplan-Drucktastenstellwerk. Eine solche Schnittstelle regelt mit Hilfe elektrischer Signale die sichere Übergabe von Zügen zwischen verschieden überwachten Bereichen. Abbildung 15: Anpassung des AMBER Modells Die Erweiterung des AMBER Modells ist problemlos und rückwirkungsfrei möglich. Die Pflege des Datenmodells stellt allerdings eine besondere Herausforderung dar. Das Löschen oder Ändern bestehender Typen kann dazu führen, dass existierende Infrastrukturmodelle angepasst werden müssen oder unbrauchbar werden. Daher müssen Änderungen im AMBER Modell sehr überlegt erfolgen und mittels Versionierung überwacht werden. Die Infrastrukturinformationen wurden, wie in der Abbildung des Infrastruktureditors (siehe oben) zu sehen, in den Infrastruktureditor eingegeben. Die Erstellung der Infrastrukturdaten erfolgte anhand der Planungsunterlagen. Durch Einfügen und Verknüpfen von Elementen wie z.b. Weichen und Gleise sowie durch das Festlegen von Eigenschaften entstand ein abstraktes Modell des Stellwerks. Dieses Infrastrukturmodell dient als Datenbasis für die weitere Verarbeitung in den Transformationen. Die Transformationen werden über folgendes Exportmenü abgerufen. Version 1.0 Seite 19 von 25

202 Projektierung von COTS-Produkten Projektierung von COTS-Produkten Abbildung 16: Auswahldialog Exportfunktionen Transformation Symboltabellenprojektierung Die Transformation erstellt die Symbole für jedes Element, welches elektrische Signale besitzt. Abhängig vom Elementtyp werden die Einträge in der Symboltabelle erzeugt. Folgendes Beispiel zeigt dies am Quellcode des Elementtyps Ausfahrsignal. Dynamisch werden bei der Ausführung die Signalnamen und die Adressen festgelegt. Abbildung 17: Quellcodeauszug Symboltabellenprojektierung Im Beispiel wurde durch die Transformation eine Symboltabelle mit mehr als 1600 Zeilen erzeugt. Die Erstellung der Symboltabelle wurde deutlich beschleunigt. Tippfehler und fehlende Elemente konnten vermieden werden. Transformation Achszählsystemprojektierung Die Anpassungen der COTS-Komponenten im Achszählsystem erfolgt ausschließlich hardwareseitig. Die Transformation liefert für das Achszählsystem deshalb keine Konfigurationsdatei, sondern die Dokumentation zur hardwareseitigen Projektierung als Bericht in der Hypertext Markup Language (HTML). Für die Projektierung berücksichtigt wurden die Richtungseinstellungen der Radsensoren sowie die Steckerkonfiguration der Frei-/Belegtmeldung. Ein Radsensor besteht intern aus zwei unabhängigen Sensorsystemen, die beim Überfahren eines Rades nacheinander aktiviert werden. Durch die zeitliche Abfolge lässt sich die Bewegungsrichtung des Rades ermitteln. Es ist notwendig, dem Achszählsystem die Überfahrrichtung zum Einzählen in den Achszählkreis mitzuteilen. Der Radsensor kann sowohl am linken als auch am rechten Schienenprofil montiert sein. Die Transformation wertet die Informationen der Infrastrukturdaten aus und ermittelt das an den jeweiligen Achszählkreis angrenzende Sensorsystem. Daraus lässt sich die Projektierung des für den Radsensor zuständigen DIP Schalters ableiten. Das folgende Beispiel zeigt ein Ergebnis einer solchen Transformation. Ein zweiter Freimeldeabschnitt tritt dabei bei Doppelnutzung eines Radsensors auf. In diesem Fall ist auf beiden Seiten des Radsensors ein Achszählkreis. Radsensorbezeichnung Freimeldeabschnitt 1 Freimeldeabschnitt 2 Version 1.0 Seite 20 von 25