Anhang 2.3: Dokumentationsumfang bei der Zulassung gemäß … · 2013-12-12 · Nach der Abstimmung mit dem Betreiber soll die seit 11.2012 vorliegende prEn 50126 in ... Die in den

Schlussbericht

Anhang zu AP 2000 – Optimierung des Zulassungsprozesses

Anhang 2.3:

Dokumentationsumfang bei der Zulassung gemäß CENELEC

1. Vorarbeiten und Unterarbeitspaket 2200.3 2. Beispielhafte Dokumentenlisten ('Best Practice')

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 2200.3

27.02.2013

Laufzeit: 01.09.2011 – 31.08.2013

Projektträger: TÜV Rheinland Consulting GmbH

AP2200 - Dokumentationsumfang bei der Zulassung gemäß CENELEC

Version: 1.0 , Status: Freigegeben (AG3-intern) Seite 2 von 18

Änderungsverfolgung

Datum Bearbeiter Version Inhalt 05.09.2012 Mathias Wagner (Bombar-

dier) 0.2 Erster Entwurf

01.02.2013 Mathias Wagner (Bombar-dier)

0.3 Überarbeitung nach weiteren Arbeitsergebnis-sen der AG3

06.02.2013 Hr. Beck (DB AG) Hr. Czepa (Thales) Hr. Griebel (Siemens) Fr. Möller-Neustock (Funk-

werk AG, TCC) Hr. Pietz (Pintsch Bamag) Hr. Dr. Priebe (S&B) Hr. Schwencke (DLR) Hr. Wagner (Bombardier)

0.4 Gemeinsame Überarbeitung nach vorherigem Review.

27.02.2013 Hr. Czepa (Thales) Hr. Griebel (Siemens) Fr. Möller-Neustock (Funk-

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



Inhaltsverzeichnis

1 Einleitung .......................................................................................................................... 4

2 Vorgaben .......................................................................................................................... 5

3 Definitionen ...................................................................................................................... 7

3.1 Rollendefinitionen .................................................................................................... 7

3.2 Spaltentitel ................................................................................................................ 8

3.3 Abkürzungen .......................................................................................................... 10

4 Dokumentenliste ............................................................................................................ 11

5 Zusammenfassung ......................................................................................................... 18



1 Einleitung

Die CENELEC-Normen EN 50126, EN 50128 und EN 50129 beschreiben die Entwicklung von Bahnanwendungen. Sie lassen dem Anwender einen großen Interpretations- und Handlungs-spielraum. So kann er auch relativ frei entscheiden, welche Maßnahmen er zur Entwicklung ei-nes sicheren Systems anwenden möchte. Umfassende Tabellen in den Anhängen der Normen EN 50128 und EN 50129 geben eine Auswahl von Maßnahmen, die anzuwenden sind. Oftmals soll der Anwender eine „geeignete“ Kombination von Maßnahmen auswählen, wobei nur ein-geschrä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 ein-heitlichen Liste sollen Best Practice-Beispiele erarbeitet und Interpretationsspielräume der Nor-men 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 An-wendungsfä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 11.2012 vorliegende prEn 50126 in die Dokumentenliste eingearbeitet werden

Das vorliegende Dokument zeigt die Ergebnisse der Vorarbeiten zu den oben genannten Unter-arbeitspaketen 2200.1, 2200.2 und 2200.4. 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ördervor-habens durchzuführen.

Das Unterarbeitspaket 2200.3 „Enge Abstimmung mit der AG2 CSM-VO“ wurde bereits ab-schließend bearbeitet und die Ergebnisse [Ergebnisbericht CSM-VO: NeGSt_Ergebnisbericht_ 2100_CENELEC_20130110.pdf] wurden in die hier vorliegende Dokumentenliste eingearbeitet.



2 Vorgaben

Die in den Kapiteln 3 und 4 dargestellte generische Dokumentenliste wurde von den Projekt-partnern 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 soll1, von wem (siehe Ta-belle 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 Vorstel-lungen 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 betrach-tet. 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 systemati-sche Fehler im Systemverhalten zeigen, wurde der Software die eigene CENELEC-Norm EN 50128 gewidmet. Aus Sicht der EN 50128 ist es nicht möglich, die Korrektheit von Software allein durch Analysen und Tests nachzuweisen. Deshalb wird in der EN 50128 neben Analyse und Test das Augenmerk ganz wesentlich auf den SW-Erstellungsprozess gelegt, um systemati-sche Fehler zu minimieren.

1 In Analogie zum Anhang C der EN 50128 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



Im Gegensatz dazu ist bei der Hardware und auf Systemebene der Nachweis korrekten Verhal-tens 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 Diffe-renzierung zwischen den Dokumenten für generische Produkte/Applikationen und spezifische Applikationen durchgeführt werden.



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 "in-

terner Gutachter", "Prüfleitstelle" und "exter-ner 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, 3.1.49, umfasst die Gruppe

der Verifizierer und Reviewer. Ein Reviewer ar-beitet 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 schrift-lich dokumentiert.

4A Prüfer nach dem 4-Augen-Prinzip

Prüfung gemäß ISO 9001

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



3.2 Spaltentitel

Spalte im Arbeitsblatt "Dokumen-te"

Erläuterung Mögliche Einträge

CENELEC-Phase Ersterstellung Phase des CENELEC-Prozesses nach EN 50126, in der das Dokument angelegt wird

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 Do-kuments gemäß aktuellster CENELEC-Norm

<Name>

CENELEC-Verweis EN 5012x:jjjj Wo wird das Dokument in der jeweiligen Norm ge-nannt?

Nummern der Unterpunkte der jeweiligen Norm, z. B. "6.2.3.1, 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 Falls die erste Prüfung bewertet werden soll2, von wem (siehe Tabelle 1: Definierte Rollen)

<Rolle des Prüfers>, z. B. "VAL"

Vorlage bei / Abstimmung mit Betrei-ber

Ist das Dokument dem Betreiber vorzulegen? x = ja, (x) = bei Bedarf / projektabhängig

Prüfung durch Gutachter Ist das Dokument in jedem Fall dem Gutachter vor-zulegen?

x = ja, (x) = bei Bedarf

2 In Analogie zum Anhang C der EN 50128 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



Prüfung durch EBA Ist das Dokument in jedem Fall beim EBA vorzule-gen?

x = ja, (x) = Prüfbericht zur Qualitätskontrolle

Dokumentenhierarchien und mögliche Dokumentenzusammenfassung

Mit welchen anderen Dokumenten kann das Doku-ment zusammengefasst werden? Ist es Bestandteil von anderen Dokumenten oder enthält es andere Dokumente?

Z <Dokumentenkürzel>, T <Dokumentenkürzel>, E <Dokumentenkürzel>

Kommentar Gibt es Besonderheiten zum Dokument, die neben den vordefinierten Spalten wichtig zum Verständnis des Dokuments sind?

<freier Text>

Tabelle 2: Erklärung der Spaltentitel

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.



3.3 Abkürzungen

Abkür-zung

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

heitsmethode 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



4 Dokumentenliste C

EN

EL

EC

-Ph

ase

Ers

ters

tellu

ng

Do

kum

ente

nkü

rzel

Do

kum

ente

nn

ame

eng

-lis

ch

Do

kum

ente

nn

ame

deu

tsch

CE

NE

LE

C-V

erw

eis

EN

50

126:

1999

CE

NE

LE

C-V

erw

eis

EN

50

128:

2001

CE

NE

LE

C-V

erw

eis

EN

50

128:

2012

CE

NE

LE

C-V

erw

eis

EN

50

129:

2003

Ers

telle

r (R

olle

- k

ein

e P

erso

n)

Ers

te P

rüfu

ng

Zw

eite

Prü

fun

g

Vo

rlag

e b

ei /

Ab

stim

-m

un

g m

it B

etre

iber

Prü

fun

g d

urc

h G

uta

ch-

ter

Prü

fun

g d

urc

h E

BA

Do

kum

ente

nh

iera

rch

ien

u

nd

mö

glic

he

Do

kum

en-

ten

zusa

mm

enfa

ssu

ng

en

Ko

mm

enta

r

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. 6.2.4 AG --- --- - --- --- 1 SyDP Development Plan Entwicklungsplan Pkt.

5.3.5.d -> ISO 9003

PM 4A --- - --- --- E PrTL ist mög-lich

Herstellerspezifisches Projektkonzept

1 PrTL Project Timeline Projekt-Zeitplan PM --- --- x --- --- T SyDP ist möglich

1 PrDL Document List Dokument-Übersicht PM --- --- x --- --- 1 PrG Glossary Glossar nicht

festge-legt

--- --- - --- ---

1-2 SySP Safety Plan Sicherheitsplan Pkt. 6.2.3.4

Pkt. 5.3.4 SM 4A --- x --- --- kann auch die die RAM-

Aspekte enthal-ten (RAM-

Programm aus 50126 Kapitel

6.4)

Z SySMR wird als sinnvoll erachtet (da dort die Prüfungsergebnisse zum SySP stehen)

2-10 SySMR Safety Management Re-port

Sicherheitsmanagementbe-richt

Pkt. 5.3.1 SM (4A) --- x x (50129, 5.5.2)

--- T SySC, E HazLog, kann auch die RAM-Aspekte enthal-

ten (RAM-Programm aus 50126 Kapitel

6.4)

Z SySP wird als sinnvoll erachtet (als zu überprüfendes Dokument), 4-Augen-Prinzip im Falle eines externen Gutach-ters

1-2 SyQMP Quality Management Plan

Qualitätssicherungsplan (Pkt. 5.3.5 d, Pkt.

6.6.3.5)

Pkt. 15.4.3 (für SW-

Teil)

Pkt. 6.5.4.4,

C.1/1 (für SW-Teil)

QM 4A --- x --- --- muss nach aktueller Praxis dem Gutach-ter vorgelegt werden

2-10 SyQMR Quality Management Report

Qualitätsmanagementbe-richt

Pkt. 6.9.3.3

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 Er-gebnisse zur Anforderungsverfolgbarkeit - kann eigenständiges Dokument (Anf.verfolgbarkeitsmatrix) oder Teil des Berichtes sein, s. diverse Stellen in der EN 50128:2012. 4-Augen-Prinzip im Fal-le eines externen Gutachters

2 SyPVR Planning Verification Report

Planungsverifikationsbericht Pkt. 6.2.4.11,

Pkt. 6.5.4.7,

Pkt. 6.5.4.8, C.1/2

VER --- VAL - Verifiziert alle Pläne außer dem Validie-rungsplan. Heißt lt. 50128:2012 (Soft-ware-) Qualitätssicherungsverifikations-bericht



1-2 SyCMP Configuration Manage-ment Plan

Konfigurationsmanage-mentplan

(Pkt. 5.3.5) Pkt. 15.4.6 (für SW-

Teil)

Pkt. 6.5.4.5,

C.1/3 (für SW-Teil)

CM 4A --- x --- ---

1-2 SyVeP Verification Plan Verifikationsplan (Pkt. 5.2.9) Pkt.11.4.1 Pkt. 6.2.4.2ff, C.1/4 (für SW-Teil)

Pkt. 5.3.9, Tabelle

E.9

VER --- SM (x) --- --- Enthält den Software-Verifikationsplan. Die Aufgaben sind in der 50126 definiert, nicht das Dokument. Im aktuellen Ent-wurfsstand der neuen 50126-1 werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genau-ere Angaben zu geforderten Dokumenten macht.

1-2 SyVaP Validation Plan Validierungsplan (Pkt. 5.2.9) Pkt. 13.4.3 (für SW-Anteil)

Pkt. 6.3.4.4,

C.1/5 (für den SW-

Teil)

Pkt. 5.3.9, Tabelle

E.9

VAL SM --- (x) x --- Die Aufgaben sind in der 50126 definiert, nicht das Dokument. Im aktuellen Ent-wurfsstand der neuen 50126-1 werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genau-ere Angaben zu geforderten Dokumenten macht

1-2 SyTP Test Plan System-Testplan Pkt. 5.3.2 TES --- VAL (x) x --- Z SwITP, Z SwHwITP

1-2 SyAP Assessment Plan Begutachtungsplan --- Pkt.6.4.4.5C.1/45

ASR 4A --- - --- --- auch als "Prüfhandbuch" bezeichnet; in der Regel fordert das EBA die Vorlage des SyAP; ist bislang nur für SW ver-pflichtend. Definiert die Kriterien, Ar-beitsweise und den Arbeitsumfang der Prüfleitstelle/des Gutachters

3 Risikoanalyse 3 SyHA Hazard and Risk Analy-

sis Gefährdungs- und Risiko-analyse

Pkt. 6.2.3.1,

Pkt. 6.3 + Anh. D

Anh. A AG --- --- - x x In Zukunft gemäß NTZ keine Prüfung durch EBA mehr? Unklar, ob die Revisi-on der 50129 (neue 50126) weiterhin Prüfung durch Aufsichtsbehörde fordert

3 SyHL Hazard Log Gefahrenprotokoll Pkt. 6.3.3.3,

Definition in Pkt. 3.18

Pkt. 13.4.3 Pkt. 5.3.5 SM (4A) --- x x --- T SySMR gängiger Begriff ist "Gefährdungslog-buch". 4A-Prüfung im Falle eines exter-nen Gutachters

4 Systemanforderungen 4 SyRS System Requirements

Specification System-Anforderungsspezifikation

Pkt. 6.4 + Anh. A

Pkt. 5.3.6 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

4 SySRS System Safety Require-ments Specification

System-Sicherheitsanforderungs-spezifikation

Pkt. 6.4 Kap. 8 Pkt. 5.3.6 AG/AN (VER) (VAL) (x) (x) (x) Z SyRS Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN. Sicher-heitskonzept gemäß Mü 8004 kann in diesem Dokument aufgehen. Prüfungen finden statt bei Ersteller AN

4 SyTS System Test Specificati-on

System-Testspezifikation Pkt. 8.4.13 (für SW)

Pkt. 5.3.9, Pkt. 5.4

TST VER VAL (x) --- --- Z SwOTS enthält neben der Abdeckung der Sys-temanforderungen auch noch zusätzliche Test zur Gesamtsystemfunktionalität

4 SyRVR System Requirements Verification Report

System-Anforderungsverifikationsbe-richt

Pkt. 6.4.5 C.1/8 VER --- VAL (x) --- --- Z SwRVR, Z HwRVR

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



5 Systementwurf 5 SyAS System Architecture

Specification System-Architekturspezifikation

C.1/9 Pkt. B.2.1 DEV VER VAL (x) --- --- Z SyDS in diesem Dokument können ggf. Sub-systeme 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)

5 SyDS System Design Specifi-cation

System-Entwurfsspezifikation

C.1/10 Pkt. 5.3.7 + 5.4

DEV VER VAL (x) --- --- Z SyAS oft wird auch der Begriff "Pflichtenheft" verwendet, s. Kommentar SyAS

5 SyADVR System Architecture and Design Verification Re-port

System-Architektur- und Entwurfsverifikationsbericht

Pkt.11.4.12 C.1/14 VER --- VAL (x) --- --- Z Komponen-tenentwurfsbe-richt möglich -

TODO

5-6 SwHwITP SW/HW Integration Test Plan

SW/HW-Integrationstestplan Pkt. 12.4.1 C.1/13 TES --- VAL (x) --- --- Z SyTP, Z SwITP

6 Entwicklung/Konstruktion und Implementierung 6.1 Hardware Zu Kapitel 6.1 s. "Kommentar Hard-

ware" in Kapitel 1 6.1.1 HW-Anforderungen 6 HwRS HW Requirements Spe-

cification HW-Anforderungsspezifikation

DEV 4A --- - --- --- Z SyRS, Z SwRS, Z HwDS, Z

HwAS, Z HwIS

6.1.2 HW-Entwurf 6 HwDS HW Design Specification HW-Entwurfsspezifikation DEV 4A --- - --- --- Z HwRS, Z

HwAS, Z HwIS, Z HwCDS

entfällt, wenn nur eine Komponente im System vorhanden

6 HwAS HW Architecture Specifi-cation

HW-Architekturspezifikation DEV 4A --- - --- --- Z HwRS, Z HwDS, Z HwIS


6 HwIS HW Interface Specificati-on

HW-Schnittstellenspezifikation

DEV 4A --- (x) --- --- Z HwRS, Z HwDS, Z HwAS


6.1.3 HW-Komponentenentwurf 6 HwCDS HW Component Design

Specification HW-Komponentenentwurfsspezi-fikation

DEV 4A --- - --- --- Z HwDS

6 HwCFMEA HW Component FMEA HW-Komponenten-FMEA DEV 4A --- - --- --- 6 HwCRC HW Component Reliabili-

ty Calculations HW-Komponenten-Zuverlässigkeitsberechnun-gen

DEV 4A --- - --- ---

6.1.4 HW-Fertigungsunterlagen 6 HwPD HW Production

Documents HW-Fertigungsunterlagen DEV 4A --- - --- --- Layout, Stücklisten, Grundschaltungen,

etc. 6.1.5 HW-Komponententest 6 HwCTS HW Component Test

Specification HW-Komponententestspezifika-tion

TES 4A --- - --- ---

6 HwCTR HW Component Test Report

HW-Komponententestbericht

TES 4A --- - --- ---

6.1.6 HW Verifikationsbericht 6 HWVR HW Verification Report HW Verifikationsbericht VER --- VAL - --- --- Verifikationsbericht fasst alle Verifikati-

onsschritte für die HW zusammen.



6.2 Software 6.2.1 SW-Anforderungen 6 SwRS SW Requirements Spe-

cification SW-Anforderungsspezifikation

Pkt. 8.4.1 Pkt. 7.2.4.1, C.1/6

DEV VER VAL - --- --- Z SyRS, Z HwRS

6 SwOTS SW Overall Test Specifi-cation

SW-Gesamttestspezifikation Pkt. 8.4.13 Pkt. 7.2.4.16,

C.1/7

TES VER VAL - --- --- Z SyTS früher (50128:2003): SW-Anforderungstestspezifikation

6 SwRVR SW Requirements Verifi-cation Report

SW-Anforderungsverifikationsbe-richt

Pkt. 11.4.11 VER --- VAL - --- --- Z SyRVR, Z HwRVR, Auftei-

lung in SW-Anforderungs-verifikationsbe-richt und SW-Anforderungs-testverifikati-

onsbericht wird je nach Projekt-

umfang als sinnvoll erachtet

6 SwAS SW Architecture Specifi-cation

SW-Architekturspezifikation Pkt. 9.4.1 Pkt. 7.3.4.1 DEV VER VAL - --- --- Z SwDS, Z SwIS

s. Kommentar SyAS

6 SwDS Software Design Specifi-cation

SW-Entwurfsspezifikation Pkt. 10.4.3 Pkt. 7.3.4.20

DEV VER VAL - --- --- Z SwAS, Z SwIS

s. Kommentar SyDS

6 SwIS SW Interface Specificati-on

SW-Schnittstellenspezifikation

Pkt. 7.3.4.19 C.1/11

DEV VER VAL - --- --- Z SwDS, Z SwAS

s. Kommentar SyAS/SyDS

6 SwADVR SW Architecture and Design Verification Re-port

SW-Architektur- und Ent-wurfsverifikationsbericht

Pkt. 11.4.12 Pkt. 7.3.4.42

VER --- VAL - --- --- Aufteilung in SW-

Architekturveri-fikationsbericht

und SW-Entwurfsverifi-kationsbericht wird je nach

Projektumfang als sinnvoll

erachtet

6 SwITP SW Integration Test Plan SW-Integrationstestplan Pkt. 11.4.5 Pkt. 7.3.4.34, C.1/12

TES --- VAL (x) --- --- Z SyTP, Z SwHwITP

6.2.3 SW-Komponentenentwurf 6 SwCDS SW Component Design

Specification SW-Komponentenentwurfsspezi-fikation

Pkt. 10.4.5 Pkt. 7.4 C.1/15

DEV VER VAL - --- --- Früher (50128:2003) "Modul" statt "Kom-ponente"

6 SwCDVR SW Component Design Verification Report

SW-Komponentenentwurfsverifi-kationsbericht

Pkt. 11.4.13 Pkt. 11.4.14

Pkt. 7.4.4.13 C.1/17

VER --- VAL - --- --- Z SwSCVR, Z SwCTR

Früher (50128:2003) "Modul" statt "Kom-ponente"

6.2.4 SW-Implementierung 6 SwSC SW Sourcecode and

Additional Documenta-tion

SW-Quellcode und Hilfsdo-kumentation

Pkt. 10.4 Pkt. 7.5 C.1/18

DEV VER --- - --- --- Früher "Zusatzdokumentation" statt "Hilfsdokumentation"; zweite Prüfung gemäß EN 50128:2012 Tabelle C.1 wird nicht immer als sinnvoll erachtet

6 SwSCVR SW Sourcecode Verifica-tion Report

SW-Quellcodeverifikationsbe-richt

Pkt. 11.4.14 C.1/19 VER --- VAL - --- --- Z SwCDVR, Z SwCTR



6.2.5 SW-Komponententest 6 SwCTS SW Component Test

Specification SW-Komponententestspezifika-tion

Pkt. 10.4.14 Pkt. 7.4 C.1/16

DEV VER --- - --- --- Norm alt: Modul --> Norm neu: Kompo-nente

6 SwCTR SW Component Test Report

SW-Komponententestbericht

Pkt. 10.4.14 Pkt. 7.5.4C.1/20

DEV VER --- - --- --- Z SwCDVR, Z SwSCVR

Der zugehörige Verifikationsbericht ist der SwCDVR

6.3 Integration 6 SwITS SW Integration Test

Specification SW-Integrationstestspezifikation

(Pkt. 11.4.5)

Pkt. 7.3.4.29

TES VER VAL (x) --- --- Z SwHwITS

6 SwHwITS SW/HW Integration Test Specification

SW/HW-Integrationstestspezifikation

Pkt. 12.4.1 Pkt. 7.3.4.33

TES VER VAL (x) --- --- Z SwITS

6 SwITR SW Integration Test Re-port

SW-Integrationstestbericht Pkt. 11.4.15 Pkt. 7.6.4.3C.1/21

TES --- --- (x) --- --- Z SwHwITR, Z SyTR

6 SwHwITR SW/HW Integration Test Report

SW/HW-Integrationstestbericht

Pkt. 12.4.8 Pkt. 7.6.4.7C.1/22

TES --- --- (x) --- --- Z SwITR, Z SyTR

6 SyAPP Application Preparation Plan

Anwendungs-Generierungsplan

Pkt. 17.4.2.1

Pkt. 8.4.1.1C.1/29

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 Anwen-dung (siehe EN 50128:2012 8.4.1.2)

6 SyIVR Integration Verification Report

Integrationsverifikationsbe-richt

Pkt 7.6.4.13

VER --- VAL (x) --- ---

7 Fertigung 7 SyARS Application Require-

ments Specification Anwendungs-Anforderungsspezifikation

Pkt. 8.4.2.1C.1/28

DEV VER VAL x --- ---

7 SyATS Application Test Specifi-cation

Anwendungs-Testspezifikation

Pkt. 8.4.5.2C.1/30

TES VER VAL x --- ---

7 SyAAD Application Architecture and Design

Anwendungsarchitektur und -entwurf Pkt. 8.4.3C.1/31

DEV VER VAL - --- --- Ist so in der Norm genannt, Titel ist aber eigentlich unlogisch, da der entspre-chende Abschnitt die Datengenerierung und -prüfung beschreibt.

7 SySCADA Source Code of Applica-tion Data/Algorithms

Quellcode der Anwen-dungsdaten-/Algorithmen

C.1/34, Pkt. 8.1.1,

8.4.4.1

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 örtli-che EBA gemeint.

7 SyAPVR Application Preperation Verification Report

Anwendungs-Generierungsverifikations-bericht

VER --- VAL x --- ---

7 SyATR Application Test Report Anwendungs-Testbericht Pkt. 17.4.2.4

Pkt. 8.4.4.2C.1/33

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

7 SyRDP Release and Deployment Plan

Freigabe- und Bereitstel-lungsplan

C.1/36 vom firmenspezifischen Prozess abhängig

- --- --- Keine expliziten Dokumente für den Ent-wicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abge-deckt

7 SyADAVR Application Da-ta/Algorithms Verification Report

Anwendungsdaten-/Algorithmen-Verifikationsbericht

VER --- VAL x --- ---

7 SyDM Deployment Manual Bereitstellungshandbuch C.1/37 vom firmenspezifischen Prozess abhängig

x --- --- Keine expliziten Dokumente für den Ent-wicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abge-deckt



7 SyRNs Release Notes Freigabemitteilungen C.1/38 vom firmenspezifischen Prozess abhängig

- --- --- E SyRN Keine expliziten Dokumente für den Ent-wicklungsprozess, da in allen beteiligten Firmen über QS- bzw. ISO 9001 abge-deckt

7 SyRN Release Note Freigabemitteilung 7.7.4.12, C.1/27

vom firmenspezifischen Prozess abhängig

x --- --- T SyRNs Zusammenfassung der ausführlichen Release Notes

7 SyDR Deployment Record Bereitstellungsaufzeichnun-gen



7 SyDVR Deployment Verification Report

Bereitstellungs-Verifikationsbericht



8 Installation/Montage 8 SyPI Preparation Instructions Projektierungsrichtlinie Kap. 8 Pkt.

B.2.2.1 b)DEV 4A SM x x x Inhalte sehr firmenspezifisch: enthält

Anleitung zur Projektierung der Anlage, z. B. Anzahl Busteilnehmer, Kabelvorga-ben, Fahrstraßentabelle, …

8 SyM Manual Bedienhandbuch Kap. 8 Pkt. B.2.2.1 b)

DEV 4A --- x --- ---

8 SyTI Test Instructions Prüfanweisungen Hw/Sw Kap. 8 Pkt. B.2.2.1 b)

DEV 4A --- x --- ---

8 SyII Installation Instructions Installationsanleitung Kap. 8 Pkt. B.2.2.1 b)

DEV 4A --- x --- ---

9 Validierung 9 SyTR System Test Report System-Testbericht C.1/24 TES --- VAL (x) --- --- Z SwITR, Z

SwHwITR

9 SyVaR System Validation Report System-Validationsbericht Pkt. 13.4.10 Pkt. 6.3.4.7C.1/25

VAL --- --- x x x E TVaR beinhaltet alle Elemente: Software, Hardware, integriertes System und Tools und Betrachtung von Aufla-gen/Restfehler, In Zukunft gemäß NTZ keine Prüfung durch EBA mehr

9 TVaR Tool Validation Report Werkzeuge-Validierungsbericht

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üh-rung.

9 SyTSR Technical Safety Report Technischer Sicherheitsbe-richt

Pkt. 5.4 SM --- --- x x x T SySC, E SyDDN

In Zukunft gemäß NTZ keine Prüfung durch EBA mehr

9 SySC Safety Case Sicherheitsnachweis Pkt. 5.1 SM --- --- - x x E SySMR, E SyQMR, E SyTSR, E "CSM-VO

Nachweisdo-kument"

In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. Vorbereitung ab Phase 6.

9 SASC Application Safety Case Anwendungssicherheits-nachweis

(6.6.3.5) SM --- --- x --- --- In Deutschland ist eine Verwendung nicht bekannt. Kann ggf. im Ausland erforder-lich sein. Vorbereitungen laut alter 50126 ab Phase 6. An dieser Stelle wird nur die "Vorbereitung" des Dokumentes erwähnt; weitere Festlegungen fehlen jedoch.



10 Abnahme 10 SyAR Assessment Report System-Gutachten Pkt. 14.4.9 Pkt.

6.4.4.16, C.1/46 (für SW-Teil)

ASR --- --- x --- x E SySAR Hierunter sind auch Gutachten zu ver-stehen, die sich nur auf Software oder Hardware beziehen

10 SySAR Safety Assessment Re-port

Sicherheitsbewertungsbe-richt

Pkt. 5.5.2 ASR --- --- (x) --- x T SyAR Gutachten zum CSM-VO Nachweisdo-kument 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 Gut-achten auf die spezifische Struktur des CSM-Prozesses einzugehen.

11 Betrieb / Instandhaltung 12 Erfassung der Leistungsfähigkeit 12 SyPR Performance Report Leistungsfähigkeitsbericht Pkt.

6.12.4.1 DEV --- --- (x) --- --- Rücklauf aus den Protokollen spezifi-

scher Anlagen für zukünftige Änderun-gen. Durch ISO 9001 abgedeckte Verfah-ren

13 Änderung / Nachrüstung 13 SyRP Release Plan Releaseplan PM --- --- x --- --- Aufstellung der geplanten Erweiterungen

und Verbesserungen. Durch die CENELEC nicht offiziell gefordertes Do-kument!

13 SyMP Maintenance Plan Wartungsplan Anhang -> 9001 ???

Pkt.16.4.3 C.1/41 PM --- VAL x x x Generischer Wartungsprozess (allgemei-ne Vorgehensweise). Für kleinere Hard-wareänderungen gibt es bereits verein-fachtes 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. 16.4.9 C.1/42 Pkt. 5.3.8 DEV SM --- x x x Änderungsbericht für jede Wartungsakti-vität. Nur für Änderungen, die keine Spe-zifikationsänderungen beinhalten - sonst nicht zwingend erforderlich. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr.

13 SwMR SW Maintenance Record SW-Wartungsaufzeichnungen

Pkt. 16.4.8 Pkt. 9.2.4.7C.1/43

DEV --- --- x --- ---

13 SwMVR Software Maintenance Verification Report

SW Wartungsverifikations-bericht

Pkt. 9.2.4.11

VER --- VAL x --- ---

14 Stilllegung / Entsorgung 9-14 SyDDN Decommissioning and

Disposal Notes Stilllegungs- und Entsor-gungshinweise

Pkt. B.5.4 PM SM --- x --- --- T SyTSR

Tabelle 4: Dokumentenliste

