IEC 61508 – Einführung in die Hardwareentwicklung

Autor / Redakteur: Olaf C. Winne* / Martina Hafner

Mit der IEC 61508 existiert eine branchenübergreifende generische Richtlinie für sicherheitsgerichtete Systeme. Welche Kriterien müssen Ingenieure bei der Hardwareentwicklung laut IEC-Standard berücksichtigen?

Firmen zum Thema

Teil 2 der IEC 61508 befasst sich mit den normativen Richtlinien für funktional sichere Hardware. In ihm wird für die Hardware des Systems ein detaillierter Sicherheitslebenszyklus über den gesamten Lebenszyklus eines Hardware-Podukts definiert.
Teil 2 der IEC 61508 befasst sich mit den normativen Richtlinien für funktional sichere Hardware. In ihm wird für die Hardware des Systems ein detaillierter Sicherheitslebenszyklus über den gesamten Lebenszyklus eines Hardware-Podukts definiert.
(Bild: Merck Gruppe)

Die IEC 61508 ist eine branchenübergreifende generische Richtlinie für sicherheitsgerichtete Systeme, in denen ein Fehler zu Tod, Verletzung, der katastrophalen Schädigung der Umwelt oder der Zerstörung von Produktionsanlagen und -gütern führen kann. Sie umfasst weit über 500 Seiten und gliedert sich in sieben Teile, wobei die Teile eins bis vier normativ sind, das heißt als Richtlinie dienen. Die Teile fünf bis sieben sind informativ.

Leitfaden: Artikel zur IEC 61508

  • Die Inhalte der IEC 61508 im Überblick

Die IEC 61508 beschreibt den kompletten Lebenszyklus des gesamten sicherheitsgerichteten Systems von der Planung bis zur Außerbetriebnahme und bezieht sich dabei auf alle Aspekte, die mit der Nutzung und Anforderung an elektrische / elektronische / programmierbare elektronische Systeme (E/E/PE-Systeme) für sicherheitsrelevante Funktionen zusammenhängen.

Teil 2 der IEC 61508 bezieht sich auf die Hardwareaspekte (inklusive Mechanik) des sicherheitsrelevanten Systems. Innerhalb des gesamten Sicherheitslebenszyklus (in der Phase 9, Realisierungsphase) wird für die Hardware des Systems ein detaillierter Sicherheitslebenszyklus definiert. Auch in allen Phasen des E/E/PES(elektrische/elektronische/programmierbare elektronische Systeme)-Lebenszyklus gelten die Anforderungen an Dokumentation, Verifikation und Validation sowie die Planung derselben wie im ersten Teil dieser Reihe beschrieben. Art und Umfang der Dokumentation können, je nach Projektgröße, erheblich variieren.

