Funktionale Sicherheit pragmatisch einfach erklärt

Es ist eigentlich unmöglich, die Funktionale Sicherheit einfach zu erklären. Der pragmatische Ansatz der Erklärung ist bereits beim Umfang der Thematik zum Scheitern verurteilt. Dennoch hat der folgende Inhalt zum Ziel, die wesentlichen Elemente im Querschnitt aller Normen herauszuarbeiten und einen ersten Überblick zu geben. Die Funktionale Sicherheit pragmatisch einfach zu erklären ist in einem Webinar oder Youtube-Video sicherlich einfacher und erträglicher aufnehmbar als eine Text-Version. Nehmen Sie sich die Zeit, Sie werden den roten Faden finden und Ihr Wissen aufbauen können – Stück für Stück.

Was ist Funktionale Sicherheit eigentlich ?

Funktionale Sicherheit, kurz FuSi oder FuSa (engl.) ist eine Art Produkteigenschaft welche mit umfangreichen Analysetätigkeiten und deren Dokumentation während der Entwicklung einhergeht. Funktionale Sicherheit wird nach der generischen Sicherheitsgrundnorm und in der Norm für den Automobilsektor wie folgt definiert:

Angelehnt an IEC 61508-Teil 4 bezeichnet Funktionale Sicherheit den wesentlichen Teil der Gesamtsicherheit eines Systems, der von der korrekten
Funktion des sicherheitsbezogenen E/E/PE-Systems und anderer risikomindernder Maßnahmen abhängt.

Angelehnt an ISO 26262-Teil 1 ist Funktionale Sicherheit die Fähigkeit eines elektrischen, elektronischen, programmierbar elektronischen Systems (E/E-System), beim Auftreten systematischer Ausfälle (z.B. fehlerhafte Systemauslegung) sowie zufälliger Hardwareausfälle (z.B. Alterung von Bauteilen) mit gefahrbringender Wirkung, einen wohl definierten sicheren Zustand einzunehmen bzw. in einem sicheren Zustand zu verharren.

Grundsätzlich können von einem System, Subsystem, einer Maschine, einem Aggregat, einem Bauteil, einer Software oder einer Hardware Fehlfunktionen ausgehen. Einige dieser Fehlfunktionen können zur Beeinträchtigung einer sicherheitsrelevanten Funktion bis zu einen gefahrbringenden Ausfall führen. Abstrakt handelt es sich um eine Abweichung von Funktionsparametern in den Dimensionen Zeit, Raum oder Wertebereich. Zum Beispiel hervorgerufen durch:

• eine zu große/kleine Drehzahl, welche zu früh/spät erkannt wird oder
• eine oszillierende Aktorik, welche zur destruktiven Resonanz führt oder
• ein zu spät eingeleitete Systemabschaltung oder
• keine Systemabschaltung oder
• Systemabschaltung, obwohl es zu keiner kommen darf oder
• eine falsche Berechnung oder
• ein korrupter Datensatz (z.B. Konstante, Referenzwert…)

Nicht jede Abweichung zur Normalfunktion ist eine potenzielle gefahrbringende Fehlerquelle. Der Mensch selbst kann als Fehlerquelle übrigens auch in Frage kommen oder die Maschine hat prozesstechnische Gefährdungsquellen. Es kommt auch auf die Systemcharakteristik bzw. den erreichbaren und haltbaren sicheren Systemzustand an. Eine Abschaltung von Triebwerken bei einem Flugzeug kann nicht direkt zu einen sicheren Zustand führen, wenn sich das Flugzeug in der Luft befindet. Im Gegensatz zum Flugzeug kann eine Abschaltung eines Elektromotors in einem E-Fahrzeug noch als tolerierbarer Zustand interpretiert werden. Funktionale Sicherheit ist nicht zu verwechseln mit elektrischer Sicherheit, Brandschutz oder Kontruktionselemente.

Folglich ist die Funktionale Sicherheit eine für den Kunden/Anwender/Endverbraucher i.d.R. nicht direkt geforderte funktionale Systemeigenschaft, sondern eine dem allgemeinen gesellschaftlichen und rechtlichen Sicherheits- und Qualitätsverständnis zugrundeliegende Systemeigenschaft, welche quasi der „System-Normalfunktion“ (bestimmungsgemäße Funktion) ergänzend hinzugefügt werden sollte. Dabei ist im Maschinenbau vorab zu trennen zwischen dem EUC = Equipment Under Control, also die Maschine, welche zusammen mit der Maschinensteuerung die „Normalfunktion“  ausführt und den dazu passend zu entwicklenden sicherheitsrelevanten Teilsystem, dem SRP = safety related part, welches die Normalfunktion zu einer sicheren Funktion ergänzt und eine Risikominderung im Hinblick auf eine identifizierte Gefährdung darstellt.

Systemcharakteristik (Fail-Safe / Fail-Operational) bestimmt Aufwände