Hinweis: Verifikationsberichte sind hellgrau markiert.



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 Be-rücksichtigung der neuen Software-Norm DIN EN 50128:2012 und der Ergebnisse der AG2 zur CSM-VO (Unter-Arbeitspaket 2200.3).

Als Ergebnis liegt eine generische Dokumentenliste vor, die für die folgenden Unter-Arbeitspakete 2200.1, 2200.2 und 2200.4 als Grundlage dient.



Ergebnisbericht AP2200 Dokumentationsumfang bei der Zulassung gemäß CENELEC

Unterarbeitspaket 2200.1: Beispielhafte Dokumentenlisten ('Best Practice')

12.08.2013

Laufzeit: 01.09.2011 – 31.08.2013



Version: 1.0, Status: Veröffentlicht Seite 2 von 21


Datum Bearbeiter Version Inhalt

06.06.2013 Mathias Wagner (Bombardier) 0.1 Erster Entwurf

04.07.2013 Mathias Wagner (Bombardier) 0.2 Update nach internem AG3-Review 08.07.2013 Mathias Wagner (Bombardier) 0.3 Update nach internem AG3-Review

16.07.2013 Mathias Wagner (Bombardier) 0.4 Update des Kapitels 4 Skalierbarkeit nach inter-nem AG3-Review

18.07.2013 Mathias Wagner (Bombardier) 0.5 Update nach internem AG3-Review

07.08.2013 Beck (DB AG) Czepa (Thales) Griebel (Siemens) Möller-Neustock (Funkwerk

AG, TCC) Pietz (Pintsch Bamag) Dr. Priebe (S&B) Schwencke (DLR) Wagner (Bombardier)

0.6 Erweiterung um SIL 0 und SIL 2

12.08.2013 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



Inhaltsverzeichnis

1 Einleitung ................................................................................................................ 4

2 Definitionen ............................................................................................................. 5

2.1 Spaltentitel ....................................................................................................... 5

2.2 Abkürzungen ..................................................................................................... 6

3 Vorgaben ................................................................................................................ 7

4 Skalierbarkeit........................................................................................................... 9

5 Safety Integrity Levels .............................................................................................10

5.1 SIL 4 ................................................................................................................10

5.2 SIL 2 ................................................................................................................10

5.3 SIL 0 ................................................................................................................10

6 Dokumentenliste .....................................................................................................12

7 Zusammenfassung und Ausblick ................................................................................21



1 Einleitung

Die CENELEC-Normen EN 50126, EN 50128 und EN 50129 beschreiben die Entwicklung von Bahn-anwendungen. 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 Sys-tems anwenden möchte. Umfassende Tabellen in den Anhängen der Normen EN 50128 und EN 50129 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 CENELEC-konforme Dokumentenliste bei der Einreichung zur Zulassung von Projektvorhaben. Auf Basis die-ser 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 Unter-arbeitspakete strukturiert:

0. Erstellung einer abgestimmten generische CENELEC-Dokumentenliste

1. Erstellung von beispielhaften Dokumentenlisten ('Best Practice') für spezifische Anwen-dungsfä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 Sek-torhandbuch Infrastruktur aufbereitet.

3. Enge Abstimmung mit der AG2 (CSM-VO)

4. Nach der Abstimmung mit dem Betreiber soll die seit 11.2012 vorliegende prEn 50126 in die Dokumentenliste eingearbeitet werden

Das Unterarbeitspaket 2200.2 wurde ausgesetzt, da die NeGSt-Arbeitsgruppe 4 die Bearbeitung des „Sektorhandbuches Infrastruktur“ im Mai 2013 vorerst ausgesetzt hat.

Das Unterarbeitspaket 2200.3 wurde bereits im Teilbericht „Vorarbeiten und Unterarbeitspaket 2200.3“ (NeGSt_Teilbericht_2200.0u3_1.0.pdf) abschließend bearbeitet.

Das Unterarbeitspaket 2200.4 wurde ausgesetzt, da es im Mai 2013 mit dem vorliegenden Zwi-schenstand der prEN 50126 nicht zielführend scheint, die Dokumentenliste daraufhin anzupassen.

Als Ersatz für die Unterarbeitspakete 2200.2 und 2200.4 wurde das optionale Unterarbeitspaket 2200.1 Teil b „Einarbeitung von SIL 2 in die Best Practices“ und 2200.1 Teil c „Einarbeitung von SIL 0 in die Best Practices“ in die Liste der Unterarbeitspakete aufgenommen.

Das vorliegende Dokument zeigt die Ergebnisse des Unterarbeitspaketes 2200.1 Teil a bis Teil c „Er-stellung von beispielhaften Dokumentenlisten ('Best Practice') für vier spezifische Anwendungsfälle für SIL 4 und SIL 2 und SIL 0“.



2 Definitionen

2.1 Spaltentitel

Folgende Spaltentitel werden in Tabelle 4 verwendet.

Spalte im Arbeitsblatt "Dokumente"

Erläuterung Mögliche Einträge

CENELEC-Phase Ersterstellung

Phase des CENELEC-Prozesses nach EN 50126, in der das Dokument angelegt wird

Zahl zwischen 1 und 14, ggf. auch mehrere mögliche Phasen

Dokumentenkürzel Kürzel für den (englischen) Dokumen-tennamen

<Kürzel>, i.d.R. beginnend mit "Pr...", "Sy…", "Sw…" oder "Hw..." für Projekt-, System-, Software- und Hardware-Dokumente

Dokumentenname vollständiger Name des Dokuments gemäß aktuellster CENELEC-Norm

<Name>

Kommentar Gibt es Besonderheiten zum Dokument, die neben den vordefinierten Spalten wichtig zum Verständnis des Doku-ments sind?

<freier Text>

Best Practice x: An-wendungsfall

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 überarbei-tet

werden soll

„+“, „-“, „+/-“, „-/+“

Erläuterung BP x Erläuterungen zu dem jeweiligen Do-kument für diesen Anwendungsfall

Tabelle 1: Erklärung der Spaltentitel



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

methode 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: Relia-

bility, Availability, Maintainability, Safety) Sb 3 Sachbereich 3 (des Eisenbahn-Bundesamtes) SIL Sicherheitsanforderungsstufe SW Software THR Tolerierbare Gefährdungsraten

Tabelle 2: Verwendete Abkürzungen



3 Vorgaben

Auf Basis der Dokumentenliste aus dem Teilbericht „Vorarbeiten und Unterarbeitspaket 2200.3“ (NeGSt_Teilbericht_2200.0u3_1.0.pdf) wurden Ausprägungen für die folgenden spezifischen An-wendungsfä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

Definition

Best Practice 1: SW-Fehlerbehebung

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.

Best Practice 2: Systemerweiterung

Der Anwendungsfall ‚Systemerweiterung‘ setzt voraus, dass ein Release bereits zugelassen ist. Es wird angenommen, dass Änderungen an Hard- und 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 Syste-me rückwirkend aktualisiert werden müssen.

Best Practice 3: Weiterentwicklung einer HW-Steckkarte (als HW-Kompon.)

Der Anwendungsfall ‚HW-Weiterentwicklung‘ setzt voraus, dass ein Relea-se bereits zugelassen ist. Es wird eine kompatible Änderung einer Kompo-nente 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.

Best Practice 4: Neue spezifische Applikation

Der Anwendungsfall ‚Neue spezifische Applikation‘ setzt eine gleichblei-bende 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



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



4 Skalierbarkeit

Das zu betrachtende System kann aus einer mehr oder weniger komplexen Struktur von Sys-tem/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 2200.3“ (NeGSt_Teilbericht_2200.0u3_1.0.pdf) grundsätzlich angewendet werden. Pro Ebene ist dabei eine Teilmenge der Dokumente der generi-schen 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, Va-lidation 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.



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 50128 Tabelle A.1. Unterschiede zwischen SIL 4 und SIL 2 Entwicklungen ergeben sich durch die verschie-denen Techniken und Maßnahmen, wie z. B. in der DIN EN 50129 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äsentati-ves 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. Fahrgastinfor-mationssysteme oder Infotainment-Applikationen werden nicht nach CENELEC entwickelt.

Dies erfolgt unter Berücksichtigung der Regeln in DIN EN 50129, die zur Thematik die fol-genden wesentlichen Aussagen enthält:

» Die Anwendung dieses Sicherheitsmanagementprozesses ist verbindlich für die Si-cherheitsanforderungsstufen 1 bis 4 (siehe Anhang A zur Erläuterung der Sicherheitsan-

forderungsstufen). Jedoch sollten die Tiefe der Darlegungen und der Umfang der beglei-

tenden Dokumentation der Sicherheitsanforderungsstufe des/der betrachteten Sys-

tems/Teilsystems/Einrichtung angemessen sein. Die Anforderungen für die Sicher-

heitsanforderungsstufe 0 (nicht sicherheitsrelevant) liegen außerhalb des Anwen-

dungsbereiches dieser Sicherheitsnorm.

In allen Fällen sind Gefährdungsanalyse und Risikobewertungsprozesse, wie in EN

50126 definiert, notwendig, um den benötigten Grad an Sicherheitsintegrität jeder ein-

zelnen 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 si-

cherheitsrelevant) und feststeht, dass die Stufe 0 bestehen bleibt, dann endet die An-wendbarkeit 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 gege-ben, 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 05.08.2010



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

ria has been met for Minor Failure Conditions. Current transport category aeroplane products

are regarded as meeting this standard simply by using current commonly-accepted indus-

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



6 Dokumentenliste

Die folgende Dokumentenliste listet die Dokumente der generischen CENELEC-Dokumentenliste aus dem Teilbericht „Vorarbeiten und Unterarbeitspaket 2200.3“ (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 wer-den soll (siehe auch Tabelle 1: Erklärung der Spaltentitel).

CE

NE

LE

C-P

has

e E

rste

rste

l-lu

ng

Do

kum

ente

nkü

rzel

Do

kum

ente

nn

ame

Ko

mm

enta

r

Bes

t P

ract

ice

1: S

W-

Feh

lerb

eheb

un

g

Erl

äute

run

gen

BP

1

Bes

t P

ract

ice

2: S

yste

mer

-w

eite

run

g

Erl

äute

run

gen

BP

2

BP

3:

Wei

tere

ntw

ickl

un

g

ein

er H

W-S

teck

kart

e

Erl

äute

run

gen

BP

3

Bes

t P

ract

ice

4: n

eue

spez

i-fi

sch

e A

pp

likat

ion

Erl

äute

run

gen

BP

4

1/2 Konzept und Systemdefinition SyCR Kundenanforderung optionales Dokument; wird u.U. bis inkl.

Phase 4 weiter verfeinert - +/- Falls sich Anforderun-

gen des Kunden än-dern.

- -

1-2 SyDef Systemdefinition - +/- Falls sich Anforderun-gen des Kunden än-dern.

- -

1-2 SyCIA Änderungsauswirkungsanaly-se

Dokument ist nicht von CENELEC gefor-dert, wird aber als sinnvoll erachtet. Es ist nur bei Änderungen zu erstellen. Ziel ist zu entscheiden, welche Teile des Pro-zesses betroffen sind und welche Doku-mente und Systembestandteile geändert werden müssen

+ Wenn nicht alle Sys-tem- und Modultest wiederholt durchgeführt werden sollen, muss dies hier analysiert und begründet werden

+ Die Frage der Kompa-tibilität zu bestehen-den Systemen ist in der SyCIA zu klären. Ggf. müssen Anforde-rungen zur Kompatibi-lität aufgenommen werden.

+ Hier ist festzustellen, dass der Umfang der Änderung nur eine Hardwarekomponente (die Steckkarte) betrifft. Die Frage der Kompatibi-lität zu bestehenden Systemen ist in der SyCIA zu klären.

-

1 SyDP Entwicklungsplan Herstellerspezifisches Projektkonzept; klärt u.a. den Zusammenhang Zulas-sungsstrategie - Systemarchitektur - Entwicklungsmodelle (V-Modell)

- - - -

1 PrTL Projekt-Zeitplan Der Zeitplan sollte für generische Pro-dukte, generische Applikationen und spezifische Applikationen erstellt werden.

+ Zeit- und Ressourcen-planung für das Fehler-behebungsprojekt; soll gemäß den Vorgaben des SyMP erstellt wer-den

+ Zeit- und Ressour-cenplanung für das Änderungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden

+ Zeit- und Ressourcen-planung für das Ände-rungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden

+ Zeit- und Ressourcenpla-nung für das Pro-jekt/Änderungsprojekt; soll gemäß den Vorgaben des SyMP erstellt werden

1 PrDL Dokument-Übersicht Die Dokumentenübersicht sollte für gene-rische Produkte, generische Applikatio-nen und spezifische Applikationen erstellt werden.

+ + + +

1 PrG Glossar - - - -

1-2 SySP Sicherheitsplan Z SySMR wird als sinnvoll erachtet (da dort die Prüfungsergebnisse zum SySP stehen)

- - - -



2-10 SySMR Sicherheitsmanagementbe-richt

Z SySP wird als sinnvoll erachtet (als zu überprüfendes Dokument), 4-Augen-Prinzip im Falle eines externen Gutach-ters

+ Ergänzung + Ergänzung + Ergänzung -

1-2 SyQMP Qualitätssicherungsplan muss nach aktueller Praxis dem Gutach-ter vorgelegt werden

- - - -

2-10 SyQMR Qualitätsmanagementbericht Z SyQP wird als sinnvoll erachtet (als zu überprüfendes Dokument); enthält Er-gebnisse zur Anforderungsverfolgbarkeit - kann eigenständiges Dokument (Anf.verfolgbarkeitsmatrix) oder Teil des Berichtes sein, s. diverse Stellen in der DIN EN 50128:2012. 4-Augen-Prinzip im Falle eines externen Gutachters

+ Ergänzung + Ergänzung + Ergänzung -

2 SyPVR Planungsverifikationsbericht Verifiziert alle Pläne außer dem Validie-rungsplan. Heißt lt. DIN EN 50128:2012 (Software-) Qualitätssicherungsverifikati-onsbericht

+ Ergänzung des alten Berichts oder komplett neuer Bericht



-

1-2 SyCMP Konfigurationsmanagement-plan

- - - -

1-2 SyVeP Verifikationsplan Enthält den Software-Verifikationsplan. Die Aufgaben sind in der 50126 definiert, nicht das Dokument. Im aktuellen Ent-wurfsstand der neuen 50126-1 werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genau-ere Angaben zu geforderten Dokumenten macht

- - - -

1-2 SyVaP Validierungsplan Die Aufgaben sind in der 50126 definiert, nicht das Dokument. Im aktuellen Ent-wurfsstand der neuen 50126-1 werden Verifizierungs- und Validierungsaufgaben für jede Phase gesondert ausgewiesen. Es ist zu prüfen, ob die ISO 900x genau-ere Angaben zu geforderten Dokumenten macht

- - - -

1-2 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 ver-pflichtend. Definiert die Kriterien, Ar-beitsweise und den Arbeitsumfang der Prüfleitstelle/des Gutachters

- - - -

3 Risikoanalyse 3 SyHA Gefährdungs- und Risikoana-

lyse In Zukunft gemäß NTZ keine Prüfung durch EBA mehr? Unklar, ob die Revisi-on der 50129 (neue 50126) weiterhin Prüfung durch Aufsichtsbehörde fordert

- + - -



3 SyHL Gefahrenprotokoll gängiger Begriff ist "Gefährdungslog-buch". 4A-Prüfung im Falle eines exter-nen Gutachters

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

-

4 Systemanforderungen 4 SyRS System-

Anforderungsspezifikation Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN.

- + - -

4 SySRS System-Sicherheitsanforderungsspezi-fikation

Bei der Erstellung durch den AN erfolgt auch die Prüfung durch den AN. Sicher-heitskonzept 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 Sys-temanforderungen auch noch zusätzliche Test zur Gesamtsystemfunktionalität

- Test-Subset wird ggf. in Änderungsauswir-kungsanalyse ausge-wählt

+ - -

4 SyRVR System-Anforderungsverifikationsbe-richt

Falls obige Dokumente im Rahmen der Entwicklung (von AN) erstellt werden, müssen sie auch verifiziert werden; wenn SwRS und HwRS mit SyRS zusammen-gelegt, dann auch SwRVR und HwRVR mit SyRVR

- + - -

5 Systementwurf 5 SyAS System-

Architekturspezifikation in diesem Dokument können ggf. Sub-systeme 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)

- +/- Bei Änderungen von Schnittstellen (inner-halb des Systems und nach außen).

- -

5 SyDS System-Entwurfsspezifikation - + - -

5 SyADVR System-Architektur- und Ent-wurfsverifikationsbericht

- + - -

5-6 SwHwITP SW/HW-Integrationstestplan - + - -

6 Entwicklung/Konstruktion und Implementierung 6.1 Hardware 6.1.1 HW-Anforderungen 6 HwRS HW-Anforderungsspezifikation - + - -

6.1.2 HW-Entwurf 6 HwDS HW-Entwurfsspezifikation kann entfallen, wenn nur eine Kompo-

nente im System vorhanden - + - -

6 HwAS HW-Architekturspezifikation kann entfallen, wenn nur eine Kompo-nente im System vorhanden

- + - -

6 HwIS HW-Schnittstellenspezifikation kann entfallen, wenn nur eine Kompo-nente im System vorhanden

- + - -



6.1.3 HW-Komponentenentwurf 6 HwCDS HW-

Komponentenentwurfsspezifi-kation

- + + -

6 HwCFMEA HW-Komponenten-FMEA - + + -

6 HwCRC HW-Komponenten-Zuverlässigkeitsberechnungen

- + + -

6.1.4 HW-Fertigungsunterlagen 6 HwPD HW-Fertigungsunterlagen Layout, Stücklisten, Grundschaltungen,

etc. - + + -

6.1.5 HW-Komponententest 6 HwCTS HW-

Komponententestspezifikation - + + -

6 HwCTR HW-Komponententestbericht - + + -

6.1.6 HW Verifikationsbericht 6 HwVR HW-Verifikationsbericht Verifikationsbericht fasst alle Verifikati-

onsschritte für die HW zusammen. - + + -

6.2 Software 6.2.1 SW-Anforderungen 6 SwRS SW-Anforderungsspezifikation +/- Änderung nur, falls

Fehler die SW-Anforderungen betrifft

+ - -

6 SwOTS SW-Gesamttestspezifikation früher (50128:2003): SW-Anforderungstestspezifikation

+/- Änderung nur, falls Fehler die SW-Anforderungen betrifft

+ - -

6 SwRVR SW-Anforderungsverifikationsbe-richt

+/- Änderung nur, falls Fehler die SW-Anforderungen betrifft

+ - -

6.2.2 SW-Entwurf 6 SwAS SW-Architekturspezifikation s. Kommentar SyAS - +/- Bei Änderungen von

Schnittstellen (inner-halb des Systems und nach außen).

- -

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

+ - -



6 SwADVR SW-Architektur- und Ent-wurfsverifikationsbericht

+/- s. Kommentare SwDS und SwIS

+ - -

6 SwITP SW-Integrationstestplan - + - -

6.2.3 SW-Komponentenentwurf 6 SwCDS SW-

Komponentenentwurfsspezifi-kation


+/- Änderung nur, falls Fehler die SwCDS be-trifft

+ - -

6 SwCDVR SW-Komponentenentwurfsverifika-tionsbericht


+/- s. Kommentar SwCDS + - -

6.2.4 SW-Implementierung 6 SwSC SW-Quellcode und Hilfsdo-

kumentation Früher "Zusatzdokumentation" statt "Hilfsdokumentation"; zweite Prüfung gemäß DIN EN 50128:2012 Tabelle C.1 wird nicht immer als sinnvoll erachtet

+ + - -

6 SwSCVR SW-Quellcodeverifikationsbericht

+ + - -

6.2.5 SW-Komponententest 6 SwCTS SW-

Komponententestspezifikation Norm alt: Modul --> Norm neu: Kompo-nente

+ + - -

6 SwCTR SW-Komponententestbericht Der zugehörige Verifikationsbericht ist der SwCDVR

+ + - -

6.3 Integration 6 SwITS SW-

Integrationstestspezifikation +/- Änderung nur, falls

Fehler die SW-Schnittstellen betrifft

+ Prüfung existierender Komponenten nur falls die SyCIA die Not-wendigkeit ergibt.

- -

6 SwHwITS SW/HW-Integrationstestspezifikation

+/- Änderung nur, falls Fehler die SW/HW-Schnittstellen betrifft


- -

6 SwITR SW-Integrationstestbericht +/- Je nach Ergebnis der Änderungsauswir-kungsanalyse


+ -

6 SwHwITR SW/HW-Integrationstestbericht

+/- Je nach Ergebnis der Änderungsauswir-kungsanalyse


+ -



6 SyAPP Anwendungs-Generierungsplan

Dieser generische Plan beschreibt die Umsetzung in der spezifischen Anwen-dung (siehe DIN EN 50128:2012, Pkt. 8.4.1.2). Er entfällt lt. EBA-Tabellen bei generischer Software (nur bei anwend.-spezifisch konfigurierten Systemen); EBA-Vorlage zur Bauaufsichtl. Freiga-be/Abnahme Sb 3.

- - - -

6 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 - - - +

7 SyAAD Anwendungsarchitektur und -entwurf

In diesem Dokument geht es um das Kombinieren/Konfigurieren der generi-schen Anwendung zum Erhalt der spezi-fischen Anwendung (Modulwahl).

- - - -/+ entspricht im Normalfall der geprüften PT2; nur im Fall besonderer Kombinationen explizit zu erstellen.

7 SySCADA Quellcode der Anwendungs-daten-/Algorithmen

Z. B. Konfigurationsdateien. Zweite Prü-fung wird durch PT2-Prüfung abgedeckt. Mit "Prüfung durch EBA" ist hier das örtli-che EBA gemeint.

- + - +

7 SyAPVR Anwendungs-Generierungsverifikationsbe-richt

- + - +

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

+ Je nach Ergebnis der Auswirkungsanalyse sind für zu aktualisie-rende Anlagen die rele-vanten Teile der SyATS Regressionstests durchzuführen. Für neue Anlagen sind alle Teile der SyATS zu testen.

+ - +

7 SyRDP Freigabe- und Bereitstel-lungsplan

Kein explizites Dokument für den Ent-wicklungsprozess, wenn z.B. über QS- bzw. ISO 9001 abgedeckt

- - - -

7 SyADAVR Anwendungsdaten-/Algorithmen-Verifikationsbericht

- + - +

7 SyDM Bereitstellungshandbuch Kein explizites Dokument für den Ent-wicklungsprozess, wenn z.B. über QS- bzw. ISO 9001 abgedeckt

- - + -

7 SyRNs Freigabemitteilungen Kein explizites Dokument für den Ent-wicklungsprozess, wenn z.B. über QS- bzw. ISO 9001 abgedeckt

+ + + +

7 SyRN Freigabemitteilung Zusammenfassung der ausführlichen Freigabemitteilungen (Release Notes)

+ + + +



7 SyDR Bereitstellungsaufzeichnun-gen


+ + + +

7 SyDVR Bereitstellungs-Verifikationsbericht


+ + + +

8 Installation/Montage 8 SyPI Projektierungsrichtlinie Inhalte sehr firmenspezifisch: enthält

Anleitung zur Projektierung der Anlage, z. B. Anzahl Busteilnehmer, Kabelvorga-ben, Fahrstraßentabelle, …

- + Ergänzung. Enthält auch die Kompatibili-tätsliste (vgl. SyCIA).

+ -

8 SyM Bedienhandbuch - + - -

8 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 aktualisie-rende Systembestand-teile die relevanten Teile der SyTS Regres-sionstests durchzufüh-ren.

+ Je nach Ergebnis der Auswirkungsanalyse sind für zu aktualisie-rende Systembe-standteile die relevan-ten 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.

-

9 SyVaR System-Validationsbericht beinhaltet alle Elemente: Software, Hardware, integriertes System und Tools und Betrachtung von Aufla-gen/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üh-rung.

- - - -

9 SyTSR Technischer Sicherheitsbe-richt

In Zukunft gemäß NTZ keine Prüfung durch EBA mehr

+ Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein.

+ + mindestens Ergänzung eines Verweises auf die neue Steckkarte

-

9 SyRAMSD RAMS-Nachweis Manteldokument mit Referenzen auf alle RAMS-Dokumente


+ + Nur Anpassung der Refe-renzen; alternativ können Referenzen in der Frei-gabemitteilung enthalten sein.

-



9 SySC Sicherheitsnachweis In Zukunft gemäß NTZ keine Prüfung durch EBA mehr. Vorbereitung ab Phase 6.


+ + Nur Anpassung der Refe-renzen; alternativ können Referenzen in der Frei-gabemitteilung enthalten sein.

-

9 SASC Anwendungssicherheitsnach-weis

SASC=Specific Application Safety Case. In Deutschland ist eine Verwendung nicht bekannt. Kann ggf. im Ausland erforder-lich sein. Vorbereitungen laut alter 50126 ab Phase 6. An dieser Stelle wird nur die "Vorbereitung" des Dokumentes erwähnt; weitere Festlegungen fehlen jedoch.

- Nur Anpassung der Referenzen; alternativ können Referenzen in der Freigabemitteilung enthalten sein.

- - Nur Anpassung der Refe-renzen; alternativ können Referenzen in der Frei-gabemitteilung enthalten sein.

-/+

10 Abnahme 10 SyAR System-Gutachten Hierunter sind auch Gutachten zu ver-

stehen, die sich nur auf Software oder Hardware beziehen

+ + + + Für die spezifische Applika-tion kein Gutachten im CENELEC-Sinne, sondern Abnahmeniederschrift

10 SySAR Sicherheitsbewertungsbericht Gutachten zum CSM-VO Nachweisdo-kument 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 Gut-achten auf die spezifische Struktur des CSM-Prozesses einzugehen.

+ + + -

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

- +/- Abhängig von der Art der Erweiterung

- -/+ je nach Firmenprozess nur Start eines SyPR mit Instal-lation der ersten spezifi-schen Applikation

13 Änderung / Nachrüstung 13 SyRP Releaseplan Aufstellung der geplanten Erweiterungen

und Verbesserungen. Durch die CENELEC nicht offiziell gefordertes Do-kument!

- - - -

13 SyMP Wartungsplan Generischer Wartungsprozess (allgemei-ne Vorgehensweise). Für kleinere Hard-wareänderungen gibt es bereits verein-fachtes Verfahren (ohne EBA-Vorlage), Idee: ähnliches für SW? Beinhaltet auch die Release-Planung. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr.

- - + mindestens Ergänzung eines Verweises auf die neue Steckkarte

-



13 SyMR Änderungsbericht Änderungsbericht für jede Wartungsakti-vität. Nur für Änderungen, die keine Spe-zifikationsänderungen beinhalten - sonst nicht zwingend erforderlich. In Zukunft gemäß NTZ keine Prüfung durch EBA mehr.

+ Beinhaltet eine Auflis-tung aller geänderten Dokumente und Sys-tembestandtei-le/Artefakte

+ + -

13 SwMR SW-Wartungsaufzeichnungen + + - -

13 SwMVR SW Wartungsverifikationsbe-richt

+ + - -

14 Stilllegung / Entsorgung 9-14 SyDDN Stilllegungs- und Entsor-

gungshinweise - - +/- Je nachdem, ob neue

Bauteile dies erfordern -

Tabelle 4: Dokumentenliste für die vier in Tabelle 3 definierten Anwendungsfälle

Hinweis: Verifikationsberichte sind hellgrau markiert.



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 50128 und EN 50129 Anwendung finden sollen.

Dieses gemeinsame Verständnis ist in die in diesem Ergebnisbericht beschriebenen Arbeitsergeb-nisse in Form von CENELEC-konformen Dokumentenlisten eingegangen.

Damit wurde aus Sicht der beteiligten Projektpartner eine signifikante Verringerung der Interpreta-tionsspielräume der CENELEC-Normen erreicht.

Auf Basis der generischen Dokumentenliste aus dem Teilbericht „Vorarbeiten und Unterarbeitspa-ket 2200.3“ (NeGSt_Teilbericht_2200.0u3_1.0.pdf) wurden Ausprägungen von Dokumentenlisten für die spezifischen Anwendungsfälle ‚SW-Fehlerbehebung‘, ‚Systemerweiterung‘, ‚Weiterentwick-lung einer HW-Steckkarte (als HW-Komponente)‘ und ‚Neue spezifische Applikation‘ für SIL 4 er-stellt.

Mit dem Erstellen der Ausprägungen von Dokumentenlisten für die ‚Best Practices‘ wurde gleichzei-tig die generische Dokumentenliste auf ihre Anwendbarkeit für verschiedene praktische Anwen-dungsfä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.

Schlussbericht

Anhang zu AP 2000 – Optimierung des Zulassungsprozesses

Anhang 2.4:

Teilberichte der Arbeitsgruppe 5 „Umgang mit Komponen-ten nach IEC 61508 (COTS) / Hybriden“

1. Vergleich der Zulassungsbedingungen IEC 61508 – 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



Teilbericht

AP 2300

Vergleich der Zulassungsbedingungen IEC 61508 – CENELEC

06.08.2013

Laufzeit: 01.09.2011 – 31.08.2013



Version 1.0 Seite 2 von 31


Datum Bearbeiter Version Inhalt 07.05.2013 Schaefer (Funkwerk

AG) 0.1 Dokumentenstruktur

05.06.2013 Schaefer (Funkwerk AG)

0.2 Beurteilung der vorliegenden Argumentation; An-satz für Normenvergleich; Reviewergebnisse


0.3 Allgemeine Anforderungen


0.4 System und Hardware


0.5 Erstellung


0.6 Vergleich des Sicherheitsnachweises; Ausblick und Zusammenfassung umformuliert

15.07.2013 Möller-Neustock 0.7 Übernahmen Sicht aus Ergebnisbericht 06.08.2013 Holger Neustock

Klaus-Dieter Winkler 1.0 Finalisierung

Inhaltsverzeichnis

1 Einleitung.........................................................................................................................................4

2 Vergleich der Zulassungsbedingungen IEC 61508 – CENELEC ...............................................5

