-Bericht- Daniel Düpont Kaiserslautern, den

Transkript

1 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 Prof. Dr.-Ing. habil. Litz, Lehrstuhl für Automatisierungstechnik, TU Kaiserslautern Erwin-Schrödinger-Straße 12, Kaiserslautern

2 Inhaltsverzeichnis A Zusammenstellung der normativen Vorgaben... 3 A.1 Allgemeine Bemerkungen... 3 A.2 IEC A.3 IEC B Zugängliche Statistische Daten B.1 OREDA B.2 PERD B.3 NAMUR C Auswertung der NAMUR-Daten Quellen

3 A.1 Allgemeine Bemerkungen A Zusammenstellung der normativen Vorgaben Die beiden maßgeblichen Normen IEC und IEC 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

4 A.2 IEC IEC : 7.6 Zuordnung der Sicherheitsanforderungen Anforderungen 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äufigkeit 1) eines gefahrbringenden Ausfalls/h (Betriebsart mit hoher oder kontinuierlicher Anforderung) ist Sicherheitsintegritätslevel Anforderungsrate Betriebsart mit niedriger (mittlere Ausfallwahrscheinlichkeit der entworfenen Funktion bei Anforderung) bis < bis < bis < bis < 10-1 Sicherheitsintegritätslevel Anforderungsrate oder Betriebsart mit hoher kontinuierlicher Anforderung (Häufigkeit 1) eines gefahrbringenden Ausfalls/h) bis < bis < bis < 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

5 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 : 7.4 E/ E/ PES-Entwurf und Entwicklung Anforderungen 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

6 - 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 Anforderungen zur Sicherheitsintegrität der Hardware 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. Anteil ungefährlicher Ausfälle (SFF) 0 Fehlertoleranz der Hardware 1 2 < 60 % SIL1 SIL2 SIL3 60 % - < 90 % SIL2 SIL3 SIL4 90 % - < 99 % SIL3 SIL4 SIL4 99 % SIL3 SIL4 SIL4 Fehlertoleranz der Hardware von N bedeutet, dass N+1 Fehler zu einem Verlust der Sicherheitsfunktion führen können. Tabelle 2 - Einschränkung aufgrund der Architektur für sicherheitsbezogene Typ A-Teilsysteme Anteil ungefährlicher Ausfälle (SFF) 0 Fehlertoleranz der Hardware 1 2 < 60 % n. erl. SIL1 SIL2 60 % - < 90 % SIL1 SIL2 SIL3 90 % - < 99 % SIL2 SIL3 SIL4 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 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 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 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 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 Anforderungen zur Abschätzung der Wahrscheinlichkeit des Ausfalls von Sicherheitsfunktionen infolge zufälliger Hardwareausfälle 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 (T I ), 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

8 h) der Wahrscheinlichkeit eines unerkannten Ausfalls irgendeines Datenkommunikationsprozesses; 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 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 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-Leitoder Steuerungssystems (mit Potential zu einem gefährlichen Vorfall) und dem Auftreten des gefährlichen Vorfalls bei nicht ausgeführter Sicherheitsfunktion definiert Anforderungen zur E/ E/ PES-Implementierung 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

9 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, Hardwareschaltplä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äufigkeit 1) λ eines Ausfalls jedes Bauteils oder Bauteilgruppe und den Ergebnissen der FMEA wird für jedes Bauteil oder Bauteilgruppe die Häufigkeit 1) eines sicheren Ausfalls λ S und die Häufigkeit 1) 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äufigkeiten 1) λ 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

10 IEC : Anhang B (informativ): Beispieltechnik zur Bewertung der Wahrscheinlichkeit eines Hardwareausfalls B.2: Durchschnittliche PFD (für niedrige Anforderungsrate) PFD SYS = PFD S + PFD L + PFD FE mit - PFD SYS := durchschnittl. PFD für eine Sicherheitsfunktion eines sicherheitsgerichteten E/ E/ PE-Systems; - PFD S := durchschnittl. PFD des Sensor-Teilsystems; - PFD L := durchschnittl. PFD des Logik-Teilsystems; - PFD FE := 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 , 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: PFD S = PFD Gi i PFD FE = PFD Gj j 10