Wie dieses sicherheitsrelevante Teilsystem beschaffen sein muss, ist von vielen Faktoren (z.B. Technologie, SIL …) abhängig und muss individuell durch systematische Analyse(n) der Normalfunktion entworfen werden. Oft kann eine grobe Klassifikation der sicherheitskritischen Systeme in Fail-Safe und Fail-Operational erfolgen. Fail-Safe bedeutet Sicherheit durch Deaktivierung der bestimmungsgemäßen Funktion. Fail-Operational bedeutet Sicherheit durch Erhalt der bestimmungsgemäßen Funktion. Damit wird deutlich, dass die Funktionale Sicherheit bei Fail-Safe-Systemen die Verfügbarkeit der bestimmungsgemäßen Funktion einschränkt. Im Allgemeinen sind Sicherheitsziele zu definieren. Bei einer Industrieanlage kann dies der Schutz eines Reaktors sein, bei einer Lenkung im Fahrzeug kann dies die Verhinderung eines Fehllenkens sein, bei einer Maschine die Anwesenheitserkennung einer Person in einen überwachten Gefahrenbereich sein oder beim Flugzeug kann es der Erhalt der steuerbaren Turbinenvorschubkraft sein.

Funktionale Sicherheit ist kurz gesagt, eine Identifikation der Gefahrenquellen, eine Beurteilung der Gefährdung und die Risikominderung durch eine Implementierung einer geeigneten Sicherheitsfunktion (SF) mit ausreichend Integrität durch aktive Vermeidung systematischer Fehler im Entwicklungsprozess und die Quantifizierung der Ausfallwahrscheinlichkeit der Komponenten.

Hat das System Schnittstellen zur Kommunikation, so ist auch das Thema „Security“ für die Erhaltung der Integrität relevant. Dies ist jedoch über andere Standards z.B. zur IT Sicherheit ausserhalb der Funktionalen Sicherheit zu gewährleisten. Man merke, Functional Safety (Funktionale Sicherheit) ist nicht Security.

Hier sei angemerkt, dass der Begriff „Normalfunktion“ hier nur der Erklärung dienlich ist und nicht mit den Safety-Standards in Beziehung steht. Im Automotive-Bereich ist es vergleichbar mit der „Item-Definition“. Im Maschinenbereich ist dies die bestimmungsgemäße Funktion.

Warum wird Funktionale Sicherheit angewandt ?

Im Grunde ist die Anwendung der FuSi rechtlich begründet. Der Ursprung dieser rechtlichen Grundlagen sind Katastophen wie Seveso (Industrieanlage in Italien mit Störfall (Dioxin wurde freigesetzt)), Zugunfälle, Atomstörfälle, Flugzeugabstürze. Aufsichtsbehörden sind oft beteiligt an der Entstehung dieser Normen. Teils wird auch die Funktionale Sicherheit als Markteintrittsbarriere wahrgenommen. Imageschäden aus Sicherheitsvorfällen mit Absatzschäden sensibilisiert die Industrie zur Normungsmitarbeit und Anwendung. Die Anwendung wird daher primär zu Vermeidung von Schäden durch fehlerhafte Produkte und die Haftungsfrage getrieben. Ausgehend von der europäischen Ebene finden sich im Rahmen der Rechtsvorschriften zum Inverkehrbringen oder Bereitstellen von Produkten auf dem europäischen Binnenmarkt z.B. folgende Richtlinien für die Artikel 95 (Freier Warenverkehr) und 137 (Arbeitsschutz) des EG-Vertrages:

• über die allgemeine Produktsicherheit 2001/95/EG
• für elektrische Betriebsmittel zur Verwendung innerhalb bestimmter Spannungsgrenzen – Niederspannungsrichtlinie (NRL) – 2014/35/EU
• über Maschinen (MRL) 2006/42/EG (bald abgelöst durch die Maschinenverordnung)
  
• für aktive implantierbare medizinische Geräte 90/385/EWG
• über Medizinprodukte 93/42/EWG
• über die Benutzung von Arbeitsmitteln – Arbeitsschutz-Rahmenrichtlinie– 89/391/EWG
• zur Beherrschung der Gefahren schwerer Unfälle mit gefährlichen Stoffen – Seveso III oder auch Störfallrichtlinie – 2012/18/EU

Richtlinien werden i.d.R. über nationale Gesetze in geltendes Recht im jeweiligen Mitgliedsstaat umgesetzt. Neben den Richtlinien sind EU-Verordnungen unmittelbar bindend, ohne nationale Gesetzentwürfe. Die Medizingeräterichtline wird seit 2017 durch die Verordnung (EU) 2017/745 Medical Device Regulation (MDR) in den nächsten Jahren die alten Richtlinien (93/42/EWG und 90/385/EWG) ablösen.

Die Produkthaftung ist in der Bundesrepublik Deutschland nach dem Produkhaftungsgesetz (ProdHaftG) geregelt und wird durch das Produktsicherheitsgesetz (ProdSG) ergänzt, welches wiederum nationales Recht nach der Richtlinie 2001/95/EG darstellt. Das ProdSG stellt Anforderungen an die Produktsicherheit, um die Sicherheit und Gesundheit von Personen bei Verwendung der Produkte zu gewährleisten. Mit Verweis auf Standards und harmonisierte Normen in § 4 ProdSG schließt sich der Kreis zur weiteren Richtlinien wie z.B. der Maschinenrichtlinie oder auch bald der 9. Verordnung (Maschinenverordnung).