2.1 Beurteilung der vorliegenden Argumentation.........................................................................5

2.1.1 These...................................................................................................................................5

2.1.2 Argumentationskette...........................................................................................................5

2.1.3 Beurteilung der Argumente ................................................................................................7

2.1.4 Ergebnis ..............................................................................................................................9

2.2 Normenvergleich ........................................................................................................................9

2.2.1 Allgemeine Anforderungen ................................................................................................9

2.2.2 System und Hardware.......................................................................................................17

2.2.3 Software............................................................................................................................22

2.2.4 Sicherheitsnachweis..........................................................................................................28

3 Ausblick und Zusammenfassung .................................................................................................30

3.1 Ziele und Schwerpunkte des Berichts ....................................................................................30

3.2 Allgemeine Anforderungen .....................................................................................................30

3.2.1 Lebenszyklen ....................................................................................................................30

3.2.2 Dokumentation, Management und RAMS .......................................................................30

3.3 System und Hardware .............................................................................................................30

3.4 Software ....................................................................................................................................30

4 Anhang ...........................................................................................................................................31

4.1 Anhang 1: Referenzen .............................................................................................................31

4.2 Anhang 2: Abkürzungen .........................................................................................................31

Tabellenverzeichnis

Tabelle 1: SIL-Klassen in EN 50129........................................................................................................ 8

Tabelle 2: SIL-Klassen in IEC 61508 ...................................................................................................... 9



Tabelle 3: Themenauswahl für den Anwendungsbereich....................................................................... 10

Tabelle 4: Auswahl von Fachbegriffen .................................................................................................. 11

Tabelle 5: Vergleich der Lebenszyklus-Phasen ..................................................................................... 12

Tabelle 6: Vergleich der Konzept-Anforderungen................................................................................. 12

Tabelle 7: Vergleich der Anforderungen zur Definition des gesamten Geltungsbereiches ................... 12

Tabelle 8: Vergleich der Gefahren- und Risikoanalyse.......................................................................... 13

Tabelle 9: Vergleich der Anforderungen an die gesamte Sicherheit...................................................... 13

Tabelle 10: Vergleich der Zuordnung der Sicherheitsbedingungen....................................................... 14

Tabelle 11: Vergleich der Entwicklung, Konstruktion, Implementierung und Fertigung...................... 15

Tabelle 12: Vergleich der Installation und Inbetriebsetzung insgesamt................................................. 15

Tabelle 13: Vergleich der Validierung der gesamten Sicherheit............................................................ 15

Tabelle 14: Vergleich des Betriebs und der Instandhaltung................................................................... 16

Tabelle 15: Vergleich von Lebenszyklus ............................................................................................... 16

Tabelle 16: Vergleich von Lebenszyklus ............................................................................................... 16

Tabelle 17: Vergleich von Software....................................................................................................... 23

Tabelle 18: Vergleich der Software........................................................................................................ 24







Tabelle 25: Vergleich des Inhalts des Sicherheitsnachweises................................................................ 29


Einleitung


1 Einleitung

Elektronische Stellwerke sind weltweit ab etwa Mitte der 80er Jahre im Einsatz. In Deutschland wur-den 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 elektri-sche 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 Erwartungshal-tung war, dass durch den Einsatz von Elektronik die Stellwerke baulich kleiner und vor allem kosten-gü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 standar-disieren. Sie sind Fachnormen zur übergeordneten IEC 61508 (im Weiteren als IEC bezeichnet), „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektroni-scher 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 Chemiein-dustrie 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 Prozessberei-chen von herausragender Bedeutung ist, wurde zur Standardisierung der Bewertung und Zulassung die IEC 61508 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 Anwendungsbe-reich 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.




2 Vergleich der Zulassungsbedingungen IEC 61508 – CENELEC

Zulassungen nach IEC 61508 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 Sicherheits-niveaus 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 Zulas-sung 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 Sicher-heit zu argumentieren.

Inhalt dieses Dokuments ist eine Gegenüberstellung der Zulassungsbedingungen für die Normen

• IEC 61508 [IN] (im Folgenden kurz: „Industrienorm“)

und

• IEC 50126 [BN6], 50128 [BN8] und 50129 [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.

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

2.1.2 Argumentationskette

1. In einem Schaubild werden die Bahnnormen EN 50126, 50128, 50129 als Spezialisierung der Fachgrundnorm IEC 61508 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 Ab-bildung der Sicherheitsstufen der Industrienorm auf die Sicherheitsstufen der Bahnnorm ange-geben.




4. Es werden Kategorien aufgelistet, für die Unterschiede zwischen den Normen betrachtet wer-den 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 Unab-hä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 Sin-ne 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 be-handelt.

12. Zum Diagnoseabdeckungsgrad (Fehleroffenbarungswahrscheinlichkeit durch Diagnosetests) finden sich nur in der Industrienorm ausreichende Informationen. Dies wird als größter Unter-schied zwischen den Normen EN 50129 und IEC 61508 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 Diagnose-maß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 bahn-technische 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 61508

b. Zertifizierung nach IEC 62061 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.




2.1.3 Beurteilung der Argumente

2.1.3.1 Spezialisierungshierarchie

Die Abbildung für Argument 1 vermittelt einen anschaulichen Überblick, über die Entwicklungsge-schichte 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 Grund-norm 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 Rich-tung 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.

2.1.3.2 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 wer-den.

2.1.3.3 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 ei-nen Vergleich der Normen geeignet zu sein und motivierten auch die Struktur des Vergleichs in Kapi-tel 2.2. Softwareaspekte und Risikoanalyse werden in der Präsentation nicht betrachtet.

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

2.1.3.5 Kommunikationsanforderungen

Der verwendete Farbcode legt nahe, dass sich die Kommunikationsanforderungen der Normen ent-sprechen sollen. Inhaltlich wird aber kein Argument angegeben. Eine erfolgreiche Argumentation würde aber die Kernthese stützen.

2.1.3.6 Sicherheitsmanagement

Beim Sicherheitsmanagement werden zwei Unterschiede identifiziert:

1. Die Bahnnorm fordert einen expliziten Sicherheitsnachweis, der bei der Industrienorm ledig-lich „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 Pra-xis“.

Obwohl die Unterschiede durch den „impliziten“ Sicherheitsnachweis und die „geübte Praxis“ einge-schrä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.




2.1.3.7 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 darge-stellten Spezialisierungshierarchie (vgl. 2.1.3.1).

2.1.3.8 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 „Sicher-heitsabstand“, 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.

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

2.1.3.10 Abstufung der Sicherheitsniveaus im Vergleich

Dieses Kapitel beschreibt vergleichend die Einstufungen der Sicherheitsniveaus beider Normen.

Tabelle 1: SIL-Klassen in EN 50129




Tabelle 2: SIL-Klassen in IEC 61508

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ückzu-führen.

2.1.4 Ergebnis

Das Ergebnis fasst die Argumente noch einmal zusammen und ist zur bisherigen Argumentation kon-sistent. 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 Vorge-hen nachweisen.

Bei einer Neuentwicklung kann das nachfolgende Kapitel nützliche Hinweise geben, welche Anforde-rungen 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. 2.1.2) ausgenutzt.

2.2.1 Allgemeine Anforderungen

Hier werden im Wesentlichen die Bedingungen der Industrienorm IEC 61508-1 mit den Bedingungen der Bahnnorm EN 50126 verglichen. An den Stellen, an denen die Bereiche von IEC 61508-1 bzw. EN 50126 verlassen werden, wird dies ausdrücklich angegeben.

2.2.1.1 Anwendungsbereich

Die folgende Tabelle beschreibt ausgewählte Themen aus dem Teil der Normen, die den Anwen-dungsbereich beschreiben.

Thema Industrienorm Bahnnorm Domäne Sicherheit Zuverlässigkeit, Verfügbarkeit, Instand-

haltbarkeit, Sicherheit (RAMS) Spezialisierungs-beziehung

Ein wichtiges Ziel ist es, die Erstellung sektorspezifischer Normen zu ermögli-chen.

Erklärt keine Spezialisierungsbeziehung

Technik Elektrische / elektronische / program-mierbare, elektronische Systeme

Keine explizite Einschränkung




Thema Industrienorm Bahnnorm Systematik Allgemeines Sicherheits-Lebenszyklus-

Modell Prozess auf Grundlage des System-Lebenszyklusses zwecks RAMS-Management

Abgrenzung der Angriffssicherheit zur Betriebssi-cherheit

Deckt keine vorbeugenden Maßnahmen ab, um Schaden oder sonstigen nachteili-gen Einfluss auf die funktionale Sicher-heit durch unbefugte Personen zu ver-hindern.

Spezifiziert keine Anforderungen für die Sicherheit im Sinne des Wachschutzes (Se-curity).

Tabelle 3: Themenauswahl für den Anwendungsbereich

2.2.1.1.1 Domäne

Obwohl sich beide Normenwerke auf die Betriebssicherheit konzentrieren, gibt es bzgl. der betrachte-ten 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. Al-lein daran ist zu erkennen, dass die Anforderungen der Industrienorm nicht hinreichend für die Bahn-norm sein können.

2.2.1.1.2 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 Eigen-stä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.

2.2.1.1.3 Systematik

Da beide Normenwerke eine ähnliche Systematik verwenden (Lebenszyklus-Modell) findet man hier einen Ansatz für einen weiteren Vergleich, der auch in Abschnitt 2.2.1.3 verfolgt wird.

2.2.1.2 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 61508-1. Auch sind bestimmte Definitionen der EN 50126 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 Begriffsdefi-nitionen in verschiedenen Teilen der Norm verwendet.

Begriff Industrienorm Bahnnorm Gefahr Potentielle Quelle für eine direkte oder

indirekte (als Folge eines Umweltscha-dens) physische Verletzung oder einen Gesundheitsschaden an einer Person.

Eine physikalische Situation, die potentiell einen Schaden für den Menschen beinhaltet.

Risiko Kombination der Wahrscheinlichkeit eines Schadens und der Schwere dieses Schadens

Die Wahrscheinlichkeit des Auftretens einer Gefahr, die einen Schaden verursacht, sowie der Schweregrad des Schadens

Safety Integrity Wahrscheinlichkeit, dass ein sicherheits-bezogenes System die geforderten Si-cherheitsfunktionen unter allen festgeleg-ten Bedingungen innerhalb einer be-stimmten Zeitspanne erfüllt.

Die Wahrscheinlichkeit dafür, dass ein Sys-tem die festgelegten Sicherheitsanforderun-gen unter allen festgelegten Bedingungen innerhalb einer bestimmten Zeitspanne er-füllt.

Sicherheit Freiheit von unvertretbaren Risiken Das Nichtvorhandensein eines unzulässigen Schadensrisikos




Begriff Industrienorm Bahnnorm Sicherheits-Lebenszyklus (Systemlebens-zyklus)

Notwendige Aktivitäten bei der Imple-mentation sicherheitsbezogener Systeme während einer Zeitspanne, die mit der Konzeptphase eines Projekts beginnt und endet, wenn alle E/E/PE sicherheitsbezo-genen Systeme, sonstige sicherheitsbe-zogener Systeme anderer Technologie und externe Einrichtungen zur Risiko-minderung nicht mehr für den Gebrauch zur Verfügung stehen.

Die Aktivitäten während einer Zeitspanne, die mit der Konzipierung des Systems be-ginnt und mit seiner Stilllegung, wenn das System nicht länger für den Gebrauch ver-fügbar ist, endet.

System (Produkt) Menge von Elementen, welche gemäß einem Entwurf interagieren. Elemente können hierbei wiederum Systeme (Sub-systeme) sein. Sie können kontrollieren-de oder kontrollierte Systeme sein und können Hardware, Software und mensch-liche Interaktionen beinhalten.

Menge von Elementen, die in einer zur Er-füllung der spezifischen Anforderung geeig-neten Art und Weise zu einem System, Sub-system oder Bestandteil einer Einrichtung zusammengeschaltet sind. In dieser Europäi-schen Norm (EN 50128) kann ein Produkt als ausschließlich aus Software oder Doku-menten aufgebaut angesehen werden1.

Validierung Nachweis, dass das sicherheitsgerichtete System alle spezifizierten Sicherheitsan-forderungen erfüllt2.

Analyse und Testen zur Demonstration, dass das Produkt in allen Belangen seine spezifi-zierten Anforderungen erfüllt3.

Verifikation Nachweis, dass für jede Phase des be-stimmten Sicherheits-Lebenszyklus, die aus bestimmten Eingaben abgeleiteten Lieferungen, alle Vorgaben und Anfor-derungen dieser spezielle Phase erfüllen2.

Analyse und Testen, um festzustellen, ob das Ausgangsprodukt jeder Phase des Lebens-zyklus die Anforderungen aus der vorherigen Phase erfüllt3.

Vertretbares Risi-ko

Das in einem bestimmten Kontext akzep-tierte Risiko auf der Grundlage der Wer-te einer Gesellschaft

Der maximale Grad an Risiko durch ein Produkt, der für ein Bahnunternehmen tole-riert werden kann

Tabelle 4: Auswahl von Fachbegriffen

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.

2.2.1.3 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 insge-samt 7: Planung der Validierung der gesamten Sicherheit 8: Planung der gesamten Installation und Inbetrieb-setzung 9: Sicherheitsbezogene Systeme: E/E/PES – Reali-sierung 10: Sicherheitsbezogene Systeme: andere Technolo-gien – Realisierung 11: Externe Einrichtungen zur Risikominderung –

6: Entwicklung/Konstruktion und Implementierung 7: Fertigung

1 ) Mangels Definition in EN 50126 wurde der Begriff anhand der Definition „Produkt“ in EN 50128 hergeleitet.

2 ) Berücksichtigt auch die Anmerkungen zur Definition, welche die Begriffsbestimmung verbessern und präzisieren.

3 ) Da die Definitionen aus EN 50126 unbrauchbar sind, werden hier die Definitionen aus EN 50128 verwendet.




Industrienorm Bahnnorm Realisierung 12: Installation und Inbetriebsetzung insgesamt 8: Installation/Montage

9: System-Validierung 13: Validierung der gesamten Sicherheit 10: Systemabnahme 11: Betrieb und Instandhaltung 14: Betrieb, Instandhaltung und Wartung insgesamt 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 ver-gleichen. 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.

2.2.1.3.1 Konzept

Industrienorm Bahnnorm 7.2.2.1 Eingehende Vertrautheit mit den kontrollier-ten Geräten und ihrer physikalischen Umgebung 7.2.2.2 Mutmaßliche Gefahrenquellen 7.2.2.3 Informationen über identifizierte Gefahren

6.1.3.1 Vorstellung vom Zweck des Systems, seiner Umgebung und seinen allgemeinen RAMS-Auswirkungen

6.1.3.2 RAMS-Auswirkungen 7.2.2.4 Informationen über aktuelle Sicherheitsbe-stimmungen 6.1.3.4 RAMS-Anforderungen ähnlicher Systeme,

Sicherheitsgesetzgebung und -politik 7.2.2.5 Gefahren aufgrund von Wechselwirkungen mit anderen kontrollierten Geräten

6.1.3.3 Gefahrenquellen für RAMS-Performance

7.2.2.6 Dokumentation 6.1.4.1 Ergebnisse

Tabelle 6: Vergleich der Konzept-Anforderungen

Aus Tabelle 6 ist ersichtlich, dass sich die Anforderungen der Konzeptphase durchaus einander zuord-nen 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 2.2.1.1.1 angemerkt sind die Anforderungen der Industrienorm daher nicht hinreichend für die Bahnnorm.

2.2.1.3.2 Definition des gesamten Geltungsbereiches

Industrienorm Bahnnorm 6.2.3.1.a Festlegung des Betriebsaufgaben-Profils 7.3.1.1 Spezifikation der materiellen Ausrüstung 6.2.3.1.c Festlegung des Umfangs der Anwendungs-bedingungen

7.3.2.2 Spezifikation externer Ereignisse 6.2.3.1.b Festlegung der Systemgrenzen 7.3.2.3 Spezifikation gefährdeter Subsysteme 7.3.2.4 Spezifikation von Störfalltypen

6.2.3.1.d Festlegung des Umfangs der Gefahrenanaly-se 6.2.3.2.b Vorläufige Gefahrenanalyse 6.2.3.2.a Vorläufige RAM-Analyse 6.2.3.3 RAMS-Politik