Bild 1: Lebenszyklus eines E/E/PES ((elektrische /elektronische / programmierbare elektronische Systeme). Bei komplexeren Systemen ist bereits die Definitionsphase kritisch, da in diesem frühzeitigen Stadium viele spätere Entwurfsfehler entstehen.
Bild 1: Lebenszyklus eines E/E/PES ((elektrische /elektronische / programmierbare elektronische Systeme). Bei komplexeren Systemen ist bereits die Definitionsphase kritisch, da in diesem frühzeitigen Stadium viele spätere Entwurfsfehler entstehen.
(Bild: Quategra)

Entwurf muss konsequent gegen Sicherheitsanforderungen verifiziert werden

Gefordert ist ein systematischer Entwurf, der aus den Sicherheitsanforderungen an das gesamte System (siehe SRS, Safety-Requirement-Spezifikation) rückverfolgbar hergeleitet ist. Dieser Entwurf besteht aus einem Architekturentwurf der Hardware, System- und Baugruppendesign bis zur Schaltung. Der Entwurfsweg muss fortlaufend gegen die Sicherheitsanforderungen geprüft (verifiziert) werden. Dabei müssen die Sicherheitsanforderungen an E/E/PE-Systeme in einer Art und Weise ausgedrückt werden, dass sie klar, genau, unzweideutig, nachprüfbar, testbar, pflegbar und ausführbar sind.

Verfahren und Maßnahmen um systematische Hardwarefehler und Ausfälle während des Betriebes zu beherrschen müssen nach dem Teil 2 der IEC 61508 implementiert, bewertet und geprüft worden sein (zum Beispiel Speichertests zur Sicherstellung der Datenkonsistenz). Dabei gibt es in der Praxis oft Unsicherheiten über die Güte der angewendeten Diagnosen zur Erkennung dieser Fehler.

Quantitative Ausfallwahrscheinlichkeit ist zu bestimmen

Neu gegenüber vielen gültigen Branchennormen ist die Forderung, die quantitative Ausfallwahrscheinlichkeit (zufällige Fehler durch Ausfälle der Bauteile oder Baugruppen) der Hardware zu bestimmen und entsprechend dem geforderten SIL nachzuweisen. Hier kommen statistische Betrachtungen mit entsprechenden Berechnungen ins Spiel – die jedoch für einige gebräuchliche Hardwarearchitekturen vereinfacht angewendet werden können.

Beim Entwurf von E/E/PE Systemen sollten folgende Anforderungen erfüllt werden:

  • Anforderungen zur Sicherheitsintegrität der Hardware
  • Anforderungen zur systematischen Sicherheitsintegrität
  • Anforderungen an das Systemverhalten bei Erkennung des Fehlers
  • Anforderungen zur E/E/PE-System-Implementierung

Bild 2: Die IEC61508 definiert Sicherheitsanforderungsstufen (SIL) 1 bis 4, die als ein Maß für die erreichte Sicherheit der Systeme dienen. Parameter einer ersten Bewertung des Systems ist u.a. der Anteil ungefährlicher Ausfälle in Bezug zu den gesamten möglichen Ausfällen der Hardware, dem sogenannten SFF-Faktor. Typ A liegt bei einfachen (Teil-)Systemen vor. Bei Typ B ist das Ausfallverhalten von mindestens einem Bauteil nicht ausreichend definiert (z.B. komplexer integrierter Schaltkreis).
Bild 2: Die IEC61508 definiert Sicherheitsanforderungsstufen (SIL) 1 bis 4, die als ein Maß für die erreichte Sicherheit der Systeme dienen. Parameter einer ersten Bewertung des Systems ist u.a. der Anteil ungefährlicher Ausfälle in Bezug zu den gesamten möglichen Ausfällen der Hardware, dem sogenannten SFF-Faktor. Typ A liegt bei einfachen (Teil-)Systemen vor. Bei Typ B ist das Ausfallverhalten von mindestens einem Bauteil nicht ausreichend definiert (z.B. komplexer integrierter Schaltkreis).
(Bild: Quategra)

SIL der Hardware bewerten

Die IEC 61508 definiert Sicherheitsanforderungsstufen (SIL, Safety Integrity Level), die als Maß für die Sicherheit der Systeme dienen. Um ein Sicherheitsintegritätslevel (SIL) zu erreichen, wird die Hardwarearchitektur berücksichtigt. Parameter einer ersten Bewertung sind die gegebene Fehlertoleranz der Hardwarearchitektur (HFT, Hardware Fault Tolerance) und der Anteil ungefährlicher Ausfälle im Bezug zu den gesamten möglichen Ausfällen der Schaltung, dem sogenannten SFF-Faktor (Safe Failure Fraction).

Bild 7: Berechnung des SFF (Safe Failure Fraction)
Bild 7: Berechnung des SFF (Safe Failure Fraction)
(Bild: Quategra)

Bei einfachen (Teil-)Systemen liegt Typ A eines E/E/PES vor, Ausfallraten und Ausfallverhalten aller Bauteile sind ausreichend definiert. Dies ist bei den Standard-Komponenten, wie Widerständen und Kondensatoren, der Fall. Bei Typ B ist das Ausfallverhalten von mindestens einem Bauteil nicht ausreichend definiert, das Verhalten des Teilsystems bei Fehler ist nicht ausreichend bestimmbar. Dies ist beispielsweise bei dem Einsatz eines Mikrocontrollers der gegeben.

Sicherheitsmodelle für Hardware-Fehler-Toleranz

Die Hardware-Fehler-Toleranz (HFT) N eines Teilsystems sagt dabei aus, dass N+1 Fehler den Verlust der Sicherheitsfunktion bedeuten. Die Hardwarearchitektur mit einem zugehörigen HFT kann durch Sicherheitsmodelle repräsentiert werden:

  • 1oo1 System, 1 out of 1 – der Ausfall eines Kanals führt zum Verlust der Sicherheitsfunktion.
  • 1oo2 System, 1 out of 2 – 2 Kanäle, der Ausfall eines Kanals führt zur Abschaltung. Aber erst der Ausfall beider Kanäle führt zum Verlust der Sicherheitsfunktion.
  • 2oo2 System, 2 out of 2 - 2 Kanäle, bei Ausfall eines Kanals bleibt das System funktionsfähig. Erst der Ausfall des 2. Kanals führt zum Verlust der Sicherheitsfunktion.

Bild 3: Parallelschaltung von Teilsystemen
Bild 3: Parallelschaltung von Teilsystemen
(Bild: Quategra)

Die Kombination mit einer Diagnose (z.B. Vergleicher, Abschalttests) wird mit einem D hinter dem System (1oo2D) gekennzeichnet und ist für die weitere Bestimmung der Ausfallwahrscheinlichkeit relevant. Weitere 2- und 3-kanalige Systeme sind in einschlägiger Literatur beschrieben (2oo3, etc).

Dabei lassen sich komplexe Systeme in Teilsysteme zerlegen, die entsprechend in Typ A oder B eingeteilt werden und sich nachträglich kombinieren lassen. Die Zusammenfassung der Teilsysteme erfolgt nach dem schwächsten Glied.

Bild 13: Blockdiagram für ein einfaches 1oo2D-System
Bild 13: Blockdiagram für ein einfaches 1oo2D-System
(Bild: Quategra)

Weiterhin gibt es in mehrkanaligen Systemen Fehler mit gemeinsamer Ursache (z.B. eine Spannungsversorgung für beide Kanäle). Hier kann ein Fehler sofort den Ausfall des Systems herbeiführen. Diese Fehler müssen gesondert im Rahmen der FMEDA (Failure Mode, Effects and Diagnostic Analysis) oder der FTA (Fehlerbaumanalyse) betrachtet werden. Eventuell sind spezielle (unabhängige) Diagnosemaßnahmen zu treffen, die das System bei Fehlfunktion (z.B. Überspannung, Mikrocontroller-Ausfall durch EMV-Einflüsse) in einen sicheren Zustand überführen.

Mit dem β-Faktor wird der Anteil der Fehler infolge gemeinsamer Ursache zur gesamten Anzahl auftretender Fehler angegeben. Für die Ausfall-Wahrscheinlichkeitsbetrachtung erlaubt die IEC 61508 eine tabellarische Ermittlung eines β-Faktor, der in die Berechnung von PFD (Probability of failure on demand)/ PFH (Probability of dangerous Failure per Hour) eingeht.

Bild 4: Typische Ausfallrate/Zeit elektronischer Bauteile
Bild 4: Typische Ausfallrate/Zeit elektronischer Bauteile
(Bild: Quategra)

Ausfallraten, Diagnosedeckungsgrad und Safe Failure Fraction

Der SFF-(Safe-Failure-Fraction-)Faktor repräsentiert den Anteil der sicheren und erkannten Ausfälle zu den gesamten Ausfällen. Ausfälle (oder zufällige Fehler) repräsentieren mögliche Fehler von eingesetzten Bauteilen. Die Ausfallrate wird als λ angegeben, die Einheit FIT (Failure in Time) gibt die Anzahl der Bauteile an, die in 10 hoch 9 Stunden ausfallen. Fehlermodelle einzelner Bauteile und Ausfallraten findet man in Datenblättern, verschiedenen Normen und anderer Literatur (z.B. Siemens DIN SN29500, MIL-STD 217). Die Angaben aus verschiedenen Quellen unterscheiden sich dabei teilweise erheblich und müssen hinsichtlich der zugrunde liegenden Ausgangsgrößen bewertet werden.

Bei elektronischen Bauteilen wird oft die „Badewannenkurve“ (Weibull-Verteilung) für Ausfälle über einen Zeitraum verwendet. Nach einer Frühphase ist λ für die Nutzungsphase annähernd konstant. Danach steigt der Ausfall (je nach Bauteil) durch Alterungsprozesse an. Das Ende der Nutzungsphase ist bei elektronischen Systemen mit ca. 10 Jahren erreicht. Die Ausfallwahrscheinlichkeit hängt damit von λ und der Einsatzdauer t des Systems ab.

Bild 5: Die Bauteilausfälle lassen sich danach klassifizieren, in welchen Zustand eine Hardware bei einem Ausfall kommt: λs = safe, sicherer Zustand, λD = dangerous, gefährlicher Zustand. Auf Basis von Diagnoseeinrichtungen kann weiter λD in λDD = dangerous detected (aufgedeckt) oder λDU = dangerous undetected (nicht aufgedeckt) unterschieden werden.
Bild 5: Die Bauteilausfälle lassen sich danach klassifizieren, in welchen Zustand eine Hardware bei einem Ausfall kommt: λs = safe, sicherer Zustand, λD = dangerous, gefährlicher Zustand. Auf Basis von Diagnoseeinrichtungen kann weiter λD in λDD = dangerous detected (aufgedeckt) oder λDU = dangerous undetected (nicht aufgedeckt) unterschieden werden.
(Bild: Quategra)

Die Bauteilausfälle können klassifiziert werden, je nachdem, in welchen Zustand eine Hardware bei dem jeweiligen Ausfall kommt ( λs = safe, sicherer Zustand, λD = dangerous, gefährlicher Zustand). Zusammen mit Diagnoseeinrichtungen (regelmäßiges Prüfen der Sicherheitsfunktion im Betrieb, z.B. Abschalttests sicherheitsrelevanter Ausgänge) kann

  • λD in λDD = dangerous detected (aufgedeckt) oder
  • λDU = dangerous undetected (nicht aufgedeckt)

unterschieden werden.

Beispiel: Ausfallwahrscheinlichkeit eines Widerstandes. Aus der SN29500 geht die Basisfehlerrate hervor, λ = 0,2 [FIT]. Diese kann auf verschiedene Ausfallarten verteilt werden (Fehler-Splitt). Die möglichen Ausfallarten und die Verteilung eines Bauteils können wiederum aus Normen und anderen Quellen entnommen werden (z.B. IEC 62061). Ob der jeweilige Fehler zu einem sicheren oder unsicheren Ausfall der Schaltung führt, und ob der unsichere Ausfall durch Diagnose erkannt wird, ist durch Analyse und Simulation zu bestimmen.

Bild 6: Berechnung des DC (Diagnosedeckungsgrad)
Bild 6: Berechnung des DC (Diagnosedeckungsgrad)
(Bild: Quategra)

Der Diagnosedeckungsgrad DC (Diagnostic Coverage) gibt an, zu welchem Anteil gefährliche Fehler durch einen Test aufgedeckt werden. Die Diagnose kann unterschiedlicher Güte sein, und daher einen Faktor zur Aufteilung zwischen λDU und λDD beinhalten (z.B. bei komplexen Bauteilen). Hinweise und Beispiele finden sich im Teil 2 der Norm und anderer Literatur.

Bild 5b: FMEDA (Failure Modes, Effects and Diagnostic Analysis) für einen Widerstand mit Fehlerrate und Splitt. Im E/E/PES müssen Safe-Failure-Fraction (SFF) und Ausfallwahrscheinlichkeit im Detail nachgewiesen werden. Dazu kann eine komplette FMEDA auf Bauteilebene oder eine FTA (Fault Tree Analysis) des Systems durchgeführt werden.
Bild 5b: FMEDA (Failure Modes, Effects and Diagnostic Analysis) für einen Widerstand mit Fehlerrate und Splitt. Im E/E/PES müssen Safe-Failure-Fraction (SFF) und Ausfallwahrscheinlichkeit im Detail nachgewiesen werden. Dazu kann eine komplette FMEDA auf Bauteilebene oder eine FTA (Fault Tree Analysis) des Systems durchgeführt werden.
(Bild: Quategra)

In der Anwendung müssen der SFF und die Ausfallwahrscheinlichkeit im Detail entsprechend nachgewiesen werden. Dazu kann, analog dem Beispiel „Widerstand“, eine komplette FMEDA (Failure Modes, Effects and Diagnostic Analysis) auf Bauteilebene oder eine FTA (Fault Tree Analysis) des Systems durchgeführt werden.

Alle λ werden dadurch bestimmt und können mit weiteren Parametern zur Ermittlung der Ausfallwahrscheinlichkeit herangezogen werden. Diese ist in den PFD- oder PFH-Werten ausgedrückt und muss mit dem aus Hardwarearchitektur und SFF bestimmten SIL übereinstimmen.

Bild 8: Die PFD- und PFH-Werte müssen mit dem aus Hardwarearchitektur und SFF bestimmten SIL übereinstimmen.
Bild 8: Die PFD- und PFH-Werte müssen mit dem aus Hardwarearchitektur und SFF bestimmten SIL übereinstimmen.
(Bild: Quategra)

Unterscheidung nach Betriebsarten

Die eigentliche Sicherheitsfunktion ist hinsichtlich der Betriebsarten zu unterscheiden. Sie kann zum einen bei Betriebsart mit niedriger Anforderungsrate (PFD, Probability of Failure on Demand) und zum anderen bei Betriebsart mit hoher/kontinuierlicher Anforderungsrate (PFH Probability of dangerous Failure per Hour) gewährleistet werden. Dabei repräsentiert der PFD- oder PFH-Wert die gefährliche Versagenswahrscheinlichkeit.

Bild 12: Resultierende Formeln (ohne Herleitung) eines typischen 1002D Logik-System mit Sensor und Aktor sind (Randbedingungen nach IEC 16508-6)
Bild 12: Resultierende Formeln (ohne Herleitung) eines typischen 1002D Logik-System mit Sensor und Aktor sind (Randbedingungen nach IEC 16508-6)
(Bild: Quategra)

Diesen beiden Betriebsarten wird eine mittlere Wahrscheinlichkeit des Ausfalls der Sicherheitsfunktion infolge zufälliger Hardware-Fehler zugeordnet. Der PFD-Wert hat keine mathematische Einheit. Der PFH-Wert erhält die Einheit [1/h] und wird verwendet, wenn die Sicherheitskette dauerhaft und nicht nur auf Anforderung reagieren muss (z.B. kontinuierliches Abbremsen einer Gondel bei Talfahrt).

Zur Ermittlung von PFD- oder PFH-Werten, sind neben den ermittelten Ausfallraten weitere Einganggrößen zu beachten (Einsatzdauer, Prüfintervall, Reparaturdauer, β-Faktor, etc). Eine Möglichkeit der Berechnung ist das „Reliability Block Diagramm“ mit hergeleiteten Formeln zur Berechnung von PFD/PFH unter Einhaltung bestimmter Randbedingungen. Weitere Möglichkeiten ergeben sich durch geeignete mathematische Verfahren (z.B. Markov-Ketten). Weitergehend ist dies Thema in gängiger Literatur der Probabilistik zu finden.

Bild 9: Zyklus reparierbarer Systeme
Bild 9: Zyklus reparierbarer Systeme
(Bild: Quategra)

Mittlere Nutzungsdauer, mittlere Reparaturdauer, mittlere Lebensdauer

Weitere wichtige Kenngrößen eines sicherheitsgerichteten Systems sind die mittlere Nutzungsdauer MTBF (Mean Time Between Failures) und die mittlere Reparaturdauer MTTR (Mean Time To Repair). Das sind Zeiten, mit denen eine Aussage über die Verfügbarkeit einer Betrachtungseinheit getroffen werden kann. Die Nutzungsdauer MTBF setzt sich aus der mittleren Lebensdauer MTTF (Mean Time To Failure) und der mittleren Reparaturdauer zusammen: MTBF = MTTF+MTTR. Der Zusammenhang zwischen MTBF und der Ausfallrate λ ist MTBF = 1/ λ.

Das „Proof-Test-Interval“ bezeichnet eine vollständige Überprüfung des Systems, danach soll das System in einem Zustand „wie neu“ sein. Bei elektronischen Systemen ist dieses Intervall meist gleich der Einsatzdauer (Betriebszeitraum) des Gerätes, weil innerhalb des Einsatzes keine derartige Prüfung stattfindet. Die Einsatzdauer wird von Hersteller spezifiziert.

Bild 10: Beispiel 1oo2D-System
Bild 10: Beispiel 1oo2D-System
(Bild: Quategra)

Beispiel Hardwarearchitektur 1oo2D (1 out of 2 Diagnosis): Das 1oo2D-System besteht aus zwei parallelen Kanälen, die während des Betriebes die Sicherheitsfunktion anfordern, bevor sie ausgeführt werden kann. Sollten beide Kanäle eine Abweichung oder einen Fehler entdecken, so begibt sich der Ausgang in den sicheren Zustand. (Bild 10)

Bild 12: Resultierende Formeln (ohne Herleitung) eines typischen 1002D Logik-System mit Sensor und Aktor sind (Randbedingungen nach IEC 16508-6)
Bild 12: Resultierende Formeln (ohne Herleitung) eines typischen 1002D Logik-System mit Sensor und Aktor sind (Randbedingungen nach IEC 16508-6)
(Bild: Quategra)

Die Rate sicherer entdeckter Fehler für jeden Kanal ist hierbei gegeben durch Formel in Bild 11.

Bild 11: Beispiel: Formel für die Rate sicherer entdeckter Fehler für jeden Kanal  
Bild 11: Beispiel: Formel für die Rate sicherer entdeckter Fehler für jeden Kanal  
(Bild: Quategra)

Hierin stellen t´CE und t´GE so genannte Äquivalenzunklarzeiten dar. Während diesen kann keine Aussage getroffen werden, ob ein gefährlicher Fehler im Kanal vorliegt oder nicht. Im Prinzip sagen diese Zeiten aus, dass die Sicherheitsfunktion u.a. während der Reparaturzeit nicht verfügbar ist und demnach ein gefährlicher Fehler nicht erkannt werden kann.

Fehler im System beherrschen

Systematische (Entwurfs-) Fehler gilt es zu beherrschen. Dazu gehören, neben Designfehlern auch Bedienerfehler und Einflüsse der Umwelt wie Temperatur, Feuchte, Staub oder EMV. Wird ein Fehler des Systems durch z.B. eine Diagnosemaßnahme festgestellt, muss eine Reaktion erfolgen, die das System in den sicheren Zustand bringt. Was der sichere Zustand ist, muss vom Prozess abhängig festgelegt werden. Im einfachsten Fall ist es Abschalten, was bei einem einfachen Gasbrenner wesentlich besser funktioniert, als bei einem Flugzeug. Daraus ist ersichtlich, dass es durchaus Prozesse gibt, die keinen sicheren Zustand haben und dadurch besondere Betrachtungen verdienen.

Ausschnitt aus Tabelle A1 der IEC 61508-2. Ziel ist die Beherrschung von Ausfällen in Halbleiter Bauelementen für SIL 3
Ausschnitt aus Tabelle A1 der IEC 61508-2. Ziel ist die Beherrschung von Ausfällen in Halbleiter Bauelementen für SIL 3
(Bild: INTERNATIONAL ELECTROTECHNICAL COMMISSION)

Der Vermeidung und der Aufdeckung von Entwurfsfehlern wird insbesondere bei der Spezifikation des E/E/PES, den Tests und den Reviews inklusive der Begutachtung der funktionalen Sicherheit Rechnung getragen. Hinweise zu Maßnahmen in der E/E/PES sind ab Tabelle A.1 im zweiten Teil der IEC 61508 zu finden. Die Einhaltung der Forderungen aus den Tabellen ist entsprechend beim Systementwurf zu dokumentieren.

Ausschnitt aus Tabelle A3 der IEC 61508-2.
Ausschnitt aus Tabelle A3 der IEC 61508-2.
(Bild: INTERNATIONAL ELECTROTECHNICAL COMMISSION)

Will man Anwendungen für das industrielle Internet of Things sicher implementieren empfiehlt es sich, die Richtlinien zu befolgen, die in Tabelle A.3 - Elektronische Teilsysteme der IEC 61508-2:2010 zu finden sind. Dazu zählen insbesondere die folgenden Merkmale:

Überwachte Redundanz (vgl. A.2.5): Sicherheitsfunktion durch mindestens zwei Hardware-Kanäle.
Hardware mit automatischen Test (vgl. A.2.6): Hardware wird vor Anlauf des Prozesses zyklisch getestet
Analog-Signalüberwachung (vgl. A.2.7): Empfohlene Verwendung von analogen Signalen ermöglicht eine Toleranzüberwachung der Signalpegel

Fazit zu Teil 2 der IEC 61508

Hier kann nur der Einstieg in die Entwicklung sicherer Systeme nach der IEC 61508-Teil 2 gegeben werden. Es stellen sich hohe Anforderungen an die Dokumentation und das Management bei der Entwicklung sicherer Systeme. Währende der Entwickler sich mit der FTA oder FMEDA und der systematischen Bewertung der Elektronik mittels der Tabellen aus Teil 2 der Norm und deren Anhängen beschäftigt, kann darauf aufbauend die Berechnung der Ausfallwahrscheinlichkeiten (Probabalistik) des Systems erfolgen, für die es bei Einsatz einer gebräuchlichen Hardwarearchitektur unter bestimmten Randbedingungen anzuwendende Formeln gibt.

Software-Tools, die bei FTA oder FMEDA und der Probabalistik helfen, können, insbesondere bei komplexeren Hardwarearchitekturen, sinnvoll sein. Die SIL-Klassifizierung hängt nicht allein von der Ausfallwahrscheinlichkeit ab, es gehen ebenfalls Kenngrößen der Lebensdauer, der Reparaturzeit, Proof-Test-Intervall, Diagnosetestintervalle und einige mehr in die Berechnungen ein. Daher ist die Angabe des SIL mit PFD-/PFH-Wert allein nicht aussagekräftig.

Quellen:

[1] DIN EN 61508 Funktionale Sicherheit sicherheitsbezogener elektrischer, elektronischer, programmierbar elektronischer Systeme, Teil 1-7, November 2002
[2] Sicherheitstechnik für Komponenten und Systeme, Peter Wratil, Michael Kieviet, Hüthig Verlag 2007
[3] Elektronische Sicherheitssysteme, Josef Börcsök, Hüthig Verlag 2004
[4] Functonal Safety, A Straightforward Guide to IEC 61508 and Related Standard,David J Smith & Kenneth G L Simpson, Butterworth/Heinemann Verlag 2001
[5] Software Criticality Analysis, TÜV Süddeutschland, H.Spiess, 2000
[6] Einführung zur IEC 61508, TÜV Süddeutschland, TÜV Automotive GmbH, 2003
[7] IEC 61508 Teil 3; Sicherheitsgerichtete Softwareentwicklung, Olaf Winne, Design&Elektronik Forum „Sichere System“, 2004
[8] Modeling for Reliability Analysis, Jan Pukite und Paul Pukite, IEEE Press 1998
[9] Herleitung und Nachweis der SIL-3 Klassifizierung nach der Norm IEC 61508-2 für ein zweikanaliges Mikrocontrollersystem, HTWK Leipzig, Quategra Gmbh; Jens Kleemann, 2008

* Olaf C. Winne ist Geschäftsführer der Quategra GmbH, die auf die Entwicklung von hochwertigen Embedded-Systemen spezialisiert ist.

(ID:45381947)