Funktionale Sicherheit – eine notwendige Produkt- oder Systemeigenschaft

Funktionale Sicherheit kann daher als grundlegende Eigenschaft eines sicheren Produktes interpretiert werden. Die zivilrechtliche Haftung (Schadenersatz für Sachschäden) des Produzenten (z.B. Hersteller/Firma/Inverkehrbringer) nach §823 Abs. 1 BGB kann schuldunabhängig nur durch eine Beweislastumkehr vermieden werden. Die Abwehr der Schuldfrage vor Gericht kann nur durch einen Nachweis der Entwicklung nach dem „Standard der Technik“ gelingen, welche durch Standards, Richtlinien und Normen definiert wird. Strafrechtlich ist die Haftung für einen Personenschaden mit einer Geld- oder Freiheitsstrafe für Unternehmen, Management (kollektiv) und einzelne Mitarbeiter (insb. Führungskräfte) im Schadenfall möglich. Nur durch den Nachweis der Einhaltung von Normen und Sicherheitsstandards nach dem Stand der Technik kann der Versuch zur Abwehr eines Haftungsfalls erfolgreich sein. Der Produktmanager oder FuSi-Manager kann zu Schadenersatz im Außenverhältnis belangt werden.

Es finden sich historisch bedingt durch Unfälle und Katastrophen sektorspezifische Ausprägungen der Funktionalen Sicherheit. Meist ist auch eine Kontrollinstanz z.B. ein „certified body“ oder eine Zulassungsbehörde wie das Eisenbahnbundesamt oder das Kraftfahrtbundesamt oder die Flugsicherheitsbehörde eingerichtet. Diese Instanzen prüfen und bestätigen oder beurteilen die angewandte Funktionale Sicherheit in Assessments/Audits und Gutachten oder Baumusterbescheinigungen. Die Anwendung der Normen zur Funktionalen Sicherheit ist jedoch i.d.R. freiwillig. Eine Zertifizierung und/oder Anwendung befreit nicht von der Produkthaftung, kann jedoch mindernd wirken im Haftungsfall.

Alle Aussagen zum Recht sind unverbindliche Informationen. Bitte konsultieren Sie in Rechtsfragen und Haftungsfragen einen spezialisierten Anwalt.

Welche Aufwände sind grundsätzlich notwendig ?

Es kommt auf den zugrunde liegenden Standard (Norm) und die erforderliche Risikoreduktion an, also auf den Sicherheitsintegritätslevel (SIL). Im Kern sind systematische Fehler während der Entwicklung zu vermeiden durch Anwendung von Methoden und Prozessstrukturen (z.B. Reviews) sowie geprüfte Werkzeuge und Werkzeugketten. Das Safety-Management überwacht dies. Weiterhin ist eine umfangreiche lückenlose revisionssichere Dokumentation zu erstellen, um die Nachweisführung (Compliance) zu ermöglichen. Projektspezifisch ist die Beherrschung von zufälligen Hardwarefehlern im Systemdesign und die Einhaltung der Ausfallwahrscheinlichkeit nachzuweisen durch Analysen.

Insbesondere bestimmt die Technologie und die Systemkomplexität maßgeblich die Aufwände. Komplexe Systeme haben vielfältige Fehlerursachen/Fehlermöglichkeiten. Die Entwicklungsaufwände für sicherheitskritische Systeme skalieren also risikobasiert und proportional zur Systemkomplexität. Einfach ausgedrückt, wenn ein System einfach aufgebaut ist mit geringen Gefährdungspotenzial und daher nur leichte oder mittelschwere Verletzungen von einem Menschen zu erwarten sind, ist der Entwicklungsaufwand gering (SIL 1-2). Wenn jedoch intelligente Machinen oder Fahrzeuge bei Fehlfunktionen Quetschungen mit Todesfolge einer oder mehrerer Personen bedingen, ist der Entwicklungsaufwand größer (SIL 3 bis 4).

Der Sicherheits-Integritätslevel gibt die Anforderungen an die Wirksamkeit von Sicherheitsmaßnahmen vor. Die Technologie, die systematische Eignung der Komponenten und die Wirksamkeit der Sicherheitsmaßnahmen müssen auf den Anwendungsfall spezifisch beurteilt und in der Konzeptphase mit Bedacht und Erfahrung ausgewählt werden. Komplexe Systeme erfordern komplexe Analysemethoden. All dies ist eine anspruchsvolle Aufgabe für alle Beteiligte. Sind die Grundvoraussetzungen wie ein Qualitätsmanagement und ein Safety Management vorhanden, kann mit mindestens 50% Mehraufwand gerechnet werden. Die Firmen-Sicherheitskultur beeinflusst auch die Aufwände des Safety Managements zu den Maßnahmen zur Vermeidung von systematischen Fehlern in der Entwicklungsphase. Weiterhin ist der Lebenszyklus vollständig bereits in der Konzeptphase zu berücksichtigen.

