Funktionale Sicherheit nach IEC61508

«Die Software tut, was sie soll.» Dieses Statement wird immer wieder als Argument in unterschiedlichen Kontexten verwendet. Es gibt jedoch trotz der Omnipräsenz von Softwaresystemen nach wie vor keine Möglichkeit zu beweisen, dass eine Software fehlerfrei funktioniert. Dies wäre insbesondere in sicherheitskritischen Anwendungen sehr praktisch und würde die Nachweisführung signifikant vereinfachen.

Um die Nachweisführung dennoch zu vereinfachen und gleichzeitig die funktionale Sicherheit sicher zu stellen, gibt es zahlreiche Normen.

Die Basisnorm der funktionalen Sicherheit ist die IEC 61508, von welcher verschiedene branchenspezifische Normen abgeleitet wurden.

Abbildung 1: Normenlandschaft funktionale Sicherheit (Auszug)

 

Safety und Security

Im Deutschen ist das Wort Sicherheit mehrdeutig. Um Missverständnisse vorzubeugen, werden häufig die englischen Begriffe Security und Safety verwendet.

Security bezieht sich auf die Gewährleistung der Vertraulichkeit von Daten eines Systems oder Personen. In erster Linie geht es also um den Schutz des Systems vor einem Individuum.

Safety hingegen bezieht sich nach IEC 61508 auf das akzeptierbare Risiko eines Systems im Bezug auf den Schutz von Gesundheit, Umwelt und des Systems selbst. Es geht also um den Schutz eines Individuums vor dem System.

Ist die Safety einmal umgesetzt, kann das System als funktional sicher betrachtet werden. Im Gegensatz dazu unterliegt die Security der Schnelllebigkeit der verwendeten Technologien. Bereits getroffene Massnahmen reichen unter Umständen nach einer gewissen Zeit nicht mehr aus.

In diesem Blog geht es um die funktionale Sicherheit (engl. functional safety), also um die Safety.

Warum braucht es funktionale Sicherheit?

Der Jungfernflug am 4. Juni 1996 der Ariane 5 Rakete fiel einem Softwarefehler zum Opfer. Der Bordcomputer entschied nach 37 Sekunden eine grosse Kurskorrektur. Durch die starken Kräfte des Luftwiderstands brach die Rakete schliesslich auseinander und löste in der Folge die in diesem Fall vorgesehene Selbstzerstörung aus.

Untersuchungen ergaben, dass der Code zur Kalibrierung der Trägheitsnavigationsplattformen vor dem Start fehlerhaft war. Dieser Code wurde blind von dem Vorgängermodell, der Ariane 4 übernommen und lief nach dem Start für 40 Sekunden weiter.

Für die Ariane 5 war dieses Weiterlaufen nicht nötig oder die Zeit deutlich zu lange bemessen. Da sie deutlich mehr Schub und Agilität aufwies als das Vorgängersystem, führte dies zu einem Überlauf in der Lageschätzung. Dadurch erhielt der Bordcomputer weder Sensordaten noch berechnete Lagedaten, sondern nur noch Diagnosedaten. Diese wurden vom Bordcomputer jedoch als normale Flugdaten interpretiert.

Es wurden also mehrere Fehler begangen, von denen jeder einzelne die Zerstörung verhindert hätte, wenn er nicht begangen wäre.

• Wären die Anforderungen an den übernommenen Code geprüft worden, wäre aufgefallen, dass das Weiterlaufen für 40 Sekunden nicht notwendig war.
• Wäre der Code nicht ungetestet übernommen worden, wäre während der Tests ein möglicher Überlauf entdeckt worden. Die Tests mit Ariane 5 Flugdaten wurden aus Kostengründen gestrichen.
• Wäre eine angemessene Ausnahmebehandlung für einen Überlauf vorhanden gewesen, wäre eine Weiterleitung der Lage- und Sensordaten gewährleistet gewesen.

Es ist also ersichtlich, dass bei einem auf funktionale Sicherheit ausgelegten Entwicklungsprozess dieser Fehler nicht unentdeckt geblieben wäre.

Hier setzt die IEC61508 an. Die Norm gibt einen Sicherheitslebenszyklus vor, welcher Vorgaben für den Entwicklungsprozess von Hard- und Softwareprodukten macht. Dadurch sollen Fehler, wie im Beispiel der Ariane 5, frühzeitig erkannt und eliminiert werden.