6.2.3.4 Erstellung des Sicherheitsplans 7.3.2.5 Dokumentation 6.2.4.1 Ergebnisse (6.2.4.2 – 6.2.4.4 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 Industrie-norm 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 Zuord-nungen finden.




2.2.1.3.3 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 Bahnnorm 7.4.2.1 Gefahren- und Risikoanalyse durchführen 7.4.2.3 Bestimmung von vorhersehbaren Gefahren und gefährlichen Ereignissen

N6.6.3.3.1.a Erkennen von vorhersehbaren Gefahren N8.5.2.4 Zu berücksichtigende Risiken

7.4.2.2 Beseitigung von Gefahren erwägen 7.4.2.4 Bestimmung von Ereignisketten für gefährli-chen Ereignisse

N6.6.3.3.1.b Identifikation von Abläufen, die Gefähr-dungen bergen

7.4.2.5 Spezifikation der Wahrscheinlichkeit gefähr-licher Ereignisse

N6.6.3.3.1.c Ermittlung der Häufigkeit des Eintretens von Gefahren

7.4.2.6 Bestimmung möglicher Auswirkungen ge-fährlicher Ereignisse

N6.6.3.3.1.d Ermittlung des Ausmaßes der Auswir-kungen von Gefahren N6.6.3.3.1.e Ermittlung des Systemrisikos für jede Gefahr

7.4.2.7 Risikoberechnung oder -abschätzung für jedes gefährliche Ereignis

N6.6.3.3.2 Festlegung und Klassifizierung von Risi-ken

(7.4.2.8 Durchführungshinweis) 7.4.2.9 Angemessenheit der Techniken 7.4.2.10 Inhalt der Gefahren- und Risikoanalyse 7.4.2.12 Pflege der Gefahren- und Risikoanalyse

N6.6.3.3.3 Erstellung des Gefahrenprotokolls

7.4.2.11 Dokumentation N6.6.3.4 Ergebnisse

Tabelle 8: Vergleich der Gefahren- und Risikoanalyse

Die Anforderungen dieser Phase lassen sich, wie in Tabelle 8 beschrieben, einander zuordnen und sind vergleichbar.

2.2.1.3.4 Anforderungen an die gesamte Sicherheit

Industrienorm Bahnnorm 7.5.2.1 Spezifikation der Sicherheitsfunktionen 6.4.3.1 Festlegung der RAMS-Anforderungen 6.4.3.2 Übergreifende Anforderungen für Erfüllung 6.4.3.3 RAM-Programm 6.4.3.4 Ergänzung Sicherheitsplan 7.5.2.2. Bestimmung der Risikominderung 7.5.2.3 Verwendung Internationaler Standards zur Risikominderung 7.5.2.4 Nicht sicherheitsbezogene Kontrollsysteme (7.5.2.5 Wiederholung)

7.5.2.6 Spezifikation der Anforderungen zur Sicher-heitsintegrität

6.4.3.1 Festlegung der RAMS-Anforderungen

(7.5.2.7 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 Übergrei-fenden Anforderungen oder Anforderungen an einen Sicherheitsplan. Erwartungsgemäß, finden sich in der Industrienorm auch keine Angaben zu einem RAM-Programm.

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




Industrienorm Bahnnorm N6.6.5.3.1.a Zuordnung der funktionalen Anforderun-gen

7.6.2.1 Spezifikation der sicherheitsbezogenen Sys-teme

N6.6.5.3.1.c Spezifizierung der Subsysteme, Kompo-nenten und externen Einrichtungen

7.6.2.2 Prüfung von Fähigkeiten und Ressourcen 7.6.2.3 Verteilung von Sicherheitsfunktionen auf sicherheitsbezogene Systeme

N6.6.5.3.1.b Zuordnung der Sicherheitsanforderungen

N6.6.5.3.1.d Aktualisierung des RAM-Programms 7.6.2.4 Vollständigkeit der Verteilung und Konsis-tenz mit den Anforderungen zur Sicherheitsintegrität

N6.6.5.3.3 Überprüfung und Aktualisierung des Si-cherheits- und Validierungsplans

N6.6.5.3.2 Bedingungen für Übereinstimmung der Anforderungen

7.6.2.5 Betriebsweise für die Anforderungen zur Sicherheitsintegrität festlegen 7.6.2.6 Verteilung unter Benutzung geeigneter Tech-niken zur Kombination von Wahrscheinlichkeiten 7.6.2.7 Verteilung berücksichtigt mögliche Fehler mit gemeinsamer Ursache 7.6.2.8 Unabhängigkeit E/E/PE, andere Sicherheits-technologien, externe Einrichtungen zur Risikomin-derung

N8.5.2.2 Festlegung der Software-Sicherheits-anforderungsstufe N8.5.2.3 Mindest-Software-Sicherheits-anforderungsstufe N8.5.2.5 Software-Sicherheitsanforderungsstufen

7.6.2.9 Zuweisung von Sicherheitsanforderungsstu-fen (SIL) an Sicherheitsfunktionen

N8.5.2.6 Dokumentation der Software-Sicherheits-anforderungsstufe

7.6.2.10 Systeme mit Sicherheitsfunktionen ver-schiedener Sicherheitsanforderungsstufen 7.6.2.11 Architekturen einzelner, sicherheitsbezoge-ner E/E/PES Systeme 7.6.2.12 Maximale Sicherheitsanforderungsstufe für einzelne, sicherheitsbezogene E/E/PE Systeme

7.6.2.13 Dokumentation N6.6.5.4 Ergebnisse

Tabelle 10: Vergleich der Zuordnung der Sicherheitsbedingungen

Im Gegensatz zur Industrienorm beschreibt die Bahnnorm in dieser Phase keine Zuordnung von Si-cherheitsanforderungsstufen. Safety Integrity wird hier als RAMS-Konzept beschrieben welches kei-ner bestimmten Lebenszyklusphase zugeordnet ist.

2.2.1.3.6 Entwicklung, Konstruktion, Implementierung und Fertigung

Industrienorm Bahnnorm 7.7.2.1 Erstellung des Wartungsplans 7.7.2.2 Wartungsaktivitäten zur Offenbarung unent-deckter Fehler 7.7.2.3 Bestätigung des Wartungsplans durch das Wartungspersonal 7.8.2.1 Erstellung eines Validierungsplans 7.9.2.1 Erstellung eines Installationsplans 7.9.2.2 Erstellung eines Inbetriebsetzungsplans

6.6.3.3 Planung nachfolgender Lebenszyklusaufgaben 6.7.3.2 Unterstützende Maßnahmen für Subsysteme und Komponenten 6.7.3.3.a Planung einer Fertigung 6.7.3.3.c Einführung einer RAMS-Prozess-Sicherung

7.8.2.2 Dokumentation 7.9.2.3 Dokumentation

6.6.4 Ergebnisse

6.6.3.1 Entwicklung/Konstruktion der Subsysteme und Komponenten

7.10.2 Realisierung E/E/PES: siehe 2.2.2 und 2.2.3

6.6.3.2 Realisierung der Subsysteme und Komponen-ten




Industrienorm Bahnnorm 6.6.3.4 Definition, Verifikation und Erstellung eines Produktionsverfahrens 6.7.3.1 Verifikation und Implementierung des Ferti-gungsprozesses 6.7.3.3.b Einführung einer Fertigung

7.11.2 Realisierung anderer Technologien: nicht im Anwendungsbereich der Industrienorm 7.12.2 Realisierung externer Einrichtungen zur Risi-kominderung: nicht im Anwendungsbereich der Industrienorm

6.6.3.5.a Erstellung System-Sicherheitsnachweis 6.6.3.5.b Vorbereitung eines Anwendungssicherheits-nachweises (vgl. auch 6.9.3.3)

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 7.10.2 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 50128 und EN 50129 verzichtet. Die Teile der Bahnnorm grenzen sich damit stärker, auch gegeneinander ab.

2.2.1.3.7 Installation und Inbetriebsetzung insgesamt

Industrienorm Bahnnorm 7.13.2.1 Verwendung des Installationsplans 7.13.2.3 Verwendung des Inbetriebsetzungsplans

6.8.3.1 Zusammenbau und Montage

7.13.2.2 Umfang der Installationsdokumentation 7.13.2.4 Umfang der Inbetriebsetzungsdokumenta-tion

6.8.3.2 Dokumentation des Montageprozesses

6.8.3.3 Überprüfung und Anpassung des Sicherheits-plans

6.8.3.4 Schulung, Arbeitsanweisungen, Lagerhaltung

Tabelle 12: Vergleich der Installation und Inbetriebsetzung insgesamt

In dieser Phase finden sich für die Überprüfung des Sicherheitsplans, sowie für Schulung, Arbeitsan-weisungen und Lagerhaltung keine Entsprechungen in der Industrienorm.

2.2.1.3.8 Validierung der gesamten Sicherheit

Industrienorm Bahnnorm 6.9.3.1 Validierung gemäß Validierungsplan 7.14.2.1 Verwendung des Validierungsplans 6.9.3.2 Inbetriebsetzung/Betriebserprobung 6.9.3.3 Vorbereitung eines Anwendungssicherheits-nachweises (vgl. auch 6.6.3.5.b)

6.9.3.4 Verfahren zur Ermittlung von Felddaten 7.14.2.2 Kalibrierung von Werkzeugen für Messun-gen

7.14.2.3 Dokumentation der Validierung 6.9.4 Ergebnisse 7.14.2.4 Dokumentation der Maßnahmen bei Abwei-chungen

Tabelle 13: Vergleich der Validierung der gesamten Sicherheit

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.




2.2.1.3.9 Betrieb und Instandhaltung

Industrienorm Bahnnorm 7.15.2.1 Umsetzung des Wartungsplans und von Wartungsroutinen für Systeme und Software 7.15.2.2 Umsetzung eines Wartungsaktivitätsmodells

6.11.3.1 Überwachung von Systemausführung, sowie von Betriebs- und Instandhaltungsverfahren 6.11.3.2.a Regelmäßige Überprüfung und Anpassung der Betriebs- und Instandhaltungsverfahren

7.15.2.3 Chronologische Dokumentation von Be-trieb, Wartung und Reparatur

6.11.3.2.b Regelmäßige Überprüfung der Schulungs-dokumentation 6.11.3.2.e Einsatz des FRACAS-Systems für die Aus-fallerfassung und Korrekturmaßnahmen 6.11.3.2.c Regelmäßige Überprüfung und Anpassung des Gefahrenprotokolls und des Sicherheitsnachweises

6.11.3.2.d Wirksame logistische Unterstützung 7.15.2.4 (Verweis auf sektorspezifische Normen) 6.12.3.1 Leistungserfüllung, RAMS-Statistik und

Überprüfung des Sicherheitsnachweises 6.12.3.2 Analyse von Leistungserfüllung und RAMS-

Daten

Tabelle 14: Vergleich des Betriebs und der Instandhaltung

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 vorge-nommen werden.

2.2.1.3.10 Abänderung und Nachrüstung

Industrienorm Bahnnorm 7.16.2.1 Planung von Änderungen und Nachrüstun-gen

6.13.3.1 Erstellung eines Sicherheitsplans

7.16.2.2 Auslösung durch formale Problemmeldun-gen 7.16.2.3 Durchführung einer Auswirkungsanalyse 7.16.2.4 Dokumentation der Auswirkungsanalyse 7.16.2.5 Berücksichtigung der Auswirkungsanalyse 7.16.2.6 Wiederholung geeigneter Lebenszykluspha-sen

6.13.3.2 Prozess für die Lenkung von Änderungen

7.16.2.7 Chronologische Dokumentation 6.13.4 Ergebnisse

Tabelle 15: Vergleich von Lebenszyklus

Die Anforderungen in der Industrienorm sind hier etwas detaillierter, passen aber zu den Anforderun-gen aus der Bahnnorm.

2.2.1.3.11 Stilllegung und Entsorgung

Industrienorm Bahnnorm 7.17.2.1 Durchführung einer Auswirkungsanalyse 7.17.2.2 Dokumentation der Auswirkungsanalyse 7.17.2.4 Berücksichtigung der Auswirkungsanalyse

6.14.3.1.a Feststellen der Auswirkungen der Stillle-gung und Entsorgung

7.17.2.3 Auslösung durch Prozedur zum Manage-ment der funktionalen Sicherheit

7.17.2.5 Vorbereitung eines Stilllegung- und Zerle-gungsplans 7.17.2.6 Wiederholung geeigneter Lebenszykluspha-sen

6.14.3.1.b Planung der Stilllegung

6.14.3.2 Erstellung der Analyse der RAMS-Lebenszyklus-Leistungsfähigkeit

7.16.2.7 Chronologische Dokumentation 6.14.4 Ergebnisse

Tabelle 16: Vergleich von Lebenszyklus

Bis auf die RAM-Analyse können hier wieder Anforderungszuordnungen gefunden werden.




2.2.1.4 Dokumentation und Management

Anforderungen zur Dokumentation und zum Management befinden sich in der Bahnnorm EN 50128. 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 2.2.3.1 statt.

2.2.1.5 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 Indust-rienorm zuzuordnen. Die eher beschreibende Form und das Fehlen expliziter Anforderungen erschwe-ren jedoch einen systematischen Zugang, so dass ein Zuordnungsversuch hier nicht vorgenommen wird.

2.2.2 System und Hardware

Hier werden im Wesentlichen die Bedingungen der Industrienorm IEC 61508-2 mit den Bedingungen der Bahnnorm EN 50129 verglichen. Das Fehlen von expliziten Anforderungen oder ähnlich detail-lierter Strukturmerkmalen in der Bahnnorm erschwert hier (wie bereits in 2.2.1.5) 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.

2.2.2.1 Nachweis des Qualitätsmanagements

• 7.4.4.1 Einsatz von Techniken und Maßnahmen zur Vermeidung von Fehlern beim Design und bei der Entwicklung von Hardware

• 7.4.4.2 Eigenschaften der Design-Methode

• 7.4.4.3 Formalisierung von Wartungsanforderungen

• 7.4.4.4 Verwendung automatischer Testwerkzeuge und integrierter Entwicklungsumgebungen

• 7.4.4.5 Planung von E/E/PES Integrationstests

• 7.4.4.6 Unterscheidung von Aktivitäten, die im Werk oder beim Kunden durchgeführt werden

• 7.4.5.1 Entwurfseigenschaften zur Kontrolle systematischer Fehler

• 7.4.5.2 Berücksichtigung von Wartbarkeit und Testbarkeit beim Entwurf und bei der Entwick-lung

• 7.4.5.3 Benutzerfreundliche Schnittstellengestaltung

2.2.2.2 Nachweis des Sicherheitsmanagements

2.2.2.2.1 Sicherheitslebenszyklus

• 7.1.3.1 Verwendeter Sicherheitslebenszyklus

• 7.1.3.2 Parallele Ausführung der Verfahren zum Management der funktionalen Sicherheit

• 7.1.3.3 Aufteilung der Phasen in Aktivitäten




• 7.1.3.4 Dokumentation der Ausgaben von Phasen

• 7.1.3.5 Anforderungen für Ausgaben von Phasen

2.2.2.2.2 Sicherheitsorganisation

2.2.2.2.3 Sicherheitsplan

2.2.2.2.4 Gefährdungslogbuch

2.2.2.2.5 Sicherheitsanforderungsspezifikation

• 7.2.2.1 Ableitung von E/E/PES Sicherheitsanforderungen

• 7.2.2.2 Qualitative Anforderungen an Ausdruck und Struktur von E/E/PES Sicherheitsanforde-rungen

• 7.2.2.3 Anforderungen für E/E/PES Sicherheitsfunktionen und für die E/E/PES Sicherheitsin-tegrität sind E/E/PES Sicherheitsanforderungen

• 7.2.3.1.a Beschreibung aller notwendigen Sicherheitsfunktionen

• 7.2.3.1.b Mengendurchsatz und Antwortverhalten

• 7.2.3.1.c System- und Betreiberschnittstellen

• 7.2.3.1.d Relevante Informationen zur funktionalen Sicherheit mit Auswirkungen auf das Sys-temdesign

• 7.2.3.1.e Alle Schnittstellen zwischen E/E/PES sicherheitsgerichteten Systemen und Um-systemen

• 7.2.3.1.f Alle Relevanten Betriebsmodi der kontrollierten Geräte

• 7.2.3.1.g Alle notwendigen Verhaltensmodi von E/E/PES sicherheitsgerichteten Systemen

• 7.2.3.1.h Bedeutung aller Hardware/Software Interaktionen

• 7.2.3.1.i Grenzen und Bedingungen für E/E/PES sicherheitsgerichtete Systeme

• 7.2.3.1.j Spezifische Anforderungen zu Start- und Wiederanlaufverfahren

• 7.2.3.2.a Sicherheitsanforderungsstufe (SIL) für Sicherheitsfunktionen

• 7.2.3.2.b Betriebsmodus für Sicherheitsfunktionen

• 7.2.3.2.c Prüfvoraussetzungen

• 7.2.3.3 Maßnahmen zur Vermeidung von Fehlern bei der Spezifikation der Sicherheitsanfor-derungen

• 7.4.3.2 Anforderungen zum Abschätzen der Wahrscheinlichkeit eines Versagens von Sicher-heitsfunktionen aufgrund von Hardwarefehlern

2.2.2.2.6 System-/Teilsystem-/Einrichtungs-Entwurf

• 7.4.2.1 Übereinstimmung von Entwurf und Sicherheitsanforderungsspezifikation

• 7.4.2.2.a Übereinstimmung von Entwurf und den Anforderungen der Hardware-Sicherheits-integrität

• 7.4.2.2.b Übereinstimmung von Entwurf und den Anforderungen der systematischen Sicher-heitsintegrität

• 7.4.2.2.c Übereinstimmung von Entwurf und den Anforderungen für das Systemverhalten bei Fehleroffenbarung

• 7.4.2.3 Gemeinsame Implementierung von Sicherheits- und Nicht-Sicherheits-Funktionen




• 7.4.2.4 Sicherheitsintegrationsstufe bei unterschiedlichen Sicherheitsfunktionen

• 7.4.2.5 Nachweis der Unabhängigkeit von Sicherheitsfunktionen

• 7.4.2.6 Verfügbarkeit der Anforderungen an sicherheitsgerichtete Software

• 7.4.2.7 Review der Anforderungen an sicherheitsgerichtete Software und Hardware

• 7.4.2.8 Notwendige Techniken und Maßnahmen im Lebenszyklus zur Erreichung der Sicher-heitsintegrationsstufe

• 7.4.2.9 Begründung der Auswahl von Techniken und Maßnahmen zur Erreichung der Sicher-heitsintegrationsstufe

• 7.4.2.10 Bedeutung der Hardware und Software-Interaktionen

• 7.4.2.11 Zerlegung des Entwurfs in Subsysteme

• 7.4.2.12 Sicherheitsfunktionen zur Vermeidung gefährlicher Ausgangskombination von Sub-systemen

• 7.4.2.13 Einsatz von Derating-Techniken

• 7.4.3.1 Architektonische Bedingungen für die Hardware-Sicherheitsintegrität

• 7.4.7.1 Implementation des E/E/PES nach dem Entwurf

• 7.4.7.2 Identifikation sicherheitsrelevanter Subsysteme

• 7.4.7.3.a Funktionale Spezifikation von Funktionen und Schnittstellen, die von Sicherheits-funktionen verwendet werden können

• 7.4.7.3.b Geschätzte Ausfallraten für gefährliche Fehler, die durch diagnostische Prüfungen offenbart werden

• 7.4.7.3.c Geschätzte Ausfallraten für gefährliche Fehler, die durch diagnostische Prüfungen nicht offenbart werden

• 7.4.7.3.d Umweltbedingungen, die beobachtet werden müssen, um die Gültigkeit der geschätz-ten Ausfallraten zu bestätigen

• 7.4.7.3.e Lebensdauer, die nicht überschritten werden darf, um die Gültigkeit der geschätzten Ausfallraten zu bestätigen

• 7.4.7.3.f Periodische Wiederholungsprüfungen und Wartungsanforderungen

• 7.4.7.3.g Diagnoseniveau

• 7.4.7.3.h Diagnose-Testintervall

• 7.4.7.3.i Zusatzinformationen zur Ableitung der mittleren Reparaturzeit

• 7.4.7.3.j Informationen zur Ableitung des Gesamtanteils sicherer Ausfälle

• 7.4.7.3.k Hardware Fehlertoleranz

• 7.4.7.3.l Anwendungsgrenzen zur Vermeidung systematischer Fehler

• 7.4.7.3.m Höchste Sicherheitsintegritätsstufe für Sicherheitsfunktion

• 7.4.7.3.n Konfigurationsinformationen

• 7.4.7.3.o Validierungsnachweise

• 7.4.7.4 Geschätzte Ausfallrate wegen zufälliger Hardwarefehler

• 7.4.7.5 Kontrolle von systematischen Fehlern bei Betriebsbewährtheit nicht notwendig

• 7.4.7.6 Kriterien für Betriebsbewährtheit zuvor entwickelter Subsysteme




• 7.4.7.7 Nachweis ähnlicher Anwendungsbedingungen bei Vergleich von Subsystemen

• 7.4.7.8 Identifikation unterschiedlicher Anwendungsbedingungen bei Vergleich von Subsys-temen

• 7.4.7.9 Mindestdauer der Betriebsbewährtheit

• 7.4.7.10 Betriebsbewährtheit nur bei Fehleroffenbarung

• 7.4.7.11 Faktoren zur Beurteilung Anforderungen für Betriebsbewährtheit

• 7.4.7.12 Funktionseinschränkung von betriebsbewährten Subsystemen

• 7.4.8.1 Abschätzung der Wahrscheinlichkeit unentdeckter Fehler bei der Datenkommunikation

• 7.4.8.2 Parameter für die Abschätzung der Wahrscheinlichkeit von Fehlern bei der Daten-kommunikation

2.2.2.2.7 Sicherheitsreviews

2.2.2.2.8 Sicherheitsverifikation und -validation

• 7.3.2.1 Planung des Nachweises der Erfüllung der Sicherheitsanforderungen

• 7.3.2.2.a Berücksichtigung aller Anforderungen der Sicherheitsanforderungsspezifikation

• 7.3.2.2.b Verfahren zur Validierung der Sicherheitsfunktionen

• 7.3.2.2.c Verfahren zur Validierung der Sicherheitsintegrität

• 7.3.2.2.d Berücksichtigung der Testumgebung

• 7.3.2.2.e Verfahren zur Testauswertung (mit Begründung)

• 7.3.2.2.f Testverfahren und Leistungsmerkmale zum Nachweis der elektromagnetischen Stör-festigkeit

• 7.3.2.2.g Richtlinien zur Auflösung bei fehlgeschlagener Validierung

• 7.5.2.1 Integration nach Entwurf und Test nach spezifizierten Integrationstests

• 7.5.2.2 Ziel der Systemtests

• 7.5.2.3 Integration von Hardware und Software

• 7.5.2.4 Dokumentation von Testergebnissen

• 7.5.2.5 Änderungen während der Integration und Prüfung

• 7.5.2.6 Umfang der Testdokumentation

• 7.5.2.7 Maßnahmen und Techniken zur Vermeidung von Fehlern bei der E/E/PES Integration

• 7.7.2.1 Übereinstimmung der Validierung mit einem Validierungsplan

• 7.7.2.2 Kalibrierung der Testumgebung

• 7.7.2.3 Prüfung aller Sicherheitsfunktionen und aller Verfahren für Betrieb und Wartung

• 7.7.2.4 Umfang der Sicherheitsvalidierungsdokumentation

• 7.7.2.5 Dokumentation von Abweichungen

• 7.7.2.6 Verfügbarkeit der Validierungsergebnisse für Entwickler der kontrollierten Geräte und des Kontrollsystems für kontrollierte Geräte

• 7.7.2.7 Maßnahmen und Techniken zur Vermeidung von Fehlern bei der E/E/PES Sicherheits-validierung

• 7.9.2.1 Planung und Dokumentation der Verifikation




• 7.9.2.2 Die Verifikationsplanung soll sich auf alle genutzten Argumente, Techniken und Werkzeuge beziehen

• 7.9.2.3 Spezifikation aller Aktivitäten zur Sicherstellung der Konsistenz zu Produkten und Normen der Phaseneingabe

• 7.9.2.4 Umfang der Verifikationsplanung

• 7.9.2.5 Nachweis der Anforderungen der Funktions- und Sicherheitsintegrität

• 7.9.2.6 Dokumentation der Verifikationsergebnisse

• 7.9.2.7 Eignung und Widerspruchsfreiheit von Sicherheitsanforderungen

• 7.9.2.8 Qualitätsmerkmale für Entwurf, Entwicklung und Tests

• 7.9.2.9 Verifikation der Integration von sicherheitsgerichteten Systemen

• 7.9.2.10 Dokumentation von Testfällen

2.2.2.2.9 Sicherheitsbegründung

2.2.2.2.10 System-/Teilsystem-/Einrichtungsübergabe

2.2.2.2.11 Betrieb und Instandhaltung

• 7.6.2.1 Vorbereitung von Verfahren für Betrieb und Wartung

• 7.6.2.2 Kontinuierliche Aktualisierung der Verfahren für Betrieb und Wartung

• 7.6.2.3 Systematisch Bestimmung von Routine-Wartungsarbeiten

• 7.6.2.4 Bewertung von Verfahren für Betrieb und Wartung auf die kontrollierten Geräte

• 7.6.2.5 Maßnahmen und Techniken zur Vermeidung von Fehlern bei Verfahren für Betrieb und Wartung

2.2.2.2.12 Stilllegung und Entsorgung

2.2.2.3 Nachweis der funktionalen und technischen Sicherheit

2.2.2.3.1 Einleitung

2.2.2.3.2 Nachweis des korrekten funktionalen Verhaltens

2.2.2.3.3 Ausfallauswirkungen

• 7.4.6.1 Reaktion bei Fehleroffenbarung in Subsystemen mit Fehlertoleranz

• 7.4.6.2 Reaktion bei Fehleroffenbarung in Subsystemen ohne Fehlertoleranz bei niedriger An-forderungsrate

• 7.4.6.3 Reaktion bei Fehleroffenbarung in Subsystemen ohne Fehlertoleranz bei hoher Anfor-derungsrate oder kontinuierlicher Anforderung

2.2.2.3.4 Betrieb mit externen Einflüssen

• 7.2.3.2.d Extreme Umweltbedingungen

• 7.2.3.2.e Elektromagnetische Störfestigkeit




2.2.2.3.5 Sicherheitsbezogene Anwendungsbedingungen

2.2.2.3.6 Sicherheitserprobung

2.2.2.4 Sicherheitsanerkennung und -zulassung

2.2.2.4.1 Sicherheitszulassungsverfahren

2.2.2.4.2 Nach der Sicherheitszulassung

• 7.8.2.1 Umfang der Dokumentation bei Änderungsaktivitäten

• 7.8.2.2 Unterhaltung eines Systems zur Auslösung von Änderungen

• 7.8.2.3 Beibehaltung des Kompetenz-, Automatisierungs-, Planungs- und Managementgrades bei Änderungen

• 7.8.2.4 Wiederholungs-Verifizierung und -Validierung

2.2.2.4.3 Abhängigkeiten zwischen Sicherheitszulassungen

2.2.3 Software

Hier werden im Wesentlichen die Bedingungen der Industrienorm IEC 61508-3 mit den Bedingungen der Bahnnorm EN 50128 verglichen. An den Stellen, an denen die Bereiche von IEC 61508-3 bzw. EN 50128 verlassen werden, wird dies ausdrücklich angegeben.

2.2.3.1 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 Bahnnorm T1.5.2.1 Informationen für Lebenszyklusphasen T1.6.2.1.c Angewendete Lebenszyklusphasen T3.7.1.2.1 Lebenszyklusmodell für Softwareent-wicklung T3.7.1.2.2 Integration von Qualitäts- und Sicher-heitsmanagement in das Lebenszyklusmodell T3.7.1.2.4 Anpassung von Phasen T3.7.1.2.5 Organisation des Softwareprojekts T3.7.1.2.7 Ergebnisdokumentation T3.7.1.2.8 Wiederholung von Phasen

7.2.1 Lebenszyklusmodell für Software-Entwicklung

T3.7.1.2.3 Aufteilung der Phasen in Aktivitäten T3.7.1.2.6 Techniken und Maßnahmen der Phasen

7.2.3 Definition von Aktivitäten einer Phase

T1.5.2.4 Begründung von Abweichungen in den Bestimmungen der Industrienorm

T1.5.2.5 Ausreichende Verfügbarkeit 7.2.7 Geeignete Form für Handhabung, Bearbeitung und Aufbewahrung

T1.5.2.6 Qualitative Anforderungen an Form und Inhalt T1.5.2.7 Titel, Bezeichner, Index-Organisation T1.5.2.9 Versionierung T1.5.2.10 Recherche, Identifikation aktueller Versi-onen T3.6.2.3 Aufgaben des Softwarekonfigurationsma-nagements

7.2.5 Struktur für fortlaufende Erweiterung 7.2.6 Verfolgbarkeit und Konsistenz

T1.5.2.8 Sektor- und firmenspezifische Arbeitswei-sen

5.2.1 Dokumentationsumfang

T1.5.2.11 Änderungswesen und Qualitätssicherung 7.2.2 Parallele Durchführung von Qualitätssicherungs-verfahren

T1.6.2.1.a Grundsätze und Strategien zur Erreichung funktionaler Sicherheit




Industrienorm Bahnnorm 6.2.6 Ernennung eines unabhängigen Gutachters 6.2.7 Autorität des Gutachters 6.2.8 Unabhängigkeit beteiligter Gruppen 6.2.9 Verantwortliche Parteien

T1.6.2.1.b Identifikation verantwortlicher Personen, Abteilungen und Organisationen

6.2.10 Organisation des Gutachters T1.5.2.2 Informationen zum Management der funk-tionalen Sicherheit T1.5.2.3 Informationen zur Durchführung der Be-wertung der funktionalen Sicherheit T1.6.2.1.d Umfang und Struktur der Dokumentation

7.2.4 Beschreibung der Verifikationsschritte und Veri-fikationsberichte 7.2.8 Umfang der Dokumentation nach DCRT 7.2.9 Kombination von Dokumenten 7.2.10 Dokumenten-Cross-Referenz-Tabelle

T1.6.2.1.e Ausgewählte Maßnahmen und Techniken zur Erreichung der Anforderungen von Bestimmun-gen T1.6.2.1.f Aktivitäten zu Bewertung der funktionalen Sicherheit T1.6.2.1.g Verfahren zur Verfolgung von Empfeh-lungen aus Analyse- und Managementaktivitäten

6.2.3 Ausbildung, Erfahrung und Qualifikation 6.2.4 Begründung der Ausbildung, Erfahrung und Qualifikation

T1.6.2.1.h Verfahren zur Ermittlung des Schulungs-bedarfs

6.2.5 Umfang der Begründung für Ausbildung, Erfah-rung und Qualifikation

T1.6.2.1.i Verfahren zur Analyse von Gefahrensitua-tionen T1.6.2.1.j Verfahren zur Analyse der Betriebs- und Wartungsleistung T1.6.2.1.k Anforderungen für regelmäßige Überprü-fungen der funktionalen Sicherheit T1.6.2.1.l Verfahren zur Einleitung von Änderung an dem sicherheitsgerichteten System T1.6.2.1.m Notwendige Verfahren und Behörden für die Genehmigung von Änderungen T1.6.2.1.n Verfahren zum Erhalt korrekter Informa-tionen zu möglichen Gefahren und sicherheitsgerich-teten Systemen T1.6.2.1.o Verfahren zum Konfigurationsmanage-ment T1.6.2.1.p Versorgung, Training und Information von Notfalldiensten T1.6.2.2 Implementation und Überwachung der Aktivitäten aus T1.6.2.1 T1.6.2.3 Formale Prüfung durch und Zustimmung von allen betroffenen Organisationen T1.6.2.4 Information von Management und Funkti-onsträgern T1.6.2.5 Übertragung auf Zulieferer

6.2.1 Umsetzung ISO 9001 6.2.2 Sicherheitsorganisation T3.6.2.1 Es gelten die Anforderungen aus T1.6.2 T3.6.2.2 Planung der funktionalen Sicherheit defi-niert Strategien für Software-Belange

Tabelle 17: Vergleich von Software

2.2.3.2 Softwareanforderungsspezifikation

Industrienorm Bahnnorm 7.2.2.1 Keine Wiederholung der Softwareanforde-rungsspezifikation




Industrienorm Bahnnorm 7.2.2.2 Ableitung der Softwareanforderungsspezifi-kation

8.4.1 Softwareanforderungsspezifikation für Eigen-schaften der Software

7.2.2.3 Detailgrad der Softwareanforderungsspezifi-kation

8.4.4 Schnittstellenspezifikation

7.2.2.4 Review der Softwareanforderungsspezifikati-on 7.2.2.5 Verfahren zur Lösung von Unstimmigkeiten bei der Zuweisung von Sicherheitsintegrationsstufen

8.4.2 Qualitätsmerkmale der Softwareanforderungs-spezifikation 8.4.3 Verständlichkeit der Softwareanforderungsspezi-fikation 8.4.15 Verfolgbarkeit von Anforderungen

7.2.2.6 Qualitätsmerkmale der Softwareanforde-rungsspezifikation

8.4.16 Umgang mit nicht-verfolgtem Material 7.2.2.7 Spezifikation der Betriebsmodi der kontrol-lierten Geräte

8.4.5 Darstellung relevanter Betriebsarten

7.2.2.8 Spezifikation von Sicherheitsbedingungen zwischen Hardware und Software

8.4.7 Identifikation und Beschreibung von Zwangsbe-dingungen zwischen Hardware und Software 8.4.8 Hinweis auf Umfang von Software-Selbsttests und Hardware-Prüfungen 8.4.9 Periodisches Testen von Funktionen

7.2.2.9 Berücksichtigung von Überwachungs- und Testfunktionen

8.4.10 Tests von Sicherheitsfunktionen im Betrieb 7.2.2.10 Identifikation von Nicht-Sicherheits-funktionen

8.4.12 Kennzeichnung von Funktionen ohne Sicher-heitsanforderung 8.4.6 Beschreibung von relevanten Verhaltensweisen, insbesondere Ausfallverhalten

7.2.2.11 Spezifikation der Sicherheitseigenschaften des Produkts

8.4.11 Kennzeichnung von Funktionen zur Erreichung der System-Sicherheitsanforderungsstufe 8.4.13 Ableitung einer Software-Anforderungs-testspezifikation

8.4.14 Testfälle für Software-Anforderungs-testspezifikation

Tabelle 18: Vergleich der Software

2.2.3.3 Softwaredesign und -entwicklung

Industrienorm Bahnnorm 7.4.2.1 Aufteilung der Verantwortung für Design-konformität

9.4.2 Möglichst einfache Umsetzung der Software-Anforderungsspezifikation 9.4.10 Festlegung der Strategie für die Softwareent-wicklung

7.4.2.2 Eigenschaften der Designmethode

9.4.15 Merkmale des gewählten Entwurfsverfahren 9.4.12 Bildung eines integrierten Satzes von Techni-

ken und Maßnahmen für Software-Anforderungs-spezifikation

7.4.2.3 Berücksichtigung von Test- und Wartungs-freundlichkeit

7.4.2.4 Designmethode soll Änderungen erleichtern 10.4.16 Eigenschaften zur Erleiterung der Software-wartung

7.4.2.5 Eindeutigkeit der Darstellungsnotation 9.4.1 Detaillierte Beschreibung in der Software-Architekturspezifikation

9.4.3 Bedeutung der Wechselwirkungen zwischen Hardware und Software 9.4.8 Minimierung des sicherheitsrelevanten Anteils 7.4.2.6 Minimierung des sicherheitsrelevanten An-

teils 10.4.2 Minimierung von Umfang und Komplexität




Industrienorm Bahnnorm 7.4.2.7 Gemeinsame Implementierung von Si-cherheits- und Nicht-Sicherheits-Funktionen 7.4.2.8 Sicherheitsintegrationsstufe bei unterschied-lichen Sicherheitsfunktionen

9.4.9 Software aus Teilen unterschiedlicher Software-Anforderungsstufe

7.4.2.9 Diagnostische Prüfungen 7.4.2.10 Selbsttests

9.4.11 Begründung der Abwägung zwischen fehler-vermeidenden und fehlerbeherrschenden Strategien 9.4.5 Einschränkungen für die Verwendung von COTS-Software 9.4.6 Einsatz von vorher entwickelter Software

7.4.2.11 Standard- oder vorher entwickelte Software

9.4.7 Bevorzugung von nach Norm entwickelter Soft-ware

7.4.2.12 Gültigkeit für Daten 7.4.3.1 Aufteilung der Verantwortung für Design-konformität

10.4.4 Umfang der Software-Designspezifikation 7.4.3.2 Umfang der Entwurfsdokumentation 10.4.5 Umfang der Software-Modulspezifikation

7.4.3.3 Berücksichtigung von Änderungen der Si-cherheitsanforderungen 7.4.4.1 Aufteilung der Verantwortung für Werk-zeugkonformität

10.4.7 Angemessene Auswahl von Werkzeugen 7.4.4.2 Auswahl von Werkzeugen und Programmier-sprachen 10.4.8 Automatische Testwerkzeuge und Integrierte

Entwicklungswerkzeuge 10.4.9 Merkmale für Compiler oder Übersetzer der ausgewählten Programmiersprache

7.4.4.3 Eigenschaften der ausgewählten Program-miersprache

10.4.10 Anforderungen an die ausgewählte Program-miersprache

7.4.4.4 Begründung für alternative Programmier-sprache

10.4.11 Begründung für alternative Programmierspra-che

7.4.4.5 Verwendung von Codierstandards 10.4.12 Entwicklung und Verwendung von Codier-standards

7.4.4.6 Eigenschaften der Codierstandards und Quellcodedokumentation

10.4.13 Eigenschaften der Codierstandards und Quell-codedokumentation

7.4.5.1 Aufteilung der Verantwortung für Detailent-wurf-Konformität

7.4.5.2 Voraussetzungen für Detailentwurf 10.4.1 Voraussetzungen für den Entwurfsprozess 7.4.5.3 Modulare, testbare und wartungsfreundliche Software

9.4.4 Identifikation aller Softwarekomponenten 10.4.3 Software-Entwurf basiert auf Zerlegung in Module

7.4.5.4 Zerlegung der Softwarearchitektur

10.4.14 Spezifikation von Software-Modultests 7.4.5.5 Spezifikation geeigneter Software-System-integrationstests

11.4.5 Inhalt des Software-Integrationsplans

7.4.6.1 Qualitative Anforderungen an den Quellcode 10.4.6 Jedes Software-Modul muss lesbar, verständ-lich und testbar sein.

7.4.6.2 Review von Softwaremodulen 7.4.7.1 Test von Softwaremodulen 11.4.13 Verifikation der Software-Modulentwurfs-

spezifikation 7.4.7.2 Ziele von Softwaremodultests 7.4.7.3 Dokumentation von Softwaremodultester-gebnissen 7.4.7.4 Verfahren zur Korrektur bei fehlgeschlage-nen Tests

7.4.8.1 Planung von Software-Integrationstests 7.4.8.2 Inhalt von Software-Integrationstests 10.4.17 Integration von Software-Modulen 7.4.8.3 Durchführung von Software-Integrationstests




Industrienorm Bahnnorm 7.4.8.4 Dokumentation der Software-Integrations-testergebisse

11.4.15 Erstellung eines Software-Integrations-testberichts

7.4.8.5 Durchführung einer Auswirkungsanalyse 10.4.18 Verfolgbarkeit von Anforderungen und Ent-

wurfsobjekten


2.2.3.4 Software/Hardwareintegration

Industrienorm Bahnnorm 11.4.16 Software/Hardwareintegration 7.5.2.1 Spezifikation von Integrationstests 12.4.1 Erstellung eines Software/Hardware-Integrationstestplans

7.5.2.2 Inhalt von Integrationstests für programmier-bare Elektronik

12.4.2 Inhalt des Integrationstestplans

7.5.2.3 Unterscheidung von Aktivitäten, die im Werk oder beim Kunden durchgeführt werden

12.4.3 Unterscheidung von Aktivitäten, die beim Her-steller oder beim Betreiber durchgeführt werden

7.5.2.4 Einsatzszenarien für Integrationstests 12.4.4 Unterscheidung zwischen Portierung und Sys-temintegration

12.4.5 Fertigstellungstermin für Werkzeuge und Hilfsmittel

7.5.2.5 Verwendung der Integrationstest für die Software

7.5.2.6 Durchführung einer Auswirkungsanalyse 12.4.6 Durchführung einer Auswirkungsanalyse 7.5.2.7 Dokumentation von Testfällen und Ergebnis-sen

12.4.7 Aufzeichnung von Testfällen

7.5.2.8 Dokumentation der Integrationstests; Not-wendige Wiederholungsprüfungen bei Änderungen

12.4.8 Erstellung eines Software/Hardware-Integrationstestberichts


2.2.3.5 Planung und Durchführung der Software-Validierung

Industrienorm Bahnnorm 7.3.2.1 Ziele der Software-Validierungsplanung 13.4.3 Erstellung eines Software-Validierungsplans 13.4.14 Test gegen Software-Anforderungstest-

spezifikation 13.4.7 Inhalt des Software-Validierungsplans 7.3.2.2 Inhalt der Software-Validierungsplanung 13.4.9 Nachbildung von Eingangssignalen bei unter-schiedlichen Bedingungen

7.3.2.3 Technische Strategie der Software-Validierungsplanung

13.4.6 Zusammenfassung der Validierungsstrategie

13.4.4 Bewertung des Software-Validierungsplans 7.3.2.4 Review der Software-Validierungsplanung 13.4.5 Abstimmung des Software-Validierungsplans

7.3.2.5 Umfang der Erfüllungs- und Ausfallkriterien 7.7.2.1 Keine Wiederholung der Software-Validierung 7.7.2.2 Ausführung der Validierung nach Planung

7.7.2.3 Dokumentation der Ergebnisse der Validie-rung

13.4.10 Dokumentation der Validierungsergebnisse

13.4.11 Umfang der Validierungsergebnisse 7.7.2.4 Umfang der Dokumentation für Sicherheits-funktionen 13.4.12 Identität und Konfiguration von Gegenständen

der Validierung 7.7.2.5 Dokumentation der Maßnahmen bei Abwei-chungen

13.4.13 Dokumentation gefundener Mängel

13.4.1 Hauptaktivitäten der Validierung 7.7.2.6 Anforderungen an die Validierung von si-cherheitsgerichteter Software 13.4.2 Ergänzende Aktivitäten der Validierung 7.7.2.7 Fähigkeiten von Softwarewerkzeugen 13.4.8 Eignung von Softwarewerkzeugen 7.7.2.8 Anforderungen an Validierungsergebnisse





2.2.3.6 Software-Wartung

Industrienorm Bahnnorm 16.4.1 Ausführung nach ISO 9000-3 16.4.2 Berücksichtigung von Wartbarkeit beim Ent-wurf 16.4.3 Aufstellen von Verfahren zur Software-Wartung

7.8.2.1 Verfügen von Verfahren zur Softwaremodifi-kation 7.8.2.2 Auslösung durch formalen Änderungsantrag 16.4.4 Auditierung von Wartungsaktivitäten

16.4.5 Verwendung der Projektumgebung aus der Entwicklung 16.4.6 Anwendung auf Altsysteme

16.4.7 Handhabung der Software-Qualitätssicherung 7.8.2.6 Inhalt der Sicherheitsplanung 7.8.2.7 Durchführung der Änderung

7.8.2.3 Durchführung einer Auswirkungsanalyse 7.8.2.4 Dokumentation der Auswirkungsanalyse 7.8.2.5 Wiederholung geeigneter Lebenszykluspha-sen 7.8.2.8 Dokumentation der Änderung 7.8.2.9 Dokumentation der Änderungsdetails 7.8.2.10 Bewertung der Modifikation

16.4.8 Software-Wartungsaufzeichnungen 16.4.9 Software-Änderungsbericht


2.2.3.7 Software-Verifikation

Industrienorm Bahnnorm 7.9.2.1 Planung der Software-Verifikation 11.4.1 Erstellung eines Software-Verifikationsplans

11.4.2 Beschreibung von Kriterien, Techniken und Werkzeugen für den Verifikationsprozess

7.9.2.2 Umfang der Planung der Software-Verifikation

11.4.4 Inhalt des Software-Verifikationsplans 7.9.2.3 Durchführung der Software-Verifikation nach Plan

7.9.2.4 Dokumentation/Nachweis von Phasenab-schlüssen

11.4.3 Beschreibung von Aktivitäten zur Gewährleis-tung von Korrektheit und Konsistenz

7.9.2.5 Dokumentation der Software-Verifikation 11.4.9 Dokumentation der Ergebnisse der Verifikation 11.4.10 Erstellung von Verifikationsberichten

7.9.2.6 Verifikation wesentlicher Informationen der Phasenübergänge 7.9.2.7 Verifikationsaktivitäten

11.4.6 Nachweis der Anforderungen an Funktion, Zuverlässigkeit, Leistung und Sicherheit

7.9.2.8 Verifikation der Software-Sicherheits-anforderungen

11.4.11 Verifikation der Software-Anforderungs-spezifikation

7.9.2.9 Verifikation der Software-Architektur 7.9.2.10 Verifikation des Software-Systemdesigns 7.9.2.11 Verifikation der Software-Moduldesign-verifikation

11.4.12 Verifikation der Software-Architektur- und Entwurfsspezifikation

7.9.2.12 Quellcodeverifikation 11.4.14 Verifikation des Software-Quellcode 7.9.2.13 Datenverifikation 17 Anwendungsspezifisch konfigurierbare Systeme

11.4.7 Durchführung von unabhängiger Stelle 11.4.8 Nicht vollständig dokumentierte Tests


2.2.3.8 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 61508-1.




Industrienorm Bahnnorm 14.4.1 Spezialfall für Software der Sicherheitsanforde-rungsstufe 0

14.4.2 Berücksichtigung vorhandener Gutachten 8.2.1 Berufung zur Bewertung der funktionalen Si-cherheit 8.2.12 Unabhängigkeit der Sicherheitsbewertung 8.2.13 Hinweise zur Unabhängigkeit der Sicher-heitsbewertung 8.2.14 Hinweise zur Unabhängigkeit der Sicher-heitsbewertung

14.4.4 Unabhängige Begutachtung der Software

8.2.2 Zugriff auf Personen, Informationen und Aus-rüstung

14.4.3 Zugang zum Entwurfs- und Entwicklungspro-zess und zu allen Projektunterlagen

8.2.3 Sicherheitsbewertung aller Phasen des Lebens-zyklus

14.4.6 Entscheidung über Verfahren des Software-Lebenszyklus

8.2.4 Ausführung der Sicherheitsbewertung 8.2.5 Sicherheitsbewertung von Werkzeugen 8.2.6 Berücksichtigung vorheriger Sicherheitsbewer-tungen, Pläne und Empfehlungen 8.2.7 Planung einer konsistenten Sicherheitsbewer-tung 8.2.8 Inhalt der Planung der Sicherheitsbewertung 8.2.9 Genehmigung der Planung der Sicherheitsbe-wertung

8.2.10 Abschluss der Sicherheitsbewertung 14.4.5 Feststellung des Gutachters 8.2.11 Sachkundige Sicherheitsbewertung

14.4.7 Zustimmung zu Geltungsbereich und Inhalt des Software-Validierungsplans 14.4.8 Zusätzliche Verifikations- und Validie-rungsschritte 14.4.9 Ergebnisbericht jeder Begutachtung 14.4.10 Abschließendes Software-Gutachten

14.4.11 Keine Angabe technischer Lösungen bei Mängeln


2.2.4 Sicherheitsnachweis

Einer der grundlegenden Unterschiede beider Normen ist das Dokument des Sicherheitsnachweises. Dieser wird nach CENELEC als das Dokument gefordert, dass zusammenfassend den gesamten Pro-zess dokumentiert. In der IEC ist dieses Dokument nicht in dieser Form explizit gefordert.

In diesem Abschnitt werden speziell die Anforderungen an den Sicherheitsnachweis verglichen.

2.2.4.1 Erstellung

Die Bahnnorm sieht die Erstellung eines Anwendungs-Sicherheitsnachweises in der Phase 9 „System-Validierung“ vor (vgl. EN 50126, 6.9.3.3). In der Industrienorm wird entsprechend in der Phase 13 „Validierung der gesamten Sicherheit“ die Dokumentation der Sicherheitsvalidierung vorgesehen (vgl. IEC 61508-1, 7.14.2.3). Zusätzlich ist in der Phase 9.2 des Software-Sicherheitslebenszyklus die Pla-nung der Software-Validierung vorgesehen (vgl. IEC 61508-3, 7.3.2.2).

2.2.4.2 Inhalt

Industrienorm Bahnnorm Systemüberblick Plan: Zeitpunkt der Validierung Plan: Durchführende der Validierung Plan: Identifikation relevanter Betriebsmodi der kontrollierten Geräte




Industrienorm Bahnnorm Plan: Identifikation sicherheitsgerichteter Software Zusammenfassung der Sicherheitsbewertung und der

Sicherheitsaudits Plan: Technische Strategie der Validierung Übersicht über die Sicherheits-Engineering-Techniken Plan: Maßnahmen und Verfahren der Validierung Zusammenfassung der Kontrollen des Qualitäts- und

Sicherheitsmanagements Zusammenfassung oder Bezug auf die Sicherheitsan-forderungen

Plan: Verweise auf spezifische Software-Sicherheits-anforderungen

Zusammenfassung der Aufgaben zur Sicherheitsana-lyse

Plan: Erforderliche Testumgebung Plan: Erfolgs- und Ausfallkriterien Plan: Richtlinien und Verfahren zur Bewertung der Validierungsergebnisse, speziell von Ausfällen

Bericht: Chronologische Dokumentation der Validie-rungsaktivitäten

Bericht: Version der Gesamt-Sicherheitsanforderungsspezifikation

Bericht: Validierte Sicherheitsfunktion und Art der Untersuchung (Analyse oder Test)

Bericht: Verwendete Werkzeuge und Ausrüstung inkl. Kalibrierungsdaten

Nachweis der Erfüllung der Sicherheitsanforderungen Bericht: Ergebnis der Validierungsaktivitäten Zusammenfassung aller Beschränkungen und Zwänge

Bericht: Konfigurationsidentifikation des untersuch-ten Gegenstandes, der angewendeten Validierungs-verfahren und der Testumgebung

Bericht: Abweichungen zwischen erwarteten und tatsächlichen Ergebnissen

Tabelle 25: Vergleich des Inhalts des Sicherheitsnachweises

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.


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 Zulas-sungsprozesse 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

3.2.1 Lebenszyklen

Beide Normenwerke erlauben eine Anpassung der Lebenszyklusphasen (IEC 61508-1, 7.1.1.1; EN 50126, 5.3.4.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 Le-benszyklen für bestimmte Phasen auszuwählen.

3.2.2 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 2.2.2 ist tatsäch-lich 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.


Anhang


4 Anhang

4.1 Anhang 1: Referenzen

IN Functional safety of electrical/electronic/programmable electronic safety-related systems; Französisch/Englische Fassung CEI/IEC 61508-1:1998, 61508-2:2000, 61508-3:1998, 61508-4:1998, 61508-5:1998, 61508-6:2000, 61508-7:2000

BN6 Bahnanwendungen – Spezifikation und Nachweis der Zuverlässigkeit, Verfügbar-keit, Instandhaltbarkeit und Sicherheit (RAMS); Deutsche Fassung EN 50126:1999

BN8 Bahnanwendungen – Telekommunikationstechnik, Signaltechnik und Datenver-arbeitungssysteme – Software für Eisenbahnsteuerungs- und Überwachungssyste-me; Deutsche Fassung EN 50128:2001

BN9 Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und Datenver-arbeitungssysteme - Sicherheitsrelevante elektronische Systeme für Signaltechnik; Deutsche Fassung EN 50129:2003

SSE TÜV-Präsentation – SPS für den sicherheitsgerichteten Einsatz in der Bahntechnik 5_SPS_für_den_sicherheitsgerichteten_Einsatz.pdf, Version von 2009-11-03

ESS Josef Börcsök; Elektronische Sicherheitssysteme – Hardwarekonzepte, Modelle und Berechnung; Hüthig, 2004

4.2 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



Teilbericht

AP 2300

Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge

06.08.2013

Laufzeit: 01.09.2011 – 31.08.2013



Version: 1.0 Seite 2 von 51


Datum Bearbeiter Version Inhalt 12.04.2013 Antje M. Möller-Neustock 0.1 Erstausgabe – Vorlage der Anforderungen an alle

Verteiler, zur Diskussion und Festlegung des Funk-tionsumfangs.

14.05.2013 Antje M. Möller-Neustock 0.2 Detaillierung 31.05.2013 Antje M. Möller-Neustock 0.3 Konzeptdetaillierung 07.06.2013 Antje M. Möller-Neustock 0.4 Prototyp-Screenshots 17.06.2013 Antje M. Möller-Neustock 0.5 Fertigstellung theoretische Analyse Gefährdungs-

logbuch

20.06.2013 Antje M. Möller-Neustock 0.6 Erstellung Draft-Version zum Review 28.06.2013 Antje M. Möller-Neustock 0.7 Review und Abschluss 11.07.2013 Antje M. Möller-Neustock 0.8 Formales Review 15.07.2013 Matthias Grimm 0.9 Übernahme Ergebnisbericht: Kapitel Konzepte der

Nachweisführung 06.08.2013 Holger Neustock


Inhaltsverzeichnis

1 Zielstellung.......................................................................................................................................5

2 Ausgangssituation ...........................................................................................................................7

3 Prozess der RAMS-Nachweisführung und unterstützende Werkzeuge...................................10

3.1 Konzepte der Nachweisführung..............................................................................................10 3.1.1 Risikoanalyse, Gefährdungsbeherrschung und Risikoakzeptanzkriterien .........................10 3.1.1.1 Risikoanalyse und Gefährdungsbeherrschung im Luftverkehr......................................... 10 3.1.1.2 Risikoanalyse und Gefährdungsbeherrschung im Schienenverkehr ................................. 12 3.1.2 Sicherheitsnachweisführung ..............................................................................................18 3.1.2.1 Common Cause Analysis.................................................................................................. 19 3.1.2.2 Event Tree Analysis.......................................................................................................... 20 3.1.2.3 Fault Tree Analysis........................................................................................................... 21 3.1.2.4 Failure-Mode- and Effect-Analysis .................................................................................. 22 3.1.2.5 Failure-Mode-, Effect- and Criticality-Analysis............................................................... 24 3.1.2.6 Hazard and Operability Study........................................................................................... 25 3.1.2.7 Markov-Analyse ............................................................................................................... 26 3.1.2.8 Preliminary Hazard Analysis ............................................................................................ 26 3.1.2.9 Sicherheitskonzept ............................................................................................................ 27 3.1.2.10 Functional Hazard Assessment ......................................................................................... 28 3.1.2.11 Preliminary System Safety Assessment............................................................................ 30 3.1.2.12 System Safety Assessment................................................................................................ 30 3.1.3 Fazit zur Verfahrensübersicht ..............................................................................................31

3.2 Evaluierung eines ALM-Werkzeuges für die Prozesse der Nachweisführung...................31 3.2.1 Grundlegende Betrachtung ................................................................................................31 3.2.2 Vorschlag für einen ALM-Workflow zur Nachweisführung von Änderungen .................36 3.2.3 Sonderfall: COTS-Betrachtung..........................................................................................42 3.2.4 Verwaltung eines Gefährdungslogbuchs ...........................................................................45



3.2.5 Ergebnis der Evaluierung...................................................................................................46

4 Zusammenfassung und Ausblick .................................................................................................48

5 Anhang Abkürzungen...................................................................................................................49

Abbildungs- und Tabellenverzeichnis

Abbildung 1: Wechselwirkung zwischen Sicherheits- und Entwicklungsprozess in der Luftfahrt (nach [KNE2001])............................................................................................................................................ 11

Abbildung 2: Bestimmung und Zuteilung der SIL-Anforderungen(nach [DIN EN 50129]) ................. 12

Abbildung 3: Bereiche des ALARP-Prinzips (nach [RSS2007])........................................................... 15

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]) ............................. 20

Abbildung 6: ETA-Graph mit binären Entscheidungen (nach [SSS1997])............................................ 21

Abbildung 7: Auswahl der wichtigsten Symbole für FTA-Graphen (nach [VES1981 und SSS1997]). 21

Abbildung 8: FTA-Graph....................................................................................................................... 22

Abbildung 9: Gitternetz für die Bewertung der Ausfallbedeutung ........................................................ 24

Abbildung 10: Ablauf des HAZOP-Prozesses ....................................................................................... 25

Abbildung 11: Verwendete Zeichen in einem Markov-Graphen ........................................................... 26

Abbildung 12: Markov-Graph................................................................................................................ 26

Abbildung 13: Fortpflanzung der Auswirkungen eines Versagens (nach WIK1998]) .......................... 29

