Der Begriff Funktionale Sicherheit besagt bereits, dass es hierbei um Systeme geht, die funktionieren müssen, da ein Ausfall zu Sicherheitsproblemen führen kann. Internationale Normen sorgen dafür, zu nachvollziehbar sicheren Geräten zu gelangen. Auch wenn Normen keine Gesetze darstellen, so werden sie doch vor Gericht als Referenz angesehen, um zu beurteilen, ob ein System nach dem aktuellen Stand der Wissenschaft und Technik gebaut wurde.
Es existiert mittlerweile allerdings eine große Anzahl an internationalen Normen. Entwicklern ist deshalb nicht immer bewusst, welche Regularien ihnen dadurch auferlegt werden und welche Normen sie überhaupt beachten müssen. Es gilt, dass marktspezifische Normen Vorrang gegenüber generischen Normen haben. Im industriellen Umfeld stellt die IEC 61508 die Basisnorm dar, nach deren Vorbild eine Vielzahl von spezifischen Normen entwickelt wurde. Trotzdem steht diese Basisnorm auch für sich alleine und sollte zur Anwendung gelangen, wenn es keine spezifische Norm gibt.
Keine 100-prozentige Sicherheit möglich
Im Zentrum der Basisnorm steht ein definierter Lebenszyklus von Systemen, unterteilt in mehrere Phasen, die jeweils mit entsprechenden Anforderungen versehen sind. Außerdem gibt sie definierte Artefakte vor, die bei Einhaltung der Norm erstellt werden müssen. Dabei umfasst der Lebenszyklus die „Geburt“ des Systems durch ein entsprechendes Konzept bis hin zum „Tod“, sprich der Außerbetriebnahme oder Stilllegung.
Ein weiteres zentrales Instrument ist das Bewerten der Sicherheit über Risiken und das eventuelle Senken des Risikos auf ein „sozial verträgliches Niveau”. Dazu werden zunächst alle möglichen Gefahren, die von dem System ausgehen können, analysiert und anschließend das Risiko bewertet. Dieses ergibt sich als Produkt aus Wahrscheinlichkeit des Eintretens der Gefahr und der Schwere der resultierenden Verletzungen. Je stärker ein Risiko gesenkt werden muss, umso höher sind die Anforderungen, die die Norm an sicherheitsrelevante Systeme stellt. Die Anforderungen werden dabei in sogenannte Integritätslevel eingeordnet. Die IEC 61508 benennt vier Level, SIL 1 bis 4 genannt, wobei letzteres die höchsten Anforderungen nach sich zieht. Die Norm erkennt an, dass es keine hundertprozentige Sicherheit gibt. Doch gibt sie über die Integritätslevel an, welche Maßnahmen zu treffen sind, damit die sicherheitsrelevanten Funktionen auch ordnungsgemäß funktionieren.
Grundsätzlich geht es in der Norm um das Vermeiden von Fehlern. Dazu ist es notwendig, sich mit unterschiedlichen Fehlerklassen auseinanderzusetzen. Als oberstes Unterscheidungsmerkmal wird zwischen zufälligen (random) und systematischen Fehlern unterschieden. Die zufälligen Fehler, beispielsweise der Ausfall eines Bauteils, werden vereinfacht auch gerne als Hardwarefehler bezeichnet. Diese lassen sich nicht wirklich vorhersehen oder verhindern, sondern nur deren Auftreten über geeignete Bauteilauswahl und Systemdesignmaßnahmen verringern. Im Gegensatz dazu können systematische Fehler, also von Menschen verursachte, eingedämmt werden, indem strukturiert und nach Prozessen gearbeitet wird. Dafür sind entsprechend hohe Anforderungen notwendig an die Dokumentation, das Management und die Verifikation in allen Phasen des Lebenszyklus. Häufig wird von Ingenieuren nur der damit verbundene hohe Aufwand gesehen und der eigentliche Grund und Nutzen darüber leider vergessen.
Die Dokumentation - das Herzstück
Aber die Norm stellt nicht nur Anforderungen, sie fordert auch, dass der Anwender selbst welche definiert. Für jede sicherheitsrelevante Funktion müssen Anforderungen an die Funktion an sich sowie an die Integrität der Funktion dokumentiert und umgesetzt werden. Gemäß den zwei Basisfehlerklassen lassen sich Anforderungen an die Hardwareintegrität und systematische Integrität unterscheiden, die allerdings wieder aus der Norm heraus definiert und in Abhängigkeit des notwendigen SIL sind. Für den eigentlichen Systementwurf spielen neben den Anforderungen an die systematische und Hardwareintegrität auch Anforderungen hinsichtlich der Behandlung von erkannten Fehlern und der Datenkommunikation eine Rolle.
Für die Hardwareintegrität kommen schließlich zwei Gruppen von Forderungen ins Spiel: Einerseits ist das die Einhaltung von Vorgaben für zufällige Hardwarefehler, zusätzlich aber auch die Einhaltung von architektonischen Einschränkungen. Letzteres kann man über zwei sogenannte Pfade beziehungsweise Routen, bezeichnet als 1H oder 2H, erreichen. Die Route 2H bezieht sich auf bereits betriebsbewährte Architekturen, für die aber zusätzlich Forderungen an Minimalwerte der sogenannten Hardware Fault Tolerance (HFT) gestellt werden. Route 1H bedeutet letztlich, dass gemäß der Norm entwickelt und der Nachweis für zwei Maße geführt wird, nämlich für die HFT und die Safe Failure Fraction (SFF). Deren Werte müssen je nach zu erfüllendem SIL eingehalten werden.
Software-Tools validieren ist essentiell
Ähnliches gilt für die systematische Integrität, deren Einhaltung sich über das Folgen von drei unterschiedlichen Routen, 1S, 2S oder 3S genannt, umsetzen lässt. Route 1S bedeutet das Entwickeln gemäß der Norm, Route 2S bezieht sich auf die Betriebsbewährtheit und Route 3S gilt für den Einsatz von vorgefertigter Software, die allerdings nicht nach Norm entwickelt wurde. Wenn funktionale Sicherheit auf programmierbaren Geräten über Software sichergestellt werden soll, gelten weitere Maßnahmen, die sich je nach gefordertem SIL unterscheiden. Da es allerdings keine zufälligen Fehler in Software gibt, zielen die Maßnahmen auf das Verhindern von systematischen Fehlern ab. Die Integrität der Software soll also durch strukturierte und zielgerichtete Methoden und Techniken erreicht werden.
Für Ingenieure, die bereits strukturiert und prozessorientiert Software entwickeln und somit allgemein anerkannte Software-Engineering-Praktiken anwenden, stellt das normalerweise kein Problem dar. Der zusätzliche Aufwand hält sich in diesem Fall in Grenzen. Das Erstellen einer Software-Architektur sowie das Software- und Modul-Design zählen ebenfalls zu den Best Practices. Neu ist allerdings oft die Notwendigkeit, sich auch die Software-Tools näher anzusehen, mithilfe derer Software realisiert wird. Je nach potentiellen Auswirkungen von Fehlern dieser Tools sind Validierungen durchzuführen, um sicherzustellen, dass über die Verwendung der Tools keine erhöhten Ausfallraten der Safety-relevanten Softwarefunktionen zu erwarten sind.
Verifikation und Validierung durch entsprechende Tests sind essentiell. Da Software häufig verändert wird, besteht die Notwendigkeit, solche Veränderungen über einen eigens dafür definierten Prozess in die Softwareentwicklung einfließen zu lassen. Dieser Prozess kann selbst definiert werden. Er muss aber zum Beispiel sicherstellen, dass nur freigegebene Änderungsanforderungen auch tatsächlich umgesetzt werden und über eine Impact-Analyse festgestellt wird, welche Phasen des Lebenszyklus von solchen Änderungen betroffen sind. Nur so lässt sich sicherstellen, dass das System als Ganzes weiterhin sicher entwickelt wird.
Funktionale Sicherheit erreichen Entwickler über weite Strecken, indem sie Best Practices anwenden und Anforderungen aus den Normen auf strukturierte Art umsetzen. Sich in Normen einzulesen ist keine einfache Sache. Man verliert schnell den Überblick über das große Ganze und auch die Ausdrucksweise der Normentexte lässt keine einfache Lesart zu. Ein kompaktes Training zu den wichtigsten Punkten ermöglicht eine effiziente Einarbeitung und Umsetzung.
