Belastbarer
Umgang mit technischen
Unsicherheiten
Statistik,
RAMS
& Qualitätsmanagement
Funktionale
Sicherheit
Inhaltsverzeichnis 
Dies
ist die Wissensseite Funktionale
Sicherheit (FuSi). Hier werden grundlegende didaktische
Aspekte beschrieben. Die
komplementäre Seite FuSi-Dienstleistung
richtet sich
an Leser mit FuSi relevanten
Aufgabenstellungen.
Der
Begriff Funktionale
Sicherheit
ist nicht eindeutig definiert. Gemeint sind aber keine einfachen, "alt
hergebrachten" Einrichtungen wie z.B. Geländer, sondern
"kompliziertere"
Einrichtungen.
Etwas anschaulich kann man sagen, dass Funktionale
Sicherheit solche
Sicherheitseinrichtungen umfasst, die
- ein Mindestmass an Komplexität
aufweisen und daher während der Entwicklung besonderes Augenmerk
erfordern,
- im Betrieb eine aktive Rolle
einnehmen, also im Anforderungsfall etwas auslösen,
- im Betrieb eine reelle Chance
haben, zu versagen. Diese mag klein sein, aber sie ist grundsätzlich quantifizierbar (z.B. als
Wahrscheinlichkeit/Stunde)
- zumindest teilweise aus
Elektrik oder Elektronik bestehen.
Alle Punkte sind bereits bei einfachen
elektrischen Systemen, die z.B. nur aus Schaltern und Verkabelung
bestehen, gegeben.
Der Begriff Funktionale
Sicherheit bezieht sich auf
keinen bestimmten Industriezweig,
und wäre so gesehen universell verwendbar. Tatsächlich ist es aber
anders, und das
hat historische
Gründe, die im Folgenden umrissen werden:
Im
Jahr 1988 geschah das Piper Alpha (Bohrinsel) Unglück, bei dem durch
eine
Verkettung von Umständen enormer
Schaden entstanden ist. Zu
dieser Zeit
gab es z.B. in den
Bereichen Militär, Luftfahrt, Kraftwerkstechnik und Bahn bereits
etablierte Prozesse und Standards, die ein derartiges Unglück mit an
Sicherheit grenzender Wahrscheinlichkeit verhindert hätten. Diese
Standards spiegelten damals schon im Grunde das wieder,
was man heute unter Funktionaler
Sicherheit versteht. Diese
Standards sind sehr branchenspezifisch, und unterscheiden sich im
Detail erheblich.
In vielen anderen Industriezweigen hat sich systematisches
Sicherheitsdenken dagegen erst
in
den 1990er Jahren etabliert, wobei der 1998 erschienene internationale
Standard IEC 61508 als Geburtsstunde einer global zu etablierenden Funktionalen
Sicherheit angesehen werden kann.
Wenn man heute von Funktionaler
Sicherheit spricht,
dann meint man vorwiegend diejenigen Industriezweige,
in denen es bis in die1990er Jahre noch kein standardisiertes Sicherheitsdenken gegeben hat.
Die
Grenze zwischen Zuverlässigkeit und Funktionaler
Sicherheit von
Geräten / Systemen
ist fliessend.
Die mit diesen beiden Faktoren,
also Sicherheit und Zuverlässigkeit,
einhergehenden Forderungen an die Systemauslegung sind in der Regel
sehr unterschiedlich und schliessen sich, bei gegebenen Gesamtkosten,
oft gegenseitig aus.
Ein sicheres System kann durchaus
unzuverlässig sein, solange seine Sicherheitsfunktion zuverlässig ist.
Ebenso kann ein zuverlässiges
System unsicher sein. Es gibt aber auch sichere UND zuverlässige Systeme.
Beispiel 1,
sicher aber
unzuverlässig 
Rauchmelder, der viele Fehlalarme
produziert. Solange er
tatsächlich gefährlichen Rauch sicher meldet, ist seine
Sicherheitsfunktion zuverlässig. Der
Rauchmelder ist allerdings unzuverlässig, da er oft eine Gefahr
vortäuscht, die in Wirklichkeit gar nicht besteht. Möglicherweise ist
der Rauchsensor zu empfindlich.
Aus Sicht Funktionaler
Sicherheit
ist an diesem Rauchmelder nur dann
nichts
auszusetzen, wenn die Fehlalarme nicht dazu führen, dass die Anwender
den Rauchmelder überbrücken oder stilllegen.
Beispiel 2, zuverlässig, aber unsicher 
Eine alte elektrische
Heckenschere, die man mit einem einzigen Schalter ein- und ausschaltet,
und die beim Einschalten sofort auf volle Drehzahl geht. Angenommen,
solche Geräte
würden immer noch hergestellt, dann wären sie rein aufgrund ihrer
Einfachheit mindestens so zuverlässig wie heutige übliche
Geräte.
Heutige Geräte haben sowohl zwei
Schalter, die so angeordnet sind, dass beide Hände zum Einschalten
benötigt werden, als auch einen weichen Start, der dem Bediener das
Anlaufen ankündigt.
Beides sind
Sicherheitseinrichtungen, die das Gerät zweifellos sicherer machen,
durch deren Versagen jedoch das Gerät unbrauchbar
wird.
Aus Sicht Funktionaler
Sicherheit ist an
der alten Heckenschere einiges
auszusetzen, an den neuen dagegen nichts.
Beispiel 3, zuverlässig, und sicher 
Steuerung eines
Bahnübergangs. Drei redundante Controller ermitteln aus mehreren
Eingabeparametern diverse Ausgangsgrössen. Sofern die gesamte Anlage
ordnungsgemäss funktioniert, sind sich alle drei Controller stets
"einig". Die Sicherheitsforderung kann z.B. wie folgt sein:
- Alle 3 Controller müssen sich
einig sein
- Tritt der Fall ein, dass sich
nur noch 2 der 3 Controller einig sind, dann wird die Anlage zwar
weiter betrieben, aber innerhalb 24 Stunden muss der Fehler behoben
werden.
Sicher
wird das System durch die "MIndestens 2 aus 3" Forderung,
zusammen mit dem 24 Stunden Fenster.
Zuverlässig wird das System durch
die Fehlertoleranz in Form von Redundanz.
Aus Sicht Funktionaler
Sicherheit
ist dieses System vorbildlich.
Bei Anwendungen mit hohen
Sicherheitsanforderungen sind derzeit
folgende Strategien anzutreffen, die sich wiederum teilweise
ausschliessen:
- Einfachheit der Sicherheitsfunktion. Weder Software noch aktive
Elektronik. Nur Schalter oder nur reine Mechanik.
- System, das sich selbst überprüft, oder das von aussen überprüft
wird, und zwar in kurzen Zeitabständen, typischerweise im
Systemtakt.
- Dies erfordert den Einsatz von Elektronik und / oder Software
- Redundante Auslegung mit oder ohne Überprüfung
- Dies erfordert den Einsatz von Elektronik und / oder Software
Alle
aufgezählten Punkte sind Stand
der Technik. Bei sehr hohen Sicherheitsanforderungen kommt meistens
Strategie 1 zur Anwendung.
Programmierbare Logik oder gar Software sind bei sehr hohen
Sicherheitsanforderungen selten, da mit zunehmender
technischer Komplexität überproportional viele Fehlermöglichkeiten
einher gehen,
und daher sowohl Entwicklungsaufwand als auch Nachweisaufwand ebenfalls
überproportional steigen. Das grundlegende Ziel in Funktionaler
Sicherheit
sollte stets sein, Sicherheit mit möglichst einfachen Mitteln zu
gewährleisten.
Technische Komplexität kann man
wie folgt skalieren:
Mechanik
Elektrik (Schalter,
Relais)
Passive Elektronik
Aktive Elektronik
Programmierbare
Elektronik (Firmware)
Software
Das
Methodenspektrum für den quantitativen
Nachweis von Funktionaler
Sicherheit bzw.
Zuverlässigkeit unterscheidet sich grundsätzlich nicht. Zum Einsatz
kommen
Die in Normen
vorgeschlagenen Methoden erscheinen oberflächlich betrachtet weitaus
vielfältiger, doch dabei handelt es sich meistens um Varianten der
zuvor genannten Methoden.
Qualitativ gibt es
allerdings grosse Unterschiede zwischen
Zuverlässigkeit und Funktionaler
Sicherheit:
Zuverlässigkeitsnachweise beruhen in der Hauptsache auf ermittelten
Wahrscheinlichkeiten.
Sicherheitsnachweise enthalten dies auch, allerdings werden dort
deutlich mehr Forderungen an den Entwicklungsprozess des Produktes
gestellt. Man könnte überspitzt sagen, dass Funktionale
Sicherheit den berechneten
Wahrscheinlichkeiten aus der Zuverlässigkeitstechnik nicht traut.
Bei Funktionaler
Sicherheit möchte man also
unabhängig von rein statistischer
(Un-)wahrscheinlichkeit auch qualitativ auf der sicheren Seite
sein. Dies hat eine gewisse Ähnlichkeit mit der ISO 9001: Diese Norm
hat an sich nichts mit Produktqualität zu tun, aber durch die
Konformität mit ihr hat eine Firma besonders gute Voraussetzungen für
die Herstellung guter
Produkte.
IEC
61508 ist der bekannteste Standard in Funktionaler
Sicherheit, und zugleich ihr Schirmstandard, d.h., alle heute
unter diesem Begriff geführten Normen
sind (allesamt vereinfachte) Ableitungen des IEC 61508.
Folgende
Tabelle zeigt ein paar Beispiele:
Norm
|
Beschreibung
|
IEC 61508
|
Schirmstandard. Gilt
automatisch, wenn keine spezielleren Normen gefordert sind, oder wenn
es keine branchenübliche Norm gibt.
|
IEC 61511
|
Modifizierter
IEC 61508 für Anlagenbauer und Prozessindustrie. Ist etwas
pragmatischer, indem er (vereinfacht gesagt) z.B. relativ schlechte
Systemkomponenten zulässt, die dafür aber höher redundant vorhanden
sein müssen.
|
| ISO 13849 |
Branchenübergreifende, relativ
kompakte Norm
"Sicherheit von Maschinen - sicherheitsbezogeneTeile von Steuerungen".
Wird deshalb oft gerne gewählt, da sie
- kurz gehalten ist, dennoch alle
grundsätzlichen Aspekte zumindest erwähnt, und daher leicht anwendbar
ist,
- z.B. das tendenziell unangenehme Thema "Ausfälle mit
gemeinsamer Ursache" nur sehr kurz abhandelt.
|
EN 50128
EN 50129
|
Bahnspezifische Normen für
Software und Hardware
|
ISO 25119
|
Vereinfachter ISO 13849 (siehe
zwei weiter oben) für Landmaschinen. 4 statt 2 Normteile. Aufgebläht,
dafür weniger Inhalt.
|
ISO 26262
|
Automobiler Standard. Automotive
SIL (ASIL) anstelle von SIL.
Stark aufgebläht, dafür noch weniger Inhalt.
|
Wie alle
Prozess- Management- oder Verfahrensstandards ist IEC 61508 sehr
generisch
gehalten, d.h., er sagt nichts darüber aus, wie bestimmte Produkte zu
entwickeln sind, sondern legt grundsätzliche Kriterien fest, die
Entwicklungsprozesse erfüllen müssen.
IEC 61508 trägt in der
Originalsprache den Namen
Functional safety
of electrical / electronic / programmable electronic safety related
systems,
was man zu Deutsch wie folgt
wiedergeben kann:
Funktionale
Sicherheit von elektrischen / elektronischen / programmierbar
elektronischen sicherheitsbezogenen Systemen
Die
Ausrichtung auf elektrische
Systeme stellt aus praktischer Anwendersicht jedoch keine
Einschränkung dar, denn alle wesentlichen Facetten dieser Norm lassen
sich ohne Weiteres auf andere Systemarten übertragen, z.B. Hydraulik,
Pneumatik, oder Mechanik im Allgemeinen.
Der
eigentliche Grund für die Fokussierung auf elektrische Systeme dürfte
eher hierin liegen:
- Der Bereich Elektrik / Elektronik verfügt über
weitaus mehr Gestaltungsspielraum und Realisierungsmöglichkeiten als
andere Systemarten, und als Folge davon lauern gerade dort besonders
viele potentiell gefährliche Fehlermöglichkeiten.
- Heute lassen sich die meisten Einrichtungen bezüglich Funktionaler
Sicherheit nicht
ohne Elektrik realisieren.
ISO
13859 ist der zweitbekannteste Standard in Funktionaler
Sicherheit. Er ist vom IEC
61508 abgeleitet, jedoch deutlich weniger umfangreich, und bietet deutlich weniger
Gestaltungsmöglichkeiten. Man könnte ihn als stark reduzierte
Version des IEC 61508 bezeichnen, welche die Möglichkeiten in der
Entwicklung einschränkt, und der Entwicklung hochsicherer Systeme
entgegensteht.
Positiv formuliert könnte man sagen,
dass ISO 13849 eine leichter verdauliche
Version des IEC 61508 ist, die den Sicherheitsingenieur an
die Hand nimmt.
ISO
13849 verfügt über Alleinstellungsmerkmale. Aus
diesem Grund wird er hier näher beleuchtet
Der ISO 13849 Originalname lautet:
Safety of Machinery
- Safety-related parts of control systems
Der Name der deutschen Fassung
lautet:
Sicherheit von Maschinen -
Sicherheitsbezogene Teile von Steuerungen
Wesentliche Besonderheiten sind:
- Allgemeinheit. ISO 13849 kann - wie
IEC 61508- in allen Branchen angewendet werden,
sofern keine spezifischeren Vorschriften existieren. Von allen
abgeleiteten Normen Funktionaler
Sicherheit ist ISO 13849 der
einzige, der auf keine spezielle Branche ausgerichtet ist.
- Keine
Beschränkung auf Elektronik und Software. Nicht nur der Name dieser
Norm ist allgemein gehalten; im Teil 2 werden neben elektronischen
Systemen auch mechanische, pneumatische und hydraulische Systeme
explizit adressiert.
- Zweidimensionale
Klassifizierung der Sicherheit. ISO 13849 verwendet im Gegensatz zu IEC 61508
zur sicherheitstechnischen Charakterisierung zwei Kennzahlen anstatt
nur eine: Kategorie und Performance Level. Dies ist eine Folge der
weiter oben erwähnten Einschränkungen. Auf diesen Punkt wird weiter
unten eingegangen.
Achtung: Alle drei genannten Punkte
sind in Wahrheit keine Vorteile, sondern eherm als heisse Luft zu
werten.
Die
Einstufung
sicherheitsbezogener
Systeme anhand von Kennzahlen ist zwar der bekannteste Aspekt von
Normen zu Funktionaler
Sicherheit, allerdings längst nicht der
einzige.
Folgende Tabelle gibt einen Überblick.
Parameter
bzw. Forderung
|
Anmerkungen |
MTTF
/
MTBF
|
Funktionale
Sicherheit stellt an MTBF / MTTF
zwar
keine Forderungen,
allerdings ist
es die Grundlage für alle
quantitativen Berechnungen.
|
MTTFd
|
ISO 13849 Kenngrössen
|
Die MTBF / MTTF, wenn man nur die
gefährlichen Ausfälle betrachtet (d = dangerous).
Entspricht dem Wesen nach IEC 61508 PFH
bzw. PFD
|
DCavg
|
Mittlerer Diagnosedeckungsgrad
[%].
Eine
Nebenbedingung an das Design. Dieser Parameter verleitet dazu, nicht
sicher zu entwickeln / bestraft
inhärent sichere Baugruppen. IEC 61508 SFF
ist deutlich geeigneter (*).
|
| Kategorie
|
Grundlegende Architektur des
Systems. Es werden 5 Kategorien unterstützt.
Kontraproduktiv. Es schränkt den Entwicklungsspielraum ein, und
erschwert gleichzeitig den Nachweis von Sicherheitszielen. IEC 61508
kennt (zum Glück) keine vergleichbare Vorgabe (**).
|
Performance
Level (PL)
|
Zusammenfassende,
das System charakterisierende Kenngrösse. Vergleichbar mit
IEC 61508 SIL, allerdings einfacher nachweisbar, und
deshalb schwächer. Ergibt sich aus Kategorie, MTTFd und DCavg.
|
| PFH
/ PFD |
IEC
61508 Kenngrössen
|
Wahrscheinlichkeit eines
gefährlichen Ausfalls pro Stunde (PFH) oder pro Jahr (PFD; eigentlich
pro 10.000h). Die Beiden sind nicht lediglich unterschiedliche
Skalierungen, sondern drücken grundlegend verschiedene
Betrachtungsweisen aus (wird weiter unten erklärt).
Entscheidet man sich für PFH, so bleibt PFD dennoch relevant (beim
Prooftest Intervall).
|
| SFF
|
Anteil
der ungefährlichen Ausfallrate an der gesamten Ausfallrate. Eine
Nebenbedingung an das Design. Dieser Parameter ist wesentlich
zielführender als ISO 13849 DCavg, weil er die Entwicklung
inhärent sicherer Baugruppen fördert (*).
|
| SIL |
Zusammenfassende, das System
charakterisierende IEC 61508 Kenngrösse.
Vergleichbar mit ISO 13849 PL, allerdings schwieriger
nachweisbar, und deshalb stärker. Ergibt sich aus PFH (oder PFD)
und SFF. In seltenen Fällen spielt auch DCavg mit hinein.
|
(*)
Dieser unsägliche Umstand wird ganz unten unter dem Stichwort Diagnoseabdeckung anhand von Beispielen
veranschaulicht.
(**)
ISO 13849 ist für viele moderne
Elektroniken ungeeignet,
weil sie sich
durch keine Kategorie gut abbilden lassen. Das betrifft z. B. komplexe
Handbediengeräte, bei denen sich die Sicherheitsfunktionen von den
"normalen" Funktionen nicht trennen lassen, oder sich
Diagnosefunktionen vom "Normalbetrieb" nur schwer trennen lassen, bzw.
der Normalbetrieb gleichzeitig Diagnose ist, oder allgemein Funktionale
Sicherheit sich
vom Normalbetrieb nicht eindeutig unterscheiden lässt.
Die beschriebenen Kenngrössen werden für Hardware und Software auf ganz
unterschiedliche Weise ermittelt:
Hardware
|
Software
|
- Quantitative Berechnung aus zahlenmässigen Eingaben.
- Betrifft alle Kenngrössen.
- Nachweis erfolgt anhand
- des Entwicklungsprozesses, UND
- des Entwicklungsergebnisses,
also anhand des fertigen Produktes.
In der betrieblichen Praxis wird
1. oft wenig Beachtung geschenkt.
|
- Qualitativer Nachweis aufgrund qualitativer Kriterien.
- Betrifft nur die Kenngrössen SIL und SFF bzw. und PL und DCavg.
- Nachweis erfolgt anhand des Entwicklungsprozesses.
|
Diese Kenngrössen bilden zwar die bekanntesten Aspekte in der Funktionalen
Sicherheit, doch die
Anforderungen an verschiedene Phasen des Produktlebenszyklus,
insbesondere der Produktentwicklungsphase, überwiegen in den Normen bei
weitem, denn die Grundidee ist folgende:
Indem man diese Anforderungen
erfüllt, entwickelt man
alle relevanten sicherheitstechnischen Aspekte in das Produkt hinein,
sodass sich die angestrebte sicherheitstechnische Einstufung zwanglos
von
selbst ergibt, und der Nachweis dann praktisch nur noch Formsache ist. Die sicherheitstechnische
Einstufung dient als Beleg dafür, dass während des
Entwicklungsprozesses allen Anforderungen genüge getan worden ist.
Die betriebliche Realität sieht meistens anders aus. Der Fokus liegt
meistens ausschliesslich auf den weiter oben beschriebenen Kennzahlen:
Der Entwicklungsprozess ist wie er schon immer war, und hinterher
werdendie Kennzahlen ermittelt, manchmal mit bösen Überraschungen.
Das IEC
61508
Kennzahlensystem besteht aus vier (eigentlich 5) Stufen, so genannten
Safety
Integrity Levels, SIL. Je höher, desto sicherer:
(kein SIL, oder SIL 0), SIL 1, SIL 2, SIL
3 und SIL 4.
Für die Einstufung eines sicherheitsgerichteten Systems in einen
SIL sind folgende Parameter ausschlaggebend: 
- Entweder / Oder
- Probability of Failure per hour (PFH).
Dies ist die
Wahrscheinlichkeit für einen gefährlichen Ausfall pro Stunde. Im
IEC
61508 bewegt man sich hier zwischen 1E-5/h und 1E-9/h.
- oder Probability of Failure on Demand (PFD). Dies ist die
Wahrscheinlichkeit für einen gefährlichen Ausfall im Anforderungsfall.
Im
IEC
61508 bewegt man sich hier zwischen 1E-1 und 1E-5.
- Safe Failure
Fraction (SFF)
- SFF ist der
Anteil an Bauteilausfällen, der zu einem so genannten sicheren, also ungefährlichen Ausfall
führt.
Interessant
ist der
Bereich oberhalb 60%.
- Hardware
Fault
Tolerance (HFT)
- HFT ist die Anzahl Fehler,
die das System tolerieren kann, ohne seine Sicherheitsfunktion zu
verlieren. Dies
kann man z.B. durch Mehrkanaligkeit (Redundanz) erreichen.
Mehrkanaligkeit sollte die letzte Option beim Systemdesign darstellen,
da hier das Phänomen der sogenannten Ausfälle
mit gemeinsamer Ursache existiert.
Das Zusammenspiel dieser Parameter kann
man mit Hilfe zweier Tabellen darstellen:
1. Zuordnung SFF und HFT zu SIL.
Funktionale
Sicherheit nach IEC 61508 unterscheidet
offenbar zwischen "einfachen" und
"komplexen" elektronischen Bauteilen:
1.a) Systeme
ohne digitale ICs:
|
HFT=0
|
HFT=1 |
HFT=2 |
SFF
= 0 ... <60%
|
SIL
1
|
SIL
2
|
SIL
3
|
SFF
= 60% ... <90%
|
SIL
2
|
SIL
3
|
SIL
4
|
| SFF
= 90% ... <99% |
SIL
3
|
SIL
4
|
SIL
4
|
SFF
> 99%
|
SIL
3
|
SIL
4
|
SIL
4 |
1.b)
Systeme mit mindestens einem digitalen IC:
|
HFT=0
|
HFT=1 |
HFT=2 |
| SFF
= 0 ... <60% |
SIL 0
|
SIL
1
|
SIL
2
|
| SFF
= 60% ... <90% |
SIL
1
|
SIL
2
|
SIL
3
|
| SFF
= 90% ... <99% |
SIL
2
|
SIL
3
|
SIL
4
|
| SFF
> 99% |
SIL
3
|
SIL
4
|
SIL
4
|
2. Zuordnung PFH bzw. PFD zu SIL
SIL
|
PFH [1/h]
|
PFD
|
Bereichsabdeckung |
SIL 1
|
1E-5
> PFH > 1E-6 |
1E-1
> PFD > 1E-2 |
Faktor 10
|
SIL 2
|
1E-6
> PFH > 1E-7 |
1E-2
> PFD > 1E-3 |
Faktor 10 |
SIL 3
|
1E-7
> PFH > 1E-8 |
1E-3
> PFD > 1E-4 |
Faktor 10 |
SIL 4
|
1E-8
> PFH > 1E-9 |
1E-4
> PFD > 1E-5 |
Faktor 10 |
Hinweis 1: Das > Zeichen ist auch
vor 1E-9/h bzw. 1E-5 richtig, mit der Begründung, dass IEC 61508 gefährliche
Ausfallwahrscheinlichkeiten kleiner als 1E-9 pro Stunde bzw. 1E-5
formal nicht für nachweisbar hält.
Zum Vergleich: 1E-9/h wäre bei
100.000 installierten Systemen etwa ein gefährlicher Ausfall pro
Kalenderjahr. (Das betrifft wohl gemerkt den Ausfall der
Sicherheitsfunktion, nicht das Eintreten eines Unglücks).
Das ISO 13849
Kennzahlsystem besteht aus fünf so genannten Kategorien (Kat), und 5
Stufen, den Performance Leveln (PL). Je höher, desto sicherer:
Kat
B, Kat 1, Kat 2, Kat 3, Kat 4
PL a PL b PL c, PL d, PL e
Ausschlaggebend
für die Funktionale
Sicherheit nach ISO 13849 ist PL (mit
IEC 61508 SIL vergleichbar). Die Kategorien
dagegen repräsentieren erlaubte Systemarchitekturen.
Folgende Kombinationen aus Kategorie und Performance
Level sind nach ISO 13849 möglich:
|
Kat B
|
Kat 1
|
Kat 2
|
Kat 3
|
Kat 4
|
PL a
|
x
|
|
x
|
x
|
|
PL b
|
x
|
x
|
x
|
x
|
|
PL c
|
|
x
|
x
|
x
|
|
PL d
|
|
|
x
|
x
|
|
PL e
|
|
|
|
x
|
x
|
Für die
Einstufung eines sicherheitsgerichteten Systems in eine Kategorie und
einen Performance Level sind folgende Parameter ausschlaggebend: 
- MTTFd pro Kanal
- MTTFd bedeutet Mittlere Zeit bis zu einem potentiell
gefährlichen Ausfall (d = dangerous; man müsste es eigentlich
Kanalversagen
nennen,
also die MTTF, mit der ein Sicherheitskanal unerkannt der
Sicherheitsfunktion nicht mehr zur Verfügung steht)
- DCavg
- DCavg bedeutet durchschnittliche Diagnoseabdeckung
(wie viel % aller gefährlichen Bauteilausfälle werden durch
sogenannte Diagnose
abgedeckt)
- Die Definition der DCavg ist etwas
unglücklich, und steht der Entwicklung hochsicherer Systeme
entgegen.
- Architektur der Sicherheitsfunktion
- Dahinter verbirgt sich eine Liste aus harten und weichen
Systemanforderungen.
Das
Zusammenspiel dieser Parameter und die Auswirkungen auf Kategorie
und Performance Level sind spezifischer als beim IEC 61508.
Die genauen
Zusammenhänge sind in der Norm im Anhang K in einer über 2
Seiten gehenden Tabelle dargestellt. Über die rechnerischen
Zusammenhänge verliert die Norm leider kein Wort. Das ist deshalb
schlecht, weil der Anwender keine Möglichkeit hat, die in der Norm
behaupteten Ergebnisse nachzurechnen. das ist ein weiterer Punkt, der
gegen ISO 13849 (und für IEC 61508) spricht. Die allgemeinen
Zusammenhänge kann man so darstellen:
- Die Kategorie ist eine Funktion aus
- Architektur der Sicherheitsfunktion
- DCavg
- Der Performance Level (PL) ist eine Funktion aus
- Kategorie
- DCavg
- MTTFd pro Kanal
ISO 13849
drückt die Sicherheit eines Kanals als MTTFd, die der gesamten
Sicherheitseinrichtung dagegen als PFH
aus.
Allgemein gilt
folgender Zusammenhang:
Je höher die
Kategorie, und je höher DCavg, desto höher der
Performance Level bei
gegebener MTTFd pro Kanal.
Der
"Wert" einer MTTFd pro Kanal steigt
in Funktionaler
Sicherheit
also mit der Kategorie und dem DCavg.
Eine mittlere
Zeit bis zum gefährlichen Ausfall (MTTFd) lässt sich
grundsätzlich in eine
Wahrscheinlichkeit eines gefährlichen
Ausfalls pro Stunde, PFH, umrechnen. In Funktionaler
Sicherheit hat man es mit
kleinen Wahrscheinlichkeiten zu tun,
weshalb eine lineare Näherung ohne Berücksichtigung der Exponentialfunktion ausreichend ist:
PFH = 1/MTTFd. 
ISO
13849 begrenzt die MTTFd
pro Kanal auf einen zulässigen Bereich zwischen 3 und 100 Jahren, was
einer Fehlerrate zwischen 38 und 1,14 fpmh (failures per million hours)
entspricht.
1) Kategorie
Folgende
Tabelle zeigt die wichtigsten Architekturanforderungen und die
geforderten Diagnoseabdeckungen.
ISO
13849
Kategorie
|
Architektur-
anforderung
|
Geforderte Diagnosedeckung
|
Ziel der Kategorie |
B
|
Einfaches
Sicherheitssystem. Keine besonderen Anforderungen
|
keine
|
Ausschöpfung
der zuverlässigkeitstechnischen Mittel bei einfachem Systemdesign.
Gesunder allgemeintechnischer Verstand.
|
1
|
Wie B,
zusätzlich:
Bewährte Prinzipien. Sicherheitstechnische Eignung ist
nachgewiesen.
|
keine
|
Bewährte
Prinzipien, bewährte Bauteile. Gesunder Fachverstand
|
2
|
Wie 1,
zusätzlich:
Die Sicherheitseinrichtung muss in regelmässigen Abständen getestet
werden.
|
mind. 60%
(mind. 90% *)
|
Erhöhung der
Offenbarungswahrscheinlichkeit.
|
3
|
Wie 1,
zusätzlich:
Es darf nur wenige Einzelfehler geben, die zum Verlust der
Sicherheitsfunktion führen. In der Praxis bedeutet das meistens
einfache Fehlertoleranz.
|
mind. 60%
(mind. 90% *)
|
Weitgehende
Fehlertoleranz. Manche Fehler dürfen unentdeckt bleiben.
|
4
|
Wie 3,
zusätzlich:
Jeder Einzelfehler muss erkannt werden, bevor die Sicherheitsfunktion
angefordert wird. Dies bedeutet mindestens einfache,
praktisch sogar
überwiegend mehrfache Fehlertoleranz, denn
ein zweiter Fehler darf nicht dazu führen, dass der erste Fehler
unerkannt bleibt.
|
mind. 99% |
Fehlertoleranz.
Kein Einzelfehler darf unentdeckt bleiben oder durch einen Folgefehler
maskiert werden.
|
*
führt manchmal zu einem besseren PL
2) Performance Level
Der
Performance Level ist eine stufenartige
Einteilung der PFH in verschiedene Bereiche, entsprechend SIL bei IEC
61508. Folgende
Tabelle gibt die etwas komplizierten Verhältnisse vereinfacht
wieder; die genauen Bereichsgrenzen hängen im Detail etwas von
Kategorie und DCavg ab:
| PFH |
Performance
Level
|
Bereichsabdeckung
|
| 3E-5 > PFH
> 1E-5 |
a
|
Faktor 3
|
| 1E-5 > PFH
> 3E-6 |
b
|
Faktor 3 |
| 3E-6 > PFH
> 1E-6 |
c
|
Faktor 3 |
| 1E-6 > PFH
> 1E-7 |
d
|
Faktor 10
|
| 1E-7 > PFH
> 2,5E-8 |
e
|
Faktor 4
|
Das
Kennzahlensystem des IEC
61508 ist einfach gehalten und plausibel.
ISO 13849 dagegen ist weniger übersichtlich.
Funktionale
Sicherheit nach IEC 61508
bedeutet, dass zusätzlich zur PFH bzw. PFD noch Nebenbedingungen,
nämlich SFF
und HFT erfüllt werden müssen,
um einen bestimmten SIL für das Gesamtsystem zu erreichen. Diese Nebenbedingungen gehen in die PFH
/ PFD nicht rechnerisch ein, sondern entsprechen der Denkweise, dass
Sicherheitstechnik sich nicht allein auf
Zuverlässigkeitsberechnungen gründen soll.
Die PFH / PFD
kann sehr stark von den Fehleroffenbarungszeiten abhängen. Darüber sagt
IEC
61508 zwar direkt nichts aus, indirekt allerdings schon über die
PFH Forderung selbst, die, egal wie, erreicht werden muss. Damit
lässt IEC 61508 grossen Freiraum bei der Ausgestaltung des
sicherheitsgerichteten Systems.
Funktionale
Sicherheit nach ISO 13849
dagegen "erlaubt" genau 5 (eigentlich nur 3) konkrete
Systemarchitekturen. Sie stellt konkrete
Anforderungen weniger an das gesamte System, sondern vielmehr an die
einzelnen Kanäle (Teile des Systems). Daraus berechnet sie
unter Berücksichtigung der DCavg und der Systemarchitektur
die PFH des
Gesamtsystems.
Speziell bezüglich der Fehleroffenbarungszeiten verhält sich ISO 13849
äusserst pauschal, sodass deren Verringerung im Rahmen dieser
Norm leider kein besonders wirksames Mittel darstellt.
Der Blickwinkel, oder allgemein der Bereich des Erlaubten ist bei ISO
13849 also wesentlich kleiner als bei IEC 61508.
Auffällig bei
ISO 13849 sind die relativ schwachen Einflüsse der beiden Faktoren
DCavg
und
Systemarchitektur auf die PFH, wie vorige Tabelle zeigt, und
folgendes
Beispiel verdeutlicht:
Ein
einkanaliges simples System der Kategorie B mit einer MTTFd
von 10 Jahren für diesen Kanal hat laut Anhang K eine PFH von 1,14E-5.
Für diesen einfachen Fall sind die 10 Jahre und die 1,14E-5 einfach
eine
Umrechnung; die beiden Werte besagen genau das Selbe.
Nun betrachte
man ein System, das aus genau 2 parallelen solchen Kanälen besteht und
zusätzlich eine DCavg von über 90%
hat. Dieses System hat bereits Kategorie 3.
Laut Anhang K
ergibt sich für dieses
System eine PFH von 1,36E-6, was gerade mal um Faktor 8 besser ist als
das eingangs beschriebene simple System.
Der Grund für
diese relativ schwache
Verbesserung liegt darin, dass Kategorie 3 Systeme eben nicht 100%
fehlertolerant sein müssen, sondern nur "fast".
Die
Fehlertoleranzforderung für Kategorie 3 Systeme ist nämlich weich
formuliert ("...wann immer möglich")
Ein ähnliches
Zahlenbeispiel mit
einem einkanaligen System der Kategorie B und einem Kategorie 4 System
aus 2 solchen Kanälen führt auf einen Unterschied von Faktor 40.
Zwar Sind
Kategorie 4 Systeme zu 100%
fehlertolerant, doch sind die mit Fehlertoleranz verbundenen
Anforderungen hinsichtlich Ausfällen mit gemeinsamer Ursache (Common
Cause Fehler, CCF) wiederum relativ weich formuliert. Es handelt
sich
hier um eine Checkliste, die den Entwicklungsprozess und nicht das
System selbst adressiert. Die quantitative Erklärung dieses
relativ kleinen Faktors von 40 beruht auf einem angenommenen Betafaktor
von 2%, das heisst, bei einem redundanten und damit
theoretisch 100% fehlertoleranten System wird davon ausgegangen,
dass 2% der Fehler gleichzeitig in allen Kanälen auftreten und somit
als Einzelfehler anzusehen sind.
Die relative
Kompliziertheit der ISO
13849, also die Festlegung auf bestimmte Architekturen und
Vorgehensweisen führt dazu, dass Funktionale
Sicherheit
leichter erreicht werden kann. Die Forderungen sind eher weich
formuliert und an allgemeinen
technischen Regeln orientiert. Dafür kommen im Endeffekt schlechtere
PFH Werte als beim IEC 61508 heraus.
IEC 61508
bietet dem Entwickler weit mehr Gestaltungsspielraum, ermöglicht damit
im Gegensatz zur ISO 13849 wesentlich sicherere
Systeme, allerdings bei höherem Nachweisaufwand.
Wirklich
gravierende Nachteile der ISO 13849 sind
- die Verwendung
der DCavg . Dies steht inhärenter Sicherheit
grundsätzlich entgegen. Stattdessen sollte SFF verwendet werden.
- die
Beschränkung der MTTFd
pro Kanal auf einen Bereich zwischen 3 und 100 Jahren,
- was
einer
Fehlerrate zwischen 38 und 1,14 fpmh entspricht. Dies spiegelt längst
nicht das technisch Machbare wieder. Mit Schaltern und etwas passiver
Elektronik pro Kanal lassen sich ohne Weiteres belastbare MTTFd
Werte von weit über 100 bis zu 1000 Jahren realisieren.
Intuitiv würde man meinen, dass Funktionale
Sicherheit auch
dadurch beeinflusst wird, ob der gefährliche Fall häufig oder
selten auftritt. Diese Unterscheidung macht allerdings nur IEC 61508.
ISO 13849 kennt nur High Demand Mode, erwähnt dies jedoch nicht
explizit.
IEC 61508 fordert, dass für sog. High Demand Systeme die PFH, und für
Low Demand Systeme die PFD massgebend sein soll. Die Grenze zwischen
Beiden liegt in der geschätzten Häufigkeit, mit der der gefährliche
Fall voraussichtlich eintreten wird.
- > 1 x / Jahr --> High
Demand,
also PFH
- < 1 x / Jahr --> Low
Demand, also PFD.
Diese Unterscheidung ist viel tiefgründiger, als es den Anschein
hat.
PFD
bedeutet Probability of failure on demand, also die
Wahrscheinlichkeit dafür, dass das System *bei Eintritt einer
Sicherheitsanforderung* selbige nicht verarbeitet aufgrund eines
Fehlers. Mit anderen Worten: Die Wahrscheinlichkeit dafür, dass der
gefährliche Fall eintritt, und dann die Sicherheitsfunktion nicht
anspricht.
Die PFD ist also sowohl eine bedingte, als auch eine über die Zeit
kumulierte Wahrscheinlichkeit. Beachte, dass
- der Zustand "ausgefallen" massgebend ist,
- der Eintritt des gefährlichen Falles vorausgesetzt wird
PFH dagegen bedeutet Probability of
failure
per hour. Das ist schlicht und einfach eine potentiell gefährliche, auf
die Stunde bezogene Ausfallrate, bzw. die Wahrscheinlichkeit dafür,
dass *in einer gegebenen Stunde* die Sicherheitsfunktion ausfällt;
etwas genauer: die Wahrscheinlichkeit dafür, dass der Vorgang des
Ausfallens der Sicherheitsfunktion in einer bestimmten Stunde
stattfindet. Beachte, dass
- der Vorgang des Ausfallens, und nicht der Zustand "ausgefallen"
massgebend ist,
- vom Eintritt des gefährlichen Falles keine Rede ist
Also:
- PFD = Wahrscheinlichkeit, dass das
System bei einem gefährlichen Ereignis nicht funktionieren wird.
- PFH = Wahrscheinlichkeit, dass
das System während einer bestimmten Stunde seine Sicherheitsfunktion
verlieren wird.
Die bisherigen Ausführungen lassen
durchblicken, dass eigentlich die PFD das Entscheidende ist, selbst
dann, wenn man den Sicherheitsnachweis an der PFH ausrichtet.
- Als zu schützende Person
interessiert mich ja weniger, mit welcher Wahrscheinlichkeit die
Schutzeinrichtung vorgestern um 17:30 (bis heute unerkannt) ausgefallen
ist, oder in 2 Monaten Sonntag Abends um 20:00 Uhr (unerkannt)
ausfallen wird, sondern vielmehr die Wahrscheinlichkeit, dass die Schutzeinrichtung im Gefahrenfall nicht
funktionieren wird.
- Anstelle Low Demand und High
Demand Systeme mittels PFD und PFH zu charakterisieren, wäre es
sinnvoller, beide Systemarten mittels PFD zu charakterisieren, und für
High Demand Systeme die PFD Schwellen um Faktor 104
niedriger anzusetzen (was zahlenmässig ja genau den PFH Schwellen
entspricht). Das hätte den Vorteil, dass Diagnose und Prooftest bei
einfachen Systemen wirksam wären. Durch die Wahl der PFH
werden sie jedoch leider (rechnerisch) wirkungslos.
Spätestens, wenn es darum geht,
maximal zulässige Testintervalle festzulegen (z.B. Proof Test
Intervall, Diagnoseintervall), kommt man um die PFD gar nicht herum: Das
maximal zulässige Intervall ergibt sich nämlich unmittelbar aus der
PFD. Dies gilt sowohl für mittels PFH, als auch mittels PFD
charakterisierte Systeme.
Die folgende
Tabelle zeigt wesentliche Zusammenhänge auf und gibt wichtige Hinweise,
die Fehlerbaumanalysen
und Zuverlässigkeits-Blockdiagramme betreffen. Besonders tückisch ist der
Fall PFH bei einfachen Systemen:
|
Einfaches,
nicht fehlertolerantes System
|
Redundantes
oder fehlertolerantes System
|
PFD
ist massgebend
|
Die PFD
beginnt bei Wert Null, wird mit der
Zeit grösser, und geht asymptotisch gegen 1. Deshalb muss der Sicherheitsnachweis die PFD für
das Diagnose- bzw. Prooftestintervall ausweisen.
Proof Test Intervall und Diagnoseintervall bestimmen massgeblich das
Ergebnis und damit die SIL Einstufung.
Durch Verkürzen dieser
Intervalle lässt sich die PFD (theoretisch) beliebig verkleinern.
|
Selbe
grundlegende Charakteristika wie links, mit dem Unterschied, dass der
Anstieg gegen 1 sehr viel langsamer verläuft.
|
PFH
ist massgebend
|
Die PFH
beginnt bei einem bestimmten Wert (ungleich Null), wird mit der Zeit kleiner und geht gegen Null,
deshalb muss der Sicherheitsnachweis
die PFH für t=0 ausweisen.
Proof Test Intervall und
Diagnoseintervall, überhaupt die Existenz von Beiden haben keinen rechnerischen Einfluss auf das
Ergebnis und damit auf die SIL Einstufung.
Beide Intervalle ergeben sich ausschliesslich aus der PFD.
|
Die PFH
beginnt bei Wert Null (*), steigt
dann bis zu einem Maximum an,
danach fällt sie wieder auf Null ab (**).
Deshalb muss der Sicherheitsnachweis
die PFH für das Diagnose- bzw. Prooftestintervall ausweisen.
Solange man sich vor dem Maximum befindet,
also für nicht allzu grosse Zeiten, bestimmen Proof Test Intervall
und Diagnoseintervall massgeblich das Ergebnis und damit die SIL
Einstufung.
Durch Verkürzen dieser
Intervalle lässt sich die (maximale) PFH theoretisch beliebig
verkleinern.
Hinter dem Maximum wird jede Betrachtung sinnlos und gefährlich
|
(*) Eine unmittelbare Folge der Fehlertoleranz.
(**) Für grosse Zeiten verhält sich das System wie ein einfaches
System, da mit hoher Wahrscheinlichkeit bereits ein Fehler eingetreten ist (HFT = 1
angenommen).
CCF
Common Cause Failures. Ausfälle mit
gemeinsamer Ursache. Bei redundanten und fehlertoleranten Systemen darf
man nicht per se davon ausgehen, als seien alle Einzelfehler unabhängig
voneinander. Die Unabhängigkeit muss separat nachgewiesen werden. ISO
13849 hält hierfür eine Checkliste bereit, die den Entwicklungsprozess
des Produktes beleuchtet (also nicht das Produkt selbst), und die bei
Erreichen einer Mindestpunktezahl die gegenseitige Unabhängigkeit fast
aller
Einzelfehler attestiert (in dem Wörtchen "fast" liegt der Hund
begraben, denn die Fehlertoleranzforderungen sind weich formuliert.
Üblich ist auch, einen (kleinen) Prozentsatz
der Fehlerrate der redundanten Zweige als Einzelfehlerrate auszuweisen,
allerdings verschlechtert sich das Gesamtergebnis dabei ganz erheblich.
Bei der ISO 13849 wurde wahrscheinlich ein solcher Faktor angenommen;
dies würde den im Vergleich zum IEC 61508 relativ geringeren PFH-Umfang
erklären:
Bei der ISO 13849 3E-5 bis 2,5E-8 in 5 Stufen, und
beim IEC 61508 1E-5 bis 1E-9 in 4
Stufen.
Diagnose
Etwas
Automatisches (kann nicht vergessen werden) und Eingebautes (gehört
also zum System). Diagnose ist etwas relativ oft stattfindendes,
gemessen an der zur erwartenden Anforderungsrate der
Sicherheitsfunktion.
Diagnose kann eine separate
Testroutine sein, oder auch das
Systemverhalten an
sich. Z.B. können potentiell gefährliche Ausfälle eine
Sicherheitsfunktion derart ausser Kraft setzen, dass es sofort
feststellbar ist. Dies gilt insbesondere bei Anlagen, bei denen
Diagnose und die eigentliche Anlage nicht grundsätzlich trennbar sind.
Beispiel: Beim 4-20mA Prinzip das
Verlassen dieses Bereichs.
Diagnoseabdeckung
In Worten: Die detektierbaren gefährlichen Fehlermoden geteilt durch
alle gefährlichen Fehlermoden.
Die Symbole bedeuten:
| Symbol |
Bedeutung
|
Lambda
|
Fehlerrate
|
Index SD
|
Safe, Detectable
|
Index SU
|
Safe, Undetectable
|
Index DD
|
Dangerous, Detectable
|
Index DU
|
Dangerous, Undetectable
|
Aus den Definitionen für SFF und DCavg
ist direkt ersichtlich, dass unter gleichen Bedingungen die DCavg
höchstens gleichgross wie die SFF sein kann; für reale Systeme ist SFF
immer grösser.
Beispiele:
Aus der Tabelle ist ersichtlich, dass
DCavg im Gegensatz zur SFF das Vorhandensein
sicherer Ausfälle bestraft, was einem sicheren Systemdesign glatt
widerspricht. Das ist ein gravierender Nachteil des ISO 13849.
Primäres Ziel sollte sein, möglichst
wenig gefährliche Ausfälle zu
haben, unabhängig davon ob detektierbar oder nicht.
Das obige Beispiel 4 ist im Grunde
ein sehr sicheres System, was die SFF mit 99% gut wiederspiegelt.
Die DCavg mit nur 50% lässt dies dagegen überhaupt
nicht erkennen.
Die Definition der DCavg
ist daher kurzsichtig, und der Verfasser
rät daher dazu, anstelle der DCavg die SFF zu verwenden,
selbst dann, wenn der Nachweis auf Grundlage der ISO 13849 geführt
wird.
Gefährlicher
Ausfall
Ausfall, der die
Sicherheitsfunktion gefährden oder gar ausser Kraft setzen kann.
Besondere Aufmerksamkeit verdienen die nicht detektierbaren
gefährlichen Ausfälle.
HFT
Hardware Fault Toleranz, Hardware
Fehlertoleranz. Die Mindestanzahl Einzelfehler, die das System
tolerieren kann, ohne die Sicherheitsfunktion zu gefährden.
Performance
Level
Ein MTTFd-Bereich
in der Begriffswelt der ISO 13849. Anstelle die MTTFd als Zahl
anzugeben, ordnet ISO 13849 die Zahlenwerte in die Bereiche a
(niedriger) bis e (höher) ein. Siehe diese Tabelle.
PFH
Probability of failure per hour. Die gefährliche Ausfallrate, bezogen
auf eine
Stunde.
PFD
Probability of failure on demand. gefährliche
Ausfallwahrscheinlichkeit, bezogen auf eine Sicherheitsanforderung.
SFF:
Safe failure Fraction
In Worten: Alle ausser die
gefährlichen und undetektierbaren Fehlermoden geteilt durch alle
Fehlermoden.
Sicherer
Ausfall
Ausfall, der die
Sicherheitsfunktion nicht gefährdet.
Ein sicherer Ausfall kann z.B. selbstoffenbarend sein, oder die Anlage
in einen sicheren Zustand überführen. In jedem Fall handelt es sich
jedoch um einen Fehler.
Sicherheitsfunktion
Diejenigen Teile einer Anlage, die
rein zu Sicherheitszwecken vorhanden sind. Im Idealbild der
Funktionalen Sicherheit sind dies spezielle und abgrenzbare
Anlagenteile
(z.B. durch Nachrüstung). Oft jedoch handelt es sich um die Anlage
selbst, in die die Sicherheitsfunktion untrennbar mit eingebettet ist.
Datenschutzhinweise
MTBF Berechnung
beauftragen Was bedeutet MTBF