Meisst wird pragmatisch versucht, bereits entwickelte Systeme im Nachgang den Anforderungen der jeweiligen Standards anzupassen. Dazu wird dann eine schnelle Schulung gemacht, dann kurzfristig das eine oder andere Dokument erstellt, hier noch ein Test, dort noch eine andere Schaltung oder eine Modifikation in der Architektur durchgeführt mit bösem Erwachen bei Projektende oder im Assessment oder im Haftungsfall.

Ich rate dringend davon ab, einfach eine Schulung zu besuchen oder zu spät das Thema „FuSi“ als Randthema anzugehen oder gänzlich auszulagern.

Nur durch einen ganzheitlichen, interdisziplinären und integrativen Ansatz, kann kostengünstig eine Übereinstimmung mit den normativen Anforderungen erreicht werden.

Wie gehe ich das Thema Funktionale Sicherheit (FuSi) richtig an ?

Wenn Sie ein gelebtes, also in der Firmenkultur verankertes Qualitätsmanagementsystem nach ISO 9001 haben, ist ein SIL 2 relativ leicht mit etwas Zusatzaufwand und Coaching sowie Weiterbildung erreichbar. Ein SIL 3 bis 4 wird ohne Erfahrung und Methodenkompetenz nicht so einfach erreichbar sein. Daher ist ein interdisziplinäres Entwicklungsteam mit einem Systemarchitekten, welcher den Überblick behält, bereits eine Grundvoraussetzung.

Falsch ist die Vorstellung, dass FuSi im Nachgang durch eine Zertifizierung, durch das Hinzufügen einer „Not-Aus“ Funktion, einer Plausibilisierungsfunktion oder einen Testnachweis oder ein bzw. mehrere im Nachgang erstellte Dokumente erreicht werden kann.

Zuerst sollten Sie das System funktional vollständig mit seiner Umwelt, seinen funktionalen Parametern und seinen Betriebsarten zu beschreiben. Dabei keine technischen Details zur Implementierung wie µC oder CAN-Kommunikationskanal betrachten. Dies kann bereits herausfordernd sein und sogar unmöglich für einen im Detail versunkenden Spezialisten. Abstrakte Modellierungssprachen wie SysML sind nutzlich und Stand der Technik.

Welcher Standard oder welche Norm ist anzuwenden ?

Wenn eine funktionale Beschreibung vorliegt, ist die Frage nach dem möglichen Standard oder der Norm für die Funktionale Sicherheit nicht immer leicht beantwortbar. Generell ist vorab auf europäischer Ebene zu prüfen, ob eine harmonisierte Norm existiert. Dazu ist folgende Seite empfehlenswert: http://ec.europa.eu/growth/single-market/ce-marking/manufacturers/.

Für eine Maschine gilt die Maschinenrichtlinie und damit z.B.:

• die harmonisierte ISO13849, sofern die Maschine nicht unter eine harmonisierte C-Norm fällt für maschinenspezifische Sicherheitsnormen oder
• die harmonisierte IEC62061, sofern es sich um eine sicherheitsrelevante Steuerung für Maschinen handelt.

Für andere Branchen gelten z.B. folgende Normen für:

• Medizingeräte gilt für die Risikoabschätzung die ISO 14971, für die Softwareentwicklung neben der IEC 60601 auch die IEC 62304, für die Hardware die IEC 60601
• Industrieanlagen im Bereich der Prozessindustrie gilt die IEC61511.
• Feuerungsanlagen gilt z.B. die IEC 50156
• Bahnanwendungen (Railway) gelten z.B. EN 50125, 50126, 50128, 50129 oder auch 50159
• die Luftfahrt (Avionic) gelten z.B. DO178B/C/ED-12C oder DO254/ED-80
• Atomkraftwerke gilt z.B. die IEC 60880
• Fahrzeuge (Automotive) gilt die ISO26262 oder auch speziell für erdbewegende Maschinen die ISO 19014

Allgemein sind viele Normen von der Sicherheitsgrundnorm IEC 61508 abgeleitet und nach dem europaweiten ABC Ansatz wie folgt gegliedert:

Haben Sie Ihren Sektor-Standard gefunden oder eine harmonisierte Sektornorm zur Funktionalen Sicherheit, so sind abgesehen von branchenspezifischen Besonderheiten in der Regel mögliche Gefahren zu analysieren und eine Risikoabschätzung ist vorzunehmen. Für C-Standards ist diese bereits i.d.R. inkludiert. Damit reduziert sich der Aufwand für die allgemeine Risikobeurteilung erheblich. Sofern Sie keine harmonisierte C oder B Standards finden, es sich jedoch um eine Anwendung im Maschinenumfeld handelt, gilt die Maschinenrichtlinie. Dann benötigen Sie höchstwahrscheinlich einen „certified body“, welcher Ihnen die Übereinstimmung zur Machinenrichtlinie bescheinigen müsste. Dieser wird auf die nicht harmonisierte Sicherheitsgrundnorm IEC 61508 verweisen, welche Sie zur Anwendung bringen müssten. Dieses Vorgehen gleicht dem „Tailoring der IEC 61508“. Der Innovator wird damit quasi zum Normenschreiber seiner Innovation. Maschinenbauer finden den Einstieg über eine der 23 Kategorien im Anhang IV (2006/42/EC, Annex IV) der Maschinenrichtlinie. Im Video „Functional Safety Basics – MRL and RFU – Secret #1“ findet sich hierzu noch ein Geheimtipp.