Abbildung 14: RAMS-Prozess............................................................................................................... 33

Abbildung 15: möglicher Workflow einer FMEA-Umsetzung innerhalb eines ALM-Tools ................ 36

Abbildung 16: Anlegen eines Projekts ................................................................................................... 37

Abbildung 17: Definition von Rollen..................................................................................................... 37

Abbildung 18: Definition der Aktivitäten gemäß Phasenmodell ........................................................... 38

Abbildung 19: FMEA-Workflow........................................................................................................... 39

Abbildung 20: tabellarische Darstellung von Systemanforderungen ..................................................... 39

Abbildung 21: Definition einer Gefährdung .......................................................................................... 40

Abbildung 22: Generierung einer Verlinkung Risk zu Anforderung ..................................................... 41

Abbildung 23: Darstellung der Verlinkung im Work-Item.................................................................... 41

Abbildung 24: Auszug aus den Daten einer Gefährdung mit Definition einer Aktion .......................... 41

Abbildung 25: Ableitung einer Hardware-Anforderung aus einer Aktion............................................. 42

Abbildung 26: Übersicht über die Status der Gefährdungen.................................................................. 42

Abbildung 27: Definition COTS ............................................................................................................ 43

Abbildung 28: Deklaration des COTS-Produkts als "Nicht-sichere-Komponente"............................... 43

Abbildung 29: Historie eines Work-Items ............................................................................................. 44

Abbildung 30: Change Request für ein COTS- Bauteil ......................................................................... 44

Abbildung 31: Verlinkung Suspect ........................................................................................................ 45

Abbildung 32: Verlinkung suspect beim Objekt .................................................................................... 45



Abbildung 33: Definition von Work-Item Types................................................................................... 46

Tabelle 1: Gegenüberstellung von THR und SIL (nach [DIN EN 50129])............................................ 13

Tabelle 2: Beschreibung der ALARP-Risikobereiche (nach [AKB2004-1])........................................ 16

Tabelle 3: Auflistung der beschriebenen Verfahren............................................................................... 19

Tabelle 4: Versagensklassen und die zugehörigen DAL-Werte (nach [ARP 4754]) ............................ 29

Tabelle 5: Übersicht der beschriebenen Verfahren ................................................................................ 31


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 61508 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 61508 - 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 61508 (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 Sicherheitsmanage-ment-Prozesses dar,

• unterbreitet sie einen Vorschlag zur Umsetzung und

• zeigt die Möglichkeiten der Implementation einer einfachen Nachweisführung anhand eines stan-dardisierten Application Lifecycle Management (ALM)-Tools.


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.


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 produktspezi-fisch. 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 Sicher-heitsbetrachtungen durch den Betreiber wird nicht aufgenommen, da diese Verfahren der Risikobe-wertung 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 6.4.3

• RAMS-Politik: Darlegung der Strategie von der Umsetzung von funktionalen Anforderungen und unterstützende Leistungsanforderungen einschließlich einer Definition sicherheitsrelevan-ter 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 be-schrieben. Zusätzlich wird die Leistungsfähigkeit des Systems und dessen Abgrenzung defi-niert und spezielle sicherheitsbezogene Anwendungsbedingungen für die Umsysteme entwor-fen.

• RAMS-Programm: Planungen der jeweiligen Techniken/Maßnahmen, die bezogen auf das be-trachtete System beachtet werden müssen. Hier werden Techniken bestimmt und ihre Einsatz-möglichkeit auf eine Entwicklung einer Generischen Applikation (GA) bzw. eines Generischen Produkts (GP) und ihre Anwendung während der verschiedenen Phasen innerhalb des Produkt-erstellungsprozesses 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 produktspe-zifische 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 Zulassungsstra-tegie, 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 Einhal-tung im Sicherheitsnachweis.


Ausgangssituation


• RAMS-Nachweis: Definition von Teststrategien und Testszenarien für die Abnahme im Rah-men der System- und Integrationspläne. Die generellen Aspekte der Verfahren sowie der ein-zusetzenden 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 Abnahme-verfahrens sowie der Beurteilungskriterien so definiert, dass diese in dem Prüfplan des Gutach-ters 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 50126 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 50126 auf die entwicklungsbegleitenden Tätigkeiten gelegt. Dies wird im Bild 5 der DIN EN 50129 er-kennbar, wenn über die Betrachtung des Entwurfs sowie dessen Validation diskutiert wird. An-zumerken ist somit, dass erstens ein Schwerpunkt die Fehlerbetrachtung generell ist und zwei-tens 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 Model-lierungen werden in diesem Ergebnisbericht dargelegt:

• In diesem Ergebnisbericht wird ein generelles Verfahren zur Betrachtung von systematischen Feh-lern 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-) Syste-me führen können. Aus einem einheitlichen Modell folgt, dass durch die vereinheitlichten Ver-fahren 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än-gig vom Produkt umgesetzt werden können.

• Die Umsetzung eines Verfahrens zur Rückverfolgbarkeit (Traceability-Matrix) für Fehlerbetrach-tungen vom Entwurf bis zur Nachweisführung in den jeweiligen Testberichten wird im vorliegen-den Teil-Ergebnisbericht dargestellt. Am Beispiel des generischen Produkts Alister wird prototy-pisch eine Umsetzung gezeigt. Die Aspekte der Traceability gemäß A.4.3. "Bestimmung und Be-handlung 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ön-nen. 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 be-trachtet.

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 Platt-form - 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ächs-ter Schritt betrachtet werden.


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 Herstel-lers, 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 Unter-schiede 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 Entwicklungsdo-kumentation,

• die Variabilität der Produkte oder

• die hohe Innovationskraft

zu beachten. Es müssen daher Prozesse aufgesetzt werden, die die dadurch häufig notwendigen Ände-rungszulassungen flexibel und effizient ermöglichen.

Aufgrund der weitgefassten Definition der COTS-Produkte sollte dabei in einem folgenden For-schungsprojekt 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 Ergeb-nisberichts.




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 Übersichtlich-keit 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 Durch-gä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 gesam-ten 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 Sicherheitsor-ganisation begegnet werden, die firmenspezifisch aufgesetzt worden ist. Aufgrund der Entwicklungs-fortschritte der Werkzeuge, hier speziell der ALM-Toolketten, besteht jetzt die Möglichkeit, firmenu-nabhä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

3.1.1 Risikoanalyse, Gefährdungsbeherrschung und Risikoakzeptanzkriterien

Zum Vergleich mit anderen Branchen einige Betrachtungen aus Industriebereichen, in denen Sicher-heit ebenfalls eine herausragende Rolle spielt.

3.1.1.1 Risikoanalyse und Gefährdungsbeherrschung im Luftverkehr

Ein generischer Entwicklungsprozess für Luftfahrzeuge wird in der ARP 4754 [ARP 4754] beschrie-ben. Die verschiedenen Entwicklungsschritte verlaufen oftmals parallel und sind voneinander abhän-gig. Einzelne Änderungen können weitere nach sich ziehen und zur Aktualisierung der Risikoanalysen führen. Der Sicherheitsanalyseprozess ist in Abbildung 1 dargestellt.




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 so-wie mögliche Versagensarten identifiziert. Entsprechend der Klassifizierung der Versagensarten er-folgt 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 An-schluss 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 abge-leitete Sicherheitsanforderungen aufgestellt werden. Das gilt ebenso für die Komponentenanforderun-gen, 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. Inner-halb des FHA und PSSA werden bei Bedarf weitere Methoden angewandt, z. B. eine Fehlerbaumana-lyse (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.




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 durch-schnittliche 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.

3.1.1.2 Risikoanalyse und Gefährdungsbeherrschung im Schienenverkehr

Mit Einführung der DIN EN 50126-1 [DIN EN 50126] im Jahre 1999 wurde der zuvor gültige regel-orientierte Sicherheitsansatz durch einen risikoorientierten abgelöst. Während früher die Einhaltung geltender detaillierter Vorschriften nachgewiesen werden musste, ist jetzt der Nachweis der Abwesen-heit 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 Aus-fall- 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 50129 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




werden tolerierbare Gefährdungsraten (THR) aufgestellt. Die Gefährdungsbeherrschung muss aufzei-gen, dass die Gefährdungsrate (H) diesen Wert nicht überschreitet.

3.1.1.2.1. 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 Ge-fä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ährdun-gen, 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 Wartungsarbei-ten 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]

SIL

10−5 > T HR ≥ 10−6

10−6 > T HR ≥ 10−7

10−7 > T HR ≥ 10−8

10−8

> T HR ≥ 10−9

1

2 3 4

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 sor-tiert 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 50129 stellt an dieser Stelle Kriterien vor, von denen durch die Analysemethode mindes-tens eines zu erfüllen ist. Auf Grundlage dessen sind die THR abzuleiten und den Gefährdungen zuzu-ordnen.

• 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 analyti-schen Methoden

• Ableitung der THR aus anderen qualitativen Verfahren, falls hierdurch eine Liste von Gefährdun-gen und entsprechenden THR erzeugt wird

3.1.1.2.2. Berücksichtigung von CSM in der Risikoanalyse

Laut CSM-Verordnung (Verordnung Nr. 352/2009, gemeinsame Sicherheitsmethode) ist jede Ände-rung einer Funktion einer Risikoanalyse zu unterziehen. Dabei sind Änderungen der Funktionen als




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

3.1.1.2.3. 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 Sub-systeme 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 Ursa-chenanalyse können z. B. Fehlerbäume, Zuverlässigkeitsblockdiagramme oder Markov-Modelle ge-nutzt 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.

3.1.1.2.4. Risikoakzeptanzkriterien

Für den Schienenverkehr wird weder von den Zulassungsbehörden noch von den Normen oder Richt-linien ein Risikoakzeptanzkriterium vorgegeben. Die DIN EN 50126-1 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 Fol-genden 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.




ALARP

Das ALARP-Prinzip beschreibt eine Vorgehensweise in der Risikominderung von technischen Syste-men, 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 Um-rechnung 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 Berei-che 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 Beschreibung

Inakzeptables

Risiko

Das vom System ausgehende Risiko kann nicht akzeptiert werden. Es sind entspre-

chende Maßnahmen zur Risikominderung durchzuführen oder das System muss still-

gelegt werden.

Toleriertes Risiko oder

ALARP-Bereich

Es muss überprüft werden, inwieweit eine Minderung des entstehenden Risi-

kos möglich ist. Die identifizierten Maßnahmen zur Risikominimierung wer-

den jedoch einer Kosten-Nutzen-Analyse unterzogen. Es werden nur solche

Maßnahmen durchgeführt, die wirtschaftlich sinnvoll sind.




Risikobereich Beschreibung

Akzeptiertes Risiko 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 gleich-wertige 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 (To-desfä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 Si-cherheitsnachweise eher als willkürlich gewählt angesehen werden. Diese Zahl darf durch ein einzu-führendes technisches System nicht mehr als 5 % erhöht werden, wodurch das Risiko durch ein einzel-nes 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 Perso-nenschaden. 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.




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 glei-chen Sicherheit wie bei Einhaltung dieser. Dieses Prinzip der Ermittlung der Risikoakzeptanzkriterien wird nicht in der DIN EN 50126 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. Bei-den 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 Fort-schritt meist auch der Bezugswert erhöht, da die nachzuweisende Sicherheit des einzuführenden Sys-tems 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 Risi-kominimierung empfohlen [HSE2001]. Allerdings findet es vorrangig in der Arbeitssicherheit im Be-reich 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 anwendba-res Verfahren beschrieben, um die Risikoakzeptanz eines technischen Systems zu bewerten. Das briti-sche 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.




3.1.2 Sicherheitsnachweisführung

Eine wichtige Voraussetzung für die Zulassung von Verkehrsmitteln ist der Nachweis der Aufgabener-füllung. Zu diesem Zweck können verschiedene Methoden angewendet werden. Sie sollen es ermögli-chen, Ausfälle, Gefährdungen und die Auswirkungen sowie die Verbindungen untereinander zu identi-fizieren. 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 bezeich-net. 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 Ereig-nisbaumanalyse.

• Deduktive Verfahren: Die deduktiven oder auch Top-Down-Verfahren folgen dem entgegen ge-setzten Weg. Die Untersuchung geht vom allgemeinen zum speziellen. Sie werden z. B. zur Iden-tifizierung der Ursachen eines Ausfalls genutzt. Ein Vertreter dieser Art ist die Fehlerbaumanaly-se.

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 Verfah-ren 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äu-fig 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 Ausfallwahrschein-lichkeiten erforderlich. Mit Hilfe von quantitativen Verfahren wird eine statistische Bewertung ei-nes 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.

Anwendungsbereich Verfahren

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




Anwendungsbereich Verfahren

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 50129 (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.

3.1.2.1 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 50129 für Bahnanwendungen angeführt.

Bei Systemen oder Komponenten gleicher Ausführung, Verwendung gleicher Komponenten oder phy-sischer 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 deut-lich behindert.

Die Common Cause Analysis wird in fünf Schritte unterteilt, die in Abbildung 5 dargestellt sind.




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)

3.1.2.1.1. 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 Ein-flüsse oder Einrichtungen verletzt werden. Das Ziel der ZSA ist die Identifizierung der Quellen ge-meinsamer Fehler sowie ihrer Auswirkungen auf Nachbarkomponenten.

3.1.2.1.2. 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 Grund-lage für spezifische Anforderungen (z. B. Lufttüchtigkeitsanforderungen) bilden.

3.1.2.1.3. 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 Anforde-rungen, der Instandhaltung, der Umgebung, des Entwurfs, der Spezifikationen). Es wird die Unab-hä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

3.1.2.2 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 einzel-nen 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.




Anschließend erfolgt für jeden Zweig wieder die Betrachtung der möglichen Konsequenzen. Die Ent-scheidungen 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])

3.1.2.3 Fault Tree Analysis

Die Fault Tree Analysis (FTA) ist eine deduktive graphische Methode zur Identifizierung der Ursa-chen 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 Anpas-sungen, 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 Ent-wicklung 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 wer-den. Mit der FTA lassen sich Fehlerkombinationen und Bedienfehler darstellen, was sowohl für tech-nische, mechanische und auch Software Systeme anwendbar ist. Das Ergebnis ist eine graphische Auf-schlüsselung der Fehlerketten. Hierfür sind feste Symbole definiert worden, wie in Abbildung 7 darge-stellt.

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 kleins-ten Fehlerkombinationen können durch eine Reduzierung der bisherigen Wege gefunden werden. Abbildung 8 zeigt die allgemeine Darstellung eines Fehlerbaums.




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üp-fungen 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 Feh-lerbaumanalyse kann auch eine Markov-Analyse durchgeführt werden.

3.1.2.4 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 Fak-tor wird nicht berücksichtigt.

Die Darstellung der Ergebnisse der FMEA erfolgt in einer Tabelle, deren Spalten u. a. Bauteile, Funk-tionen, Ausfallarten, Auswirkungen und anzuwendenden Maßnahmen enthalten. Abhängig von der Komplexität des betrachteten Systems sollte die FMEA von einer interdisziplinären Gruppe durchge-führt werden, um möglichst alle wichtigen Risiken zu identifizieren.

3.1.2.4.1. 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 Sys-tems aus folgenden systemspezifischen Unterlagen zu ermitteln:

• Systemspezifikation

• Funktionsbeschreibung

• Zeichnungen

• Beschreibung der Einsatzbedingungen (z. B. Umweltbedingungen)




• Wesentliche Schnittstellen

3.1.2.4.2. Strukturanalyse

Am Anfang der Erarbeitung einer FMEA steht die Analyse der grundsätzlichen Struktur des zu be-trachtenden Systems. Dies erfolgt anhand der oben aufgeführten Dokumente. Hieraus lässt sich ablei-ten, welche Informationen über Systemgrenzen und Schnittstellen zwischen den angrenzenden Syste-men ausgetauscht werden. Die gewonnenen Zusammenhänge werden in einer Baumstruktur darge-stellt.

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.

3.1.2.4.3. 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üh-renden Funktionen zugeordnet. Dabei dienen die Ergebnisse der Strukturanalyse als Eingangsinforma-tionen für die Funktionsanalyse. Die identifizierten Funktionen des Systems werden wiederum gra-fisch aufbereitet, indem die Darstellung der Strukturanalyse um die Auflistung und Zuordnung der identifizierten Funktionen gemäß der Struktur eingefügt wird.

3.1.2.4.4. 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 heran-gezogen. 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 60812 vorgeschlagen.

