Belastbarer Umgang mit technischen Unsicherheiten

Statistik, RAMS & Qualitätsmanagement
Auf dieser Seite suchen
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII------Dienstleistungen-----IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="first_item"_im_ersten_li_tag_xxxxxxxx
    • MTBF Berechnung
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="last_item"_im_ersten_li_tag_sowie_zusaetzliche_/ul_und_/li_tags_am_schluss_xxxxxxxx
    • Funktionale Sicherheit
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII-----Fachartikel---IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="first_item"_im_ersten_li_tag_xxxxxxxx
    • RAMS
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • RAMS Normen
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Funktionale Sicherheit
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • MTBF
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • FMEA, FMECA
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Blockdiagramme
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Fehlerbaumanalyse
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Ereignisbaumanalyse
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Markovdiagramme
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Weibullanalyse
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • SPC Einführung
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • SPC: Eingriffsgrenzen bei gestutzter Normalverteilung
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="last_item"_im_ersten_li_tag_sowie_zusaetzliche_/ul_und_/li_tags_am_schluss_xxxxxxxx
    • SPC: Eingriffsgrenzen bei Rayleighverteilung
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII-----Fachliteratur---IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="first_item"_im_ersten_li_tag_xxxxxxxx
    • Statistische Versuchsplanung (DoE)
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    • Statistische Prozessregelung (SPC)
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="last_item"_im_ersten_li_tag_sowie_zusaetzliche_/ul_und_/li_tags_am_schluss_xxxxxxxx
    • Mean Time Between Failures (MTBF)
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII-------Referenzen-----IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="first_item"_im_ersten_li_tag_xxxxxxxx
    • Kunden
    • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-beachte_class="last_item"_im_ersten_li_tag_sowie_zusaetzliche_/ul_und_/li_tags_am_schluss_xxxxxxxx
    • Projekte
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII-------Profil-----IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII-------Kontakt-----IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
  • IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII-------English-----IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
Sitemap

Funktionale Sicherheit

Inhaltsverzeichnis IEC-61508 Funktionale Sicherheit
Eins hoch

1. Funktionale Sicherheit: Einleitung

Eins runter

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
SIL1 SIL2 SIL3SIL4Alle 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.


Eins hoch

2. Sicherheit versus Zuverlässigkeit

Eins runter

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 2oo2
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 1oo2
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 2oo3
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:
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:
  1. Einfachheit der Sicherheitsfunktion. Weder Software noch aktive Elektronik. Nur Schalter oder nur reine Mechanik.
  2. System, das sich selbst überprüft, oder das von aussen überprüft wird, und zwar in kurzen Zeitabständen, typischerweise im Systemtakt.
  3. Redundante Auslegung mit oder ohne Überprüfung
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.

Eins hoch

3. IEC 61508: Einführung

Eins runter

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:
  1. 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.
  2. Heute lassen sich die meisten Einrichtungen bezüglich Funktionaler Sicherheit nicht ohne Elektrik realisieren.

Eins hoch

4. ISO 13849: Einführung

Eins runter

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:
  1. 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.
  2. 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. 
  3. 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.

Eins hoch

5. IEC 61508 und ISO 13849 Kennzahlensysteme

Eins runter

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
    1. des Entwicklungsprozesses, UND
    2. 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.

Eins hoch

5.1 IEC 61508

Eins runter

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:
PFH PFD SFF 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).

Eins hoch

5.2 ISO 13849

Eins runter

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

ISO 13849 Performance Level aAusschlaggebend 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: ISO 13849 Performance Level b
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:
  1. Die Kategorie ist eine Funktion aus
  2. Der Performance Level (PL) ist eine Funktion aus
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 Performance Level 3

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

Eins hoch

6. Bewertender Vergleich von IEC 61508 und ISO 13849

Eins runter


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

Eins hoch

7. IEC 61508: High Demand vs. Low Demand: PFH vs. PFD

Eins runter

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.
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
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
Also:
  1. PFD = Wahrscheinlichkeit, dass das System bei einem gefährlichen Ereignis nicht funktionieren wird.
  2. 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.
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).

Eins hoch

8. Funktionale Sicherheit: Erläuterung von Begriffen

Ganz Hoch


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
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:
SFF vs DCavg
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
Safe Failure Fraction, SFF
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.

Ganz Hoch

Weiter

Datenschutzhinweise               MTBF Berechnung beauftragen               Was bedeutet MTBF