Die Gefahrenanalyse (G&R oder HAZOP) gibt das Kritikalitätslevel vor

Oft wird aus Unwissenheit einer Sicherheitsfunktion ein SIL zugewiesen, ohne genaue Analyse der vorhandenen oder potenziellen Gefahren und Risiken durch eine Gefahren- und Risikoanalyse (G&R). Meistens wird dieser systematische Suche nach Gefahrenquellen wenig Bedeutung zugesprochen mit fatalen Konsequenzen für die Sicherheit und dem Projekterfolg durch unnötigen Kosten durch „Over-Engineering“ oder fehlerhafte oder unvollständige Top-Level-Spezifikation. Eine vollständig beschrieben bestimmungsgemäße Funktion bildet die Grundlage dieser Analyse. Je nach Komplexität, Umwelt, Betriebsarten und Interaktionsmöglichkeiten kann diese Analyse sehr umfangreich werden. Oft sind mehrere Iterationen notwendig. Gerade das Hinzufügen einer Sicherheitsfunktion zur bestimmungsgemäßen Funktion kann zu neuen Gefahrenquellen führen.

In der Prozesstechnik wird auch von der HAZOP, Hazard and Operability gesprochen. Ein Hazard wird als Gefährdung, als potenzielle Schadensquelle bezeichnet. Eine Gefährdung kann zu einen Schaden (Gesundheit, Verletzung, Material, Umwelt) führen. Systematisch werden Gefährdungssituationen ermittelt und bewertet. Dabei sind die folgenden Leitwörter auf eine Sollfunktion anzuwenden, mögliche Ursachen für diese Parameterabweichungen zu identifizieren und Gegenmaßnahmen wie z.B. Sicherheitsfunktionen zu spezifizieren.

Leitwörter:

• nicht / nein
• mehr oder weniger
• sowohl als auch
• teilweise
• Umkehrung oder
• anders als

Die G&R oder HAZOP bildet gleichzeitig die Top-Level-Spezifikation der Sicherheitsfunktion. Was würde eine Füllstandsbegrenzung nützen, wenn die Reaktion zu spät oder nur eine bestimmte Art von Füllmedien (dampflos) reagiert ? Der höchste Schaden in einer potenziell häufig auftretenden schwer kontrollierbaren Situation bildet die Referenz für die Sicherheitsintegritätsstufe für das zu entwickelnde System. Im Rahmen der Validierung steht am Ende der Produktentwicklung die G&R/HAZOP auf dem Prüfstand. Meist wird ein Review und Assessment in dieser Phase durch eine externe und unabhängige Instanz durchgeführt.

Eine FMEA (Fehlermöglichkeits- und Einflussanalyse) kann auch angewendet werden. Wichtig ist bei dieser Methode auf dieser Ebene im „Konzeptstadium“, dass der Funktionsansatz, also die vollständig beschrieben Funktion in eine Menge an Teilfunktionen zerlegt werden kann, welches ein Mittelmaß an Komplexität und Betrachtungsdetail bietet. Neben der Funktionen ist bei dieser Analyse die Abgrenzung des Untersuchungsgegenstandes bedeutsam. Teilweise ist die „nahe Umwelt“ der betrachteten Funktion zu beschrieben und dann auch zu analysieren.

Ein guter Einstieg in die Welt der Risikobeurteilung ist die folgende Norm:

ISO 12100 Sicherheit von Maschinen – Allgemeine Gestaltungsleitsätze – Risikobeurteilung und Risikominderung

Die Kritikalitätslevel und die Ausfallwahrscheinlichkeit

Je kritischer die Folge eines Fehlers desto hoher das Kritikalitätslevel, auch Sicherheitsintegritätslevel (SIL) genannt. Ausgehend von der Sicherheitsgrundnorm mit dem SIL sind in den verschiedenen Sektoren und Normen unterschiedliche Bezeichnungen für das Kritikalitätslevel (SIL, SILCL, PL, ASIL, DAL) vorhanden. Im Allgemeinen werden diese Level anhand von qualitativen Risikographen als diskrete Funktion verschiedener Parameter wie die Kontrollierbarkeit/Beherrschbarkeit, Schadensschwere und Häufigkeit der Situation in einer Gefahren- und Risikoanalyse ermittelt. Jedes Level gibt Sollwertbereiche der Ausfallwahrscheinlichkeit (PFH) vor und bestimmt damit die Entwicklungsaufwände.

Hier ein Querschnittsvergleich der Kritikalitätslevel:

Die Wahrscheinlichkeit eines gefährlichen Ausfalls pro Stunde ist in der Tabelle in englischer Schreibweise PFH angegeben. Dabei hat die Funktionale Sicherheit ihre eigene „Einheit“:

1 FIT = 1 Failure in Time = 1 gefahrbringender Ausfall in 10^-9 Betriebsstunden bzw. 114.155 Jahren, 1/10^9h

