Kennen Sie den unterschied zwischen der Betriebsart Low Demand und High Demand ? Die Betriebsart der Sicherheitsfunktion ist entscheidend für die quantitative Berechnung in der Funktionalen Sicherheit und hat SIL-abhängig Auswirkungen auf die Systemstruktur. Ob Low Demand oder High Demand ist auch eine Frage der Anforderungsrate und/oder der angewandten Norm (ISO 13849, IEC 61508, IEC 61511, IEC 62061). In diesem Artikel möchte ich die Unterschiede beleuchten und auf die Berechnungsgrundlagen eingehen. Weiterhin wird eine Besonderheit der Betriebsarten bei der LOPA betrachtet.
Was ist high demand / continuous mode ?
Die Betriebsart high demand (HD) ist durch eine hohe Anforderungsrate gekennzeichnet. Im Maschinenbau nach ISO 13849 sind technische Schutzmaßnahmen naturbedingt im high demand mode. Warum ? Entweder ist die Gefahr und das damit verbundene Risikopotenzial ideal durch eine inhärent sichere Konstruktion ausreichend gemindert oder die bestimmungsgemäße Funktion bedingt ein hohes Gefahrenpotenzial.
Beispielhaft führt man einer Maschine regelmäßig Material zu und muss dafür die Maschine täglich mehrmals abschalten und die gefahrbringende Bewegungen technisch verriegeln mittels einer Sicherheitsfunktion. D.h. mehr als 1 mal pro Jahr wird diese Sicherheitsfunktion angefordert, um ein Risiko zu mindern.
Damit wird die mitttlere Häufigkeit pro Stunde maßgeblich, abgekürzt PFH mit der Einheit [1/h]. Hierfür ist die unbedingte Ausfallintensität w(t) zu integrieren über den Zeitraum. Dies entspricht der Ausfallrate Lambda. Wir verwenden in der Funktionalen Sicherheit eine spezielle Einheit FIT = Failure in Time = 1×10^-9/h. Im Kontext von der Fehlerratenberechnung (FMEDA) werden diese Ausfallraten („Lambda“) aus Fehlerratenkatalogen entnommen, manchmal an den Anwendungsfall angepasst und Klassifiziert (DU, DD, SD, SU).
Wenn die Sicherheitsfunktion als Bestandteil des Normalbetriebes den sicheren Zustand kontinuierlich aufrecht hält, sprechen wir vom continuous mode (CM). Eine SIF im CM ist die letzte Barriere vor dem Eintreten des gefahrbringenden Ereignis und damit eine extreme Form des HD. Damit wird auch deutlich, dass der Diagnoseintervall extrem klein ist. Mit Ausfall einer Sicherheitsfunktion im High-Demand muss die Gefahr unmittelbar durch Übergang in den sicheren Zustand gebannt werden. Faktor 1/100 ist typisch und daher liegen oft Diagnoseintervalle im Millisekundenbereich vor. Eine zu späte Diagnose im System mit HD Sicherheitsfunktion hat ein Diagnosedeckungsgrad von 0% – unbrauchbar. Die Anforderungsrate liegt also wesentlich höher als der Proof Test Intervall (PTI)
Bremssysteme im KFZ Bereich werden mehrmals pro Fahrt angefordert, vor und nach der Fahrt findet eine Diagnose statt und dann gibt es da noch die jährliche Inspektion und alle 2 Jahre in Deutschland oder auch alle 12 Monate z.B. hier in Georgien den TÜV. Kredit für die PFH-Berechnung aus den Diagnosen kann daher nur bedingt gezogen werden, denn ein Systemausfall ist gleichbedeutend mit plötzlichen hohen Risiko. D.h. Komponenten mit hoher Güte, schnelle und umfangreiche Diagnosen sowie eine mehrkanalige Struktur sind bereits ab SIL 2 erforderlich.
PFH_G: mittlere Häufigkeit eines gefahrbringenden Ausfalls für die Sicherheitsfunktion pro Stunde (engl. Probability of Failure per Hour)
Was ist der low demand mode ?
Der low demand mode (LD) liegt vor, wenn weniger als 1 mal pro Jahr die Sicherheitsfunktion (SIF) angefordert wird. Diese Anwendungsfälle sind stark abhängig vom Gesamtsicherheitskonzept nach IEC 61508. Diese Betriebsart kommt vorwiegend im Bereich der Prozess- und Anlagenindustrie vor nach IEC 61511. Die VDI/VDE2180 als pragmatisches Kochrezept zur IEC 61511 behandelt auschließlich Sicherheitsfunktionen im low demand mode. Der unterschied zum high demand mode ist, dass es sich um eine „echte Wahrscheinlichkeit“ handelt und damit einheitenlos ist. Eine weitere Besonderheit ist das Verhältnis von Diagnosetestintervall (z.B. Online-Funktionstest für Teilelemente) zur Anforderungsrate. Dies sollte um Faktor 10 liegen. Der Proof-Test-Intervall (PTI, 100% Testung) sollte um Faktor 1/2 zur Anforderungsrate liegen. Beispielhaft, wenn man mit einer Anforderungsrate (Demand Rate, DR) von 1 mal in 10 Jahren rechnet, dann sollte jährlich eine Diagnose stattfinden und alle 5 Jahre ein 100%-Manual-Proof-Test durchgeführt werden. Also Testung bevor der Ausfall im Anforderungsfall – statistisch gesehen – eintreten kann.
Die PFD-Berechnung ist daher stark von dem Diagnoseintervall und PTI abhängig. D.h. man kann mit Komponenten niedriger Güte und geringerer Diagnose rechnerisch einen höheren SIL erreichen im Vergleich zum HD. Klar, wenn das SIS versagt, ist ja mit hoher Wahrscheinlichkeit keine unmittelbare Gefahr vorhanden, wenn der Prozess und die Steuerung (BPCS, PLC) ordnungsgemäß funktionieren.
PFD_avg: mittlere Wahrscheinlichkeit eines Ausfalls bei Anforderung (engl. Probability of Failure on Demand)
Wenn man genauer hinschaut und vergleicht, dann liegt zwischen dem HD und dem LD der Faktor 10.000 also 10^4. Ein Jahr hat 8760 Stunden [h] und da der LD mit weniger als 1 mal pro Jahr definiert ist, hat man den Faktor 10^4h gewählt, um vom HD auf den LD zu kommen. Historisch war der low demand mode vor dem high demand mode entstanden.
Wann spezifiziert man die Betriebsart ?
Nun, entweder die Norm bzw. Ihr Anwendungsfall gibt dies vor oder Sie haben belastbare Annahmen zur Anforderungsrate in ihrer Risikoanalyse. Die ISO 26262 liegt wie auch die ISO 13849 pauschal im Bereich der high demand modes. Diese Pauschalierung nimmt Ihnen die Frage nach der Betriebsart ab, macht Ihnen das Leben leichter, doch logisch nach dem obigen Aussagen ist das nicht immer. Es ist eher konservativ, den HD oder CM anzunehmen, als den LD.
Ein Beispiel: Wann hatten Sie zuletzt einen Autounfall, wo Ihnen der Airbag das Leben rettete ? Der Airbag im Fahrzeug ist per Scope der ISO 26262 ein System im HD. Es gibt viele Fahrzeuge und potenziell viele Menschen, die verletzt werden könnten.
Die Sicherheitsziele beim Airbag sind:
- löse aus, wenn ein Unfall passiert (Insassenschutz),
- löse nicht aus, wenn kein Unfall passiert (verhindere Fehlauslösung).
So ein Airbag im Gesicht bei einem Familienausflug auf der Landstraße ist wohl ziemlich gefährlich. Doch ist das Auto mit bestimmungsgemäßer Funktion per se nicht gefährlich, wenn alle Einrichtungen (Bremse, Lenkung, Antrieb) und insbesondere der Fahrer ordnungsgemäß funktionieren ? Daher entscheidet sich die Betriebsart der Sicherheitsfunktion am Anwendungsfall und insbesondere im Gesamtsicherheitskonzept anhand der Anforderungsrate (Demand Rate, DR) und des Testintervalls (Ti).
Die Betriebsart hat nicht nur Auswirkungen auf die Berechnung der Zielwertarten (PFH/PFD), sondern auch auf die Struktur im Sinne der Hardwaresicherheitsintegrität. Schauen Sie sich mal die Grafiken auf unserer Seite zur 61508 Teil 2 und der Hardwarefehlertoleranz (HFT) genauer an. Bis SIL 2 reicht im LD ein einkanaliges System (HFT=0). Bei SIL 2 im HD oder CM wäre ein zweikanaliges System (HFT=1) erforderlich! Bitte beachten Sie, dass die HFT kein zusätzlichen Layer in der LOPA erzeugt, sondern innerehalb der Berechnung der PFD des jeweiligen berücksichtigt wird.
Fallstricke der Betriebsart in der LOPA
Gerade im Bereich der Anlagensicherheit / Prozessindustrie nach IEC 61511 gibt es in der LOPA mehrere spezifizierte unabhängige Protectionlayer, welche i.d.R. die Betriebsart LD fordern. Damit ist die LOPA eigentlich nur gültig für LD Betriebsarten! Wir bauen i.d.R. Anlagen, welche bestimmungsgemäß mit hoher Verfügbarkeit über einen langen Zeitraum betrieben werden. Neben Personenschäden zählen im Anlagenbereich auch Faktoren wie Umwelt und Kapitalschäden an teuren Anlagenteilen eine bedeutende Rolle. Vor der LOPA nutzen wir HAZOPs, um die relevanten High-Consequence-Szenarien aus den sogenannten Ursprungsereignissen (init-Events) zu identifizieren. Es entsteht ein Gesamtsicherheitskonzept, bestehend aus einer Vielzahl von Maßnahmen, welche in unabhängigen Schichten (IPL) angeordnet werden. Erst wenn die letzte Schicht versagt, tritt das unerwünschte Ereignis ein. Es ist ein Defence-in-Depth (DiD) Ansatz.
Die LOPA beantwortet uns dann die Frage: Wie sicher ist sicher genug ?
Um einen Druckbehälter (Reaktor) zu schützen, setzen wir Berstscheiben (rupture disc, RD) ein, eine Art Einweg-Überdruckventil. Berstscheiben sind also ein Beispiel für ein Independent Protection Layer (IPL) in der LOPA, ausgeführt in mechanischer Technologie. Es werden oft Überströmventile (relief valves, RV) oder eine Kombination von Berstscheibe und Überströmventil eingesetzt. Überdruck ist eine Abweichung von der bestimmungsgemäßen Funktion in diesem Anlagenteil. Ursächlich kann der Mensch oder eine Kombination von Mensch und fehlerhafter Anlagensteuerung (PLC, BPCS) sein. Die Anlagensteuerung und der Anlagenführer werden im Normalfall bei einer Prozessabweichung reagieren müssen. D.h. erst wenn Mensch und/oder Steuerung versagen, wird es zu diesem Szenario kommen. Das kann z.B. der Fall sein, wenn der Mensch nicht unabhängig von der Steuerung ein folgenschweres Urteil fällt (z.B. Sensorfehler [Stuck-at] unerkannt).
Doch mit welcher Häufigkeit wird ein gefährliches Ereignis (Hazard Event Frequency, HEF) eintreten ?
Für ein System mit 2 IPL’s wie in den obigen Bildern dargestellt, errechnet sich die HEF aus der Anforderungsrate (DR_1) aus dem konkreten Ursprungsereigniss (init event) multipliziert mit den PFD-Werten der Schichten (PFD_n). Für jede Zwischenschicht lässt sich die Anforderungsrate berechnen. Das Versagen einer Schicht führt zur Anforderung der anderen Schicht, daraus folgt:
HEF=DR_1*PFD_1*PFD_2
Achtung: Wahrscheinlichkeiten und Häufigkeiten darf man multiplizieren, jedoch keine Haufigkeiten miteinander.
Jede Schicht (IPL) hat sinnvollerweise eine Anforderungsrate (DR_n), die kleiner der vorhergehenden ist (Ordnung der IPL nach DR), sonst würde sich die Haufigkeit für das Eintreten des gefahrbringenden Ereignisses (HEF) erhöhen:
DR_n+1 = DR_n * PFD_n < PFH_n
Wenn eine Berstscheibe anspricht, wird der Inhalt (Chemikalien) aus dem Reaktor freigesetzt (containment loss) aber ein unkontrolliertes Platzen des Druckbehälters verhindert. Um das Ansprechen der Berstscheibe (rupture disc, RD) zu vermeiden im Sinne der Umwelt oder des Mitarbeiterschutzes, sind oft Sicherheitsfunktionen (Safety Instrumented Functions, SIFs) von nöten, um dieses „Gap“ zu schließen. Wir ziehen für solche Fälle ein Layer ein, die SIF „Überdruck verhindern durch Überwachung der maximalen Reaktionsmengen“. Diese SIF wird durch ein Safety Instrument System (SIS) realisiert, welches unabhängig (IPL) von der Anlagensteuerung (BPCS) über eine Kombination aus Sensor, Logik, Aktor den Überdruck irgendwie verhindert. Dann hätten wir 3 IPLs, den Operator, der auf eine fehlerhafte Steuerung (BPCS) reagiert, das SIS und die RD.
Damit ergibt sich folgende Sequenz:
Betrieb (BPCS) -> Alarm (Störbeseitigung durch Operator) -> SIS (SIF Eingriff um Ansprechen der RD zu vermeiden) -> RD
Anforderungsraten aus der Praxis (unverbindlich):
- Lock-out-tag-out Prozedurfehler: 0,001 bis 0,0001 per Möglichkeit
- Operator macht Fehler: 0,1 bis 0,001 per Möglichkeit
- 3. Partei (Fahrzeug-Einschlag): ca. 0,01 pro Jahr
- PLC Loop-Fehler: 1 bis 0,01 pro Jahr
- Regler-Fehler: 1 bis 0,1 pro Jahr
- ungewolltes Öffnen eines Sicherheitsventils: 0,01 pro Jahr
- Be-/Enladeschlauch versagt: 1 bis 0,01 pro Jahr
- Pumpendichtung versagt: 0,1 bis 0,01 pro Jahr
- Dichtungsversagen: 0,01 bis 0,000001 pro Jahr
- Blitzschlag: 0,001 bis 0,0001 pro Jahr
- Last Fall am Kran: 0,001 bis 0,0001 pro Hebevorgang
Welchen SIL benötige ich für die SIF, die durch das SIS ausgeführt werden soll ?
Das Restrisiko, welches durch ein SIS erfüllt werden soll, ist der Quotient aus der tolerierbaren Häufigkeit des Worst Case Ereignis (TEF) und den IPLs. Wir nehmen an, dass wir eine TEF von 1×10^-5/Jahr haben und die Steuerung (BPCS) 1 mal alle 10 Jahre diesen gefahrbringenden Zustand anregt:
TEF / BPCS*Operator*RD = 10^-5 / 10^-1*10^-1*10^-1 = 10^-5 / 10^-3 = 10^-2 -> SIL 2 erforderlich
LOPA – vom High Demand Mode zum IE & weiter zum Low Demand
Nun haben wir die Grundlagen der LOPA und die Betriebsarten erörtert. Weitere Informationen zur LOPA findet sich in diesem pdf. Eine Sicherheitsfunktion (SIF), welche von einem Systen (SIS) unabhängig in einer low demand (LD) Betriebsart (Anforderungsrate weniger als 1x pro Jahr) verwendung findet, ist also ein independent protection layer (IPL) in der LOPA. Wenn im Prozess selbst eine sicherheitskritische Funktion in der Betriebsart high demand (HD, mehr als 1x pro Jahr) erforderlich ist, so würde ein Fehler dieser Sicherheitsfunktion ein init Event (IE) in der LOPA sein, und damit ist die Anforderungsrate für den nächsten IPL die PFH dieser Sicherheitsfunktion.
Um beim Beispiel von Bremssystem und Airbag zu bleiben, das Bremssystem ist im HD und dessen PFH ist die Anforderungsrate an den nächsten IPL, das wäre der Fahrer (Handbremse, Lenken, Gas wegnehmen) im LD, und ein Airbag ist ein weiterer IPL in der Betriebsart LD. Natürlich ließe sich auch eine andere Struktur aufbauen mit gleicher Eintrittswahrscheinlichkeit. Damit lassen sich unterschiedliche Gesamt-Sicherheitskonzepte realisieren. Entweder man baut zuverlässige Bremssysteme oder man lässt halt öfters mal einen Airbag auslösen. Würden Sie öfters mal eine Berstscheibe platzen lassen mit der Folge Containment-Loss, wenn ihr BPCS/PLC versagt ?
High Demand Mode in der LOPA dennoch möglich ?
Ob eine Sache sinnvoll ist, entscheidet sich am Zweck. Die LOPA erlaubt uns ein Blick auf das Gesamtsicherheitskonzept und nimmt indirekt Kredit von der Anlagensteuerung. Das ist die Stärke dieser Methode mit dem Hang, den low demand mode zu bevorzugen. Ist historisch gewachsen, eine Art Altlast. Macht es Sinn den HD in der LOPA zu nutzen ? Im Sinne der systematischen Fehlervermeidung – NEIN – denn es verzerrt die Berechnungen i.d.R. zum konservativen hin. Over-Safety-Engineering ist vorprogrammiert.
Wenn eine Gefahr im Prozess nicht vermeidbar ist, so muss man eine Kontrollierbarkeit sicherstellen. Wenn Prozesse dynamisch und/oder instabil sind, so muss neben robuster Bauweise auch ein gutes Steuerungssystem vorhanden sein, sonst macht es keinen Sinn. Da kann ein Fehler in Prozessfunktionen wie „erhalte Redoxgleichgewicht“ schnell zum Hazard führen und damit ist der zur Instabilität neigende Prozess selbst eine Sicherheitsfunktion im HD oder CM, welche als Anforderungsrate (DR=PFH [1/h]) den nächsten IPL im LD triggert.
Durch Verwendung von Sicherheitsfunktionen im high demand mode, ist zu berücksichtigen, dass kein Kredit zur Erreichung der quantitativen Zielwerte durch die Proof-Testintervalle genommen werden kann, wie es im LD möglich ist.