Die funktionale Sicherheit dient folglich dem Schutz von Menschen und Maschinen. Um diese Sicherheit zu quantifizieren, werden folgende Begriffe definiert:

• Sicherheit: Freiheit von unakzeptierbaren Risiken
• Risiko: Kombination von Auftretungswahrscheinlichkeit und Auswirkungsgrad eines Schadens
• Gefährdung: Potenzielle Schadensquelle

Das Ziel ist es, das Risiko bis auf ein akzeptierbares Niveau zu reduzieren.

Entwicklungsprozess nach IEC61508

Die Norm empfiehlt nachdrücklich die Entwicklung nach V-Modell. Als zentrales Element steht zu Beginn die Risikoanalyse. Von dieser ausgehend startet die Konzeptphase, gefolgt von der Realisierungsphase. Die Abbildung 2 stellt dabei die verschiedenen Stationen dar.

Zu sehen sind auch die Phasen nach der Entwicklung, namentlich Installation, Betrieb, Modifizierung und Ausmusterung, für welche die Norm ebenfalls Schritte vorgibt, die es zu beachten gilt.

Jede Phase im Detail zu betrachten, würde den Rahmen dieses Blogbeitrags sprengen. Aus diesem Grund liegt der Fokus des Blogbeitrags auf der Risikoanalyse sowie der Realisierung in Hard- und Software.

Abbildung 2: Entwicklungsprozess nach IEC61508

 

Risikoanalyse

Die IEC61508 definiert vier Sicherheits-Integritätslevel (SIL). Die Kategorisierung beschreibt das benötigte Level der Risikoreduzierung, wobei SIL1 die tiefste und SIL4 die höchste Risikoreduzierung angibt. Die Risiken werden mit der Risikoanalyse identifiziert, woraus der benötigte SIL abgeleitet wird.

Übrigens wird auch für nicht sicherheitskritische Anwendungen im Rahmen einer CE-Zulassung eine Risikoanalyse gefordert.

Zur Durchführung einer Risikoanalyse definiert die Norm in Teil 5 verschiedene Normen:

• Die ALARP-Methode (As Low As Reasonably Possible)
• Die quantitative Methode der SIL-Bestimmung
• Die Risikograph-Methode
• Analyse der Schutzebenen (LOPA: Layer Of Protection Analysis)
• Matrix des Ausmasses des gefährlichen Vorfalls

Jede Methode hat ihre eigenen Anwendungsbereiche und können einander ergänzen. Im Folgenden wird die Risikograph-Methode genauer erläutert, welche in diversen Projekten oft angewendet wird.

Die Risikograph-Methode

Diese Methode führt eine Anzahl von Parametern ein, die eine Gefährdung beschreiben können, wenn Sicherheitssysteme versagen oder nicht vorhanden sind.

C: Auswirkung des Vorfalls

F: Häufigkeit des Vorfalls

P: Möglichkeit, den Vorfall zu vermeiden

W: Wahrscheinlichkeit des unerwünschten Ereignisses

Die Klassifizierungen dazu können zum Beispiel wie folgt definiert werden:

Tabelle 1: Mögliche Klassifizierung der Risikograph-Parameter

Danach kann ein Risikograph gezeichnet und für eine Reihe an gefährlichen Vorfällen die Parameter klassifiziert werden. Es resultiert der geforderte SIL-Level, um das Risiko so weit zu reduzieren, damit das System funktional sicher betrieben werden kann.

Abbildung 3: Möglicher Risikograph zur Bestimmung des SIL

    ---     = keine Sicherheitsanforderungen
    1-4    = SIL
    X      = mehrere SIL4 Sicherheitsfunktionen sind nötig

 

Safety Funktion und Fehlertypen

Für die weitere Analyse und die Realisierung definiert die Norm einige zentrale Begriffe.

Eine Safety Funktion ist eine Funktion, die von einem System ausgeführt wird, um Risiken zu minimieren. Das Ziel ist es, einen sicheren Zustand für das System zu erreichen, wenn ein vordefiniertes gefährliches Ereignis in Betracht gezogen wird.

Eine Safety Funktion beinhaltet immer die folgenden Subsysteme:

• Einen oder mehrere Sensoren
• Eine Logik
• Einen oder mehrere Aktoren