Bei SIL 4 liegt also die Ausfallwahrscheinlichkeit bei 1:100.000.000 !!!. Eine Lenkung im Fahrzeug wird in ASIL D, also nahe SIL 4 eingestuft, eine Tür im Zug mit SIL 2, ein Autopilot im Flugzeug während Start und Landung ist mit DAL-A, also besser SIL 4 eingestuft. Ein Airbag wird in ASIL B eingestuft.

Je höher die Kritikalität, also der Sicherheitsintegritätslevel, desto geringer muss die Ausfallwahrscheinlichkeit sein. Ein Mensch kann z.B. an einer Maschine tödlich verletzt werden, in einem Flugzeug oder Fahrzeug oder durch Exposition von gefährlichen Stoffen sind immer mehrere Menschen in tödlicher Gefahr, wenn ein elektrisches oder elektrisch programmierbares System versagt.

Die Kritikalität bestimmt also die maximal erlaubte Eintrittswahrscheinlichkeit eines gefahrbringenden Ausfalls. Um niedrige Ausfallwahrscheinlichkeiten zu erreichen, muss die Hardware im Sinne der Ausfallsicherheit z.B. bei SIL 4 mehrkanalig ausgeführt werden. Je nach Standard und systematischer Eignung der verwendeten Technologie, kann bereits ab SIL 2 eine 2 kanalige Architektur notwendig werden, um die erforderlichen Ausfallwahrscheinlichkeiten einzuhalten. Auch wenn diese Werte scheinbar absolut erscheinen, sind diese jedoch relativ und interpretierbar. Es gibt keine 100 prozentige Sicherheit, wenn die Zielwerte eingehalten werden würden. Vielmehr steht die Robustheit der Systeme gegenüber Einfachfehlern im Fokus.

Integrität, Zuverlässigkeit & Verfügbarkeit in Fail-Safe/Fail-Operational

Mit Integrität kann das Vertrauen in die sichere bestimmungsgemäße Funktion verstanden werden. Begriffe wie Zuverlässigkeit und Verfügbarkeit werden oft falsch interpretiert oder als Synonyme verwendet.

ZUVERLÄSSIGKEIT (Reliability) ist die Wahrscheinlichkeit der fehlerfreien Funktion eines Systems unter definierten Bedingungen innerhalb eines Zeitraumes

Ist ein System reparabel (z.B. durch Austausch von Komponenten), so ist seine Zuverlässigkeit in einem Intervall gegeben und beschrieben durch folgende Zeiten:

• Meantime between failures – MTBF
• Meantime to repair/recover – MTTR

Ist ein System nicht reparabel und muss ausgetauscht werden (Leuchtmittel), so ist seine Zuverlässigkeit ausgedrückt durch:

• Meantime to failures – MTTF

Die Ausfallrate oder Fehlerrate eines Systems wird i.d.R. als konstant angenommen und durch den Kehrwert der MTBF oder MTTF Zeiträume beschrieben:

Hat das System eine lange mittlere fehlerfreie Lebensdauer (MTTF) , so ist die Ausfallrate „Lambda“ klein. Die Lebensdauer wird pro Betriebsstunde angegeben. Wenn MTTF = MTBF = 114.155 Jahre, dann wäre die Ausfallrate Lambda ca. 1 FIT. Die Ermittlung der System-Ausfallwahrscheinlichkeit bzw. System-Ausfallrate, erfolgt durch eine Analysemethode (FMEDA, FTA) und Fehlerratenkatalogen für elektronische Komponenten wie die TR 62380, SN 29300 oder auch MIL-HDBK-217F.

VERFÜGBARKEIT (Availability) ist die Wahrscheinlichkeit der fehlerfreien Funktion eines Systems unter definierten Bedingungen zu einem bestimmten Zeitpunkt

Die Verfügbarkeit ist ein wichtiger Aspekt zur Erhaltung der bestimmungsgemäßen Funktion. Wenn eine Sicherheitsfunktion eines einkanaligen Systems bei einem zyklischen Selbsttest einen Fehler im Abschaltpfad diagnostiziert und das System grundlegend Fail-Safe, also im abgeschalteten Zustand sicher wäre, so wird die bestimmungsgemäße Funktion i.d.R. abgeschaltet und es kommt zu Betriebsunterbrechungen. Hier wird also die Verfügbarkeit der bestimmungsgemäßen Funktion zugunsten der Sicherheit eingeschränkt. Dieser Umstand kann zu vorhersagbaren Fehlverhalten des Personals führen. Daher kann es unter Umständen sinnvoller sein, die Gefahr durch eine inhärent sichere Konstruktion (z.B. Trennung von Gefahrenbereich und Mensch/Personal durch einen Schutzzaun) zu vermeiden, als die Verfügbarkeit der Maschinenfunktion durch eine Sicherheitsfunktion einzuschränken. Zuverlässige Systeme mit hoher Verfügbarkeit lassen sich mit mindestens 3 kanaligen Systemen, sogenannte triple-modular-redundancy-(TMR)-Architekturen oder auch 2oo3-Architekturen realisieren.