11 B.2.2 Architekturen für niedrige Anforderungsrate B oo1 Kanal Diagnose 1oo1 physisches Blockdiagramm λ D λ DU t c1 =T 1 +MTTR 2 λ DD t c2 =MTTR t CE 1oo1 Verlässlichkeits-Blockdiagramm Die Rate gefährlicher Fehler wird gegeben durch: λ D = λ DU + λ DD =λ/2 Mean Down Time t CE des Kanals: λ tce = λ DU D T1 2 + MTTR λ + λ DD D MTTR Für jede Art Architektur werden λ DU und λ DD gegeben durch: λ λ λ DU = DD = 2 2 ( 1 DC ); λ DC Für Kanäle mit t CE, resultierend aus gefährlichen Fehlern, gilt: PFD = 1 e λ t D CE λdtce falls λ t D CE << 1 Folglich ergibt sich im Falle einer 1oo1 Architektur eine PFD gemäß: PFD G =(λ DU +λ DD )t CE 11

12 B oo2 Kanal Diagnose 1oo2 Kanal 1oo2 physikalisches Blockdiagramm λ D λ DU λ DD t CE Common cause Fehler t GE 1oo2 Verlässlichkeits-Blockdiagramm Nun ist es zusätzlich notwendig, die System-äquivalente Down Time t GE zu berechnen: t GE λdu T1 λdd = + MTTR + MTTR λ 3 λ D D Die durchschnittliche PFD der Architektur beträgt: T1 PFDG = 2 D DD DU CE GE D DD DU MTTR 2 2 (( 1 β ) λ + ( 1 β ) λ ) t t + β λ MTTR + βλ + B oo2 Kanal Diagnose 2oo2 Kanal 2oo2 physikalisches Blockdiagramm 12

13 λ D λ D λ DU λ DD λ DU λ DD t CE t CE 2oo2 Verlässlichkeits-Blockdiagramm Entsprechender Wert für t CE ergibt sich aus B Die durchschnittliche PFD für selbige Architektur berechnet sich als: PFD G =2λ D t CE B oo2D Kanal Diagnose Diagnose 1oo2D Kanal 1oo2D physikalisches Blockdiagramm t GE` λ DU Common cause Fehler λ DU λ DD λ SD t CE` 1oo2D Verlässlichkeits-Blockdiagramm Die Rate sicherer entdeckter Fehler für jeden Kanal ist gegeben durch: λ λ SD = DC 2 13

14 Die Werte der äquivalenten Mean Down Times unterscheiden sich von denen der anderen Architekturen in B.2.2, also werden sie mit t CE` und t GE` bezeichnet. Ihre Werte erhält man durch: t CE λ ' = DU T1 + MTTR + 2 λ + λ DU ( λ + λ ) DD DD + λ SD SD MTTR t GE λ ' = DU T1 + MTTR + 3 λ + λ DU ( λ + λ ) DD DD + λ SD SD MTTR PFD G T1 = 2 DU DU D DD SD CE GE D DD DU MTTR 2 ( 1 β ) λ (( 1 β ) λ + ( 1 β ) λ + λ ) t ' t ' + β λ MTTR + βλ + B oo3 Kanal Diagnose Kanal 2oo3 Kanal 2oo3 physikalisches Blockdiagramm λ D λ DU λ DD t CE 2oo3 Common cause Fehler t GE 2oo3 Verlässlichkeits-Blockdiagramm Der Wert von t CE wird in B und der Wert von t GE in B gegeben. PFD G T1 = 6 D DD DU CE GE D DD DU MTTR 2 2 (( 1 β ) λ + ( 1 β ) λ ) t t + β λ MTTR + βλ + 14