3.1.2.4.5. 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 be-trachtet 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 Entde-ckung von Fehlern herangezogen und mit bewertet.

Die unterschiedlichen Ausfallarten können nach verschiedenen Kriterien (z. B. Sicherheit, Zuverläs-sigkeit, Kosten, Terminverzug etc.) bewertet werden. Diese Bewertung bzw. Ausfallbedeutungsanaly-se kann z. B. mittels Bewertungsgitternetzen durchgeführt werden. Abbildung 9 zeigt ein solches Git-ternetz, welches aus Gründen der Normkonformität an die Begrifflichkeiten der CENELEC [EN 50126] angepasst wurde.




Abbildung 9: Gitternetz für die Bewertung der Ausfallbedeutung

In dem Gitternetz wird die Eintrittshäufigkeit gegen die entstehende Auswirkung eines Fehlers aufge-tragen. 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 identifizier-ter 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ähr-licher ist der Fehler und umso dringender sind Maßnahmen zur Verhinderung des Ausfalls zu treffen.

3.1.2.4.6. 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 Sys-tem 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 Hand-lungsregeln 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.

3.1.2.5 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 Ge-fährdungen durch die Bildung einer Risikoprioritätszahl (RPZ), die sich aus der Bedeutung, der Auf-tretenswahrscheinlichkeit und der Entdeckungswahrscheinlichkeit eines Fehlers zusammensetzt.

Bei der Auswertung der Ergebnisse muss das Zustandekommen des RPZ-Wertes berücksichtigt wer-den. Derselbe Wert für eine RPZ kann aus einem ungefährlichen Ereignis mit einer hohen Auftretens-wahrscheinlichkeit sowie aus einer kritischen Auswirkung mit einer geringen Auftretenswahrschein-lichkeit gebildet werden. Besonders die RPZ bei Ausfallarten mit kritischen oder katastrophalen Ef-fekten müssen verringert werden. Dies kann durch Änderungen des Entwurfs oder Maßnahmen zur Früherkennung erreicht werden.




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.

3.1.2.6 Hazard and Operability Study

Die Hazard and Operability Study (HAZOP) ist eine qualitative Methode zur Identifizierung von Ge-fä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, Ingeni-eure, 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 wer-den, 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 Teilaufga-ben:

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.




3.1.2.7 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].

3.1.2.8 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 abgear-beitet werden. Die Gefährdungsidentifizierung und -bewertung sollte nach [FAA2000] zumindest die folgenden Punkte berücksichtigen:




• Gefährliche Komponenten (z. B. Treibstoffe, Giftstoffe, Drucksysteme)

• Sicherheitsrelevante Elementschnittstellen (z. B. Materialkompatibilität, Elektromagnetische Inter-ferenzen)

• Umweltbedingungen (z. B. extreme Temperaturen, Blitzeinschlag, Feuer)

• Verfahren für Betrieb, Tests, Instandhaltung und Notfälle (z. B. Analyse von Bedienfehlern, Le-bensrettungsanforderungen)

• Einrichtungen, Anlagen und Training (z. B. Lagerung brennbarer Materialien, Lärmquellen)

• Sicherheitsrelevante Anlagen, Schutzvorrichtungen, Alternativen (z. B. Systemredundanz, Brand-erkennung und -bekämpfung)

Mit Hilfe der in der PHA identifizierten Gefährdungen können Schwerpunkte für eine weitere Beo-bachtung, z. B. mit einer Fehlerbaumanalyse (FTA), gesetzt werden. Die Dokumentation einer PHA erfolgt in tabellarischer Form.

3.1.2.9 Sicherheitskonzept

Die VDV-Schrift 161 schlägt als Mittel zur Untersuchung der funktionalen Sicherheit eines Gesamt-systems – 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 wer-den können.

Die zu untersuchenden Funktionen des Gesamtsystems werden im Vorfeld zwischen Betreiber, Her-steller 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.

3.1.2.9.1. Funktionalitäten

In einem ersten Schritt werden im Rahmen der Erstellung des Sicherheitskonzeptes die zu untersu-chenden Funktionen beschrieben. Der Sinn der Funktion innerhalb des Gesamtsystems und die Aus-führung der jeweiligen Aktionen werden beschrieben. Dies geschieht anhand der Systemdokumentati-onen, 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 Sicherheitsphi-losophie 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.

3.1.2.9.2. Sicherheitsphilosophie

Ziel des Sicherheitskonzeptes ist es sicherzustellen, dass das System im Falle eines eintretenden Feh-lers 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 Eisen-bahnfahrzeuges, dass die zum Zugverband gehörenden Fahrzeuge jederzeit sicher zum Stillstand ge-bracht werden können.

Die Maßnahmen zur Absicherung des Systems gegenüber Fehlern sind im Rahmen der Dokumentati-on der Sicherheitsphilosophie zu beschreiben. Die Sicherheitsphilosophie wird durch diverse Sicher-heitsziele erreicht, die durch die Implementierung des Systems umgesetzt werden. Als Sicherheitsziele sind unter anderem anzusehen:




• Die Systemkonstruktion ist ständig während des gesamten Entwicklungsprozesses auf das anzu-

wendende 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 de-taillierte Beschreibungen (Handbuch) über den gesamten Lebenszyklus des Systems minimieren.

• Die Gefahr von Unfällen zu minimieren.

• Die Folgen von Unfällen zu mindern.

3.1.2.9.3. Risikograph

In einem vierten Schritt wird im Rahmen der Erstellung des Sicherheitskonzepts die zu untersuchen-den und im Schritt II.1 und II.3 beschriebenen Funktionen auf Grundlage einer qualitativen Bewer-tung 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 unterschied-lichen 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 Entschei-dungsbaum ü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] erfol-gen. 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 Um-setzung der nach VDV angesetzten Anforderungsklassen in die Sicherheitsintegritätslevel auf der Ba-sis der IEC 61508 erfolgt.

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




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 DAL

No safety effect Minor Major Hazardous / Severe Major Catastrophic

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- geord-neten 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 Insas-sen 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 Rah-men der Flugzeug-FHA erfolgt außerdem die Zuweisung der DAL anhand Tabelle 4. Die Klassifizie-rung „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




Systeme unterteilt, die wiederum diverse Subsysteme beinhalten. Das wird in Abbildung 13 am Bei-spiel 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 hin-durch, 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] aufge-führt und beschrieben.

3.1.2.11 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 Ausfall-kombinationen 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 Untersu-chungen aufgespürt werden. Durch das Aufstellen entsprechender Wartungs- und Instandhaltungspro-gramme soll das rechtzeitige Auffinden der Ausfälle sichergestellt werden. Die Aufgaben und Inter-valle dieser abgeleiteten Sicherheitsanforderungen werden im nachfolgend ausgeführten System Safe-ty Assessment (SSA) verifiziert.

3.1.2.12 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 Assess-ment (PSSA) aufgestellten Anforderungen, deren Ergebnisse hier als Eingangsdaten verwendet wer-den. 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




3.1.3 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 Sicher-heitskonzept sinnvoll einsetzbar. Unterstützt wird diese Einstufung auch durch den vorhandenen Ana-lyseansatz, 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 gleichzuset-zen - 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 kom-plexen Systems mit Sicherheitsverantwortung wird schnell unübersichtlich und ist nicht mehr be-herrschbar. 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

3.2.1 Grundlegende Betrachtung

Die sicherheitstechnischen Analysen der Sicherheitsorganisation entsprechen der Detaillierung gemäß den jeweiligen Entwicklungsstufen. Basierend auf der Risikoanalyse werden die RAMS-Aspekte und




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, darge-stellt. Wie den dort dargestellten Prozessketten zu entnehmen ist, sind die einzelnen Aspekte des En-gineerings dediziert zu betrachten. Der Themenblock der Ausbildung und technischen Kompetenz wird in diesem Ergebnisbericht nicht näher betrachtet, da diese Maßnahmen individuell und firmen-spezifisch 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 be-schriebenen Methodiken durch eine geeignete "Tool-Box", basierend auf Standard-Werkzeugen, um-gesetzt werden können, so dass eine vollständige und nachvollziehbare Beweiskette der Einhaltung der definierten Sicherheitsziele erreicht werden kann.




Abbildung 14: RAMS-Prozess

Exemplarisches Standardflußdiagramm RAMS

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

- ...

Dokumente1)

Inhalte

Sicherheitskonzept

(SySRS)

24.04.2013

Hinweise

1) 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

- 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ührungs-

methodiken /

Instandhaltungskonzept

Sicherheitstechnische (RAMS) –

Anforderungen

(teilweise SySRS, SyDS, ...)




Während die theoretischen mathematischen Modelle des RAMS-Engineerings bzgl. RAMS-Theorie / mathematischer Modelle von Seiten der Forschung analysiert und entsprechend abgeleitete Vorge-hensmodelle bewertet worden sind, wurden die Anforderungen an den Managementprozess bislang noch sehr allgemeingültig beschrieben. Die Modellierung von Risiken und Fehlern, die zu einer Ge-fährdung führen, sei es in der Theorie sowie aufgrund von Unfällen, stand dabei im Fokus der bisheri-gen Forschung und Normierung. Anhand der konkreten Szenarien und vorgekommenen Ereignisse konnten allgemein gültige Klassifizierungen aufgesetzt werden. Dies zeigt sich u.a. in den Ergebnisbe-richten 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 Jona-than F. Luedecke), Signal+Draht, 2003

• Anwendung der Methode STAMP1 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), Sig-nal+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 unzu-reichenden Werkzeuge nicht weiter betrachtet. Diese Managementprozesse wurden, abgeleitet aus den Normen, firmenspezifisch entwickelt und umgesetzt. Dies führte dazu, dass durch die internen manu-ellen 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 ef-fektiv zu gewinnen ist. Außerdem mussten externe Institutionen, seien es die Gutachter oder die Zu-lassungsbehö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 wer-den:

• Sicherheitsbezogene Anwendungsbedingungen - Gratwanderung zwischen Sicherheit und Auf-wand (Friedemann Bitsch, Huw Gough), Signal+Draht, 11, 2012

1 STAMP - Systems Theory Accident Modeling and Process




• Thema der safe.tech 2013:

• Komplexitätsbeherrschung in der sicherheitskritischen Software-Entwicklung durch agile Me-thoden 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 Verifika-tion 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 15504 der AUTOSIG2 wur-den SPICE als Bewertungsrichtlinie der Unternehmensprozesse, mit dem ursprünglichen Schwerpunkt auf den Software-Erstellungsprozess, etabliert. Dieses Modell beschäftigt sich vorrangig mit der Pro-zess-Assessment-Modellierung und -Dimensionierung und ermöglicht eine Fähigkeits- oder Reife-grad-Bewertung. Seit 2006 wurde diese Norm zur Bewertung des Managementverfahrens in einen internationalen Standard ISO/IEC 15504 vollständig überführt. Gegenstand dieser Norm wurden dabei u.a. die Forderungen nach unterschiedlichen Traceability-Matrizen, die aufgrund von Spezifikations-tools wie Doors heute State-of-the-Art sind. Eine besondere Betrachtung der Verfolgbarkeit der Si-cherheitsvorgaben wurde nicht aufgenommen. Dies erfolgt vsl. in der ISO 15504 Part 10 "Safety ex-tension", 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 Toolket-te 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.




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_Feinkon-zept_Diagnose.doc) entnommen werden können, müssen dabei noch innerhalb der Toolkette entwi-ckelt werden. Ob weitere Normen wie die deduktiven Verfahren FTA DIN 25424 oder weitere induk-tiven Verfahren wie HAZOP IEC 61882 (PAAG-Verfahren) oder Ereignisbaumanalysen DIN 25419 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 Attri-bute, 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 auf-grund der Einstufung des Risikos, der Wahrscheinlichkeit des Eintritts und der Häufigkeitseinschät-zung 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 durchge-führten FMEA in das Tool überführt werden.

Durch die Implementierung der RAMS-Methoden in ein ALM-Tool ist der erste Schritt zu einer integ-rierten Toolkette inklusive des Risk-Management-Prozesses umgesetzt worden. Weitere Schritte bzgl. der Umsetzung werden im folgenden Kapitel dargelegt, in dem die Modellierung und Abhängigkeits-betrachtung 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 Ände-rungen 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 unter-schiedlicher ALM-Tool-Hersteller ausgetauscht werden können. Erste Ansätze einer Standardisierung dieser Interoperabilität kommen aus der Automobil-Industrie. Ein Austausch von Anforderungen in-klusive Anhänge und Attribute kann heute mittels des Standards RIF (Requirements Interchange For-mat) zwischen unterschiedlichen ALM-Tools erfolgen. Im Gegensatz zur Verwendung von Standard-Office-Komponenten, wie Word-, Excel- oder PDF-Dateien, ermöglicht dieser Standard den verlust-freien 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 Daten-austausch einerseits und des Datenmodells andererseits zentral aufgesetzt werden, um die Interopera-bilität zukünftig sicherzustellen. Dies sollte in einem weiteren Fördervorhaben konkretisiert werden.

3.2.2 Vorschlag für einen ALM-Workflow zur Nachweisführung von Änderungen

Gemäß dem Ergebnisbericht der AG1 dieses Fördervorhabens kann festgehalten werden, dass die "un-

ternehmensinterne Prozessregelungen und Arbeitsanweisungen immer schon der kritischen Bewertung

unterzogen gewesen (Anmerkung: sind), die effektiv Einfluss auf die Qualität und Sicherheit der Pro-

dukte im Produktlebenszyklus hatten. Die Erfahrung und Fachkompetenz spiegelt sich in den Quali-

tätshandbüchern der beteiligten Unternehmen wider. Der Erhalt der Qualität und Sicherheit der Pro-

dukte im Produktlebenszyklus wird durch die ständige Kontrolle im Rahmen von Auditierungen si-

chergestellt. Über diese externen Auditierungen wird abgesichert, dass die unternehmensinternen

Prozessregelungen und Arbeitsanweisungen auch jeweils den aktuellen Stand der Normung berück-

sichtigen"




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.




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.




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 Systemanforde-rungen in Tabellenform gezeigt.

Abbildung 20: tabellarische Darstellung von Systemanforderungen




Basierend auf den Systemanforderungen können die Aktivitäten des RAMS-Prozesses gestartet wer-den. Z. B. werden einzelne Risiken sowie die daraus abgeleiteten Anforderungen definiert. In der Ab-bildung sind dabei besondere Attribute zu erkennen, die nicht Gegenstand einer "normalen" Systeman-forderung 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 nachzu-weisen, 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 Hardware- wie die Software-Entwicklung können somit schnell alle Vorgaben erkennen und entsprechend in der weiteren Detaillierung aufgreifen.




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 Design-entscheidungen mit der Gefährdung verlinkt werden. Als Beispiel wurde das Risiko mit einer Anfor-derung des Typs "mechanische Entwicklung" verlinkt (hier: ein spezieller Filter muss eingebaut wer-den).




Abbildung 25: Ableitung einer Hardware-Anforderung aus einer Aktion

In der Nachweisführung ist durch die Auswahl von diesen genannten Traceability-Matrizen u.a. jeder-zeit eine Übersicht über die Durchführung der erforderlichen Aktionen möglich. Zeitgleich kann in-nerhalb 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, rele-vant 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

3.2.3 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ücksich-tigt werden. Das "Verfahren zur Vereinfachung des Zulassungsverfahrens bei Änderungen von bereits nach EN 50129 zugelassenen Hardware-Komponenten" zeigt schon auf, dass durch die Wahl be-stimmter 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:




• 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 wer-den, 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 entspre-chend dem Zulassungsverfahren die angezeigten Veränderungen gemäß den hinterlegten Workflows initiieren.




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.




Abbildung 31: Verlinkung Suspect

Abbildung 32: Verlinkung suspect beim Objekt

3.2.4 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




zu Projektbeginn aufgesetzt und wird bis zum Projektende von ggf. unterschiedlichen Instanzen fort-geschrieben.

Die Definition eines Gefährdungslogbuchs kann zu Projektbeginn in Analogie zur Definition von si-cherheitsbezogene 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 einzel-ner 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.

3.2.5 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 nachvoll-ziehbar 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




• Sicherung der Flexibilität durch die Anpassung bewährter Verfahren an Teams jeder Größenord-nung 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 61508 oder Bahn-normen CENELEC, in Prozess-Workflows hinterlegt werden können,

• die zusätzlichen Anforderungen der CENELEC-Normen durch Add-Ins in den ALM-Tools abge-deckt 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 61508 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 Auf-sichtsbehö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 zwi-schenzeitlich Mischformen) und der daraus resultierenden Obsolezenz-Problematik kann durch Auf-setzen 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 Hard-ware 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 Anforderun-gen aus Fehlerbetrachtungen, aus dem Sicherheitskonzept, der Gefährdungsanalyse, der Fehlerkapse-lung 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.


Zusammenfassung und Ausblick



Zusammenfassend können folgende Punkte festgehalten werden:

• Stand der Technik ist es, dass heute schon eine Standardisierung der erforderlichen Dokumentati-on weit fortgeschritten ist. Die Erkenntnisse der AG3 zeigen, dass ein einheitlicher Maßnahmen-katalog 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 geson-derte Fehlerbetrachtung und -strategie bzgl. der Kapselung. Durch Attributierung der sich daraus ergebenden Anforderungen kann ein Standard-Prozess definiert werden, der ein einfaches Zulas-sungsverfahren 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 umfassen-

der 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 Betrach-

tungsgegenstandes 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 ge-

troffenen Annahmen nachvollziehbar und korrekt?"

Aus dieser Betrachtung der Arbeitsgruppe NTZ sowie den Ergebnissen der AG5 kann abgleitet wer-den, dass neben der Definition der firmenspezifischen Projektabwicklung eine durchgehende Prozess-kette mittels eines ALM-Tools aufgestellt werden sollte. Durch diese Definitionen allgemeiner Workflows können die Prozesse optimiert werden, was wiederum zu einer vereinfachten und termin-lich verkürzten Zulassung bzw. Änderungszulassung führen kann. Aufbauend auf den Ergebnissen dieses Fördervorhabens sollte eine Definition dieser Prozesse und deren Optimierungen erfolgen.


Anhang


5 Anhang


AKB2004-1 Alran, Dominique; Berg, Paul van den; Kuijlen, Hans (2004): European Com-mission Fifth Framework Programme SAMRAIL - D.2.3: Common Safety Methods, Report. SAMRAIL Consortium

AMB2001 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 2001-01-0674, 05.03.2001 bis 08.03.2001, De-troit, Michigan, SAE International - The Engineering Society for Advancing Mobility Land Sea Air and Space, ISSN: 0148-7191

ARP 4754 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)

BRA2004 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

BRA2006 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 3-7771-0353-5

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 00-56 "Ministry of Defence - Defence Standard 00-56 - Safety Management Require-ments for Defence Systems - Part 1 - Requirements - Issue 4"’ in der Version vom 01.06.2007, Defence Equipment and Support, UK Defence Standardization, Glasgow

EHS2003 Environmental Health and Safety - University of Washington (1999/2003): Ra-diation Safety Manual - Section 7: ALARA Program. Radiation Safety Office - Environmental Health and Safety (EH+S) der Universität Washington, Seattle

FAA2000 Federal Aviation Administration (2000): FAA System Safety Handbook. Inter-netquelle: http://www.faa.gov/library/manuals/aviation/risk–management/ss–handbook (Stand: Januar 2009)

FAA2005 Federal Aviation Administration / EUROCONTROL (2005): FAA / EU- RO-CONTROL ATM Safety Techniques and Toolbox - Safety Action Plan-15. Ver-sion 1.0 vom 24.01.2008

HLH2005 Hlinomazová, Z.; Hrazdira, I. (2005): ALARA - Principle and Safety Problems of Diagnostic Ultrasound. SCRIPTA MEDICA, Volume 78, Ausgabe 6/2005, Seiten 341-346, Faculty of Medicine, Masaryk University, Brno

HSE2001 Health and Safety Executive (2001) - Reducing risks, protecting people - HSE’s decision-making process. HSE Books, ISBN 0-7176-2151-0

KNE2001 Knepper, Roger (2001): Technische Sicherheit - Der Sicherheits- und Zuverläs-sigkeitsprozess in der zivilen Luftfahrt. In: Achtes Kolloquium Luftverkehrs an der Technischen Universität Darmstadt, Wintersemester 2000/2001, Seiten 115-148, Arbeitskreis Luftverkehr der Technischen Universität Darmstadt [Hrsg.], Darmstadt, ISBN 3-931385-07-08

LIG2008-1 Liggesmeyer, Peter (2008): Safety and Reliability of Embedded Systems - Risi-koakzeptanz-Verfahren. Vorlesungsunterlagen, Wintersemester 2008, Tech-nische Universität Kaiserslautern

LIG2008-2 Liggesmeyer, Peter (2008): Safety and Reliability of Embedded Systems - Safety and Reliability Analysis Models: Overview. Vorlesungsunterlagen, Wintersemes-ter 2008, Technische Universität Kaiserslautern

MIE2004 Mihm, Peter; Eckel, Andreas (2004): European Commission Fifth Framework Programme SAMRAIL - WP 2.4 Acceptabel Risk Level - Final Report. SAM-RAIL Consortium

NeGSt_AG3 NeGSt_Teilbericht_2200.0u3_1.0.pdf

NeGSt_CSM NeGSt_Ergebnisbericht_2100_AUM_2013-04-18.pdf


Anhang


NeGSt_CSM_Signifkanz NeGSt_Ergebnisbericht_2100_Signifikanz_20120828.pdf

NeGSt_CSM_AVR NeGSt_Ergebnisbericht_2100_AVR_20130626.pdf

RSS2007 Rail Safety and Standards Board [Hrsg.] (2007): Engineering Safety Manage-ment (The Yellow Book) - Volumes 1 and 2 - Fundamentals and Guidance. 4. Auflage, London, ISBN 978-0-9551435-2-6

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 1-921168-80-3

SSS1997 System Safety Society, New Mexiko Chapter (1997): System Safety Analysis Handbook. Albuquerque, Library of Congress Catalog Card Number 093-84964 (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 as-sessment - Volume 1: Methods and Techniques. John Wiley and Sons Ltd, Chichester, ISBN 0-471-93048-2

WER2002 Wery, Sten (2002): Anwendung der Functional Hazard Analysis (FHA) in der Eisenbahnsignaltechnik am Beispiel ETCS Level 2. Diplomarbeit an der Techni-schen 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 Inte-grated Aerospace. Systems. Certification of Ground/Air Systems Seminar (Ref. No. 1998/255), Seiten 4/1-4/6, London



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



Anhang


ETA Event Tree Analysis

FHA Functional Hazard Assessment

FMEA Failure Mode and Effects Analysis

FMECA Failure Mode, Effects and Criticality Analysis

FTA Fault Tree Analysis

GAMAB Globalement au moins aussi bon

GAME Globalement au moins equivalent

HAZOP Hazard and Operability Study

HR Hazard-Rate




MEM Minimum endogenous mortality

MGS Mindestens gleicher Sicherheit

PHA Preliminary Hazard Analysis

PRA Particular Risk Assessment

PSSA Preliminary System Safety Assessment

RAMS Reliability, Availability, Maintainability, Safety

ReqIF/RIF Requirements Interchange Format

RPZ Risikoprioritätszahl

SFAIRP So far as is reasonably practicable


SPICE Software Process Improvement and Capability Determination

SSA System Safety Assessment

THR Tolerierbare Hazard-Rate

VDV Verbund Deutscher Verkehrsunternehmen

ZSA Zonal Safety Analysis



Teilbericht

AP 2300

Ansätze zur Optimierung toolgestützter Teststrategien

09.08.2013

Laufzeit: 01.09.2011 – 31.08.2013





Datum Bearbeiter Version Inhalt 12.04.2013 Suter 0.1 Erstellung Grobkonzept 28.05.2013 Suter 0.2 Erstellung Feinkonzept 24.06.2013 Suter 0.3 Erste Ausgabe 02.07.2013 Suter 0.4 Abschluss 04.07.2013 Möller-Neustock 0.5 Review 05.07.2013 Suter 0.6 Abschluss 17.07.2013 Neustock 0.7 Review 09.08.2013 Neustock

Winkler 1.0 Finalisierung

Inhaltsverzeichnis

1 Einleitung.........................................................................................................................................4

2 Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement..........................................................................................................................5

2.1 Fehlerdefinition ..........................................................................................................................5

2.2 Gefährdungsklassen...................................................................................................................5

2.3 FMEA..........................................................................................................................................5

2.4 Grundlagen.................................................................................................................................5 2.4.1 Sicherheitsintegritätslevel (SIL) .........................................................................................5 2.4.2 Fehlerbaumanalyse (FTA) ..................................................................................................6

2.5 Fehlererkennung ........................................................................................................................6 2.5.1 Ausfallbetrachtungen..........................................................................................................6 2.5.2 Bauteilbetrachtung..............................................................................................................6 2.5.3 Maßnahmen zu einer höheren Wahrscheinlichkeit zur Aufdeckung von Fehlern..............6

3 Ansätze zur Optimierung toolgestützter Umsetzung von Teststrategien...................................7

3.1 Überblick über die Zielplattform .............................................................................................7

3.2 Toolchain.....................................................................................................................................9

3.3 Testvorgaben ..............................................................................................................................9

3.4 Testkonzept für das Generische Produkt ................................................................................9 3.4.1 Schritt 1: Erstellen der Prüffallspezifikation für eine Steuereinheit ...................................9 3.4.2 Schritt 2: Prüffalldurchführung am Realsystem ...............................................................10 3.4.3 Schritt 3: Prüffalldurchführung am Simulationssystem....................................................10 3.4.4 Schritt 4: Vergleich von Original- und Simulationssystem ..............................................10

3.5 Ansatzpunkte für Prozess- und Tooloptimierungen.............................................................11 3.5.1 Modellierungstool.............................................................................................................11 3.5.2 Testerstellung und -verwaltung ........................................................................................12

3.6 Evaluierung eines ALM-Tools ................................................................................................13 3.6.1 Grundkonzept....................................................................................................................14 3.6.2 Positive Feststellungen aus der Evaluation.......................................................................16 3.6.3 Negative Feststellungen aus der Evaluation ....................................................................16

4 Fazit und Ausblick ........................................................................................................................17



5 Anhang ...........................................................................................................................................18

5.1 Anhang 1: Referenzen .............................................................................................................18

5.2 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................................................. 12

Abbildung 5: Beschreibung des Verhaltens der Zustandsmaschinen während des Prüffalls ................. 13

Abbildung 6: Grundkonzept der Testanbindung an Polarion................................................................. 14

Abbildung 7: Anstoßen von Testfällen................................................................................................... 15

Abbildung 8: Rückgabe von Testergebnissen ........................................................................................ 16

Tabellenverzeichnis

Tabelle 1: Einteilung der Sicherheitsintegritätslevel................................................................................ 5

Tabelle 2: Testkategorien ......................................................................................................................... 9


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 tool-gestützt, nachgewiesen werden muss. Es wurde festgestellt, dass die globalen Sicherheitsanforderun-gen des RAMS-Prozess ab der Phase des Designs einer Untersuchung, sowie einer Detaillierung unter-liegen. 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, Durch-führen und Verwalten von Tests“ bis zur Nachweisdarlegung im Sicherheitsnachweis (TSB). Im Fol-genden 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.


Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement


2 Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehler-management

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 vorausge-setzt 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 Feh-lers 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 Auswir-kungsanalyse) versucht alle möglichen Fehler, die Fehlerfolgen und die schlimmsten möglichen Feh-lerverkettungen 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 Feh-lers. 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 Ausfallar-ten, welche verschiedene Auswirkungen auf das System haben. Diese Betrachtungen fließen dann in die RAMS-Berechnungen eines Systems mit ein.

2.4 Grundlagen

2.4.1 Sicherheitsintegritätslevel (SIL)

Das Sicherheits-Integritätslevel SIL (Safety Integrity Level) gibt die Ausfallgrenzwerte für eine Si-cherheitsfunktion, die in der Betriebsart mit hoher Anforderungsrate oder in der Betriebsart mit konti-nuierlicher Anforderung betrieben wird an.

Sicherheits-Integritätslevel

Rate gefahrbringender Ausfälle der Sicher-heitsfunktion

4 3 2 1

Tabelle 1: Einteilung der Sicherheitsintegritätslevel


Grundlagen und Definitionen zur Fehlererkennung, -verfolgung und zum Fehlermanagement


2.4.2 Fehlerbaumanalyse (FTA)

Die Fehlerbaumanalyse (FTA) ist ein „ableitendes“ bzw. „fortführendes“ Verfahren, welches ein Sys-tem, 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 Ent-wicklungsphase erkannt werden, um Schwachstellen rechtzeitig beheben zu können.

2.5.1 Ausfallbetrachtungen