Die Betriebsart der Sicherheitsfunktion bestimmt die Sichtweise

Zuverlässigkeit und Verfügbarkeit dürfen niemals mathematisch vertauscht werden. Gleichwohl können beide Größen sicherheitsrelevant sein. Eine Sicherheitsfunktion muss i.d.R. über die Lebensdauer verfügbar sein, um die Funktion mit hoher Wahrscheinlichkeit auszuführen. Dies kann entweder durch unzuverlässige Systeme (hohe Ausfallrate) mit hoher Testrate bzw. hohen Austauschraten erfolgen oder durch zuverlässige Systeme mit geringerer Testrate. Die Betriebsart der Sicherheitsfunktion (s. IEC 61508: High- oder Low-Demand) bestimmt den Betrachtungswinkel.

Es muss daher unterschieden werden zwischen „Zuverlässigkeit der Sicherheitsfunktion“ bei Ausführung ihrer Aufgaben, also nicht nur im Anforderungsfall und der Verfügbarkeit der bestimmungsgemäßen Funktion. Solange die bestimmungsgemäße Funktion ausgeführt wird, so muss gleichzeitig die sicherheitsrelevante Funktion zuverlässig sein. Die bestimmungsgemäße Funktion muss jedoch nicht generell verfügbar sein, wenn die Sicherheitsfunktion durch zufällige Hardwarefehler eingeschränkt ist und die Integrität somit nicht gewährleistet werden kann. Beispielsweise sollte ein Airbag nicht während der Fahrt auslösen, jedoch bei einem Unfall (Anforderungsfall) verfügbar sein und funktionieren.

Sicherheit baut auf Integrität auf. Das Integritätslevel ist einzuhalten.

SICHERHEITSINTEGRITÄT (safety integrity) ist die Wahrscheinlichkeit, dass ein sicherheitsbezogenes E/E/PE-System die festgelegten Sicherheitsfunktionen unter allen festgelegten Bedingungen innerhalb eines festgelegten Zeitraumes anforderungsgemäß ausführt.

Eine zuverlässige Sicherheitsfunktion bedingt Integrität. Die Beherrschung von zufälligen Hardwarefehlern durch ein fehlertolerantes Design und Diagnosemechanismen und die Vermeidung von systematischen Fehlern durch Analyse der Werkzeuge (Kann Compiler falsch optimieren ?), Sicherstellung der Qualifikation (Programmierer kennt Coding-Guidelines und kann defensiv programmieren) und weitere Maßnahmen auch nach der Entwicklung (Wartung, Softwareupdates, Hardwarekompatibilität usw…) bilden die Gesamtheit der Maßnahmen, welche dem geforderten Sicherheistintegritätslevel entsprechen müssen. Solange das System und die Sicherheitsfunktion zuverlässig arbeiten mit der geforderten geringen Ausfallwahrscheinlichkeit, ist die bestimmungsgemäße Funktion verfügbar. Fail-Safe Systeme sind daher nur verfügbar, wenn die Sicherheitsfunktion mit robusten Diagnosen und Bauteilen hoher Güte zuverlässig arbeitet.

Es ist ein Irrtum, eine nach SIL 2 entwickelte programmierbare elektronische Komponente mit einer Ausfallwahrscheinlichkeit besser SIL 2 in einer SIL 3 oder SIL 4 Anwendung einzusetzen.

Oft wird fälschlicherweise angenommen, dass ein zufällig auftretender und erkennbarer/diagnostizierbarer Fehler im System mit einer globalen Fail-Safe-Strategie behandelt werden müsste. Es hängt jedoch von den Ergebnissen der G&R/HAZOP ab, wie mit Fehlern umgegangen werden darf. Wenn das Fahrzeug parkt, ist ein Abschalten bestimmer Fahrzeugfunktionen bei diagnostizierten und damit erkannten Fehlern z.B. durch ein POST (pre-operational self test) sinnvoll und der sichere Zustand kann durch „fail-safe“-Charakteristik eingenommen werden. Wenn ein Fahrzeug auf der Landstraße fährt, so ist z.B. ein Abschalten einer x-by-wire Lenkung unbedingt zu vermeiden. Letzteres kann nur durch einen Zustand mit „fail-operational“-Charakteristik sichergestellt werden, was meist durch eine redundante (mehrkanalige) Systemauslegung erreicht wird. Die Sicherheitsfunktion ist im Fail-Operational-Fall die Aufrechterhaltung der bestimmungsgemäßen Funktion selbst. Energie aufrechterhalten, Energie sicher abbauen, Energien begrenzen oder Kräfte mit Gegenkräfte in eine stabile Lage bringen, sind wesentliche Eigenschaften von Sicherheitsfunktionen.

Daher gilt es, die bestimmungsgemäße Funktion in ihrer Verfügbarkeit nicht einzuschränken sowie die Sicherheitsfunktionen mit Bedacht und mit der geforderten Integrität und hoher Zuverlässigkeit in das Anwendungsfeld mit systematisch geeigneten Technologien zu integrieren.

Es ist ein Irrtum, dass durch die Kombination mehrere Elemente eines SILs generell ein höherer SIL erreichbar ist.

