FB Elektro- und Informationstechnik Lehrstuhl für Automatisierungstechnik Prof. Dr.-Ing. habil. Lothar Litz Projekt: Durchführung einer Studie und Erstellung einer Methode zum Nachweis des „Safety Integrity Level (SIL)“ für PLT-Schutzeinrichtungen auf Basis statistischer Daten realisierter PLT- Schutzeinrichtungen -Bericht- Daniel Düpont Kaiserslautern, den 15.12.2004 Prof. Dr.-Ing. habil. Litz, Lehrstuhl für Automatisierungstechnik, TU Kaiserslautern Erwin-Schrödinger-Straße 12, 67663 Kaiserslautern
Transcript
FB Elektro- und Informationstechnik Lehrstuhl für Automatisierungstechnik Prof. Dr.-Ing. habil. Lothar Litz
Projekt: Durchführung einer Studie und Erstellung einer
Methode zum Nachweis des „Safety Integrity Level (SIL)“ für PLT-Schutzeinrichtungen auf Basis
A.1 Allgemeine Bemerkungen Die beiden maßgeblichen Normen IEC 61508 und IEC 61511 enthalten zusammen über 1000 Seiten an normativen und informativen Festlegungen. Im Folgenden werden daraus diejenigen zusammengestellt, welche Vorgaben zum Nachweis des Safety Integrity Levels (SIL) machen. Selbst unter dieser Einschränkung sind dies 33 Seiten. Diese sind wichtig, um die Zwänge und die Freiheiten zu erkennen, die in diesem Zusammenhang bestehen. Die Nummerierung der Absätze ist identisch mit derjenigen der Norm. Wichtige Zusammenhänge sind kursiv bzw. fett hervorgehoben. In der deutschen Norm falsch oder unglücklich übersetzte Teile sind verbessert. Auf solche Korrekturen wird in Fußnoten hingewiesen. Alle nicht als explizit „informativ“ bezeichneten Auszüge sind als normativ zu verstehen.
3
A.2 IEC 61508 IEC 61508-1:
7.6 Zuordnung der Sicherheitsanforderungen 7.6.2 Anforderungen
7.6.2.5 Die Anforderungen zur Sicherheitsintegrität jeder Sicherheitsfunktion müssen geeignet sein, anzuzeigen, ob der Zielparameter der Sicherheitsintegrität entweder: - die mittlere Wahrscheinlichkeit eines Ausfalls der entworfenen Funktion bei
Anforderung (Betriebsart mit niedriger Anforderungsrate), oder - die Häufigkeit1) eines gefahrbringenden Ausfalls/h (Betriebsart mit hoher oder
kontinuierlicher Anforderung) ist. 7.6.2.9
Sicherheits-integritätslevel
Betriebsart mit niedriger Anforderungsrate
(mittlere Ausfallwahr-scheinlichkeit der entworfenen
Funktion bei Anforderung) 4 ≥ 10-5 bis < 10-4 3 ≥ 10-4 bis < 10-3 2 ≥ 10-3 bis < 10-2 1 ≥ 10-2 bis < 10-1
Sicherheits-
integritätslevelBetriebsart mit hoher
Anforderungsrate oder kontinuierlicher
Anforderung (Häufigkeit1) eines
gefahrbringenden Ausfalls/h) 4 ≥ 10-9 bis < 10-8 3 ≥ 10-8 bis < 10-7 2 ≥ 10-7 bis < 10-6 1 ≥ 10-6 bis < 10-5
Anmerkung 8: Es ist wichtig anzumerken, dass die Ausfallwerte für SIL 1, 2, 3 und 4 Ausfallgrenzwerte sind. Es ist allgemein anerkannt, dass es nur hinsichtlich der Sicherheitsintegrität der Hardware möglich ist, quantitativ zu arbeiten und Methoden zur Voraussage der Zuverlässigkeit bei der Beurteilung, ob die Ausfallgrenzwerte erreicht worden sind, anzuwenden. Um die Ausfallgrenzwerte in Hinblick auf die systematische Sicherheitsintegrität zu erreichen, müssen qualitative Methoden und Beurteilungen unter Berücksichtigung der erforderlichen Vorsichtsmaßnahmen angewendet werden.
1) Der Begriff „Wahrscheinlichkeit“ wurde durch „Häufigkeit“ ersetzt, da die offizielle deutsche Übersetzung „Wahrscheinlichkeit“ an dieser Stelle irreführend ist. Es handelt sich um eine Ausfallrate.
4
7.6.2.11 Eine Architektur, die nur aus einem einzigen sicherheitsbezogenen E/ E/ PE-System des SIL 4 besteht, ist nur erlaubt, wenn von den unten stehenden Kriterien entweder a) oder b) und c) gemeinsam erfüllt werden: a) der Ausfallgrenzwert der Sicherheitsintegrität wurde durch eine Kombination
von angemessen analytischen Methoden und Tests eindeutig bewiesen; b) es liegen weitläufige Betriebserfahrungen bezüglich der als Teile für das
sicherheitsbezogene E/ E/ PE-System verwendeten Komponenten vor. Diese Erfahrungen müssen in einer vergleichbaren Umgebung gewonnen und mindestens in einem System mit vergleichbarem Komplexitätsgrad angewendet worden sein;
c) es liegen ausreichende Hardwareausfalldaten bezüglich der als Teile für das sicherheitsbezogene E/ E/ PE-System verwendeten Komponenten vor, um ausreichendes Vertrauen in Bezug auf den zu erreichenden Ausfallgrenzwert der Sicherheitsintegrität der Hardware zu erreichen. Die Daten sollten bezüglich der vorgesehenen Umgebung, der Anwendung und des Komplexitätsgrads zutreffend sein.
IEC 61508-2:
7.4 E/ E/ PES-Entwurf und Entwicklung 7.4.2 Anforderungen
7.4.2.2 Der Entwurf des sicherheitsbezogenen E/ E/ PES-Systems muss so ausgeführt werden, dass alle Anforderungen a) bis c) wie folgt erfüllt werden: a) die Anforderungen zur Sicherheitsintegrität der Hardware, bestehend aus - Einschränkungen der Sicherheitsintegrität der Hardware aufgrund der
Architektur und - den Anforderungen an die Wahrscheinlichkeit gefahrbringender zufälliger
Hardwareausfälle; b) die Anforderungen zur systematischen Sicherheitsintegrität, bestehend aus - den Anforderungen zur Vermeidung von Ausfällen und den Anforderungen zur
Beherrschung von systematischen Ausfällen oder - dem Beweis, dass die Betriebsmittel „betriebsbewährt“ sind; c) die Anforderungen an das Systemverhalten bei Erkennung eines Fehlers.
Anmerkung 1: Gesamtrahmen der E/ E/ PES-Sicherheitsintegrität: Die umfassende Methode zur Auswahl eines Entwurfsansatzes, um das Erreichen eines SIL in sicherheitsbezogenen E/ E/ PE-Systemen darzulegen, ist wie folgt: - Bestimmung der erforderlichen SIL der Sicherheitsfunktionen; - setze: Sicherheitsintegrität der Hardware = systematische
Sicherheitsintegrität = SIL; - zur Sicherheitsintegrität der Hardware: Bestimmung der Architektur, um die
Einschränkungen aufgrund der Architektur zu erfüllen und aufzeigen, dass die Wahrscheinlichkeiten des Ausfalls der Sicherheitsfunktionen infolge zufälliger Hardwareausfälle die erforderlichen Ausfallgrenzwerte erfüllen;
- zur systematischen Sicherheitsintegrität: Auswahl von Entwurfsmerkmalen, die systematische Fehler im tatsächlichen Betrieb beherrschen oder Bestätigung, dass die Anforderungen zur „Betriebsbewährung“ erfüllt worden sind; und
5
- zur systematischen Sicherheitsintegrität: Auswahl von Verfahren und Maßnahmen, die systematische Fehler während des Entwurfs und der Entwicklung vermeiden, oder Bestätigung, dass die Anforderungen zur „Betriebsbewährung“ erfüllt worden sind.
7.4.3 Anforderungen zur Sicherheitsintegrität der Hardware
7.4.3.1 Einschränkungen der Sicherheitsintegrität der Hardware aufgrund der Architektur Im Kontext der Sicherheitsintegrität der Hardware ist der höchste SIL, der für eine Sicherheitsfunktion in Anspruch genommen werden kann, durch Fehlertoleranz der Hardware und den Anteil ungefährlicher Ausfälle SFF der Teilsysteme, die die Sicherheitsfunktion ausführen, begrenzt.
≥ 99 % SIL3 SIL4 SIL4 Fehlertoleranz der Hardware von N bedeutet, dass N+1 Fehler zu einem Verlust der Sicherheitsfunktion führen können.
Tabelle 3 - Einschränkung aufgrund der Architektur für sicherheitsbezogene Typ B-Teilsysteme
7.4.3.1.2
Ein Teilsystem kann als vom Typ A betrachtet werden, wenn für die Bauteile, die für das Erreichen der Sicherheitsfunktion erforderlich sind, a) das Ausfallverhalten aller eingesetzten Bauteile ausreichend definiert ist; und b) das Verhalten des Teilsystems unter Fehlerbedingungen vollständig bestimmt
werden kann; und c) verlässliche Ausfalldaten durch Felderfahrungen für das Teilsystem
existieren, um zu zeigen, dass die angenommenen Ausfallraten für erkannte (λDD) und unerkannte (λDU) gefahrbringende Ausfälle erreicht werden.
6
7.4.3.1.3 Ein Teilsystem muss als vom Typ B betrachtet werden, wenn für die Bauteile, die für das Erreichen der Sicherheitsfunktion erforderlich sind, a) das Ausfallverhalten von mindestens einem eingesetzten Bauteil nicht
ausreichend definiert ist; oder b) das Verhalten des Teilsystems unter Fehlerbedingungen nicht vollständig
bestimmt werden kann; oder c) keine ausreichend zuverlässigen Ausfalldaten aus Felderfahrungen für das
Teilsystem vorliegen, um die in Anspruch genommenen Ausfallraten für erkannte (λDD) und unerkannte (λDU) gefahrbringende Ausfälle zu unterstützen.
7.4.3.1.5
In sicherheitsbezogenen E/ E/ PE-Systemen, in denen eine Sicherheitsfunktion durch einen einzelnen Kanal ausgeführt wird, muss der max. SIL der Hardware, der in Anspruch genommen werden kann, durch das Teilsystem bestimmt werden, das die niedrigsten Anforderungen zur Sicherheitsintegrität der Hardware erfüllt.
7.4.3.1.6 In sicherheitsbezogenen E/ E/ PE-Systemen, in denen eine Sicherheitsfunktion durch mehrere Kanäle von Teilsystemen ausgeführt wird, muss der höchste SIL der Hardware, der für die betrachtete Sicherheitsfunktion in Anspruch genommen werden kann, bestimmt werden durch: a) Beurteilung jedes Teilsystems gegenüber den Anforderungen aus Tabelle 2
oder 3; und b) Zusammenfassung der Teilsysteme zu Kombinationen; und c) Analyse dieser Kombinationen, um den Gesamt-SIL der Hardware zu
bestimmen.
7.4.3.2 Anforderungen zur Abschätzung der Wahrscheinlichkeit des Ausfalls von Sicherheitsfunktionen infolge zufälliger Hardwareausfälle
7.4.3.2.2 Die Wahrscheinlichkeit des Ausfalls jeder Sicherheitsfunktion infolge zufälliger Hardwareausfälle muss unter Berücksichtigung von Folgendem abgeschätzt werden: a) Architektur des sicherheitsbezogenen E/ E/ PE-Systems in Bezug zur
betrachteten Sicherheitsfunktion; b) geschätzte Ausfallrate jedes Teilsystems in allen Modi, die zu einem
gefahrbringenden Ausfall des sicherheitsbezogenen E/ E/ PE-Systems führen, jedoch durch Diagnosetests erkannt werden (λDD);
c) der geschätzten Ausfallrate jedes Teilsystems in allen Modi, die zu einem gefahrbringenden Ausfall des sicherheitsbezogenen E/ E/ PE-Systems führen und welche durch Diagnosetests nicht erkannt werden (λDU);
d) der Anfälligkeit des sicherheitsbezogenen E/ E/ PE-Systems für Ausfälle infolge gemeinsamer Ursache (β);
e) des Diagnoseaufdeckungsgrads (DC) und dem zugehörigen Diagnose-Testintervall;
f) des Intervalls (TI), innerhalb dessen Wiederholungsprüfungen durchgeführt werden müssen, um gefahrbringende Fehler zu erkennen, die durch Diagnosetests nicht erkannt werden;
g) der Reparaturzeiten für erkannte Ausfälle;
7
h) der Wahrscheinlichkeit eines unerkannten Ausfalls irgendeines Datenkommunikationsprozesses;
7.4.3.2.3
Das Diagnose-Testintervall jedes Teilsystems, das eine Fehlertoleranz der Hardware von mehr als null besitzt, muss so gewählt sein, dass das sicherheitsbezogene E/ E/ PE-System die Anforderungen zur Wahrscheinlichkeit eines zufälligen Hardwareausfalls erfüllen kann.
7.4.3.2.4 Das Diagnose-Testintervall jedes Teilsystems, das eine Fehlertoleranz der Hardware von null besitzt, von dem die Sicherheitsfunktion vollständig abhängt und das nur eine Sicherheitsfunktion(en) in der Betriebsart mit niedriger Anforderungsrate ausführt, muss gewählt sein, dass das sicherheitsbezogene E/ E/ PE-System die Anforderung zur Wahrscheinlichkeit eines zufälligen Hardwareausfalls erfüllen kann.
7.4.3.2.5 Das Diagnose-Testintervall jedes Teilsystems, das eine Fehlertoleranz der Hardware von null besitzt, von dem die Sicherheitsfunktion vollständig abhängt und das irgendeine Sicherheitsfunktion in der Betriebsart mit hoher Anforderungsrate/ kontinuierlicher Anforderung ausführt, muss so gewählt sein, dass die Summe von Diagnose-Testintervall und der Zeit, die festgelegte Reaktion auszuführen, um einen sicheren Zustand zu erreichen oder aufrechtzuerhalten, kleiner als die Prozess-Sicherheitszeit ist. Die Prozess-Sicherheitszeit ist als die Zeitspanne zwischen dem Auftreten eines Ausfalls der EUC oder des EUC-Leit- oder Steuerungssystems (mit Potential zu einem gefährlichen Vorfall) und dem Auftreten des gefährlichen Vorfalls bei nicht ausgeführter Sicherheitsfunktion definiert.
7.4.7 Anforderungen zur E/ E/ PES-Implementierung
7.4.7.3 Folgende Informationen müssen für jedes sicherheitsbezogenes Teilsystem verfügbar sein: b) geschätzte Ausfallraten (aufgrund zufälliger Hardwareausfälle) in allen
Modi, die zu einem gefahrbringenden Ausfall des sicherheitsbezogenen E/ E/ PE-Systems führen würden und durch Diagnosetests erkannt werden;
c) der geschätzten Ausfallrate jedes Teilsystems in allen Modi, die zu einem gefahrbringenden Ausfall des sicherheitsbezogenen E/ E/ PE-Systems führen und welche durch Diagnosetests nicht erkannt werden;
e) jede Grenze bzgl. Lebensdauer des Teilsystems, um die Ausfallrate zu gewährleisten;
g) nach Anhang C bestimmter Diagnoseaufdeckungsgrad; h) Diagnose-Testintervall; i) jede zusätzliche Information zur Ermittlung der MTTR, die auf die Erkennung
eines Fehlers durch Diagnose erfolgt; j) jegliche Information, die zur Ableitung der SFF des Teilsystems notwendig ist
(siehe Anhang C); m) höchster SIL, der für eine Sicherheitsfunktion in Anspruch genommen werden
kann, die das Teilsystem verwendet;
8
7.4.7.4 Die geschätzten Ausfallraten für Teilsysteme aufgrund zufälliger Hardwareausfälle können entweder festgelegt werden durch a) Ausfallarten- und Auswirkungsanalyse (FMEA) des Entwurfs unter
Verwendung von Bauteilausfalldaten aus einer anerkannten industriellen Quelle (empfohlenes Vertrauensniveau mind. 70 % und Berücksichtigung der Lebensdauer),
b) durch Erfahrung aus vorheriger Verwendung des Teilsystems in einer ähnlichen Umgebung.
Anhang C (normativ): Diagnoseaufdeckungsgrad und Anteil ungefährlicher Ausfälle C.1 Berechnung Diagnoseaufdeckungsgrad und Anteil ungefährlicher Ausfälle eines Teilsystems Vorgehensweise Diagnoseaufdeckungsgrad:
a) Durchführung einer Ausfallarten- und Auswirkungsanalyse (FMEA), gestützt auf ausreichende Informationen (detailliertes Blockschaltbild, Hardwareschalt-pläne, Ausfallarten und –raten jedes Bauteils oder jeder Bauteilgruppe mit zugehörigen prozentualen Werten der Gesamt-Ausfallwahrscheinlichkeit in Bezug auf sichere und gefahrbringende Ausfälle);
b) Einstufung jeder Ausfallart je nachdem, ob sie (ohne Diagnosetests) zu sicherem (Sicherheitsintegrität nicht betroffen) oder gefahrbringendem (Sicherheitsintegrität betroffen) Ausfall führt;
c) Aus Abschätzung der Häufigkeit1) λ eines Ausfalls jedes Bauteils oder Bauteilgruppe und den Ergebnissen der FMEA wird für jedes Bauteil oder Bauteilgruppe die Häufigkeit1) eines sicheren Ausfalls λS und die Häufigkeit1) eines gefahrbringenden Ausfalls λD berechnet.
d) Für jedes Bauteil oder Bauteilgruppe Abschätzung des Anteils gefahrbringender Ausfälle λDD von λD, die durch Diagnosetests erkannt werden;
e) Für das Teilsystem werden die Gesamtausfallhäufigkeiten1) ∑ λD, ∑λDD und ∑λS berechnet.
f) Diagnoseaufdeckungsgrad DC des Teilsystems = ∑λDD/ ∑ λD g) Anteil ungefährlicher Ausfälle des Teilsystems (∑λS +∑λDD)/(∑λS +∑ λD). Werden bei a) Felddaten verwendet ist eine Vertrauensuntergrenze von 70 % erforderlich.
1) Der Begriff „Wahrscheinlichkeit“ wurde durch „Häufigkeit“ ersetzt, da die offizielle deutsche Übersetzung „Wahrscheinlichkeit“ an
dieser Stelle irreführend ist. Es handelt sich um eine Ausfallrate.
9
IEC 61508-6: Anhang B (informativ): Beispieltechnik zur Bewertung der Wahrscheinlichkeit eines Hardwareausfalls
- PFDSYS := durchschnittl. PFD für eine Sicherheitsfunktion eines sicherheitsgerichteten E/ E/ PE-Systems;
- PFDS := durchschnittl. PFD des Sensor-Teilsystems; - PFDL := durchschnittl. PFD des Logik-Teilsystems; - PFDFE:= durchschnittl. PFD des Aktor-Teilsystems;
Prozedur zur Ermittlung der drei PFDs: a) Darstellung des jeweiligen Teilsystems in einem Blockdiagramm gemäß Architektur
(1oo1, 1002,etc.); b) Betrachtung der jeweiligen Wertetabelle nach Wartungsintervall (6 Monate, 1 Jahr, 2
Jahre oder 10 Jahre); Annahme einer MTTR von 8h bei Fehlerauftreten für jede Wertetabelle (Referenzwerttabellen siehe IEC 61508-6, Anhang B, B.2.3);
c) Wahl der folgenden Parameter aus den Wertetabellen für jede Gruppe des Teilsystems:
- Architektur - Diagnoseaufdeckungsgrad DC für jeden Kanal - Fehlerrate λ [h] für jeden Kanal - Common cause Fehler β-Faktoren, β und βD (Annahme 2 βD ~ β), für die
Interaktion zwischen Kanälen der gewählten Gruppe - Erhalt der durchschn. PFD der gewählten Gruppe mit Hilfe der jeweiligen
Wertetabelle - Besteht die untersuchte Sensor-/Aktor-Gruppe aus mehreren Sensor-/ Aktor-
Untergruppen Gi bzw. Gj, so ergeben sich die gesuchten PFDs durch Summation:
∑=i
GiS PFDPFD
∑=
jGjFE PFDPFD
10
B.2.2 Architekturen für niedrige Anforderungsrate B.2.2.1 1oo1
Kanal
Diagnose
1oo1 physisches Blockdiagramm
λD
λDU λDD
tc1=T1+MTTR tc2=MTTR
2
tCE
1oo1 Verlässlichkeits-Blockdiagramm
Die Rate gefährlicher Fehler wird gegeben durch: λD= λDU+ λDD=λ/2
Mean Down Time tCE des Kanals:
MTTRMTTRTtD
DD
D
DUCE λ
λλλ
+
+=
21
Für jede Art Architektur werden λDU und λDD gegeben durch:
( ) DCDC DDDU 2;1
2´λλλλ =−=
Für Kanäle mit tCE, resultierend aus gefährlichen Fehlern, gilt:
11
<<≈−= −
CEDCED
t
tfallstePFD CED
λλ
λ
Folglich ergibt sich im Falle einer 1oo1 Architektur eine PFD gemäß:
PFDG=(λDU+λDD)tCE
11
B.2.2.2 1oo2
Diagnose
Kanal
1oo2 physikalisches Blockdiagramm
U D
Common
Kanal
1oo2
1oo2 Verlässlich
Nun ist es zusätzlich notwendig, die Syst
TtD
DUGE λ
λ=
31
Die durchschnittliche PFD der Architekt
( ) ( )( )−+−= ttPFD GCEDUDDDG 112 2λβλβ
B.2.2.3 2oo2
Diagn
Kan
Kan
2oo2 physikalis
λD
tCE
λD
keits-Blo
em-äquiv
MTTR+
ur beträg
+ DDE λβ
ose
al
al
ches Bloc
λD
cause Fehler
c
a
t:
D
k
tGE
kdiagramm
lente Down Time tGE zu berechnen:
MTTRD
DD
λλ
+
++ MTTRTMTTR DU 2
1βλ
2oo2
diagramm
12
U
DU D
2oo2 Verlässlichkeits-Blockdiagramm
Entsprechender Wert für tCE ergibt sich aus B.2.2.1. Die durchschnittliche PFD für selbige Architektur berechnet sic
PFDG=2λDtCE
B.2.2.4 1oo2D
e
e
Kanal
Kanal
1oo2D
1oo2D physikalisches Blockdiagramm
λDUtGE`
λDU λDD λSD
tCE`
1oo2D Verlässlichkeits-Blockdiagramm
Die Rate sicherer entdeckter Fehler für jeden Kanal ist gegeben
DCSD 2λλ =
λD
tCE
λD
h als:
durch:
λD
λD
tCE
λD
λD
Diagnos
Diagnos
Common cause Fehler
13
Die Werte der äquivalenten Mean Down Times unterscheiden sich von denen der anderen Architekturen in B.2.2, also werden sie mit tCE` und tGE` bezeichnet. Ihre Werte erhält man durch:
( )
SDDDDU
SDDDDU
CE
MTTRMTTRT
tλλλ
λλλ
++
++
+
= 2'
1
( )
SDDDDU
SDDDDU
GE
MTTRMTTRT
tλλλ
λλλ
++
++
+
= 3'
1
( ) ( ) ( )( )
++++−+−−= MTTRTMTTRttPFD DUDDDGECESDDDDDUDUG 2
''1112 1βλλβλλβλβλβ
B.2.2.5 2oo3
Kanal
Kanal
Diagnose
Kanal 2oo3
2oo3 physikalisches Blockdiagramm
U D
2oo3 Verlässlich
Der Wert von tCE wird in B.2.2.1 und der We
( ) ( )( )−+−=PFD DUDDDG 116 2λβλβ
λD
tCE
λD
keits-Blo
rt von tG
+tt GECE β
λD
2oo3 Common
cause
c
E
D
Fehler
tGE
kdiagramm
in B.2.2.2 gegeben.
++ MTTRTMTTR DUDD 2
1βλλ
14
B.3: PFH (für hohe Anforderungsrate oder kontinuierlichen Modus) B.3.1 Rechenverfahren Stadt der Bezeichnung PFDSYS verwendet man nun PFHSYS. PFHSYS = PFHS + PFHL + PFHFE mit
- PFHSYS := Häufigkeit1) eines Fehlers pro Stunde für eine Sicherheitsfunktion eines sicherheitsgerichteten E/ E/ PE-Systems;
- PFHS := Häufigkeit1) eines Fehlers pro Stunde für das Sensor-Teilsystem; - PFHL := Häufigkeit1) eines Fehlers pro Stunde für das Logik-Teilsystem; - PFHFE:= Häufigkeit1) eines Fehlers pro Stunde für das Aktor-Teilsystem;
B.3.2 Architekturen für hohe Anforderung oder kontinuierlichen Operationsmodus B.3.2.1 1oo1 Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate.
λD= λDU+ λDD=λ/2
MTTRMTTRTtD
DD
D
DUCE λ
λλλ
+
+=
21
( ) DCDC DDDU 2;1
2´λλλλ =−=
Angenommen das Sicherheitssystem führt das EUC bei Entdeckung eines Fehlers in einen sicheren Zustand über, wird für eine 1oo1 Architektur Folgendes erreicht:
PFHG=λDU
B.3.2.2 1oo2 Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate.
B.3.2.3 2oo2 Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate. Wird unterstellt, dass jeder Kanal bei Entdeckung eines Fehlers in den sicheren Zustand geht, gilt:
PFHG=2λDU B.3.2.4 1oo2D Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate.
1) Der Begriff „Wahrscheinlichkeit“ wurde durch „Häufigkeit“ ersetzt, da die offizielle deutsche Übersetzung „Wahrscheinlichkeit“ an
dieser Stelle irreführend ist. Es handelt sich um eine Ausfallrate.
Annex D (informativ): Methode zur Quantifizierung des Effektes Hardware-verursachter Common cause Fehler in E/ E/ PE-Systemen D.3 Form der Methode Der Schätzer für die Wahrscheinlichkeit von Common cause Fehlern bezieht sich nur auf Fehler in Verbindung mit Hardware, es werden keine Software-bedingten Fehler in Betracht gezogen. D.4 Punkte bzgl. Der Methode Das Sensor-, Logik- und Aktor-Teilsystem wird jeweils separat untersucht. Programmierbare elektronische Kanäle haben das Potential, fundierte diagnostische Testfunktionen auszuführen. Diese können
- einen hohen Diagnoseaufdeckungsgrad innerhalb des Kanals haben; - zusätzlich redundante Kanäle überwachen; - eine hohe Wiederholungsrate haben; und - in einer wachsenden Zahl von Fällen auch Sensoren und/ oder Aktoren
überwachen.
Unterscheidung in Maßnahmen, die die Diagnose von Common cause Fehlern verbessern und welchen, die dies nicht tun. Hieraus resultieren in Tabelle D.1 die beiden Spalten X und Y. Es wird angenommen, dass falls ein Common cause Fehler auftritt, er alle Kanäle betrifft. Allerdings gibt es keine bekannten Daten bzgl. Hardware-bezogener Common cause Fehler zur Kalibrierung der Methode. Folglich basieren die Tabellen in diesem Annex auf Konstrukteurs-Ermessen. D.5 Benutzung des β-Faktors zur Berechnung der Ausfallwahrscheinlichkeit in einem sicherheitsbezogenen E/ E/ PE-System bzgl. Common cause Fehlern Unter Benutzung des β-Faktor-Modells beträgt die Häufigkeit1) eines Common cause Fehlers
λDβ, wobei λD die Häufigkeit1) gefährlicher zufälliger Hardwarefehler und β den Anteil von Einzelkanalfehlern, die alle Kanäle betreffen, bezeichnet. Man nehme an, die Zeitspanne zwischen dem Befall des ersten Kanals und der übrigen sei vernachlässigbar klein im Vergleich zum zeitlichen Abstand zweier aufeinander folgender Common cause Fehler. Die Gesamtausfallhäufigkeit1) in Bezug auf gefährliche Common cause Fehler ist durch
λDUβ + λDDβD gegeben, wobei
- λDU:= Häufigkeit1) eines unentdeckten gefährlichen Einzelkanalfehlers; - β := Common cause Fehler-Faktor für unentdeckbare gefährliche Fehler; - λDD:= Häufigkeit1) eines entdeckten gefährlichen Einzelkanalfehlers; - βD := Common cause Fehler-Faktor für entdeckbare gefährliche Fehler;
1) Der Begriff „Wahrscheinlichkeit“ wurde durch „Häufigkeit“ ersetzt, da die offizielle deutsche Übersetzung „Wahrscheinlichkeit“ an dieser Stelle irreführend ist. Es handelt sich um eine Ausfallrate.
17
D.6 Benutzung der Tabellen zur Schätzung von β Der β-Faktor sollte für Sensoren, logisches Teilsystem und Aktoren separat berechnet werden. Tabellarisch wird für den Logikteil XLS und YLS, für Sensoren und Aktoren XSF und YSF angegeben. Der Wert S wird unter Verwendung folgender Gleichungen ermittelt
- S = X + Y zur Bestimmung von β, - SD = X(Z + 1) + Y, um βD zu erhalten.
Hier repräsentiert S oder SD den Wert, der unter Zuhilfenahme von Tabelle D.4 benutzt wird, um den geeigneten β-Faktor zu bestimmen. Bei Verwendung von Tabelle D.1 ist unbedingt darauf zu achten, dass der Gesamtwert in den X und Y Spalten für jede Kategorie nicht kleiner als der Gesamtwert in den X und Y Spalten geteilt durch 20 ist. Sind Sensoren oder Aktoren PE-basiert, sollten sie als Teil des Logiksubsystems behandelt werden, wenn sie an das gleiche Gebilde wie der überwiegende Teil der Logik angeschlossen sind, ansonsten werden sie zum Sensor-/ Aktorteil gerechnet.
18
19
20
21
IEC 61508-7:
Annex D (informativ): Ein probabilistischer Ansatz zur Bestimmung der Software-Sicherheitsintegrität für vor-entwickelte Software D.1 Allgemeines Der im Folgenden dargelegte Ansatz basiert auf Anwendungserfahrung und sollte nur von Personen herangezogen werden, die die notwendige Fachkompetenz im Bezug auf statistische Analysen besitzen. Mittels dieser Technik ist es ebenfalls möglich, den wachsenden SIL der Software mit fortschreitendem zeitlichen Verlauf zu demonstrieren. Anwendungserfahrung von einigen Seiten darf kombiniert werden, aber nur wenn
- die Softwareversion, die im sicherheitsbezogenen E/ E/ PE-System benutzt wird, identisch mit der Version ist, für die Anwendungserfahrung vorliegt;
- das Operationsprofil des Eingaberaums ähnlich ist; - ein effektives System zur Fehlermeldung und –dokumentation existiert; und - die relevanten Voraussetzungen (siehe D.1) erfüllt sind.
4 ≥ 10-5 bis < 10-4 4,6 x 105 3 x 105 ≥ 10-9 bis < 10-8 4,6 x 109 3 x 109 3 ≥ 10-4 bis < 10-3 4,6 x 104 3 x 104 ≥ 10-8 bis < 10-7 4,6 x 108 3 x 108 2 ≥ 10-3 bis < 10-2 4,6 x 103 3 x 103 ≥ 10-7 bis < 10-6 4,6 x 107 3 x 107 1 ≥ 10-2 bis < 10-1 4,6 x 102 3 x 102 ≥ 10-6 bis < 10-5 4,6 x 106 3 x 106
Tabelle D.1 – notwendige Historie für Vertrauen in SIL (bzgl. Details siehe
D.2.1 und D.2.3)
D.2 Statistische Testformeln und Bespiele zur Benutzung D.2.1 Einfacher statistischer Test für niedrige Anforderungsrate D.2.1.1 Voraussetzungen
a) Testdatenverteilung gleich Verteilung der Anforderungen während Online-Betrieb. b) Die Testläufe sind statistisch unabhängig voneinander in Bezug auf
Fehlerverursachung. c) Es existiert ein geeigneter Mechanismus zu Entdeckung jedes Fehlers. d) Die Zahl der Testläufe n > 100. e) Es geschieht kein Fehler während der n Testläufe.
D.2.1.2 Ergebnisse Fehlerwahrscheinlichkeit (bei Anforderung) zum Konfidenzlevel 1-α ist gegeben durch
pnoderp n αα ln1 −≥−≤
1) Der Begriff „Wahrscheinlichkeit“ wurde durch „Häufigkeit“ ersetzt, da die offizielle deutsche Übersetzung „Wahrscheinlichkeit“ an dieser Stelle irreführend ist. Es handelt sich um eine Ausfallrate.
22
D.2.2 Testen eines Eingaberaums (Domäne) für niedrige Anforderungsrate D.2.2.1 Voraussetzungen Die einzige Voraussetzung besteht darin, dass die Testdaten uniform über dem Eingaberaum verteilt sind. D.2.2.2 Ergebnisse Ziel ist es, die Testanzahl n zu finden, die notwendigerweise auf der Schwellwertgenauigkeit δ der Eingaben für die Funktion niedriger Anforderungsrate, die getestet wird, basiert.
Dimension der Domäne
Mittlere Abstand zweier Testpunkte in Richtung einer beliebigen Achse
1 n/1=δ 2 2 /1 n=δ 3 3 /1 n=δ k k n/1=δ
k kann jede positive Integer sein;
Tabelle D.3 – mittlerer Abstand zwischen zwei Testpunkten D.2.3 Einfacher statistischer Test für hohe Anforderungsrate oder kontinuierlichen Operationsmodus D.2.3.1 Voraussetzungen
a) Testdatenverteilung ist gleich der Verteilung während des Online-Betriebs. b) Die relative Reduktion der Wahrscheinlichkeit für keinen Fehler ist proportional zur
Länge des betrachteten Zeitintervalls und andernfalls konstant. c) Es existiert ein geeigneter Mechanismus zur Entdeckung jedes Fehlers. d) Der Test erstreckt sich über eine Testzeit t. e) Kein Fehler tritt während t auf.
D.2.3.2 Ergebnisse Der Zusammenhang zwischen Fehlerrate λ, Konfidenzlevel 1-α und der Testzeit t ist
tαλ ln
−=
Die Fehlerwahrscheinlichkeit ist indirekt proportional zur MTBF:
MTBF1
=λ
Anmerkung: Unterscheidet nicht zwischen Fehlerwahrscheinlichkeit pro Stunde und Fehlerrate pro Stunde. Streng genommen besteht die Verbindung zwischen Fehlerwahrscheinlichkeit F und Fehlerrate f durch
. fteF −−=1
23
Aber die Form dieses Standards bezieht sich auf Fehlerraten kleiner als 10-5 und für Werte dieser Größenordnung ist . ftF ≈ D.2.4 Vollständiger Test Das Programm kann als Urnenmodell mit N Kugeln betrachtet werden, an dem „Ziehen mit Zurücklegen“ praktiziert wird. Dabei repräsentiert jede Kugel in der Urne eine Programmeigenschaft, die von Interesse ist. D.2.4.1 Voraussetzungen
a) Die Testdatenverteilung ist derart, dass die N Programmeigenschaften mit gleicher Wahrscheinlichkeit getestet werden.
b) Die Testläufe sind unabhängig voneinander. c) Jeder auftretende Fehler wird entdeckt. d) Kein Fehler tritt während der n Testläufe auf. e) Jeder Testlauf prüft eine Programmeigenschaft.
D.2.4.2 Ergebnisse Die Wahrscheinlichkeit p, alle Programmeigenschaften zu testen, ist gegeben durch
( )njN
j NjN
jN
p
−
−= ∑
−
=
1
01 oder ( )
n
Nj
jN
j NjNCp
−
−+= ∑=
,1
11
wobei
( ) ( )!
11, j
jNNNC Nj+−−
=K
Zur Bewertung dieser Formel werden normalerweise nur die ersten Terme betrachtet, da realistische Fälle durch n >> N charakterisiert sind. Der letzte Faktor macht alle Terme für großes j sehr klein.
24
A.3 IEC 61511 IEC 61511-1:
3 Begriffe und Abkürzungen 3.2 Begriffe
3.2.15 Diagnose-Aufdeckungsgrad (DC) der Diagnoseaufdeckungsgrad einer Komponente oder eines Teilsystems ist das Verhältnis der Ausfallrate der durch Diagnoseprüfungen erkannten Fehler zur Gesamtausfallrate der Komponente oder des Teilsystems. Der Diagnoseaufdeckungsgrad beinhaltet keine bei Funktionsprüfung festgestellten Fehler. Anmerkung 1: Die Diagnose-Aufdeckung wird benutzt, um die festgestellte (λdetected) und nicht festgestellte (λundetected) Ausfallrate aus der Gesamtausfallrate (λtotal failure rate) folgendermaßen zu berechnen: λdetected = DC x λtotal failure rate und λundetected = (1-DC) x λtotal failure rate. Anmerkung 2: Der Diagnose-Aufdeckungsgrad kann für Bauteile oder Baugruppen eines sicherheitsbezogenen Systems angewendet werden. Typischerweise wird der Diagnose-Aufdeckungsgrad für Sensoren, Stellglieder oder Logikbaugruppen bestimmt. Anmerkung 3: Für Sicherheitsanwendungen wird der Diagnose-Aufdeckungsgrad typischerweise auf sichere und gefährliche Ausfälle des Bauteils oder der Baugruppe angewendet. Beispielsweise kann der Diagnose-Aufdeckungsgrad für den gefährlichen Ausfall bei einer Baugruppe DC = λDD / λDT betragen, wobei λDD die Ausfallrate für festgestellte, gefährliche Ausfälle und λDT die Gesamtausfallrate für gefährliche Ausfälle ist.
3.2.29 Sicherheitsintegrität der Hardware1)
Teil der Sicherheitsintegrität der sicherheitstechnischen Funktion, der sich auf zufällige Hardware-Ausfälle mit gefährlicher Ausfallart bezieht.
3.2.60 betriebsbewährt1)
Eine Komponente ist dann betriebsbewährt, wenn eine Untersuchung mit entsprechender Dokumentation ergeben hat, dass geeignete Nachweise über frühere Einsätze belegen, dass die Komponente für den Einsatz in einem sicherheitstechnischen System geeignet ist.
1) Diese Definition weicht wegen in der Prozessindustrie vorhandener Unterschiede in der Terminologie von der Definition in IEC 61508 – 4 ab.
25
5 Management der funktionalen Sicherheit 5.2 Anforderungen
5.2.5 Ausführung und Überwachung 5.2.5.3
Es müssen Bewertungsverfahren eingeführt werden, mit denen sich die Leistungsfähigkeit des sicherheitstechnischen Systems in Bezug auf die Sicherheitsanforderungen bestimmen lässt, einschließlich Verfahren zur: - Erkennung und Vermeidung von systematischen Ausfällen, welche die
Sicherheit in Frage stellen könnten; - Klärung, ob die Wahrscheinlichkeit P(F) gefährlicher Ausfälle des
sicherheitstechnischen Systems mit den zum Zeitpunkt der Auslegung getroffenen Annahmen übereinstimmt.1)
- Ermittlung der Häufigkeit P(D), mit der sicherheitstechnische Funktionen im tatsächlichen Betrieb ausgelöst werden, um die Annahmen zu prüfen, die während der Risikobeurteilung bei Festlegung der Anforderung an die Integritätslevel getroffen wurden.
8 Gefährdungsbeurteilung und Risikobewertung
8.2 Anforderungen 8.2.1
Für das Verfahren und seine zugehörigen Betriebsmittel (z.B. BPCS) müssen eine Gefährdungsbeurteilung und Risikobewertung durchgeführt werden, die zu Ergebnissen führen:
- Beschreibung jedes erkennbaren gefährlichen Zustands und der Komponenten, die dazu beitragen (einschließlich menschlichen Fehlverhaltens)
- Beschreibung der damit verknüpften Folgewirkungen und Eintritts-Wahrscheinlichkeit;
- Festlegung der Anforderungen für zusätzliche zum Erreichen der erforderlichen Sicherheit notwendige Maßnahmen zur Risikoreduzierung;
- Beschreibung oder Verweis auf eine entsprechende Dokumentation für die Maßnahmen, die zum Ausschluss oder zur Reduzierung von Gefahren getroffen werden;
- genaue Beschreibung der bei der Risikoanalyse getroffenen Annahmen, einschließlich wahrscheinlicher Anforderungsraten und Geräte-Ausfallraten und der vorausgesetzten betrieblichen Randbedingungen und Bedienereingriffe;
- Zuordnung von Sicherheitsfunktionen zu Schutzebenen (siehe Abschnitt 9) unter Berücksichtigung möglicher Verminderung der Schutzwirkung aufgrund von Ausfällen infolge gemeinsamer Ursache (Common cause Fehler) zwischen den einzelnen Schutzebenen und zwischen Schutzebenen und dem BPCS (siehe Anmerkung 1);
- Bestimmung derjenigen Sicherheitsfunktionen, die als sicherheitstechnische Funktionen ausgeführt werden (siehe Abschnitt 9).
Anmerkung 1: Bei der Beurteilung, ob die allgemeine Planung für die Anlage und für die Schutzebenen die Anforderungen erfüllt, ist es erforderlich, Fehler gemeinsamer Ursache zu berücksichtigen.
1) Dies wäre z.B. durch Auswertung der NAMUR-Daten möglich.
26
8.2.2 Die Ausfallrate bezüglich gefährlicher Ausfälle eines BPCS (das nicht der IEC 61511 entspricht), das eine Anforderung an eine Schutzebene stellt, darf bestenfalls mit 10-5 pro Stunde angesetzt werden.
8.2.3 Die Bewertung von Gefährdung und Risiko sollte in einer Form aufgezeichnet werden, dass der Zusammenhang innerhalb der oben aufgeführten Punkte klar und nachvollziehbar ist.
9 Zuordnung von sicherheitstechnischen Funktionen zu Schutzebenen
9.2 Anforderungen für den Prozess der Zuordnung 9.2.3
Für jede sicherheitstechnische Funktion, die in Anforderungsbetriebsart arbeitet, muss der erforderliche SIL in Übereinstimmung mit Tabelle 3 oder 4 festgelegt werden. Wenn Tabelle 4 verwendet wird, darf weder die Häufigkeit der Funktionsprüfung noch die Anforderungsrate bei der Bestimmung des SIL verwendet werden.
9.2.4 Für jede sicherheitstechnische Funktion, die in Betriebsart mit kontinuierlicher Anforderung arbeitet, muss der erforderliche SIL in Übereinstimmung mit Tabelle 4 festgelegt werden.
Anforderungsbetriebsart SIL Zielwert für die mittlere
Ausfallwahrscheinlichkeit bei Anforderung
Zielwert für die Risikoreduzierung
4 ≥ 10-5 bis < 10-4 > 10.000 bis ≤ 100.000 3 ≥ 10-4 bis < 10-3 > 1.000 bis ≤ 10.000 2 ≥ 10-3 bis < 10-2 > 100 bis ≤ 1000 1 ≥ 10-2 bis < 10-1 > 10 bis ≤ 100
Tabelle 3 – SIL: Ausfallwahrscheinlichkeit bei Anforderung
Betriebsart mit kontinuierlicher Anforderung SIL Zielwert für die Häufigkeit gefährlicher
Ausfälle der sicherheitstechnischen Funktion pro Stunde
4 ≥ 10-9 bis < 10-8 3 ≥ 10-8 bis < 10-7 2 ≥ 10-7 bis < 10-6 1 ≥ 10-6 bis < 10-5
Tabelle 4 – SIL: Häufigkeit gefährlicher Ausfälle der sicherheitstechnischen Funktion Anmerkung 2: Der SIL ist numerisch festgelegt, damit man einen objektiven Zielwert zum Vergleichen alternativer Entwürfe und Lösungen hat. Es wird jedoch anerkannt, dass nach heutigem Wissensstand viele systematische Ursachen für Ausfälle nur qualitativ angegeben werden können. Anmerkung 3: Die erforderliche Ausfallrate für gefährliche Ausfälle pro Stunde einer sicherheitstechnischen Funktion in Betriebsart mit kontinuierlicher Anforderung ergibt sich aus der Betrachtung des Risikos eines Ausfalls der sicherheitstechnischen Funktion in Betriebsart mit kontinuierlicher Anforderung und der Ausfallrate anderer Einrichtungen,
27
die zum selben Risiko führen, unter Berücksichtigung von Beiträgen anderer Schutzebenen. Anmerkung 4: Es ist möglich anstelle einer Funktion mit höherem Integritätslevel mehrere Systeme niedrigerer SIL zu kombinieren (z.B. SIL 1 und SIL 2 zu SIL 3)
9.3 Zusätzliche Anforderungen für SIL 4 9.3.1
Einem sicherheitstechnischen System darf keine sicherheitstechnische Funktion mit einem SIL größer als 4 zugeordnet werden. Anwendungen, die eine einzelne sicherheitstechnische Funktion mit einem SIL 4 erfordern, kommen in der Prozessindustrie selten vor und sollten nach Möglichkeit vermieden werden. Sollte es laut Analyse dennoch erforderlich sein, muss überprüft werden, ob sich durch Verfahrensänderung oder zusätzliche Schutzebenen die Eigensicherheit verbessern lässt, um die Anforderung an den SIL möglicherweise reduzieren zu können.
9.3.2
Eine sicherheitstechnische Funktion mit SIL 4 ist nur dann zulässig, wenn entweder das folgende Kriterium a) oder beide Kriterien b) und c) erfüllt werden: a) ein eindeutiger Nachweis aufgrund geeigneter analytischer Methoden und Prüfungen
belegt den Sollwert der Ausfallwahrscheinlichkeit dieses SIL; b) mit den in dieser sicherheitstechnischen Funktion eingesetzten Komponenten liegen
ausgiebige Betriebserfahrungen vor (in ähnlicher Umgebung und ähnlichem Komplexitätsgrad).
c) es liegen ausreichende Daten über die Hardware-Ausfallrate der Komponenten vor, die in der sicherheitstechnischen Funktion eingesetzt werden sollen, um ein hinreichendes Zutrauen in den von der Hardware geforderten Sollwert der Gesamt-Ausfallrate zu begründen.
9.4 Anforderungen an Betriebseinrichtungen, die als Schutzebene eingesetzt werden
sollen 9.4.2
Der mit einem BPCS (das IEC 61511 oder 61508 nicht entspricht) erreichbare Faktor der Risikoreduzierung bei Verwendung als Schutzebene liegt unterhalb von 10.1)
9.4.3 Wenn eine größere Risikoreduzierung als Faktor 10 für das BPCS geltend gemacht wird, dann muss es nach den Anforderungen dieser Norm ausgeführt werden.
9.5 Anforderungen zur Vermeidung von Ausfällen infolge gemeinsamer Ursache, gleichartige Ausfälle und abhängige Ausfälle
9.5.1 Der Entwurf der Schutzebenen muss dahingehend geprüft werden, ob die Wahrscheinlichkeit von Ausfällen gemeinsamer Ursache, von gemeinsamer Art und von abhängigen Ausfällen zwischen Schutzebenen ausreichend gering ist. Die Überprüfung kann qualitativ oder quantitativ durchgeführt werden.
1) Das bedeutet eine deutliche Einschränkung für Sicherheitslösungen, bei denen das BPCS als Schutzebene verwendet wird.
28
10 Sicherheitsspezifikation des SIS 10.3 Sicherheitsanforderungen an das SIS
10.3.1 Die Anforderungen müssen ausreichend für den Entwurf des SIS sein und Folgendes beinhalten: …
- Anforderungen, um Fehler gemeinsamer Ursache herauszufinden und zu berücksichtigen;
- eine Definition des sicheren Zustands für jede einzelne sicherheitstechnische Funktion;
… - die zu erwartenden Auslöser einer Anforderung, sowie deren geschätzte
Anforderungsrate der sicherheitstechnischen Funktion; - Anforderung an das Intervall der Wiederholungsprüfung; - die erforderlichen Antwortzeiten für das SIS, um den Prozess in einen sicheren
Zustand zu bringen; - der SIL und die Betriebsart (auf Anforderung oder kontinuierlich) jeder
Sicherheitsfunktion; …
- die maximal zulässige Häufigkeit aktiver Fehler; …
- Sicherheitsanforderungen an die Anwendungssoftware gemäß 12.2.2; ...
- die für das SIS erreichbare mittlere Reparaturzeit unter Berücksichtigung von Reisezeiten, Örtlichkeit, Verfügbarkeit von Ersatzteilen, Serviceverträgen, Umgebungsbedingungen;
… - Extremwerte aller Umgebungsbedingungen, die im Betrieb des SIS
gegebenenfalls auftreten können, müssen ermittelt werden (Temperatur, Feuchtigkeit, Verschmutzung, Erdung, elektro-magnetische Verträglichkeit, Erschütterungen, Schwingungen, elektrostatische Entladungen, Ex-Zonen Einteilung, Überschwemmung, Blitzeinschlag und andere zugehörige Faktoren);
…
11 SIS-Entwurf und Planung 11.2 Allgemeine Anforderungen
11.2.1 Der Entwurf eines SIS muss alle Anforderungen der Spezifikation unter Berücksichtigung aller Forderungen, die sich aus diesem Abschnitt ergeben, erfüllen.
11.2.2 Wenn im SIS sowohl sicherheitstechnische, als auch nicht-sicherheitstechnische Funktionen realisiert werden sollen, muss die gesamte Hardware und Software, die irgendeine SIF unter Normal- oder Fehlerbedingungen negativ beeinflussen könnte, als Teil des SIS behandelt werden und den Anforderungen des höchsten SIL-Werts genügen. Anmerkung 1: Soweit durchführbar sollten sicherheitstechnische Funktionen immer von nicht-sicherheitstechnischen Funktionen getrennt werden.
29
Anmerkung 2: Hinreichende Unabhängigkeit bedeutet, dass weder der Ausfall irgendeiner Nicht-Sicherheitsfunktion noch Eingriffe in die Programmierung von Nicht-Sicherheits-Softwarefunktionen zu einem gefährlichen Ausfall sicherheitstechnischer Funktionen führen können.
11.2.3 Wenn ein SIS sicherheitstechnische Funktionen mit unterschiedlichen SIL umfasst, muss die gemeinsam verwendete oder gemeinsame Hardware und Software dem jeweils höchsten SIL genügen, außer wenn sich zeigen lässt, dass die sicherheitstechnischen Funktionen der niedrigeren SIL die sicherheitstechnischen Funktionen der höheren SIL nicht negativ beeinflussen können.
11.2.4 Wenn das BPCS nicht entsprechend dieser Norm ausgeführt werden soll, muss es soweit unabhängig und getrennt aufgebaut werden, dass die funktionale Integrität des sicherheitstechnischen Systems durch das BPCS nicht in Frage gestellt wird.
11.2.10 Eine als Teil einer sicherheitstechnischen Funktion benötigte Komponente darf nicht für Funktionen des BPCS verwendet werden, wenn ein Ausfall dieser Komponente einen Ausfall des BPCS zur Folge hat und dies eine Anforderung an die sicherheitstechnische Funktion auslösen würde, außer eine Untersuchung bestätigt, dass das Gesamtrisiko vertretbar ist.
11.4 Anforderungen an die Hardware-Fehlertoleranz
11.4.1 Sensoren, Logiksysteme und Aktoren von sicherheitstechnischen Funktionen müssen eine Mindestfehlertoleranz aufweisen. Anmerkung 1: Die Hardware-Fehlertoleranz ist die Fähigkeit einer Komponente oder eines Teilsystems, trotz des Vorliegens eines oder mehrerer gefährlicher Hardwarefehler, die geforderte sicherheitstechnische Funktion auszuführen. Eine Hardware-Fehlertoleranz von 1 bedeutet, dass z.B. zwei Geräte vorhanden und so angeordnet sind, dass ein gefährlicher Ausfall eines der Geräte oder Teilsysteme die Durchführung der Sicherheitsmaßnahme nicht verhindert. Anmerkung 2: Die Mindest-Fehlertoleranz wurde festgelegt, um mögliche Versäumnisse bei der Festlegung der sicherheitstechnischen Funktionen aufgrund der dem Entwurf der sicherheitstechnischen Funktion zugrunde liegenden Annahmen und aufgrund der Unsicherheit der Ausfallraten von Komponenten oder Teilsystemen in unterschiedlichen Prozess-Anwendungen auszugleichen. Anmerkung 3: Es ist wichtig, dass die Anforderungen hinsichtlich der Hardware-Fehlertoleranz die Mindest-Redundanz von Komponenten oder Teilsystemen darstellen. Um den SIL der sicherheitstechnischen Funktion einzuhalten, können zusätzliche Redundanzen gemäß Abschnitt 11.9 in Abhängigkeit von Anwendung, Ausfallraten der Komponenten und Prüfzyklus erforderlich sein.
30
11.4.2 PE-Logiksysteme müssen eine Mindest-Hardware-Fehlertoleranz gemäß Tabelle 5 aufweisen.
Tabelle 5 – Mindest-Hardware-Fehlertoleranz von PE-Logiksystemen
11.4.3 Bei allen Teilsystemen außer bei PE-Logiksystemen muss die Mindest-Fehlertoleranz Tabelle 6 entsprechen, wenn die hauptsächliche Ausfallart in den sicheren Zustand gerichtet ist oder gefährliche Ausfälle erkannt werden, ansonsten muss die Fehlertoleranz um 1 erhöht werden. Anmerkung: Um zu entscheiden, ob die hauptsächliche Ausfallart in den sicheren Zustand gerichtet ist, sind alle folgenden Punkte zu berücksichtigen:
- Prozessanschluss des Geräts; - Nutzung von Diagnoseinformationen des Geräts zur Validierung des
Prozesssignals; - Verwendung von im Gerät vorhandenen Failsafe-Eigenschaften (z.B.
Ruhesignalprinzip, Ausfall der Energieversorgung führt zum sicheren Zustand).
11.4.4 Bei allen Teilsystemen außer bei PE-Logiksystemen kann die Mindest-Fehlertoleranz nach Tabelle 6 um 1 reduziert werden, wenn für die verwendeten Geräte alle folgenden Bedingungen zutreffen:
- die Hardware des Geräts wurde auf Basis einer früheren Verwendung ausgewählt;
- das Gerät ermöglicht nur die Einstellung prozessbezogener Parameter; - Einstellung der prozessbezogenen Parameter des Geräts ist geschützt (z.B.
Brücke oder Passwort); - die Funktion hat einen geforderten SIL von weniger als 4.
SIL Mindest-Hardware-Fehlertoleranz (siehe 11.4.3 und
Tabelle 6 – Mindest-Hardware-Fehlertoleranz von Sensoren, Aktoren und nichtprogrammierbaren Logiksystemen
11.4.5
Alternative Anforderungen an die Fehlertoleranz können verwendet werden, wenn eine Beurteilung gemäß den Anforderungen der IEC 61508-2, Tabellen 2 und 3 durchgeführt wird.
31
11.5 Anforderungen zur Auswahl von Komponenten und Teilsystemen 11.5.2 Allgemeine Anforderungen
11.5.2.1 Komponenten und Teilsysteme, die als Teil eines SIS für Anwendungen mit einem SIL 1 bis SIL 3 ausgewählt werden, müssen entweder IEC 61508-2 und IEC 61508-3, soweit zutreffend entsprechen oder sie müssen den Abschnitten 11.4 und 11.5.3 bis 11.5.6 soweit zutreffend entsprechen.
11.5.2.2
Komponenten und Teilsysteme, die als Teil eines SIS für SIL 4-Anwendungen ausgewählt werden, müssen IEC 61508-2 und IEC 61508-3, soweit zutreffend entsprechen.
11.5.2.3
Die Eignung der ausgewählten Komponenten und Teilsysteme muss unter Berücksichtigung folgender Punkte nachgewiesen werden:
- Dokumentation des Herstellers über Hardware und Firmware; - soweit zutreffend, geeignete Auswahl von Anwendungssprache und
Hilfsmitteln (siehe 12.4.4).
11.5.2.4 Die Komponenten und Teilsysteme müssen der Spezifikation der Sicherheitsanforderungen des SIS entsprechen.
Anmerkung: Bei der Auswahl von Komponenten und Teilsystemen gelten alle anderen anwendbaren Gesichtspunkte dieser Norm, einschließlich Beschränkungen hinsichtlich der Architektur, Hardwareintegrität, Verhalten bei der Aufdeckung eines Fehlers und Anwendungssoftware.
11.5.3 Anforderung hinsichtlich der auf Basis einer früheren Verwendung erfolgenden Auswahl von Komponenten und Teilsystemen
11.5.3.1 Es muss in geeigneter Weise nachgewiesen werden, dass die Komponenten und Teilsysteme für den Einsatz im sicherheitstechnischen System geeignet sind. Anmerkung 1: Bei Feldgeräten kann als Grundlage des Nachweises eine umfangreiche Betriebserfahrung sowohl in Sicherheits- als auch in Nicht-Sicherheitsanwendungen herangezogen werden. Anmerkung 2: Der Detaillierungsgrad des Nachweises sollte mit der Komplexität der betrachteten Komponente oder des Teilsystems und der zum Erreichen des SIL der sicherheitstechnischen Funktion(en) erforderlichen Ausfallwahrscheinlichkeit übereinstimmen.
11.5.3.2 Der Nachweis muss Folgendes beinhalten:
- Berücksichtigung des Qualitätsmanagements und des Konfigurationsmanagements beim Hersteller;
- geeignete Identifizierung und Spezifikation der Komponenten oder Teilsysteme;
32
- eine Betrachtung der Leistungsfähigkeit der Komponenten oder Teilsysteme bei vergleichbaren Betriebseigenschaften in einer ähnlichen Umgebung;
- den Umfang der Betriebserfahrung; Anmerkung: Informationen bezüglich der Betriebserfahrung werden bei Feldgeräten meistens in Form von Standardgerätelisten der Anwender festgehalten, die sie für den Einsatz in ihren Anlagen zugelassen haben und deren Basis eine lange, erfolgreiche Leistung in Sicherheits- und Nicht-Sicherheitsanwendungen und ein Ausschluss von Geräten ist, die eine nicht zufrieden stellende Leistung bringen. Die Standardgeräteliste darf unter folgenden Voraussetzungen zur Unterstützung der Annahme verwendet werden, dass eine Betriebserfahrung vorliegt:
- die Liste wird laufend auf Stand gehalten und überwacht; - Feldgeräte werden erst dann aufgenommen, wenn eine ausreichende
Betriebserfahrung vorliegt; - Feldgeräte werden von der Liste gestrichen, wenn sie keine zufrieden
stellende Leistung zeigen; - sofern erforderlich ist in der Liste die Prozessanwendung enthalten.
11.5.4 Anforderungen hinsichtlich der Basis einer früheren Verwendung erfolgenden Auswahl von mit festen Sprachen programmierbaren Komponenten und Teilsystemen
11.5.4.1 Es gelten die Anforderungen der Abschnitte 11.5.2 und 11.5.3.
11.5.4.2 Nicht benötigte Funktionen der Komponenten und Teilsysteme müssen im Eignungsnachweis ermittelt werden, und es muss sichergestellt sein, dass sie die erforderlichen sicherheitstechnischen Funktionen nicht beeinträchtigen.
11.5.4.3 Der Eignungsnachweis muss Folgendes für die vorliegende Konfiguration und das Anwendungsprofil der Hardware und Software berücksichtigen:
- Eigenschaften der Ein- und Ausgangssignale; - Betriebsarten; - verwendete Funktionen und Konfigurationen; - früherer Einsatz in ähnlichen Anwendungen in einer ähnlichen
Betriebsumgebung.
11.5.4.4 Für SIL 3-Anwendungen muss eine formale Beurteilung des FPL-Geräts (in Übereinstimmung mit Abschnitt 5.2.6.1) durchgeführt werden, um zu zeigen, dass:
- das FPL-Gerät die erforderlichen Funktionen durchführen kann und dass die frühere Verwendung des Geräts gezeigt hat, dass bei einer Verwendung als Teil eines sicherheitstechnischen Systems die Wahrscheinlichkeit eines Versagens in Hardware oder Software aufgrund zufälliger oder systematischer Ausfälle, das zu einem gefährlichen Ereignis führen könnte, genügend niedrig ist;
- geeignete Normen für Hardware und Software angewendet wurden; - das FPL-Gerät in Konfigurationen verwendet oder geprüft wurde, die dem
vorgesehenen Anwendungsprofil entsprechen.
33
11.5.5 Anforderungen hinsichtlich der auf Basis einer früheren Verwendung erfolgenden Auswahl von mit Sprachen eingeschränkten Sprachumfangs programmierbaren Komponenten und Teilsystemen
11.5.5.1 Die folgenden Anforderungen können nur auf PE-Logiksysteme in SIS mit sicherheitstechnischen Funktionen in SIL 1 und SIL 2 angewendet werden.
11.5.5.2
Es gelten die Anforderungen des Abschnitts 11.5.4.
11.5.5.3 Wenn es Unterschiede hinsichtlich der Betriebseigenschaften und der Betriebsumgebung einer Komponente oder eines Teilsystems zwischen den vorliegenden Erfahrungswerten und seinem Einsatz innerhalb des SIS gibt, dann müssen diese Unterschiede festgestellt und soweit zutreffend auf Grundlage einer Analyse und von Tests beurteilt werden, um so zu zeigen, dass die Wahrschein-lichkeit systematischer Fehler bei Verwendung innerhalb des SIS genügend niedrig ist.
11.5.5.4
Die zur Eignungsfeststellung als notwendig erachtete Betriebserfahrung muss unter Berücksichtigung folgender Punkte bestimmt werden:
- SIL der sicherheitstechnischen Funktion - Komplexität und Funktionalität der Komponente oder des Teilsystems.
11.5.5.5
Für SIL 1 oder SIL 2-Anwendungen kann ein sicherheitsgerichtet konfiguriertes PE-Logiksystem verwendet werden, wenn alle folgenden Voraussetzungen vorliegen:
- Klarheit über die gefährlichen Ausfallarten - Verwendung entsprechender Techniken für die erkannten gefährlichen
Ausfallarten bei der sicherheitsgerichteten Konfiguration; - hinsichtlich der Firmware liegen gute Erfahrungen in Sicherheitsanwendungen
vor; - Schutz gegen unbefugte oder unbeabsichtigte Änderungen.
11.5.5.6
Für SIL 2-Anwendungen muss eine formale Beurteilung jedes PE-Logiksystems (in Übereinstimmung mit Abschnitt 5.2.6.1) durchgeführt werden, um zu zeigen, dass:
- das PE-Logiksystem die erforderlichen Funktionen durchführen kann und dass die frühere Verwendung des Systems gezeigt hat, dass bei seiner Verwendung als Teil eines sicherheitstechnischen Systems die Wahrscheinlichkeit eines Versagens in Hardware oder Software aufgrund zufälliger oder systematischer Ausfälle, das zu einem gefährlichen Ereignis führen könnte, genügend niedrig ist;
- Maßnahmen zur Aufdeckung von Fehlern während des Programmablaufs und zur Einleitung geeigneter Gegenmaßnahmen getroffen sind; diese Maßnahmen müssen alle folgenden Punkte beinhalten: - Überwachung des Programmablaufs; - Schutz des Programms vor Änderung oder Ausfallerkennung durch ständige
Überwachung; - Plausibilitätskontrollen oder diversitäre Programmierung;
34
- Messbereichsprüfung von Variablen oder Plausibilitätskontrolle von Werten: - modulare Programmierung.
- geeignete Programmiernormen für die Firmware und die Hilfssoftware verwendet wurden;
- es in typischen Konfigurationen unter Bedingungen getestet wurde, die repräsentativ für die beabsichtigten Anwendungsprofile sind;
- verlässliche, verifizierte Softwaremodule und Komponenten eingesetzt wurden; - das System dynamischen Analysen und Tests unterzogen wurde; - Tests mit Erbringung von Fehlern mit entsprechender Dokumentation
durchgeführt wurden.
11.5.5.7 Für SIL 2-Anwendungen muss ein Sicherheitshandbuch mit Randbedingungen für den Betrieb, die Instandhaltung und die Aufdeckung von Fehlern vorliegen, das die typischen Konfigurationen des PE-Logiksystems und die vorgesehenen Anwendungsprofile abdeckt.
11.9.1 Die Ausfallwahrscheinlichkeit einer jeden sicherheitstechnischen Funktion muss kleiner oder gleich dem Versagensgrenzwert der Sicherheitsspezifikation sein. Dies ist durch eine Berechnung nachzuweisen. Anmerkung 1: Bei einer sicherheitstechnischen Funktion in Anforderungsart sollte der Versagensgrenzwert als mittlere Wahrscheinlichkeit ausgedrückt werden, dass die geforderte Funktion bei Anforderung nicht ausgeführt wird, wie für den SIL der sicherheitstechnischen Funktion festgelegt (siehe Tabelle 3). Anmerkung 2: Bei einer sicherheitstechnischen Funktion in Betriebsart mit kontinuierlicher Anforderung sollte der Versagensgrenzwert durch die Häufigkeit eines gefährlichen Ausfalls pro Stunde ausgedrückt werden, wie für den SIL der sicherheitstechnischen Funktion festgelegt (siehe Tabelle 4). Anmerkung 3: Die Ausfallwahrscheinlichkeit muss für jede sicherheitstechnische Funktion einzeln quantifiziert werden, weil bei verschiedenen Komponenten unterschiedliche Ausfallarten vorkommen können und sich der innere Aufbau des SIS (im Hinblick auf Redundanz) auch unterscheiden kann. Anmerkung 4: Der Versagensgrenzwert kann eine festgelegte mittlere Ausfallwahrscheinlichkeit bei einer Anforderung oder gefährliche Ausfallrate als Ergebnis einer quantitativen Analyse sein oder der einem SIL zugeordnete festgelegte Bereich, wenn dies durch qualitative Methoden ermittelt wurde.
11.9.2 Die berechnete Ausfallwahrscheinlichkeit durch Hardware-Fehler für jede sicherheitstechnische Funktion muss Folgendes berücksichtigen: a) den inneren Aufbau des SIS in Bezug auf die betrachtete sicherheitstechnische
Funktion; b) die geschätzte Ausfallrate λDD jedes Teilsystems in jedem Betriebszustand für
Fehler, die zu einem gefährlichen Ausfall des SIS führen könnten, aber vorher durch Diagnosemaßnahmen entdeckt werden;
35
c) die geschätzte Ausfallrate λDU jedes Teilsystems aufgrund von Hardware-Ausfällen in jedem Betriebszustand für Fehler, die zu einem gefährlichen Ausfall des SIS führen könnten, aber durch Diagnose-Maßnahmen nicht entdeckt werden können;
Anmerkung: Die geschätzten Ausfallraten eines Teilsystems können durch eine quantitative Fehlermode-Analyse des Entwurfs unter Nutzung von Ausfalldaten für Komponenten oder Teilsysteme aus anerkannten industriellen Quellen oder von Erfahrungswerten mit dem Teilsystem unter bezüglich der geplanten Anwendung gleichen Umgebungsbedingungen ermittelt werden. In diesem Fall sollte die Erfahrung ausreichend sein, um die angenommene mittlere Ausfallwahrscheinlichkeit auf statistischer Basis mit einem Vertrauensniveau von mindestens 70 % abzusichern. d) die Anfälligkeit des SIS für Ausfälle gemeinsamer Ursache (Common cause
Failures); e) der Diagnoseaufdeckungsgrad jeder wiederkehrenden diagnostischen Prüfung (der
gemäß IEC 61511-2 bestimmt wurde), der zugehörige Wiederholungszyklus und die Zuverlässigkeit der Diagnoseeinrichtungen;
f) die Intervalle, zu denen Wiederholungsprüfungen durchgeführt werden; g) die Reparaturzeit für entdeckte Fehler; h) die geschätzte Rate gefährlicher Ausfälle aller Kommunikationsprozesse in allen
Betriebsarten, die ein gefährliches Versagen des SIS verursachen könnten (unabhängig davon, ob sie durch Diagnosetests entdeckt werden oder nicht);
i) die geschätzte Rate gefährlicher Ausfälle menschlicher Reaktionen in allen Betriebsarten, die ein gefährliches Versagen des SIS verursachen könnten (unabhängig davon, ob sie durch Diagnosetests entdeckt werden oder nicht);
j) die Empfindlichkeit gegenüber EMV-Störungen; k) die Empfindlichkeit gegenüber klimatischen und mechanischen Einflüssen. Anmerkung 1: Es existieren eine Reihe von Modellierungs-Methoden, wobei die Auswahl der geeigneten Methode Sache eines Analytikers ist und von den Gegebenheiten abhängt. Zu den verfügbaren Methoden gehören (siehe IEC 61508-6, Anhang B):
- die Simulation; - die Ursache-Wirkungs-Analyse; - die Fehlerbaumanalyse; - Markov-Modelle; - Zuverlässigkeits-Block-Diagramme.
Anmerkung 2: Das Diagnosetestintervall und die folgende Reparaturzeit bilden zusammen die mittlere Zeit zur Wiederherstellung, die im Zuverlässigkeitsmodell verwendet werden sollte.
36
B Zugängliche Statistische Daten
B.1 OREDA [4] OREDA ist eine Projektorganisation, die von zehn weltweit operierenden Ölkonzernen gefördert wird. Das Hauptziel von OREDA ist das Sammeln und Austauschen von Zuverlässigkeitsdaten unter den teilnehmenden Unternehmen. Dabei dient die Organisation als Forum für Koordination und Management für das Sammeln von Zuverlässigkeitsdaten innerhalb der Öl- und Gasindustrie. OREDA hat eine umfassende Datenbank mit Zuverlässigkeits- und Wartungsdaten für Förderungs- und Produktionsanlagen aus vielen verschiedenen geographischen Regionen, Installationen, Gerätetypen und Betriebsbedingungen aufgebaut. Abgedeckt werden hauptsächlich Offshore-Anlagen unter und über Wasser. Onshore-Anlagen werden ebenfalls berücksichtigt. Die Daten werden in einer Datenbank gespeichert. Eine spezielle Software wurde entwickelt, um die Informationen zu sammeln, zu erfassen und zu analysieren. Eine Norm wurde veröffentlicht. Derzeit wird die Norm überarbeitet, um auch Downstream-Anlagen zu berücksichtigen. Gegründet wurde das OREDA-Projekt im Jahr 1981 in Zusammenarbeit mit dem Norwegischen Petroleum Direktorat. Seitdem wurden verschiedene Phasen durchlaufen, in denen zum Teil Modifikationen der Datenerhebungsmethoden, Änderungen bei der Verarbeitung der Informationen, sowie Zugewinn, aber auch Abwanderung von teilnehmenden Unternehmen zu verzeichnen war. In Tabelle B.1.1 werden die Konzerne aufgelistet, die einen Datenbeitrag geliefert haben.
Teilnehmende Unternehmen AGIP BP Chevron (in Verbindung mit Texaco) ELF (in Verbindung mit TOTAL) Esso/ Exxon (in Verbindung mit Mobil) Norsk Hydro Phillips Petroleum Company Norway Statoil Saga Petroleum (verkauft an Norsk Hydro) Shell Texaco (in Verbindung mit Chevron) TOTAL (in Verbindung mit Elf) Tabelle B.1.1 – Teilnehmerunternehmen OREDA
Bisher wurden vier OREDA-Handbücher herausgegeben, die sich jeweils auf unterschiedliche Jahresperioden beziehen. Die aktuellste Ausgabe (Edition 2002) umfasst die Projektierungsphasen IV (1993-1996) und V (1997-2000) mit einem Datenvolumen von insgesamt 3878 Einzelgeräten. Dabei wird in Systeme und Ausrüstungsklassen gruppiert, was im Detail nach Tabelle B.1.2 vorgenommen wird. Seit 1981 wurden von OREDA bis ins Jahr 2000 27565 Geräte erfasst, was mengenmäßig eine recht große Zahl darstellt, aber leider nicht der OREDA 2002 als Basisvolumen unterliegt.
37
System Equipment class
Gas Turbines Compressors Combustion engines Pumps Turboexpanders Electric generators
Rotating machinery
Electric motors Vessels Heaters und boilers
Static equipment
Heat exchangers Valves F&G detection equipment
Other topside
Process sensors/control Kontrollsysteme Wellhead & X-mas tree Pipelines Template Manifold Risers Running tools
Auf exemplarische Tabellen, entnommen aus dem OREDA-Handbuch 2002, wird an dieser Stelle verzichtet, da derartige Abbildungen lizenzrechtliche Probleme nach sich ziehen würden. Um dennoch die Struktur zumindest etwas zu verdeutlichen, sei angemerkt, dass für die in Tabelle B.1.2 dargestellten Gruppierungen u.a. Fehlerart, Fehlerzahl, Fehlerrate (pro 106 Stunden), Anforderungszahl und Reparaturstunden angegeben werden. Nach Aussage eines verantwortlichen Ingenieurs einer der NAMUR-Mitgliedsfirmen wird OREDA gekauft und kostet einen fünfstelligen Eurobetrag, findet jedoch in der Praxis nur in geringem Maße Verwendung. Begründet ist diese Tatsache in dem nicht tief genug gehenden Detaillierungsgrad der Auswertungen, bedingt durch unzureichende Datenvolumina, und der ungünstigen Form der Daten. Denn es existiert keine digitale Fassung des Handbuchs, was eine großflächige Nutzung der Informationen enorm erschwert. Weiterhin wären Exemplare in kürzeren Abständen wünschenswert, um die Aktualität der Referenzwerte zu gewährleisten. Diese Problematik erwächst wiederum aus dem Fehlen genügend großer Volumina. Ferner stammen die Rohdaten überwiegend aus der Ölindustrie über den gesamten Erdball verteilt, was einerseits unterschiedliche Sicherheitsstandards implizit mischt und andererseits der Verwendung für Anlagen in der chemischen Industrie deutliche Grenzen setzt, da dort die stark divergierenden Einsatzbedingungen der Sicherheitsschaltungen eine große Rolle spielen.
38
B.2 PERD Ziel der Process Equipment Reliability Database (PERD) ist es, qualitativ hochwertige, gültige und nützliche Daten für die Kohlenwasserstoff- und chemische Prozessindustrie zu liefern. Diese Daten können die Analyse der Geräteverfügbarkeit, das Design, die Wartungsstrategien, quantitative Risikoanalysen und die Bestimmung von Lebenszykluskosten unterstützen. Im Vergleich zu OREDA hätte man in diesem Fall speziell Referenzwerte zur Verfügung, die aus Datenmaterial der Kohlenwasserstoff- und chemischen Prozessindustrie stammen, also dem angestrebten Verwendungsfeld entnommen wurden. Weiterhin ist eine detailliertere Aufsplittung in Fehlermodi geplant als in OREDA ausgeführt. Nach Aussage eines verantwortlichen Ingenieurs, der bei einer der NAMUR-Mitgliedsfirmen tätig ist, wird PERD jedoch noch nicht verwendet, da sich das System im Aufbau befindet. Die nachfolgende Tabelle B.2.1 listet Unternehmen auf, die ihre Daten PERD zwecks Auswertung zur Verfügung stellen [5].
Teilnehmer Air Products & Chemicals Inc. BP/ Amoco BOC Group Capstone Engineering Citgo Corpus Christi Refinery DNV (Det Norske Veritas) Dow DuPont Factory Mutual Res. Corp. Hartford Steam Boiler General Physics Mitsubishi Chemical Corp. Roberts & Roberts Consulting Rohm and Haas Co. Rosemount Shell Texaco
Tabelle B.2.1 – Teilnehmerunternehmen PERD
Welchen Stellenwert die Datenbank PERD in Zukunft bei dem numerischen SIL-Nachweis erreicht, wird die zukünftige Entwicklung zeigen.
39
B.3 NAMUR [6] Der dritte und letzte Ansatz zur Stördatenerfassung, der innerhalb dieses Berichts Erwähnung finden soll, entstammt der NAMUR. Er entstand aus dem Anspruch heraus, die Verfügbarkeitsanforderungen der international entstandenen Normen nachzuweisen. Zu selbigem Zweck wurde die NE 93 herausgegeben. Hierbei handelt es sich um eine seit Mitte der 80er Jahre praktizierte Vorgehensweise am heutigen Industriepark Höchst, die 2001 von der NAMUR aufgegriffen und im Jahr 2002 erstmals innerhalb verschiedener NAMUR-Mitgliedsfirmen angewendet wurde. Zu diesen zählen die in Tabelle B.3.1 aufgelisteten Unternehmen.
Bei der Erfassung von Störungsdaten innerhalb der Betriebe sind bestimmte Rahmenbedingungen bezüglich unabdingbarer Informationen, die zur Auswertung benötigt werden, zu erfüllen. Die relevanten Größen werden in der NE 93 in Anlage 8 durch ein Formblatt zur Störungserfassung vorgegeben (siehe Bild B.3.1 [7]). Hierbei handelt es sich um von den Mitgliedsfirmen umzusetzende Mindestkonformitäten, die das Grundgerüst für die firmeninternen Störungsmeldungen vorgeben, jedoch bei jedem Unternehmen nur den „gemeinsamen Nenner“ zu anderen Konzernen repräsentieren. De facto hat darüber hinaus dieses Dokument bei jeder Firma ein anderes Aussehen. Die Art der Erfassung findet bei den Mitgliedsunternehmen positive Resonanz, wobei die NAMUR, genauer gesagt die verarbeitende Firma InfraServ, bei einigen Unternehmen keinen direkten Zugriff auf die Firmenstörungsdatenbanken besitzt, was dazu führt, dass der Begriff „NAMUR-Datenbank“ in diesem Zusammenhang eigentlich nicht korrekt ist. Grundsätzlich wird aber der Prozess durchaus von Unternehmensseite begrüßt und weitere Firmen haben bereits ihre Zusammenarbeit signalisiert. Die im Jahr 2002 im Rahmen der NE 93 durchgeführte Stördatenerheben hat die in Tabelle B.3.2 dargestellte Statistik ergeben.
C Auswertung der NAMUR-Daten Abschließend wird eine Datenanalyse durchgeführt, um Unzulänglichkeiten und verwertbare Erkenntnisse aus dem Stördatenmaterial zu gewinnen, die resultierend einen numerischen SIL-Nachweis liefern. Vorab ist zu bemerken, dass zu diesem Zweck leider nur bereits verarbeitetes Material der an der Datenerhebung teilnehmenden NAMUR-Firmen zur Verfügung steht, was darauf zurückzuführen ist, dass InfraServ nicht bei allen Unternehmen Zugriff auf das Rohmaterial hat. Es handelt sich dabei um aktuelle Informationen des Jahres 2003, die von Herrn Dr. Pirmin Netter (InfraServ) zu diesem Verwendungszweck zur Verfügung gestellt wurden. Beispielhaft ist das im Industriepark Höchst zur Erhebung verwendete Formblatt zur PLT-Störungsmeldung in Übereinstimmung mit der NE 93 in Bild C.1 abgebildet. Zur Datenstruktur ist anzumerken, dass sowohl die Gesamtpopulation als auch der auf verschiedene Gruppen von Sicherheitsschaltungen (Temperatur, Füllstand, Druck, etc.) entfallende absolute Anteil bereitgestellt wird. Ergänzt wird jede Gruppierung durch die Anzahl aufgetretener passiver Fehler (siehe Tabelle C.1).
Gruppe
Anz. Sicherheitsschaltungen [absolut]
pass. Fehler [absolut]
Gesamt 12132 41 Druck 1479 11
Temperatur 1154 1 Füllstand 1020 2 Analyse 417 6
Hand 537 0 Sonstige 1526 6
Tabelle C.1 – Störungsdaten NAMUR 2003 Bei näherer Betrachtung wird augenscheinlich, dass die Summe der Gruppen nicht identisch mit der Gesamtanzahl der Sicherheitsschaltungen ist. Diese Tatsache ist dahingehend begründet, dass einige NAMUR-Firmen zwar die Anzahl der bei ihnen eingesetzten Sicherheitsschaltungen angeben, jedoch keine Auskunft bezüglich der in Tabelle C.1 vorgenommenen Untergliederung erteilen. Diesbezüglich wäre eine weitere Verbesserung der Kommunikation zur detaillierteren Datengewinnung wünschenswert, um die Volumina auch bei tiefer gehendem Datensplitting zu erhöhen. Informationen über das Wartungsintervall standen InfraServ nur vereinzelt zur Verfügung, so dass Annahmen für diese Größe getätigt werden mussten. Deshalb wurde ein Pauschalwartungsintervall von 12 Monaten festgelegt, ausgenommen für Analysemessungen, die de facto im Normalfall monatlich überprüft werden. Ergo ist für Analysesicherheitsschaltungen ein anderes TI zu wählen. Hierzu wurde unter Berücksichtigung des worst case ein Prüfintervall von 3 Monaten unterstellt. Zusätzlich lag auch Datenmaterial vor, das eine weitere Unterteilung in ein- und zweikanalige Schaltungen ermöglicht hätte. Jedoch wurde in diesem Rahmen darauf verzichtet, da die dabei dahinter liegenden Volumina zu gering wären. Der soeben angeführte Kritikpunkt unzulänglicher Datenmengen wird an anderer Stelle nochmals aufgegriffen werden.
42
Bild C.1 – PLT-Störungsmeldung Höchst
43
Tabelle C.2 zeigt den prozentualen Anteil jeder Gruppierung von Sicherheitsschaltungen an der Gesamtzahl (echte Summe der Elementanzahlen der Gruppen), sowie die Verteilung der aufgetretenen passiven Fehler auf die Gruppen bezogen.
Tabelle C.2 – prozentuale Aufteilung Störungsdaten NAMUR 2003 Vergleicht man Zeilen und Spalten in Tabelle C.2, scheinen die meisten passiven Fehler bei der Gruppe „Druck“ aufzutreten, auch unter Berücksichtigung der verbauten Anzahl, wohingegen Temperatur und Füllstand eine geringere Anfälligkeit aufweisen. Um weitere Aussagen tätigen zu können, ist nun die sicherheitstechnische Verfügbarkeit VS zu bestimmen. Dazu wäre es zunächst erforderlich die sicherheitstechnische Mean Time Between Failure MTBFS zu ermitteln. Dies geschieht nach der Formel [3]:
MTBFS = (N*∆T)/FP,
wobei N die Anzahl verbauter Sicherheitsschaltungen und FP die Zahl aufgetretener passiver Fehler im Betrachtungszeitraum ∆T bezeichnet. Die angestrebte sicherheitstechnische Verfügbarkeit VS resultiert nun aus [3]:
VS = MTBFS /(MTBFS + MDTP) Dabei repräsentiert MDTP die Mean Down Time durch passive Fehler, da nur solche das Auslösen der Sicherheitsschaltung im Auslösefall blockieren können. Sie ergibt sich aus der Summe [3]:
MDTP = MTE + MTRP,
mit MTE als mittlerer Fehlererkennungszeit, die unter der Annahme einer Gleichverteilung sicherheitsbezogener Ausfälle über das Inspektionsintervall TI zu TI/2 vereinfacht werden kann, und MTRP als mittlerer Reparaturzeit, die meist im Bereich von Stunden liegt und so vernachlässigbar gegenüber MTE ist (MTRP << TI/2). Auf diese Art und Weise vereinfacht sich die Formel für VS zu [3]:
VS = MTBFS /(MTBFS + TI/2)
Die derart gewonnenen Werte für die relevanten Größen sind in Tabelle C.3 zusammengefasst.
44
Gruppe N FP ∆T TI MTBFS VS SIL TI-Spanne [abs.] [abs.] [Jahre] [Jahre] [Jahre] [W-keit] [abs.] [Tage]
Tabelle C.3 – Datenanalyse NAMUR 2003 Bezogen auf die Gesamtheit erfasster Sicherheitsschaltungen wird laut Datenanalyse eine Verfügbarkeit erreicht, die in SIL 2 anzusiedeln ist. Betrachtet man die einzelnen Gruppierungen, so erreicht die Gruppe der Druckmessungen eine Verfügbarkeit, die eine Einstufung in SIL 2 ermöglicht. Für Temperatur- und Füllstandsschaltungen kann sogar eine Zuordnung in SIL 3 vorgenommen werden. Ergänzend werden noch informativ TI-Spannen berechnet, die angeben, in welchem Zeitraum sich das Wartungsintervall bewegen müsste, um den angegebenen SIL weiterhin zu gewährleisten. Grundsätzlich ist jedoch nicht von der Hand zu weisen, dass das bei dieser Analyse zugrunde liegende Datenvolumen viel zu gering ist, um auf Basis der errechneten Werte, fundierte und verlässliche Aussagen zu treffen und Maßnahmen einzuleiten. Zur Behebung des Mangels an Informationen muss weiterhin das Bestreben verfolgt werden, den Kreis Daten bereitstellender Unternehmen zu erweitern und die Kommunikation mit selbigen zu verbessern, um in der Lage zu sein, neue theoretische Ansätze in Datenerhebung und Verarbeitung praktizieren zu können.
45
46
Quellenverzeichnis
[1] IEC 61508; [2] IEC 61511; [3] Litz, L.: Safety and availability of components and systems, 2004; [4] OREDA-Handbuch (Edition 2002); [5] Thomas, H.W., Moosemiller, M.: Establishing a Data Farm to Harvest Quality
Information, 2001; [6] Netter, P.,Brusa, P.: Erste Anwendungserfahrungen mit probabilistischen Methoden in der
Anlagensicherung, 2004; [7] NE 93, Version 10.02.2003;