Die Safety Funktion soll Fehler erkennen und das System in einen sicheren Zustand überführen. In diesem Zustand (Safe State) ist garantiert, dass das System keinen gefährlichen Vorfall verursacht. Je nach System und Safety Funktion kann es aber auch sein, dass es nicht mehr für den Normalbetrieb verfügbar ist und gewartet, repariert oder zurückgesetzt werden muss.

Die IEC61508 unterscheidet zwischen zwei Fehlertypen: zufällige und systematische Fehler.

Systematische Fehler treten aufgrund inkorrekten Designs auf. In der Hardware könnte dies zum Beispiel durch das Betreiben von Komponenten ausserhalb ihrer Spezifikation auftreten. In der Software liegt ein Codierfehler vor. Softwarefehler sind immer systematische Fehler. Systematische Fehler sollen mit einem guten Entwicklungsprozess und angemessenen Techniken und Massnahmen vermieden werden. Die Norm enthält dazu Empfehlungen und Vorgaben, welche Massnahmen in welchem Fall als angemessen betrachtet werden.

Zufällige Fehler treten trotz korrektem Design auf, können nicht vorausgesagt, jedoch statistisch beschrieben werden. Ein Beispiel wäre eine Komponente, die aufgrund der erreichten maximalen Betriebsdauer, einen Kurzschluss aufweist. Zufällige Fehler sollen zur Laufzeit beherrscht werden durch Redundanz, Diversifikation oder Selbsttests.

Es ist wichtig, sich gründlich Gedanken über mögliche Ausfälle und deren Auswirkungen zu machen. Ein Werkzeug dazu ist die FMEA (Failure Mode and Effect Analysis). Vereinfacht erklärt wird jede Komponente (Hard- und Software) auf mögliche Ausfälle untersucht und die Auswirkungen eines Ausfalls nach Schweregrad, Häufigkeit und Möglichkeit zur Detektion bewertet. Daraus erfolgt eine Tabelle, die eine Priorisierung der Ausfälle zulässt und aufzeigt, wo im System die wichtigsten Komponenten sind.

Realisierung

Bei der Umsetzung von Safety Funktionen bietet die IEC61508 zahlreiche Hilfsmittel, um angemessene Massnahmen auszuwählen. Dies sowohl für die Beherrschung von zufälligen Fehlern zur Laufzeit als auch für die Vermeidung von systematischen Fehlern während der Entwicklung.

Zufällige Fehler können zum Beispiel durch das Herabsetzen der Betriebswerte der Komponenten reduziert werden. Ist ein Widerstand für den Betrieb von 10A ausgelegt, so soll er trotzdem nur mit höchstens 6.5A betrieben werden. Dies schafft zum einen eine Sicherheitsmarge, um kurze Spitzenwerte abzufangen, zum anderen erhöht es die Betriebsdauer, da der Widerstand weniger heiss wird und somit weniger Verschleiss über die Zeit aufweist.

Eine andere Möglichkeit ist Komponenten redundant einzuführen. Ein Mehrheitsentscheider bestimmt, mit wieviel Toleranz sich die Werte der redundanten Pfade unterscheiden dürfen. Auch die Diversifizierung über mehrere Technologien, stellt eine gute Möglichkeit dar, zufällige Fehler zu erkennen und zu reduzieren.

Systematische Fehler werden durch einen robusten Prozess vermieden. Dazu gehört unter anderem ein strukturiertes Design, Modularisierung (Hard- und Software) und die Überprüfung durch Review und Tests. Auch das Schreiben von Anforderungen trägt einen grossen Teil dazu bei, dass Missverständnisse verhindert werden. Wenn eine Anforderung klar, präzise und unmissverständlich formuliert wird, so ist es für alle Beteiligten einfacher, ein gutes System zu entwickeln.

Die Norm gibt auch Massnahmen vor, um sicheren Code zu schreiben. Lesbarkeit, Testbarkeit, das Einhalten von Coding Guidelines (Konventionen, Struktur, Dokumentation) und Coding Rules (z.B. MISRA) und das Überprüfen dieser Einhaltung mittels automatisierten Analysetools sind nur eine Auswahl davon.

Beispiel: Lifttüren

In einem Beispiel sollen verschiedene Aspekte des Entwicklungsprozesses veranschaulicht werden. Es soll ein Sicherheitssystem für die Türen eines Lifts entwickelt werden. Initial wird davon ausgegangen, dass das System über keine Sicherheitsfunktionen verfügt. Wird der Knopf gedrückt öffnen sich die Türen.