Der Kernprozess zur Funktionalen Sicherheit

Folgende grobe Arbeitspakete sind als roter Faden anzugehen:

Um diese Arbeitspakete zu behandeln, bedarf es neben der Prozesstreue (gelebtes QM mit V&V Aktivitäten) auch strukturiertes Vorgehen und Beschreiben sowie einer ausreichenden Methoden- und Technologiekompetenz im Entwicklungsteam.

Der Einstieg in das Thema FuSi über die Sicherheitsgrundnorm IEC 61508 ist grundsätzlich empfehlenswert. Ein Personalentwicklungsplan ist vor Projektbeginn aufzustellen, um die Rollen wie den FuSi-Manager oder Sicherheitskoordinatoren zu qualifizieren.

Abgrenzung zur Funktionalen Sicherheit

Funktionale Sicherheit kann nur sichergestellt werden, wenn Integritätsrandbedingungen eingehalten werden. Diese Randbedingungen sind innerhalb Ihrer Definitionsgrenzen zu behandeln und ausschließlich nur in den notwendigen Berührpunkten zur Funktionalen Sicherheit wie z.B. der Top-Level-Anforderungsspezifikation enthalten. Diese Themenkapselung ist notwendig, um sich nicht zu verlieren in der Vielfalt der Themen und Disziplinen.

Die Funktionale Sicherheit bezieht sich auf elektrische, elektronische und elektronisch programmierbare Systeme (E/E/PE-Systeme), welche notwendige Sicherheitsfunktionen bereitstellen, basierend auf der jeweiligen notwendigen Risikominderung im Anwendungsbereich. Um diese Sicherheitsfunktionen zuverlässig zu realisieren, müssen u.a. zufällige Hardwarefehler ausreichen beherrschbar sein. Dazu gehört neben der Betrachtung statistischen Ausfallwahrscheinlichkeiten der elektronischen Komponenten (Quantifizierung) auch die Robustheit des Hardware-Designs gegenüber Einfachfehlern. Eine erhöhte Störfestigkeit im Sinne der elektromagnetischen Verträglichkeit (EMV) solcher E/E/PE-Systeme ist explizit von der Funktionalen Sicherheit gefordert, und wird in einem EMV-Standard zur Funktionalen Sicherheit z.B. in der Testart und den Störpegeln gemäß DIN EN 61000-6-7 für Anwendungen im industriellen Sektor behandelt. Dieser Umstand wirkt auf die Ausgestaltung des Hardware-Designs (z.B. höhere Signalströme) und Abschirmung des Systems.

Ein weiterer Aspekt der Funktionalen Sicherheit sind Maßnahmen zur Vermeidung systematischer Fehler. Ein systematischer Fehler wäre z.B. in einer Industrie 4.0 Anwendung keinen IT-Sicherheitsstandard anzuwenden. Hier wird auch explizit von der Funktionalen Sicherheit auf die IEC 62443 verwiesen im Kontext einer IT-Bedrohungsanalyse. Es ist also wichtig, die Berührpunkte FuSi->EMV sowie FuSi->IT-Sicherheit klar zu definieren und Zuständigkeiten klar abzugrenzen und Anforderungen klar abgegrenzt zu formulieren. Insbesondere ist die IT-Sicherheit mit ihrer dynamischen Arbeitsweise eine Herausforderung für die statischen Elemente der Funktionalen Sicherheit und insbesondere für den Erhalt der Beurteilung zur Funktionalen Sicherheit. Wenn ein Hacker das System in seiner Reaktionszeit oder Parametrisierung beeinflussen kann oder eine Änderung der EMV-Umgebungbedingung (z.B. Hafenradar oder Schweißroboter) zur Funktionsstörung führt, ist die Funktionale Sicherheit aufgrund dieser fehlenden Integritätsrandbedingungen nicht gewährleistet.

Letzendlich ist die Abgrenzung der Funktionalen Sicherheit pragmatisch nicht einfach mal erklärt.

Kritik an der Funktionalen Sicherheit

Oft wird der Aufwand unterschätzt oder der Zusatzaufwand führt dazu, dass der Business-Case nicht mehr gegeben ist. Der Personenschaden und der Imageschaden bei einen Schadensereignis sind in der Regel teurer als der Zusatzentwicklungskosten. Die Funktionale Sicherheit ist stets ganzheitlich zu betrachten. Ich selbst habe die Funktionale Sicherheit in Rahmen der E-Mobilität als innovationshemmend wahrgenommen. Sicherheit kommt durch Vertrauen, Vertrauen braucht Zeit, Zeit bringt Qualifikation und damit ein Stück mehr sichere Produkte auf dem Markt. Dennoch sind einige Aspekte in der Funktionalen Sicherheit wie folgt, historisch gewachsen und disskusionswürdig:

• Alterung nur bei Betrieb und konstante Fehlerraten,
• Subjektive qualitative SIL-Einstufungen,
• Determinismus und Probabilistik – Pragmatismus und Wahrscheinlichkeitstheorie,
• relative Betrachtungen in den Architekturen (SPF (Einfachfehlerbetrachtungen), LF (Latente Fehler)).