Durch RAMS-Nachweisdokumentationen wird dargelegt, wie Fehler rechtzeitig erkannt und behoben werden. Die RAMS-Prozesse (Reliability-Zuverlässigkeit, Availability-Verfügbarkeit, Maintainabili-ty-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 Kompo-nenten eines Systems hat hierbei eine große Bedeutung. Sie hilft dabei, rechnerisch eine Zuverlässig-keit 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 29500 ermittelt. Die Ausfallraten für die verwendeten Bauteile werden vom Hersteller an-gegeben 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.

2.5.2 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 zusammen-geschaltet.

2.5.3 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 Bau-teils bzw. der Baugruppe vorgenommen werden kann.


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 Teststra-tegie 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 verfah-rensgesicherten 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 Anschalt-baugruppen (xCM) zu Ansteuerung der Außenelemente. Das GP umfasst auch die Treiberebene für




die Außenelemente und soll die Stellwerkslogik der GA von den jeweils eingesetzten Hardwarekom-ponenten 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 Para-metrisierung über einen SA-Anteil. SA definiert eine Spezifische Applikation und beinhaltet zum Bei-spiel die örtlichen Stellwerkselemente sowie die einzelnen Fahrstraßen.

Abbildung 3: Schnittstellen der Teilsysteme GA und GP




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 Anfor-derungsmanagementtool 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 Beschreibung

Bedienplatz - Squish Tests

GA - automatisierte Modultests

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 Zu-sammenwirken. Eine Teilmenge sind Prüffälle, die aus Betrachtungen der FMEA ent-stammen oder bestimmte Hardwareausfallszenarien testen.

Schnittstellentests - GA/GP Prüffälle, die das korrekte Zusammenspiel der beiden Kom-ponenten 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 Zusammen-spiel

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 darge-stellt werden.

Es werden Ansatzpunkte für eine Verbesserung bzgl. Verwaltung, Effizienz und Transparenz darge-stellt, mit der Intension, die unterschiedlichen Rollen in der Nachweisführung gemäß CENELEC signifikant zu unterstützen.

3.4.1 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 sol-ches Prüfszenario wäre beispielsweise das Umstellen der Weiche von links nach rechts. Hierbei han-




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 Teil-schritte 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.

3.4.2 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 Soft-wareanforderungsspezifikation voraussetzt. Für die Dokumentation wird ein Datenlogger verwendet, der an den physikalischen Ein- und Ausgängen angeschlossen wird.

3.4.3 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 Hardwarekompo-nenten aufzubauen. Dennoch bestehen der Wunsch und die Notwendigkeit nach einer solchen Testan-lage.

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 digita-len 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 Testszena-rien 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.

3.4.4 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 Simulationssys-tem 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 Au-toPruV. 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.




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 (Skrip-te, 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 Sui-te, bietet bereits viele gemeinsame Schnittstellen und Abhängigkeiten, die für eine CENELEC-konforme Entwicklung notwendig oder mindestens hilfreich sind, wie z.B. Versionierung und Tracea-bility. Gerade im Bereich der Testverwaltung offenbaren sich für den Bereich der Stellwerksentwick-lung jedoch Grenzen.

Es ist grundsätzlich möglich, Testsuiten und Testcases anzulegen und/oder mit Anforderung oder De-fekten zu verknüpfen. Eclipse-basierenden Tools sind jedoch stark auf das Testen von objektorientier-ten 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 umsetz-bar. 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 Fehler-fall Folgereaktionen auszulösen. Dies könnte z.B. die Erstellung eines Defekts beinhalten. Ein Ansatz-punkt wäre also alternative Verwaltungstools einzusetzen.

Die Möglichkeit eines modernen Application Lifecycle Management Systems (ALM) soll die Evaluie-rung 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än-dig 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 Automatisie-rungsgrad und die Erarbeitung eines zentralen Testmanagement Systems.

Wie bereits zuvor erwähnt, wird bei der Auswertung der Prüffälle ebenfalls die Spezifikation mit ein-bezogen. 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 Model-lierung im Bereich der Stellwerkstechnik auf SPS-Basis Einschränkungen hinzunehmen. Da objektori-entierte Hochsprachen wie C++ oder Java in diesem Umfeld nicht zulässig sind und kein bislang eva-luiertes Modellierungstool die volle angestrebte Funktionalität bietet, hat sich Funkwerk dafür ent-schieden, 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, eben-falls evaluiert im MENGES-Förderprojekt). Dies setzt jedoch eine Akzeptanz in der Sicherheitsnach-weisfü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.

3.5.1 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. Schnittstellensig-nale, 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




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 programm-technisch weiterverarbeitet werden kann, lassen sich auch automatisiert atomare Tests, also Schnitt-stellentests auf Modulebene, generieren und zwar für alle relevanten Permutationen der Zustandsüber-gä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 Software-verifikation unterstützen bzw. diese auch ersetzten. Die 1:1 Umsetzung der UML-Spezifikation könn-te somit nachgewiesen werden.

3.5.2 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 sol-chen Prüffallspezifikation umfasst teilweise, je nach Komplexität der Steuereinheit, mehr als einhun-dert 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 Salz-nebel-, 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




Nach heutigem Kenntnisstand gibt es kein marktgängiges Werkzeug, welches die hier aufgeführten Anforderun-gen 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 Forma-te 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 geschaf-fen 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 Infor-mation aus der Datenbank. Formale Vorgaben könnten durch Templates realisiert werden. Die auto-matisierte Dokumentengenerierung wäre auf viele Arten von Dokumenten des ganzen Entwicklungs-prozesses 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 Ent-wicklung 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.




3.6.1 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 ei-nem Test Automation Server (TAS). Für die meisten Endanwender sind beide Server getrennte Syste-me.

In unserem Fall besteht der TAS aus einer geeigneten Testanlage, gekoppelt mit einem Simulations-system. 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üh-rungsumgebung verfügbar sein müssen.

3.6.1.1 Aufrufen eines Builds

Um den Prozess der gemeinsamen Nutzung von Informationen zwischen Polarion QA (dem Collabo-rative 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.

3.6.1.2 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




3.6.1.3 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 verdeutli-chen.

Abbildung 7: Anstoßen von Testfällen

3.6.1.4 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üh-rung 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 vorgese-hen, der diese Aufgaben übernimmt.




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 durchge-fü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 fehl-schlagen. Am Ende wird die xml Datei (-en) automatisch gelöscht. 3.6.2 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 getrof-fen werden.

• Die lokale Installation war vollkommen problemlos.

• Testcases/Testruns sind importierbar und exportierbar im Excelformat. Damit besteht eine einfa-che 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. Systemintegra-tionstests und Checklisten).

• Schnittstellen zu externen Testservern sind implementiert.

• Neueste Erweiterung: Integration mit Matlab/Simulink

3.6.3 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 Pola-rion verknüpft werden (siehe xUnit framework + xml format).


Fazit und Ausblick


4 Fazit und Ausblick

Im Laufe des Entwicklungsprozesses elektronischer Stellwerke wurden viele Erfahrungen in den Be-reichen 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. Festzu-stellen 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 Verwen-dung 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 Test-systemen. 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 beson-ders wichtig im Hinblick auf den Einsatz in einem geplanten DB AG Testlabor (siehe „AP 1300 -Entwicklung eines Testkonzeptes“), welches eine zentrale Rolle in der Optimierung des Zulassungs-prozesses für die DB AG einnehmen soll.

Ein weiteres Beispiel für einen praktischen Einsatz wäre die bereits im Kapitel 2.5.3 skizzierte Anbin-dung an eine Diagnosedatenbank (siehe Teilergebnisbericht "NeGSt_Ergebnisbericht_2300AG5_Fein-konzept und Prototyp für eine RAMS-Diagnoseplattform").


Anhang


5 Anhang


[1] Polarion 2013 User Guide

[2] Polarion QA for Test Managers

[3] User-Guide-Automated-Test-Execution-with-Polarion



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)


GP Generisches Produkt

ITG Integrationsprüffälle

KM Konfigurationsmanagement



ReqPro (IBM-Tool) Rational Requisite Pro


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



Teilbericht

AP 2300

Feinkonzept und Prototyp für eine RAMS-Diagnoseplattform

05.08.2013

Laufzeit: 01.09.2011 – 31.08.2013





Datum Bearbeiter Version Inhalt 15.02.2013 Sven Markus 0.1 Entwurf 23.05.2013 Antje M. Möller-Neustock 0.2 Übernahme theoretischen Grundlagen 05.06.2013 Antje M. Möller-Neustock 0.3 Übernahme Fehlerbetrachtung / Vorgehensweise

Prototyp 05.06. 2013 Michael Keste 0.4 Übernahme Konzept-Dokument Diagnose 12.06. 2013 Sven Markus 0.5 Aufnahme Erkenntnisse Prototyping 13.06.2013 Antje M. Möller-Neustock 0.6 Erweiterung theoretische Grundlagen 25.06. 2013 Antje M. Möller-Neustock 0.7 Ausblick/allgemeine Entwicklung 03.07.2013 Antje M. Möller-Neustock 0.8 Abschluss nach fachlichen Review 25.07.2013 Antje M. Möller-Neustock 0.9 Korrekturen nach Vorstellung der Ergebnisberichts 05.08.2013 Holger Neustock


Inhaltsverzeichnis

1 Einleitung.........................................................................................................................................5

2 Theoretische Grundlagen ...............................................................................................................6

2.1 Definition der Verfügbarkeit .......................................................................................................6

2.2 Definition der Instandhaltbarkeit................................................................................................6

2.3 Definition der Zuverlässigkeit......................................................................................................6

2.4 Grundlagen der Zuverlässigkeitsanalyse....................................................................................6

2.5 Wichtige Größen und Formeln zur Berechnung der Zuverlässigkeit....................................10 2.5.1 Begriffe und Einheiten ..............................................................................................................10 2.5.2 Berechnung von MTTF-Werten...............................................................................................11

2.5.2.1 Grundlagen........................................................................................................................ 11

2.5.2.2 Zuverlässigkeitsblockdiagramme ..................................................................................... 11

2.5.2.3 Anmerkungen zur MTTF-Berechnung ............................................................................. 12

2.5.2.4 Arten der MTTF-Ermittlung ............................................................................................. 12 2.5.3 Zusammenhang .........................................................................................................................12 2.5.4 Part-count-Methode ..................................................................................................................13 2.5.5 Redundanz.................................................................................................................................14

2.5.5.1 Redundanz beim 1oo2 (1 out of 2) -System (ohne Reparatur) ......................................... 14

2.5.5.2 Redundanz beim 2oo3 (2 out of 3) -System (ohne Reparatur) ......................................... 14

2.5.5.3 Gleichzeitige Fehler in mehreren Komponenten (redundante Systeme mit Reparatur) ... 15

2.6 Wichtige Größen und Formeln zur Berechnung der Sicherheit.............................................16 2.6.1 Begriffe und Größen: ................................................................................................................16 2.6.2 Common-Cause-Anteil .............................................................................................................17 2.6.3 Kanalbezogene mittlere Ausfallzeit ..........................................................................................17 2.6.4 Wichtige Formeln zur Berechnung von PFH............................................................................17

2.6.4.1 Für 1oo1-Systeme ............................................................................................................. 17

2.6.4.2 Für 1oo2-Systeme ............................................................................................................. 17

2.7 FMEA...........................................................................................................................................18



2.8 Zusammenhang zwischen Siemens-Norm, FMEA, Zuverlässigkeit, Sicherheit und RAMS-Nachweisdokumenten .................................................................................................................20

2.9 Fehlerbaumanalyse .....................................................................................................................21 2.9.1 Qualitative Fehlerbaumanalyse.................................................................................................24 2.9.2 Quantitative Fehlerbaumanalyse...............................................................................................24 2.9.3 Mathematische Vorgehensweisen bei der Fehlerbaumanalyse.................................................24

2.9.3.1 Berechnung der Ausfallwahrscheinlichkeit im Fehlerbaum............................................. 24

2.9.3.2 Common-Cause-Fehler-Analyse in einem Fehlerbaum.................................................... 25

3 Anforderungen an Diagnosemeldungen zur Erhärtung von Prognose-Werten aus den RAMS-Nachweis ...........................................................................................................................26

3.1 Anforderungen für die Diagnose archivierter Daten...............................................................26

3.2 Anforderungen für die Diagnose aktueller Daten....................................................................26

3.3 RAMS Anforderungen................................................................................................................27

3.4 Abfrage der Diagnoseinformationen .........................................................................................27

3.5 Architekturentwurf für die Diagnose.......................................................................................27 3.5.1 Übersicht Diagnose-Netzwerk ..................................................................................................28 3.5.2 Beschreibung Diagnose-Datenströme.......................................................................................29 3.5.3 Beschreibung Störungsermittlung Bedienzentrale....................................................................29 3.5.4 Analyse von Architekturen gemäß bestehender Systeme .........................................................29

4 Anforderungen an den Prototypen..............................................................................................31

5 Ergebnis aus den prototypischen Betrachtungen.......................................................................32

5.1 Eine beispielhafte Betrachtung der Fehlermöglichkeiten .......................................................32 5.1.1 Quelle der Fehlermöglichkeiten................................................................................................32 5.1.2 Darstellung der Fehlermöglichkeiten........................................................................................33

5.2 Analysemöglichkeiten .................................................................................................................34 5.2.1 Motivation.................................................................................................................................34 5.2.2 Applikationen............................................................................................................................34 5.2.3 NeGSt-Client.............................................................................................................................35 5.2.4 Nutzer des NeGSt-Clients.........................................................................................................35

5.2.4.1 Administration .................................................................................................................. 35

5.2.4.2 Aktuelle Informationen..................................................................................................... 36

5.2.4.3 Auswertung....................................................................................................................... 37

5.2.4.4 Wartungsinformationen .................................................................................................... 38 5.2.5 Ausblick zum Client..................................................................................................................40

6 Zusammenfassung und Ausblick .................................................................................................41

7 Anhang ...........................................................................................................................................42

7.1 Anhang 1: Referenzen.................................................................................................................42

7.2 Anhang 2: Abkürzungen ............................................................................................................42

Abbildungs- und Tabellenverzeichnis

Abbildung 1: FMEA-Analyse ................................................................................................................ 19



Abbildung 2: Grafische Darstellung der Zusammenhänge .................................................................... 21

Abbildung 3: Grafische Darstellung von logischen Verknüpfungen in einem Fehlerbaum................... 22

Abbildung 4: Grafische Darstellung der zu analysierenden Schaltung als Zuverlässigkeits-Blockdiagramm ...................................................................................................................................... 23

Abbildung 5: Zusammenhang zwischen quantitativer und qualitativer FTA......................................... 24

Abbildung 6: Aufbau des Diagnose-Netzwerkes ................................................................................... 28

Abbildung 7: Fehlerklassifizierung am Beispiel RBLK (Alister) .......................................................... 32

Abbildung 8: Rechte und Anzahl der Nutzer vom Client. ..................................................................... 36

Abbildung 9: Darstellung der aktuellen Informationen ohne Festlegung von Auswahlkriterien........... 36

Abbildung 10: beispielhafte Darstellung der aktuellen Informationen nach Festlegung möglicher Auswahlkriterien. ................................................................................................................................... 37

Abbildung 11: Darstellung vom Bereich "Auswertung" mit Beispiel-Daten......................................... 38

Abbildung 12: Darstellung des Registers Wartungsinformationen mit einer Beispiel-Störung mit editierbaren Informationen für das Wartungspersonal. ......................................................................... 39

Abbildung 13: Darstellung des Registers Wartungsinformationen mit einer Beispiel-Störung mit editierbaren Informationen für das Wartungspersonal und dem RAMS-Manager. ............................... 39

Tabelle 1: FTA-Symbole........................................................................................................................ 23

Tabelle 2: Ausfallraten ........................................................................................................................... 25

Tabelle 3: Fehlermöglichkeiten am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren................................................................................................................................................ 33

Tabelle 4: beispielhafte Fehlerbetrachtung am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren. ................................................................................................................................. 33


Einleitung


1 Einleitung

Im Rahmen des Forschungsprojekts NeGSt soll neben einer Analyse von Diagnosemeldungen evalu-iert werden, inwieweit der RAMS-Prozess bzgl. der Phase 12 "Erfassung der Leistungsfähigkeit" op-timiert 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 all-gemeingültigen Anforderungen werden in diesem Dokument mit „ANF“ gekennzeichnet.

Dabei ist die Zielstellung, eine vom Stellwerkshersteller unabhängige Einsatzmöglichkeit zur zentrali-sierten Diagnose von Störungen und Fehlern sowie deren statistische Auswertung durch das Service-personal 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.


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 be-findet, 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 Ein-satz von Hilfsmitteln erfolgen. Die Systemeigenschaft, dass bei einem Gerät unter gegeben Einsatzbe-dingungen innerhalb eines festgelegten Zeitraumes eine bestimmte Instandhaltungsmaßnahme durch-gefü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 entwi-

ckeln 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 hilf-reich in der Entwicklungsphase, um rechtzeitig Schwachstellen zu erkennen und zu beheben. Die Un-tersuchung 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“ (funk-tionsfä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 an-

nehmen, da das Lebensalter t nur positive Werte annimmt.

� Offenbarungszeit




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 „unend-

lich“ 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 Verteilungsfunkti-

on 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 und einen

absolut stetigen Anteil . Daher gilt:

.

Es existiert eine Dichte für den absolut stetigen Anteil so, dass

mit .

Daraus ergibt sich für die Verteilungsfunktion:

für .




In der Zuverlässigkeitsanalyse werden überwiegend absolute stetige Modelle untersucht, des-

halb 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 betrach-

tet.

Dazu wird eine Komponente, die das Lebensalter t erreicht und eine Lebensdauer T hat, be-

rechnet. Es reicht nicht aus, die bedingte Wahrscheinlichkeit,

d.h. die Wahrscheinlichkeit, dass die betrachtete Komponente innerhalb des nächsten Inter-

valls ∆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




existiert, dann heißt die Funktion Ausfallrate, wobei ist. D.h. also, die Ausfall-

rate 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 Kom-

ponente 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:




, 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

2.5.1 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 ge-

nutzt, die bei einem Ausfall nicht repariert werden können,

sondern ausgetauscht werden müssen.

Die Maßeinheit ist a (Jahre).




• 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ön-

nen. 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 Komponen-

ten dies sind.

• 2-aus-3-System

(2oo3-,2v3-System): Das System ist funktionsfähig, solange zwei der drei

vorhandenen parallel geschalteten Komponenten dies sind.

2.5.2 Berechnung von MTTF-Werten

2.5.2.1 Grundlagen

Die Zuverlässigkeits-Kennwerte von Baugruppen (Systeme) werden grundsätzlich mit Hilfe einer FMEA und der Siemens-Norm SN 29500 ermittelt. Die Ausfallraten für die verwendeten Bauteile werden vom Hersteller gegeben oder mit Hilfe der Daten aus der Siemens-Norm SN 29500 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, wel-cher Anteil der auftretenden Ausfälle sicherheitskritisch ist) für jedes einzelne Bauteil in Prozent fest-gelegt.

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 Spannwei-ten der Tabelle A.1 aus IEC 61508-2 „Faults or failures to be detected during operation or to be analy-sed in the derivation of safe failure fraction“ und der Tabelle C.2 aus IEC 61508-6 „Diagnostic cove-rage and effectiveness for different subsystems” orientiert.

2.5.2.2 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 Funk-tion beteiligt sind in Serie (Reihe) und die redundanten Blöcke parallel, in einem Zuverlässigkeits-blockdiagramm zusammengeschaltet. Da das Zuverlässigkeitsblockdiagramm ein Ereignisdiagramm ist, existieren für jeden Funktionsblock nur die Zustände:

• intakt




• defekt.

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

2.5.2.4 Arten der MTTF-Ermittlung

Vorteile Nachteile Analyse (rückblickende Untersuchung)

Randbedingungen, Annahmen und Untersuchungszeiträume sind klar definiert, denn es handelt sich hier um rückblickende Untersuchungen.

In vielen Fällen sind nicht ge-nug und geeignete Felddaten vorhanden.

Prognose (vorausschauende Untersu-chung)

Zur Verfügung stehen Normen und Datenbankwerte, welche durch Her-stellerangaben erweitert werden kön-nen.

Es besteht eine gewisse Unge-nauigkeit, denn es müssen An-nahmen zugrunde gelegt wer-den, deren Zutreffen noch nicht bestätigt ist. Folglich ergeben verschiedene Standards unter-schiedliche Ergebnisse.

2.5.3 Zusammenhang

- R(t) und λ=const.: mit

(für ), wobei die Wahrscheinlichkeit be-zeichnet, 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)




• MTTF und R(t):

• MTTF und λ=const.:

2.5.4 Part-count-Methode

Als Part-count-Methode bezeichnet man die Ermittlung einer Ausfallrate durch Addition der Ausfall-raten 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:




Für die MTTF-Werte gilt dann entsprechend:

2.5.5 Redundanz

Ein System, welches noch funktionsfähig ist, obwohl nicht alle seine Komponenten funktionsfähig sind, bezeichnet man als redundant.

2.5.5.1 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:

2.5.5.2 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 Kompo-

nenten intakt sind:




• Berechnung der MTTF:

2.5.5.3 Gleichzeitige Fehler in mehreren Komponenten (redundante Systeme mit Reparatur)

Es werden hier in den folgenden Berechnungen wiederholt Fälle betrachtet, bei denen nur der gleich-zeitige 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 Be-deutung.

Für zwei Komponenten gelten für die resultierenden Werte der MTTF und der MTTR die Literatur-formeln:

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 regel-mäß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 ange-nommen 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 .




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äl-

le und den Anteil der Common-Cause-Fehler (Ausfälle aufgrund gemeinsamer Ursache) und die Sie-

mens-Norm liefert die Basis-Ausfallraten der Bauelemente.

2.6.1 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 er-

kennbare (dangerous, undetected) gefährliche Ausfäl-

le.

• : 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 Be-

triebsart mit kontinuierlicher Anforderung betrieben wird an.

Sicherheits-Integritätslevel

Rate gefahrbringender Ausfälle der Sicher-heitsfunktion

4 3 2 1

� Ausfallratenberechnung auf Funktionsblockebene




Die Ausfallraten , , , des Funktionsblockes werden wie folgt be-

stimmt: Es wird jedem Funktionsblock nach entsprechender Analyse (z.B. durch FMEA) der Schal-tung 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 sicherheitskriti-schen Ausfälle

Rate der nicht erkennbaren sicherheits-kritischen Ausfälle

2.6.2 Common-Cause-Anteil

2.6.3 Kanalbezogene mittlere Ausfallzeit

Diese Formel gilt nur für ein 1002-System.

2.6.4 Wichtige Formeln zur Berechnung von PFH

2.6.4.1 Für 1oo1-Systeme

2.6.4.2 Für 1oo2-Systeme




2.7 FMEA

Die FMEA (Failure Mode and Effects Analysis) oder Auswirkungsanalyse ist ein wichtiger Bestand-teil 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 identi-fizieren, 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äts- und 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 untersuch-te Gegenstand, das Ziel und die erwarteten Ergebnisse definiert. Um eine rechtzeitig durchge-fü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 schwer-wiegenden Auswirkungen angegeben. Weiterhin werden die Änderungen, die während der Er-stellung der FMEA entstanden sind, beschrieben. Empfehlungen/Aktionen für Konstrukteure, Instandhaltungspersonal, Planer und Anwender werden angefertigt. Der Schluss des Ergebnis-berichtes 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 festge-legten Maßnahmen.

Die Ziele der FMEA sind das Erkennen von (gefährlichen) Ausfällen eines Systems und eine Beurtei-lung durch eine Klassifizierung bzgl. Erkennbarkeit, Prüfbarkeit, Diagnosefähigkeit, Reparatur und




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 effek-tiver 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ähr-lichen und nicht gefährlichen Ausfälle und den Anteil der Common-cause-Fehler, d.h. sie lie-fert 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 Sicherheitsberech-nungen 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 (Syste-men) 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 Ha-zard-Rate (Anteil der gefährlichen Ausfälle) und gibt somit an, welche Sicherheitsintegritäts-stufe 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 Zuver-lä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.




Siemens-Norm

Zuverlässigkeit

FMEA

RAMS-Nachweis-

dokumentation

Sicherheit

a a

b

b

c

d

e

Abbildung 2: Grafische Darstellung der Zusammenhänge

2.9 Fehlerbaumanalyse

Die Fehlerbaumanalyse (FTA) ist ein „ableitendes“ bzw. „fortführendes“ Verfahren, welches ein Sys-tem 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 ver-laufen alle kritischen Pfade (Kombinationen von Komponentenausfällen des Systems), die dieses ver-ursachen 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 Ausgangs-ereignis tritt nur dann ein, falls irgendeines der Eingangsereignisse eintritt) und für eine Parallelschal-tung AND-Gatter (das Ausgangsereignis tritt nur dann ein, falls alle Eingangsereignisse eintreten) verwendet.

Die folgenden Abbildungen zeigen diesen Zusammenhang.




Hauptereignis z.B.

Ausfall der Schaltung:

Signal wird nicht

korrekt übertragen

Block A Ausfallereignis

das zum Hauptereignis

führt (unterbricht das

Signal)

Die Blöcke B und C

unterbrechen das

Signal

Block B Ausfallereignis

das ein Basisereignis ist

(unterbricht das Signal)

Block C Ausfallereignis

das ein Basisereignis ist

(unterbricht das Signal)

OR

AND

Abbildung 3: Grafische Darstellung von logischen Verknüpfungen in einem Fehlerbaum.




Abbildung 4: Grafische Darstellung der zu analysierenden Schaltung als Zuverlässigkeits-Blockdiagramm

Die folgende Tabelle erklärt die meist verwendeten Symbole.

Symbol Name Beschreibung

Grundereignis Sind Ereignisse, für die Anga-ben zur Eintrittswahrschein-lichkeit und Zuverlässigkeit vorliegen

OR-Gatter Das Ausgangsereignis tritt nur dann ein, wenn irgendeines der Eingangsereignisse eintritt

AND-Gatter Das Ausgangsereignis tritt nur dann ein, wenn alle Eingangser-eignisse eintreten

Transfer-Gatter Wird verwendet, wenn sich der Fehlerbaum über mehrere Sei-ten erstreckt oder Elemente des Baumes wiederholt werden.

Tabelle 1: FTA-Symbole




Bei der FTA wird zwischen qualitative und quantitative FTA unterschieden, wobei die quantitative FTA die qualitative FTA enthält.

Abbildung 5: Zusammenhang zwischen quantitativer und qualitativer FTA

2.9.1 Qualitative Fehlerbaumanalyse

Die qualitative FTA verwendet man zu folgenden Zwecken:

• Identifikation der relevanten Ausfallarten der Komponente und des Systems, d.h. der Systemauf-

bau wird analysiert und bewertet.

• Nachweis, dass die qualitative Anforderung, ein Einzelausfall führt nicht zu einem gefährlichen

Ereignis, erfüllt ist.

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

2.9.3 Mathematische Vorgehensweisen bei der Fehlerbaumanalyse

2.9.3.1 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

Quantitative FTA

Qualitative FTA




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

2.9.3.2 Common-Cause-Fehler-Analyse in einem Fehlerbaum

Bei der CCF-Analyse wird die Unabhängigkeit der Komponenten untersucht und, falls man die Unab-hä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 Ausfallwahrschein-lichkeit, welche hervorgerufen wird durch gemeinsame Ursachen der Komponenten, zu verringern. In der Fehlerbaumdarstellung wird der CCF durch eine logische AND-Verknüpfung gekennzeichnet.


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 Be-dienplatzinformationen (Kommandos, Meldungen, Störungen und Fehler) sowie der Kommunikati-onsschnittstellen geloggt und an autorisierte Abnehmer verteilt werden. Des Weiteren muss diese Ser-ver-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 Be-dienerarbeitsplatz 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 zent-ral 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 Übertra-gungsprotokoll zu wählen.

[ANF7] Die Datentelegramme werden mit einem Zeitstempel für den Erfassungszeitpunkt der Mel-dung gesendet.

[ANF8] Der Aufbau des Datentelegramms soll für die Diagnose so allgemein sein, dass es unab-hängig von Stellwerk, Schnittstellensignal oder Bedienkommando ist.

[ANF9] Optional soll es für Meldungen vom Bedienplatz den Bearbeitungsstatus für die Meldung beinhalten.




3.3 RAMS Anforderungen

[ANF10] Der Ablageort der Logdateien muss festgelegt sein und es müssen Maßnahmen zur siche-ren 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ög-lich sein.

[ANF12] Um Verfälschungen von Inhalten der Logdateien beim Speichern oder der Datenübertra-gung 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 Stellwerkssys-tems nachweisen zu können.

3.4 Abfrage der Diagnoseinformationen

Die Diagnose basiert auf dem zentral auf der Diagnose Auswerteplattform bereitgestellten Datenbe-stand und den aktuellen Meldungen der Stellwerke und Bedienplätze. Der Datenbestand kann vor-zugsweise 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 an-melden 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 Stellwerkssys-tems 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.




3.5.1 Übersicht Diagnose-Netzwerk

Abbildung 6: Aufbau des Diagnose-Netzwerkes

Stellwerk

SwitchBedien-

zentrale

Diagnose-

zentrale

lok. Diagn. lok. Diagn. lok. Diagn.

Switch

Stellwerk StellwerkStw-KernStw-KernStellwerk

ModasModaslok. Diagn.

Modbus Modbus Modbus

Ethernet Ethernet Ethernet

Ethernet Ethernet Ethernet

Ethernet

Ethernet

Modbus

räumlich zusammen

D

D

D

D

P

P

P

P

P Prozessdaten D Diagnosedaten

D

TS

V24

D

Funkverbindung




3.5.2 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 dar-stellt. 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 Verbindungsunterbre-chung die Verbindung zur Diagnose-Zentrale wieder hergestellt, so werden die lokal archivierten Da-ten für den Zeitraum der Unterbrechung nachgesendet. Über eine Funkverbindung können Diagnose-daten 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 perma-nente Verbindung.

In der Diagnose-Zentrale können die Zustands-/Diagnosedaten der einzelnen Stellwerke online darge-stellt 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 wer-den 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.

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

3.5.4 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 Bei-spiele 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" Diagnosestrate-

gie

• Visualisierung Maschinentechnischer Anlagen, Signal & Draht 05/2013: Einbindung von Informa-

tionen von maschinentechnischer Anlagen in ein Leit- und Visualisierungssystem

Ziel vorab zitierten Konzepte ist eine verbesserte Anbindung und Bereitstellung von Diagnosemög-lichkeiten sowie eine Effizienzsteigerung im Bereich der Instandhaltung und Wartung. Man erkennt, dass jedoch der weitere Schritt zur Bestätigung der sicherheitsgerichteten Annahmen konzeptionell




nicht in einem Diagnosesystem aufgegriffen wird. Ziel sollte jedoch sein, dass nicht nur die LST kon-zeptionell 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 Installati-onsprozess 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.


Anforderungen an den Prototypen


4 Anforderungen an den Prototypen