15 B.3: PFH (für hohe Anforderungsrate oder kontinuierlichen Modus) B.3.1 Rechenverfahren Stadt der Bezeichnung PFD SYS verwendet man nun PFH SYS. PFH SYS = PFH S + PFH L + PFH FE mit - PFH SYS := Häufigkeit 1) eines Fehlers pro Stunde für eine Sicherheitsfunktion eines sicherheitsgerichteten E/ E/ PE-Systems; - PFH S := Häufigkeit 1) eines Fehlers pro Stunde für das Sensor-Teilsystem; - PFH L := Häufigkeit 1) eines Fehlers pro Stunde für das Logik-Teilsystem; - PFH FE := Häufigkeit 1) eines Fehlers pro Stunde für das Aktor-Teilsystem; B.3.2 Architekturen für hohe Anforderung oder kontinuierlichen Operationsmodus B oo1 Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate. λ D = λ DU + λ DD =λ/2 t CE λdu T1 = λ 2 D + MTTR λ + λ DD D MTTR λ λ λ DU = DD = 2 2 ( 1 DC ); λ DC Angenommen das Sicherheitssystem führt das EUC bei Entdeckung eines Fehlers in einen sicheren Zustand über, wird für eine 1oo1 Architektur Folgendes erreicht: PFH G =λ DU B oo2 Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate. PFH G = 2 2 (( 1 β D ) λdd + ( 1 β ) λdu ) tce + βdλdd + βλdu B oo2 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: PFH G =2λ DU B oo2D 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. 15

16 t CE λ ' = DU λ λ SD = DC 2 T1 + MTTR + 2 λ + λ DU ( λ + λ ) DD DD + λ SD SD MTTR PFH G ( 1 β ) λdu (( 1 β ) λdu + ( 1 βd ) λdd + λsd ) tce + βdλdd + βλdu = 2 ' B oo3 Die relevanten Blockdiagramme sind gleich denen für niedrige Anforderungsrate. Der Wert für t CE errechnet sich wie in B PFH G = 6 2 (( 1 β D ) λdd + ( 1 β ) λdu ) tce + βdλdd + βλdu (Referenzwerttabellen siehe IEC , Anhang B, B.3.3) 16

17 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äufigkeit 1) eines Common cause Fehlers λ D β, wobei λ D die Häufigkeit 1) 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äufigkeit 1) in Bezug auf gefährliche Common cause Fehler ist durch λ DU β + λ DD β D gegeben, wobei - λ DU := Häufigkeit 1) eines unentdeckten gefährlichen Einzelkanalfehlers; - β := Common cause Fehler-Faktor für unentdeckbare gefährliche Fehler; - λ DD := Häufigkeit 1) 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

18 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 X LS und Y LS, für Sensoren und Aktoren X SF und Y SF angegeben. Der Wert S wird unter Verwendung folgender Gleichungen ermittelt - S = X + Y zur Bestimmung von β, - S D = X(Z + 1) + Y, um β D zu erhalten. Hier repräsentiert S oder S D 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 19

20 20

21 21

22 IEC : 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. SIL Niedrige Anforderungsrate (Ausfallwahrscheinlichkeit bei Anfrage) Anzahl getätigter Anforderungen Hohe Anforderungsrate oder kontin. Modus 1-α = 0,99 1-α = 0,95 (Häufigkeit 1) eines gefährlichen Fehlers / h) Gesamtlaufzeit [h] 1-α = 0,99 1-α = 0, bis < ,6 x x bis < ,6 x x bis < ,6 x x bis < ,6 x x bis < ,6 x x bis < ,6 x x bis < ,6 x x bis < ,6 x x 10 6 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 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 Ergebnisse Fehlerwahrscheinlichkeit (bei Anforderung) zum Konfidenzlevel 1-α ist gegeben durch n lnα p 1 α oder n p 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

23 D.2.2 Testen eines Eingaberaums (Domäne) für niedrige Anforderungsrate D Voraussetzungen Die einzige Voraussetzung besteht darin, dass die Testdaten uniform über dem Eingaberaum verteilt sind. D 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 Mittlere Abstand zweier Testpunkte in Richtung Domäne einer beliebigen Achse 1 δ = 1/ n 2 2 δ = 3 3 k δ = δ = k 1/ n 1/ n 1/ n 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 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 Ergebnisse Der Zusammenhang zwischen Fehlerrate λ, Konfidenzlevel 1-α und der Testzeit t ist lnα λ = t Die Fehlerwahrscheinlichkeit ist indirekt proportional zur MTBF: λ = 1 MTBF Anmerkung: Unterscheidet nicht zwischen Fehlerwahrscheinlichkeit pro Stunde und Fehlerrate pro Stunde. Streng genommen besteht die Verbindung zwischen Fehlerwahrscheinlichkeit F und Fehlerrate f durch ft F = 1 e. 23