SIL-Bestimmung mittels Risikograph

Es wird die in Kapitel "Die Risikograph-Methode" vorgestellte Risikograph-Methode angewendet.

1)    Gefährliche Vorfälle bestimmen

• Schachttür öffnet sich, obwohl die Kabine nicht da ist
• Lifttür klemmt eine Person ein
• Lift fährt mit offener Tür los

2)    C: Auswirkung eines Vorfalls

• Absturz und dadurch schwere Verletzung oder Tod einer Person -> C2

3)    F: Häufigkeit des Vorfalls

• Häufiges Ein- oder Aussteigen von Personen -> F2

4)    P: Möglichkeit, den Vorfall zu verhindern

• Beinahe unmöglich, wenn die Kabine in Bewegung ist -> P2

5)    W: Wahrscheinlichkeit

• Hohe Wahrscheinlichkeit -> W2

Wenn dem in Abbildung 3 dargestellten Risikographen entlang gefolgt wird, resultiert folgendes: Das Risiko ist nicht akzeptierbar und muss mit einer Safety Funktion mit SIL3 reduziert werden.

Design einer Safety Funktion

Eine einfache Safety Funktion für Lifttüren könnte eine Überwachung des Zustands der Türen darstellen. Ein Endanschlag gibt an, ob die Tür offen oder zu ist (Sensor), ein Mikrokontroller wertet die Daten vom Endanschlag aus (Logik) und verhindert durch das Blockieren der Kabine mit einem Bolzen (Aktor) das Losfahren.

Der Bolzen wird erst zurückgezogen, wenn der Endanschlag angibt, dass die Türen vollständig geschlossen sind. Dadurch wird ein Losfahren des Lifts mit geöffneten Türen verhindert.

Abbildung 4: Einfache Safety Funktion

 

Mit dieser Funktion wird jedoch nicht verhindert, dass sich die Schachttüren öffnen ohne vorhandene Kabine. Dafür müsste eine weitere Safety Funktion realisiert werden.

Zum Beispiel: Ein Näherungssensor detektiert die Anwesenheit der Kabine. Ein Mikrokontroller wertet die Sensordaten aus und gibt die Speisung der Türmotoren frei.

Wenn also die Steuerung der Türmotoren diese irrtümlicherweise öffnen möchte, kann sie das nicht, weil die Safety Funktion den Motoren die Spannung nicht freigibt.

Einfache FMEA für die Safety Funktion

Für die oben beschriebene Safety Funktion soll eine einfache Tabelle für den Endanschlag erstellt werden.

Tabelle 2: Stark vereinfachte FMEA für den Endanschlag

Der Schweregrad zeigt auf, dass ein Endanschlag, der immer eine geschlossene Tür meldet, viel gefährlicher ist als eine immer geöffnete Tür und deshalb höher zu priorisieren ist.

Diversifizierung für den Endanschlag

In der FMEA wurde für den Endanschlag eine gefährliche Ausfallart entdeckt. Durch die Verwendung von unterschiedlichen Technologien für die Zustandsmessung der Lifttür, wird das Risiko einer offenen Tür minimiert.

Abbildung 5: Safety Funktion mit Diversifizierung

 

Fazit

Wie die Geschichte zur Ariane 5 Rakete oder das fiktive Liftbeispiel zeigt, ist die funktionale Sicherheit in vielen Fällen von grosser Wichtigkeit für einen sicheren Umgang mit den Systemen. Die Entwicklung solcher Systeme ist nicht trivial, doch gibt es Hilfsmittel hierzu. Die Basisnorm IEC61508 liefert Struktur, Vorgehen und konkrete Massnahmen zur Minimierung der Risiken auf ein akzeptables Mass. Kenntnisse in diesem Bereich helfen direkt das geeignete Vorgehen und Massnahmen zu wählen und vereinfacht die Entwicklung.

Die CSA Engineering AG verfügt über dieses Know-How und die Erfahrung im Umgang mit der IEC61508 Norm sowie deren abgeleiteten Normen. Wir unterstützen Sie gerne bei der Konzeption, der Entwicklung oder Verifikation von sicheren Systemen, sei es in der Industrieautomation, der Medizin- oder Bahntechnik.