Der Prototyp für die Diagnose Auswerteplattform soll die Anforderungen [ANF1] – [ANF16] am Bei-spiel der Stellwerksprojekte ESTW-R abdecken. Im Dokument NeGSt_Ergebnisbericht_2500_Feinkonzept_Diagnose_Prototypvorgaben können die aus diesen über-geordneten Anforderungen abgeleiteten Vorgaben für die Erstellung eines Prototyps entnommen wer-den.


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.

5.1.1 Quelle der Fehlermöglichkeiten Die Prüfspezifikation liefert die auftretenden Fehlermöglichkeiten, die hier am Beispiel des Relais-blocks 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)




5.1.2 Darstellung der Fehlermöglichkeiten Für eine bessere Übersicht über die Fehlermöglichkeiten stellt man diese in einer weiteren Tabelle dar.

Tabelle 3:

Fehlermöglichkeiten am Beispiel RBLK (Alister), wobei die Felder mit X eine Störung definieren.

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:

Fehlermöglichkeiten Kompo-nente oder Funkti-onsblock

An-zahl der Kon-takte

λ_1 [1/h] λ_14 [1/h] λ_15 [1/h] λ_16 [1/h] λ_17 [1/h]

λ_18 [1/h] λ_19 [1/h] λ_20 [1/h] λ_45 [1/h]

Relais GP A

2 X X

Relais GP UE

2 X X

Relais GP A

1 X

Relais GP UE

1 X

2 Relais H4135A

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),

Prü

ffa

ll ID

Prü

ffa

ll

Beschre

ibun

g

Prü

ffa

llab

lauf

mit

Beschre

ibun

g

GP

_A

GP

_U

E

FS

_A

FS

_U

E

HM

_A

HM

_U

E

Ea_

A

Ea_U

E

MU

_A

MU

_U

E

400

Um

schaltung

des

Moto

r-in

dukto

rs

Erla

ubn

is

vorh

and

en

X

401

Erla

ubn

is

nic

ht vorh

and

en

X




• 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 Her-

stellerangaben zu Verfügung, d.h. es sind noch die Ausfallraten der Relais-Bauteile zu berechnen (sie-

he 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 Ha-

zard-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 übertra-gen.

5.2 Analysemöglichkeiten

5.2.1 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 Auswertun-gen durch das Servicepersonal der LST zu erstellen und zu vereinfachen. Die dazu notwendigen In-formationen vom Stellwerk und der Bedieneroberfläche sollen sowohl aktuell als auch aus archivier-tem Datenbestand dem Servicepersonal der LST zur Verfügung stehen. Dies soll durch eine gut struk-turierte Übersicht und Klassifizierung der Störungsarten geschaffen werden. Eine wichtige Hilfestel-lung 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 geziel-te Reparatur oder ein schneller Austausch des Bauteils bzw. der Bauteile vorgenommen werden kann.

5.2.2 Applikationen Die Server-Applikation im Stellwerksnetz soll sicherstellen, dass die aktuellen Stellwerks- und Be-dienplatzinformationen (Kommandos, Meldungen, Störungen und Fehler) und der Daten der Kommu-nikationsschnittstellen 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 Kom-mando-Datei „Start_Transformation“ durchgeführt und sollte im Zielsystem automatisch im Hin-tergrund ablaufen.




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 Auswerteplatt-form.

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 Hinter-grund vereinfacht. Die Idee einer zentralen, herstellerunabhängigen Auswerteplattform er-leichtert dem LST-Personal die Servicearbeiten für verschiedene Stellwerksbauformen.

5.2.3 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 Informa-tionen“, „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 Doppel-klick 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“.

5.2.4 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 Star-ten des Clients anmeldet.

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




Abbildung 8: Rechte und Anzahl der Nutzer vom Client.

5.2.4.2 Aktuelle Informationen

Dieses Register ist für alle Nutzer sichtbar. Hier werden alle auszuwertenden Log-Daten und die An-zahl 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örungs-art.

Abbildung 9: Darstellung der aktuellen Informationen ohne Festlegung von Auswahlkriterien.




Abbildung 10: beispielhafte Darstellung der aktuellen Informationen nach Festlegung möglicher Auswahlkrite-

rien.

5.2.4.3 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 Le-

bensdauer 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 ge-troffen werden.




Abbildung 11: Darstellung vom Bereich "Auswertung" mit Beispiel-Daten.

5.2.4.4 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äte-stö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 betroffe-ne 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.




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ög-lichkeit, Ä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)




vorzunehmen.

Der RAMS-Manager muss die Ausfallrate (falls die Daten dazu vorhanden sind) angeben. Durch Ak-tivierung 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.

5.2.5 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 rele-

vante 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 hinter-

legen.

• Spezifische statistische Modellierungen werden integriert. Die Basis dieser Modellierungen ergibt

sich aus den Anforderungen aus dem RAMS-Prozess und ggf. Anforderungen von Seiten des Be-

treibers.

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


Zusammenfassung und Ausblick



Im Rahmen NeGSt sollte das Konzept der Nachweisführung in Hinblick auf Sicherheitsaspekte analy-siert 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 vorzei-tig 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 Einhal-tung 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 Auf-ruf von Standardabfragen, aber auch AdHoc-Abfragen des RAMS-Managers. Die durch derartige sta-tistische 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 Betriebspha-se.

Die Schaffung eines durchgängigen werkzeuggestützten Prozesses ist ein wichtiger Aspekt in der Kos-ten- und Zeitoptimierung bei Neu- bzw. Änderungszulassung.


Anhang


7 Anhang


[1] NeGSt_Ergebnisbericht_2300AG5_Feinkonzept_Diagnose_Prototypvorgaben.doc



ANF Anforderung

CCF Common-Cause-Fehler


CRC Cyclic redundancy check (Zyklische Redundanzprüfung)

EBA Eisenbahn Bundesamt

ESTW-R ESTW-Regional

FMEA Failure Mode and Effects Analysis

FTA Fault Tree Analysis



MTBF Mean time between failures

MTTF Mean time to failure

MTTR Mean time to repair

PFH Probability of a dangerous Failure per Hour


SIL Safety Integration Level



Teilbericht

AP 2300

Projektierung von COTS-Produkten

05.08.2013

Laufzeit: 01.09.2011 – 31.08.2013





Datum Bearbeiter Version Inhalt 12.04.2013 Sascha Stöckel 0.1 Erster Draft nach Prototyping 15.04.2013 Antje M. Möller-

Neustock 0.2 Review

31.05.2013 Sascha Stöckel 0.3 Einstellen abschließende Version zum Review 26.06.2013 Antje M. Möller-

Neustock 0.4 Review

05.08.2013 Holger Neustock Klaus-Dieter Winkler

1.0 Finalisierung

Inhaltsverzeichnis

1 Einleitung.........................................................................................................................................4

2 Gründe für die Anwendung von COTS-Produkten.....................................................................5

3 Projektierung von COTS-Produkten ............................................................................................7

3.1 Allgemeines.................................................................................................................................7

3.2 Ist-Analyse ..................................................................................................................................8

3.3 Konzepterstellung ....................................................................................................................15

3.4 Besondere Aspekte der COTS-Projektierung in einen Infrastruktureditor ......................18

4 Fazit ................................................................................................................................................24

5 Anhang Abkürzungen...................................................................................................................25

Abbildungsverzeichnis

Abbildung 1: Systemarchitektur einer SIL2 Depotsteuerung................................................................... 8

Abbildung 2: exemplarische Klassifizierung von steuerbaren Elementen ............................................... 9

Abbildung 3: Prinzipanschaltung Ausfahrsignal.................................................................................... 10

Abbildung 4: Simatic S7-300 mit (v.l.n.r) SPS, Schnittstellen Modul und Ein-/Ausgabemodulen....... 10

Abbildung 5: Beispielsymbole für ein Ausfahrsignal U42 .................................................................... 11

Abbildung 6: Simatic Selection Tool ..................................................................................................... 11

Abbildung 7: SPS SA Projektierung (Auszug) ...................................................................................... 12

Abbildung 8: Projektierungsschritte der SPS Steuerung........................................................................ 12

Abbildung 9: Frauscher ACS2000 Vorderseite (Sicherungsbaugruppen, Zählbaugruppen und Auswertebaugruppen) ............................................................................................................................ 13

Abbildung 10: Frauscher ACS2000 Rückseite (Busplatinen)................................................................ 14

Abbildung 11: Sys-Sys Richtung Radsensor.......................................................................................... 14

Abbildung 12: Top-Down Modell Projektierung ................................................................................... 16

Abbildung 13: Infrastrukturansicht ........................................................................................................ 17

Abbildung 14: Funkwerk AG Infrastruktureditor .................................................................................. 18

Abbildung 15: Anpassung des AMBER Modells .................................................................................. 19

Abbildung 16: Auswahldialog Exportfunktionen .................................................................................. 20

Abbildung 17: Quellcodeauszug Symboltabellenprojektierung............................................................. 20



Abbildung 18: Richtungseinstellung für die Achszählsystemprojektierung (Auszug) .......................... 21

Abbildung 19: Steckerprojektierung der Frei-/Belegtmeldung für die Achszählsystemprojektierung .. 21

Abbildung 20: Anpassung des AMBER Modells für die Serverprojektierung (Auszug) ...................... 22

Abbildung 21: Objekte und Prädikate für die SPS Softwareprojektierung (Auszug) ............................ 23


Einleitung


1 Einleitung

Die Nutzung von COTS-Produkte bei der Erstellung von Stellwerken bietet Vorteile, wie Kostener-sparnis 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 verbun-denen Projektierungsverfahren. Es wird auf die Änderungen im Zulassungsverfahren eingegangen sowie ein Konzept vorgestellt und evaluiert, welches den Erstellungsprozess optimiert und die Zulas-sung unterstützt.


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 Pro-jektabwicklung 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 An-forderungen 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 besit-zen 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üg-bar. (Quelle: http://de.wikipedia.org/wiki/Simatic , 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 wer-den müssen. Zum Beispiel lässt sich das Achszählsystem ACS2000 der Firma Frauscher durch Aus-tausch einer Busplatine und durch Hinzufügen von Schnittstellenkarten um weitere Achszähler erwei-tern. Bestehende Systemkomponenten können weiter verwendet werden.


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. Insbeson-dere 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 Kos-ten.

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 ver-schiedener 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 Zulas-sungsverfahrens sowie des dadurch erforderlichen Produktvariantenmanagements. Das Produktvarian-tenmanagement erfasst dabei zentral, welche Komponenten mit ihren jeweiligen Versions- und Konfi-gurationsstä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 61508 wurde als übergeordnete Norm für sicherheitsgerichtet Systeme entwi-ckelt. 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 20206 oder die Norm IEC 61511 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 Indust-riezweige sind, nicht einfach bzgl. ihrer Nachweisdokumente übertragen werden. Aufwände bzgl. der Übertragung dieser Zulassungsdokumente bzw. -nachweisführungen müssen somit eingeplant werden.




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 Ge-samtsystem 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 Anpas-sung, 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 Über-sichtsplä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 Projek-tierungsvorgaben,

• 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 Anforderun-gen 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 Soft-ware 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:




• Setzen von Parametern in Konfigurations- und Projektierungsdateien zur Steuerung von Pro-grammablä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 Differenzbe-trachtung kann Software zur Visualisierung der Änderungen angewendet werden. Eine Änderungszu-lassung 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 Anforde-rungen aus den oben genannten Quellen erfüllt werden und dass der Projektierungsvorgang nachvoll-ziehbar 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 Anwen-dung in Abstell-, Instandsetzung- oder in Be-/Entladebereichen.

SPS Regelsystem

Achszählsystem

Serverrechner

Bedienplatzrechner

Anpassbaugruppe

Weichen

Anpassbaugruppe

Signale

Signale Weichenantriebe Radsensor

Systemüberwachung

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.




Das SPS Regelsystem, die Systemüberwachung, die Anpassbaugruppen Signale und Weichen sowie das Achszählsystem befinden sich in den Schaltschränken mit Kabelabschlussgestell und Stromver-sorgung. Optional sind die Bedienplatz- und der Serverrechner. Diese werden je nach konkreter Aus-prägung dem System hinzugefügt. Ebenso kann das Achszählsystem durch ein Gleiskreissystem er-setzt sein. Ein wesentliches COTS-Produkt ist die SPS Steuerung, die bislang vorrangig bei der Steue-rung industrieller Maschinen und Anlagen zum Einsatz gekommen ist und nun im Bahnbereich Steue-rungssysteme auf Relaisbasis oder proprietäre Logiksysteme ablöst.

Die Durchführung einer Projektierung einer solchen Depotsteuerung wird im folgendem näher erläu-tert. 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.

Weicheantrieb

7-Draht

4-Draht

Signal

Vorziehsignal (H3)

Ausfahrsignal

(H0/H4)

Freimeldeabschnitt

Planungsunterlagen

Gleiskreis

Achszählkreis

Weichenlagemelder

Abbildung 2: exemplarische Klassifizierung von steuerbaren Elementen

Für die definierten Klassen werden im Rahmen der Projektierung des Schaltschranks Prinzipanschal-tungen 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 Projek-tierung 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 Er-satzteilhaltung.

Zum Beispiel wurde als Prinzipschaltung für das Ausfahrsignal folgende Anschaltung definiert:




Abbildung 3: Prinzipanschaltung Ausfahrsignal

Für jedes Ausfahrsignal ergeben sich als Schnittstelle zwei Kontakte (DO) zur Ansteuerung der Sig-nalaspekte 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 Speicherpro-grammierbaren Steuerung (SPS) und dezentraler Peripherie, eingesetzt. Bei diesem modularem Sys-tem werden aneinanderreihbare Ein-/Ausgabemodule per Schnittstellen Modul und Kommunikations-strecke 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 anzu-sprechen. Für die Erstellung dieser Tabelle kommt ein einfacher Texteditor zum Einsatz. Bei der Pro-jektierung der dezentralen Peripherie und der Symboltabelle ist es sinnvoll, Gruppen zu bilden und Reserven einzuplanen.




U42_SI_H0 Q 7.0 BOOL Haltbegriff H0

U42_SI_H4 Q 7.1 BOOL Fahrtbegriff H4

U42_SI_H0r I 8.0 BOOL Rueckmelder Haltbegriff H0

U42_SI_H4r 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 beschrei-benden 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 wer-den. 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 Soft-ware Simatic Selection Tool.

Abbildung 6: Simatic Selection Tool




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 Ge-schä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 de-finiert und dann in den GA Quellcode übernommen. Zu Erstellung des SA Quellcodes wird ein Code-generator 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 Ele-mente und den Relationen zwischen diesen.

Abbildung 7: SPS SA Projektierung (Auszug)

Eine Elementprojektierung wird durch das Schlüsselwort OBJECT eingeleitet und von Elementeigen-schaften, wie z.B. der Elementklassifikation oder dem Elementnamen, gefolgt. Die Relationen zwi-schen 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 zusammen-gefasst.

Codegenerator

Symboltabelle

Projektierung derdez. Peripherie

SA Quellcode

SA Projektierung

Step7

Simatic SelectionTool

SPS Software

Planungsunterlagen

KlassifikationElemente Prinzipanschaltung

Projektierungswerkzeug

Projektierung

GA Quellcode

Abbildung 8: Projektierungsschritte der SPS Steuerung

…

OBJECT rsig U42 240;

…

PREDICATE RSigFs(U42,FS085);

…




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 Bedienrech-nern kommuniziert. Das Serverprogramm setzt die Informationen zwischen der SPS und den Bedien-rechnern um, koordiniert die Ausführung von Kommandos und protokolliert Bedienaktionen und Feh-lerzustä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 ermit-telt. 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 Freimelde-abschnitt werden verschiedene Komponenten zugeordnet. Neben einer Sicherungsbaugruppe (SIB) zur Stromversorgung gehören zu jedem Freimeldeabschnitt eine Zählbaugruppe (ACB) und eine Busplati-ne (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 Auswertebaugrup-

pen)

(Bildquelle: © Frauscher)




Abbildung 10: Frauscher ACS2000 Rückseite (Busplatinen)


Die Projektierung des Achszählsystems erfolgt ohne Unterstützung spezieller Projektierungswerkzeu-ge. Die Projektierung wird als Dokument erstellt und beim Aufbau des Achszählsystems hardwaresei-tig, 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 Achs-zä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


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 Versionskontrol-le 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 neue-ren, 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 Projektierungsdoku-mente sein.

Hardwarekomponenten unterliegen ebenfalls stetigen Änderungen. Dies betrifft die in einer Kompo-nente 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 Liefe-rung eines Systems, wie einer Depotsteuerung, werden Typen und Versionen dokumentiert. Der Si-cherheitsnachweis wird einzeln bzw. im Gesamtsystem erbracht. Der identische Austausch defekter Komponenten kann, sofern erhältlich, aus einer Neubeschaffung oder aus einem Lagerbestand erfol-gen. In diesem Fall ist kein neuer Sicherheitsnachweis notwendig. Jedoch ist dies, bedingt durch Ob-soleszenz, nicht immer möglich. Ersatzkomponenten sind in der Regel zum Zeitpunkt des Sicherheits-nachweises nicht bekannt, sodass diese nicht durch den Sicherheitsnachweis abgedeckt sind. Die Nut-zung andere Komponenten als die durch den Sicherheitsnachweis abgedeckten Komponenten kann zum Erlöschen der Betriebserlaubnis führen. Gegebenenfalls ist es möglich, abwärtskompatible Pro-dukte als Ersatz zu verwenden, sofern durch den Sicherheitsnachweis akzeptiert. Die abwärtskompa-tible Produkte bieten dabei mindestens die gleichen Eigenschaften wie die ursprünglich verwendeten Produkte. Die Überwachung anwendbarer und die Dokumentation angewendeter kompatibler Versio-nen über eine Vielzahl von Anlagen setzt eine Versionskontrolle mit Möglichkeiten zur Rückverfol-




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übergrei-fende Nutzung der projektierten Daten z.B. durch Import, Export oder Konvertierungsfunktionen na-hezu 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 Innova-tionen 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 die-ser kompatiblen Nachfolger Produkte als Produktevolution verstehen lässt.

Während der langen Betriebsdauer einer Anlage spielen die kompatiblen COTS-Produkte insbesonde-re 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 dahin-gehend 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 Eigen-schaften hinsichtlich Funktion, Bauform, Schnittstelle und Fehlerraten haben, eingesetzt werden dür-fen. Anderenfalls ist eine Nachweisführung über die Änderungen notwendig.

3.3 Konzepterstellung

In den vorhergehenden Kapiteln wurden verschiedene Verfahren im Rahmen der Projektierung vorge-stellt. 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. Einarbei-tung. Doppeleingaben von Daten sind die Regel. Die Anwendung der Projektierungsverfahren, insbe-sondere 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. An-schließ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 Transforma-tion von Daten in eine Projektierung entspricht dem Verfahrensweg aus dem bisherigen Projektie-rungsverfahren. Eine solche Implementierung ist deterministisch und verhindert Fehler, die durch eine nicht korrekte Anwendung von Projektierungsverfahren entstehen können.




Datentransformation auf einer

gemeinsamen Datenbasis

Projektierungen

Achszählsystem

Datenerfassung im einheitlichenProjektierungstool

Planungsunterlagen

Projektierungen

SPS Steuerung

Projektierungen

Schaltschrank

Klemmleisten-

Konfiguration fürAußenelemente

SymboltabelleDIP Schalter-konfiguration

Mengengerüst SA ProjektierungStecker-

kontaktierung

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 Ap-plikation (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 (Modellba-sierte Entwurfsmethoden für eine neue Generation elektronischer Stellwerke) hervorgebracht wurden.

Ein weiteres Datenmodell ist railML (www.railml.org), ein Extensible Markup Language (XML) ba-siertes 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 angewende-ten Verfahren und Regeln ab.

Die Ausgabe einer Transformation kann je nach abgebildetem Projektierungsverfahren sehr unter-schiedlich sein. Dies können einfache Textdaten, XML-Daten oder auch komplexe Binär- oder Bildda-ten sein. Vorstellbar ist auch die Erstellung von Schaltplänen auf Basis einer Prinzipanschaltung. Ent-sprechend flexibel und mächtig müssen die Transformationen sein.




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. Schulung-saufwä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 graphi-schen 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 spezifi-schen Eigenschaften der Elemente werden festgelegt.

Abbildung 13: Infrastrukturansicht

Die Bedienoberfläche soll den Nutzer während der Erstellung einer Projektierung unterstützen, auto-matisch fehlerhafte Daten zu erkennen. Insbesondere sind hier folgende Anforderungen an die Projek-tierung 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 Sicherheitsnachwei-ses. Ein Sicherheitsnachweis gemäß CENELEC erfordert zudem die Verifikation der eingegebenen Daten. Vorstellbar ist, den Verifikationsprozess durch die Bedienoberfläche zu unterstützen. Eine Än-derungsverfolgung, die Änderungen zwischen zwei Versionen eines Infrastrukturmodells (Differenz-betrachtung) anzeigt, und das Erzeugen von Berichten für eine Verifikation kommen hierbei in Be-tracht. 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 Infra-strukturmodell. 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 da-durch einfacher und schneller erkannt werden. Ermüdungserscheinungen bei einer Verifikation kön-nen reduziert werden.




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 betrieb-lichen 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 unter-stützen. Durch die zentrale Datenhaltung können Änderungen leichter nachvollziehbar gemacht wer-den.

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 ent-stand eine Softwareprodukt, welches das AMBER Datenmodell und einen Infrastruktureditor integ-riert. Das AMBER Modell lässt sich um neue Elemente oder Eigenschaften, wie z.B. spezielle Signal-typen, erweitern. Ebenfalls ist die Anwendung von Transformationen und einer Fehlerprüfung vorge-sehen. Gegenüber dem Konzept ist es derzeit allerdings noch nicht möglich, eine automatisierte Diffe-renzbetrachtung von Änderungen auf den Infrastrukturdaten durchzuführen.

Abbildung 14: Funkwerk AG Infrastruktureditor




Im Rahmen des NeGSt Projekts fand eine Evaluierung der Anwendbarkeit des Konzepts auf die Pro-jektierung von COTS-Produkten statt. Es wurde die Software exemplarisch erweitert, sodass Teilas-pekte 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 gra-phisch in der Unified Modeling Language (UML). Als Elementtypen wurden z.B. ein Schnittstellen-typ, 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 Bei-spiel 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 beste-hender 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 mit-tels 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.




Abbildung 16: Auswahldialog Exportfunktionen

Transformation Symboltabellenprojektierung

Die Transformation erstellt die Symbole für jedes Element, welches elektrische Signale besitzt. Ab-hä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 Signal-namen 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 Ra-des 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




{angrenzendes Sensorsystem} {angrenzendes Sensorsystem} 31.1/31.2 FMA31.1 {2} FMA31.2 {1}

31.2/31 FMA31.2 {2}

31U/31.1 FMA31.1 {1} FMA31U {2}

32U/32 FMA32U {2}

Abbildung 18: Richtungseinstellung für die Achszählsystemprojektierung (Auszug)

Die Kennzeichnung {1} bedeutet im Regelfall, für die Einfahrt in den Achszählkreis, eine Überfahrt von Sensorsystem 2 nach Sensorsystem 1. Der DIP Schalter des betreffenden Radsensors muss in Stellung ON gebracht werden. Die Kennzeichnung {2} erfordert die DIP Schalterstellung OFF. Ab-weichend vom Regelfall kann es technisch bedingt vorkommen, dass von dieser DIP Schalterstellung abgewichen werden muss. Diese Spezialfälle werden an dieser Stelle jedoch nicht betrachtet.

Das nun folgende Beispiel zeigt die Steckerprojektierung für die Frei- bzw. Belegtmeldung eines Achszählkreises. Entsprechend der Projektierung in der folgenden Abbildung werden Kabel des Achs-zählkreises mit dem Stecker verlötet.

Abbildung 19: Steckerprojektierung der Frei-/Belegtmeldung für die Achszählsystemprojektierung


Durch die Transformation Achszählsystemprojektierung konnten am Beispiel Richtungsprojektierun-gen für 74 Radsensoren und Steckerprojektierungen für 43 Achszählkreise generiert werden. Die Er-stellung des Projektierungsdokuments wurde deutlich beschleunigt. Fehler, die z.B. durch Ermüdung bei der hohen Anzahl an Radsensoren oder Achszählkreisen entstehen, konnten vermieden werden.

Transformation Serverprojektierung

Aus dem Infrastrukturmodell werden die Daten in eine Serverprojektierung transformiert. Der Server erfährt über diese Projektierung, welche Informationen durch die SPS bzw. durch die Bedienarbeits-plätze kommuniziert werden. Außerdem wird die Kommunikationsschnittstelle zwischen Server und den Clients definiert.

Für die Serverprojektierung wurden spezialisierte Klassen für den Server und für die Clients in das AMBER Modell integriert. Mit Instanzen dieser Klassen werden Einstellungen für die Netzwerkkom-

ABP FMA31.1, Stecker ST6

2d frei 2b frei 2z frei






14d FMA31.1 Reset 1+ 14b frei 14z FMA31.1 Reset 1-


18d FMA31.1 Reset 2+ 18b frei 18z FMA31.1 Reset 2-



24d FMA31.1 Fm (in) 24b frei 24z frei

26d FMA31.1 P (in) 26b frei 26z frei


30d FMA31.1 Fm (out) 30b frei 30z frei

32d FMA31.1 P (out) 32b frei 32z frei




munikation wie Servername, IP Ports und Sicherheitskanal festgelegt. Am Beispiel werden so 5 Stan-dard-Bedienarbeitsplätze und 2 Bedienarbeitsplätze in die Projektierung integriert.

Abbildung 20: Anpassung des AMBER Modells für die Serverprojektierung (Auszug)

Transformation SPS Softwareprojektierung

Auf Basis der Infrastrukturdaten wird die spezifische Applikationslogik der SPS generiert, die dann als Programm auf der SPS ausgeführt wird. Dazu werden in der Projektierung die Infrastrukturobjekte und deren Beziehungen festgelegt. Die Infrastrukturobjekte werden über das Schlüsselwort OBJECT mit Angabe des Typs, Objektnamen und interne Adresse deklariert. Eine Beziehung wird durch das Schlüsselwort PREDICATE eingeleitet. Zudem werden der Verknüpfungstyp und die zu verknüpfen-den Elemente angegeben.

Aus den Infrastrukturdaten werden mittels Transformation diese Objekt- und Prädikateinträge gene-riert. Für das Beispiel konnten so mehr als 8200 Zeilen Projektierungsdaten erzeugt werden.




Abbildung 21: Objekte und Prädikate für die SPS Softwareprojektierung (Auszug)

Das Beispiel zeigt die Elementprojektierung der Objekte Stellwerk (stw), Schaltschrank (cab), Signale (rsig) und der Fahrstrasse (fs). Mittels Prädikat RSigFs wird eine Beziehung zwischen einem bestimm-ten Signal und einer bestimmten Fahrstrasse hergestellt. Diese Beziehung wird in der SPS Logik ver-arbeitet.

OBJECT stw BBA 0;

OBJECT cab CAB1 2;

…




…

OBJECT fs FS084 484;






…







…


Fazit


4 Fazit

Im Rahmen NeGSt sollte das Konzept der Nachweisführung in Hinblick auf Sicherheitsaspekte und speziell der Umgang mit COTS-Komponenten analysiert werden. In diesem Ergebnisbericht lag der Fokus auf der Nachweisführung der Änderungen von COTS-Komponenten in einem zugelassenen System, wodurch neben der Nachweisführung der Kompatibilität auch die spezifische Applikation nebst Projektierungsregeln angepasst werden müssen.

Ziel des dabei umgesetzten Prototyps war es, darzulegen, dass basierend auf den schon in Men-ges/AMBER entwickelten Datenmodellen eine Erweiterung derart gestaltet werden kann, dass die Projektierungsdaten mit berücksichtigt werden können.

Die einheitliche Bedienoberfläche für den Projektanten und Planprüfer mit gemeinsamer Datenbasis beschleunigte den Erstellungsprozess verschiedener Projektierungen. Eine Änderung der SA-Projektierung, die insbesondere in der CENELEC-Norm DIN EN 50128/2011, Kapitel 8, betrachtet wird (siehe Dokumentenliste der Arbeitsgruppe 3), kann somit auf derselben Datenbasis erfolgen. Das Konzept für die Prüfung einer Projektierung spricht für eine Beschleunigung des Sicherheitsnachwei-ses. Der Einsatz toolgestützter Projektierungsverfahren, wie dem beschriebenen, verringert Projektie-rungsaufwände, beschleunigt die Erstellung von Sicherungsstechnik im Bahnbereich und vereinfacht die Führung des Sicherheitsnachweises nach CENELEC.

Allerdings lohnt sich der hohe initiale Entwicklungsaufwand nur bei guter Wiederverwendbarkeit in vielen gleichartigen Projekten. Es hat sich auch gezeigt, dass während der Entwicklungs- und Anwen-dungsphase das Projektierungstool den Bedürfnissen der Anwender nachläuft. Die Anforderungen sind vielschichtig und ändern sich erfahrungsgemäß am Anfang eines Projekts im Detail sehr stark.

Wenn Varianten eines zugelassenen COTS-Produktes zum Einsatz kommen, kann man dies mit dem beschriebenen Editor sehr schnell erfassen und die nachfolgende Dokumentation zum Zwecke der Nachweisführung automatisiert erzeugen. Wenn die Änderungskennzeichnung auch noch implemen-tiert wird, vereinfachen Differenzbetrachtungen die Nachweisführung noch weiter.


Anhang Abkürzungen


5 Anhang Abkürzungen


ABP Busplatine

AMBER Advanced Model-Based Environment for Railways

BOF Bedienoberfläche


COTS Commercial off the shelf

DIN Deutsche Institut für Normung

DIP Dual in-line package, Gehäuseform für elektronische Bauelemente



HTML Hypertext Markup Language



PLD Programmable logic device



SPS Speicherprogrammierbare Steuerung

UML Unified Modeling Language

XML Extensible Markup Language