24 Aber die Form dieses Standards bezieht sich auf Fehlerraten kleiner als 10-5 und für Werte dieser Größenordnung ist F ft. 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 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 Ergebnisse Die Wahrscheinlichkeit p, alle Programmeigenschaften zu testen, ist gegeben durch p N 1 = j = 0 j N N j j N n ( 1 ) oder p 1 + ( 1) N wobei N = j = 1 ( N 1) K( N j 1) + C j, N = j! j C j, N N N j n 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

25 A.3 IEC IEC : 3 Begriffe und Abkürzungen 3.2 Begriffe 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 Sicherheitsintegrität der Hardware 1) Teil der Sicherheitsintegrität der sicherheitstechnischen Funktion, der sich auf zufällige Hardware-Ausfälle mit gefährlicher Ausfallart bezieht betriebsbewährt 1) 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 ab. 25

26 5 Management der funktionalen Sicherheit 5.2 Anforderungen Ausführung und Überwachung 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 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; - Berücksichtigung von Betriebsbedingungen (z.b. Normalbetrieb, Anfahren, Abfahren, Instandhaltung, Anlagenausfall, Notabschaltung); - 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

27 8.2.2 Die Ausfallrate bezüglich gefährlicher Ausfälle eines BPCS (das nicht der IEC entspricht), das eine Anforderung an eine Schutzebene stellt, darf bestenfalls mit 10-5 pro Stunde angesetzt werden 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 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 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 Zielwert für die Risikoreduzierung bei Anforderung bis < 10-4 > bis bis < 10-3 > bis bis < 10-2 > 100 bis 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 bis < bis < bis < 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

28 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 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 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 Der mit einem BPCS (das IEC oder nicht entspricht) erreichbare Faktor der Risikoreduzierung bei Verwendung als Schutzebene liegt unterhalb von 10. 1) 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 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

29 10 Sicherheitsspezifikation des SIS 10.3 Sicherheitsanforderungen an das SIS 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äß ;... - 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 Der Entwurf eines SIS muss alle Anforderungen der Spezifikation unter Berücksichtigung aller Forderungen, die sich aus diesem Abschnitt ergeben, erfüllen 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

30 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 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 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 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 Anforderungen an die Hardware-Fehlertoleranz 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

31 PE-Logiksysteme müssen eine Mindest-Hardware-Fehlertoleranz gemäß Tabelle 5 aufweisen. SIL Mindest-Hardware-Fehlertoleranz SFF < 60 % 60 % SFF < 90 % SFF 90 % Es gelten besondere Anforderungen. Siehe IEC Tabelle 5 Mindest-Hardware-Fehlertoleranz von PE-Logiksystemen 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) 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 und ) Es gelten besondere Anforderungen (siehe IEC 61508) Tabelle 6 Mindest-Hardware-Fehlertoleranz von Sensoren, Aktoren und nichtprogrammierbaren Logiksystemen Alternative Anforderungen an die Fehlertoleranz können verwendet werden, wenn eine Beurteilung gemäß den Anforderungen der IEC , Tabellen 2 und 3 durchgeführt wird. 31

32 11.5 Anforderungen zur Auswahl von Komponenten und Teilsystemen Allgemeine Anforderungen 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 und IEC , soweit zutreffend entsprechen oder sie müssen den Abschnitten 11.4 und bis soweit zutreffend entsprechen Komponenten und Teilsysteme, die als Teil eines SIS für SIL 4-Anwendungen ausgewählt werden, müssen IEC und IEC , soweit zutreffend entsprechen 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 ) 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 Anforderung hinsichtlich der auf Basis einer früheren Verwendung erfolgenden Auswahl von Komponenten und Teilsystemen 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 Der Nachweis muss Folgendes beinhalten: - Berücksichtigung des Qualitätsmanagements und des Konfigurationsmanagements beim Hersteller; - geeignete Identifizierung und Spezifikation der Komponenten oder Teilsysteme; 32

33 - 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 Anforderungen hinsichtlich der Basis einer früheren Verwendung erfolgenden Auswahl von mit festen Sprachen programmierbaren Komponenten und Teilsystemen Es gelten die Anforderungen der Abschnitte und 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 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 Für SIL 3-Anwendungen muss eine formale Beurteilung des FPL-Geräts (in Übereinstimmung mit Abschnitt ) 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