Funktionale Sicherheit erfolgreich planen und umsetzen

Funktionale Sicherheit als Stakeholder

Das Thema Funktionale Sicherheit kurz FuSi ist eigentlich eine schwere Kost. Es handelt sich um eine fast unscheinbare Produkteigenschaft und bedeutet so viel wie die Abwesenheit von nicht tolerierbaren Risiken. Der Einfluss auf das Projekt ist signifikant und in vielen Bereichen spürbar wie z.B. Mitarbeiterqualifikation (Methoden & Technologiekompetenz), Arbeitskultur, Werkzeuge, Prozesse, System- Hard- und Softwarearchitektur.

In einer typischen Stakeholder-Analyse durch das Projektmanagement ist der FuSi-Manager und sein Team als externes Schwergewicht zu bewerten. Von ihm werden zeitaufwendige Work-Products (Dokumente) mit hoher Qualität und teils großen Umfang gefordert. Oft wird die Funktionale Sicherheit auch als Opponent eingestuft. Eine frühzeitige und kooperative Zusammenarbeit ist empfehlenswert.

Haftung & Normen

Welche Risiken tolerierbar sind und welche nicht liegt im Mittel unserer gesellschaftlichen Vorstellungen und wird in den FuSi-Standards bzw. Normen indirekt festgelegt. Das Produkthaftungsgesetz (ProdHaftG) fordert eine Produktentwicklung nach dem Stand der Technik. D.h. nur die nachgewiesene Anwendung des richtigen FuSi-Standards erlaubt eine potenziell erfolgreiche Prozessführung für den Hersteller im Haftungsfall.

Der Grundstandard ist die umfangreiche und nicht harmonisierte Norm IEC 61508. Dieser Standard findet oft Anwendung, wenn noch keine Norm besteht und ist somit die erste Adresse für Innovatoren. Dabei bezieht sich dieser anwendungsneutrale Standard technologisch nur auf elektrische (E), elektronische (E) oder programmierbare elektronische (PE) Systeme (E/E/PE). Fast jede neu entwickelte Funktion hat einen Anteil dieser Technologien – kurz gesagt, ohne Hard- und Software geht in Zeiten von IoT 4.0, autonomen Fahren und künstlicher Intelligenz kein Weg an dieser Technologie (E/E/PE-Systeme) vorbei.

Sektorspezifische Ausprägungen finden sich z.B. im Maschinenbau in der harmonisierten EN ISO 13849 oder auch EN 62061. In der Prozessindustrie findet sich z.B. die IEC 61511 Auch die Automobilindustrie hat mit der ISO 26262 ihren Standard. In Bereichen des öffentlichen Lebens finden sich auch staatlich regulierte Anwendungsbereiche der Funktionalen Sicherheit wie Bahntechnik und Flugverkehrstechnik. Weitere FuSi-Anwendungsnormen werden in vielen Sektoren mit dem Fortschreiten der Technologien folgen.

Funktionale Sicherheit & die 5 Kernelemente

Es finden sich in unterschiedlichen Ausprägungen die 5 Kernelemente aus dem Grundstandard nach IEC 61508 in den erwähnten sektorspezifischen Standards (sog. B- und C-Normen) wieder. Die Abwesenheit von nicht tolerierbaren Risiken und dessen Nachweis wird im sogenannten Sicherheitslebenszyklus im Wesentlichen durch diese Kernaspekte erreicht:

1. Identifizierung von spezifischen Gefährdungen & Bewertung von Risiken
2. Maßnahmen zur Beherrschung von zufälligen Hardware-Ausfällen
3. Maßnahmen zur Vermeidung systematischer Fehler
4. Quantifizierung der Ausfallwahrscheinlichkeit
5. Unabhängigkeit & Dokumentation

Identifizierung von Gefährdungen & Bewertung von Risiken (G&R)

Oft wird diesem ersten Schritt zu wenig Aufmerksamkeit geschenkt. Ziel ist es in der frühen Konzeptphase, die Gefährdungen zu identifizieren und davon ausgehende Risiken zu bewerten sowie die Kritikalität im Sinne eines Sicherheitsintegritätslevels qualitativ einzuordnen. In dieser Phase ist der risikobasierter Entwicklungsansatz der Funktionalen Sicherheit erkennbar. Je höher der Schaden für Mensch und Umwelt aufgrund einer möglichen Fehlfunktion der bestimmungsgemäßen Funktion, desto höher die Entwicklungsaufwände.

Von der Produktidee bis zur fundierten und abgeschlossenen Gefahren- und Risikoanalyse (G&R) ist einiges an Aufwand notwendig. Je nach Firmen- und Entwicklungskultur sowie Methodenkompetenz kann dieser frühe Bewertungsansatz unterschiedlich ausgeführt werden.

Beginnen Sie mit den wesentlichen Use-Cases und beschreiben Sie die bestimmungsgemäße und/oder erlebbare Funktion. Achten Sie darauf, dass Sie nicht in Details und Lösungen denken, sondern abstrakt und ohne Wertung oder gar Diagnosefunktionen. Begriffe wie Erkennen, Erfassen, Berechnen, Schneiden, Befüllen, Lenken oder Bremsen können z.B. Teilfunktionen einer bestimmungsgemäßen Funktion sein.

Eine Recherche zu bestehenden Produkten mit ähnlichen Funktionen (Innovation) oder die Merkmalsextraktion einer neuen Technologie (Disruption) im Rahmen einer Technologiebetrachtung können vorab notwendig sein. Wenn Sie alle relevanten Informationen zusammengetragen haben und die bestimmungsgemäße Funktion in wenigen Worten genau beschreiben können, beginnt die eigentliche Analysetätigkeit.

Der nächste Schritt ist die Bewertung der Risiken. Diese ist unterschiedlich und sektorspezifisch. Der bekannteste Vertreter der qualitativen Bewertungsmethodik ist der Risikograph. Hier wird anhand mehrerer Faktoren eine Kritikalität ermittelt in Form von diskreten Sicherheits-Integritätsstufen. Bekannte Vertreter sind Safety Integrity Level (SIL) (IEC 61508), Automotive Safety Integrity Level (ASIL) (ISO 26262) oder Performance Level (PL) (ISO 13849). Zu den Faktoren zählen Kontrollierbarkeit, Auftretenswahrscheinlichkeit und Schadensschwere. Eine Gefährdung mit hoher Schadensschwere (mehrere Menschen Tod durch Exposition schädlicher Substanzen), welche jedoch selten Auftritt und nicht erkennbar und kontrollierbar sei, wird zu einem anderen Integritätslevel führen als ein Quetschen einer Hand mit reversiblen Verletzungen mit häufiger Auftretenswahrscheinlichkeit und Kontrollierbarkeit.

Sicherheitsanforderungen aus der G&R ableiten

Am Ende haben Sie quasi die Toleranzschwelle der möglichen Gefährdungen herausgearbeitet in Form von Sicherheitszielen bzw. Top-Level-Sicherheitsanforderungen an eine sichere Funktion des betrachteten Subjekts (Items). Dabei hat jedes Sicherheitsziel das ASIL als Attribut und vererbt dieses an alle weiteren abzuleitenden Sicherheitsanforderungen. Weiterhin wird eine Fehlertoleranzzeit ermittelt und der sichere Zustand beschrieben. Diese Ergebnisse und die Analyseartefakte werden i.d.R. nach dem Mehraugenprinzip prozessbegleitend durch einen externen Prüfer, Assessor bzw. certified body geprüft. Je nach Schadensschwere sind unterschiedliche Unabhängigkeitsgrade gefordert.

Von nun an gilt für das gesamte Projekt das höchste ermittelte Sicherheitsintegritätslevel. Beispielsweise wird i.d.R. eine Komfortfunktion im Automotive-Bereich mit ASIL A oder B eingestuft, während Bremsen und Lenken mit den höchstkritischen Level ASIL D eingestuft wird. Im Maschinenbereich sind die Gefährdungen oft noch örtlich bzw. lokal begrenzt und gekapselt. Hier ist Vorsicht geboten. Die Kapselung selbst kann bereits eine Sicherheitsmaßnahme sein. Betrachtungsgegenstand der G&R ist die bestimmungsgemäße Funktion in ihrem Umfeld mit allen Situationen und den betrachteten Gefährdungen (Hazards) u.a. jedoch mit vorhersehbarer Falschanwendung und Missbrauch (z.B. Katze in der Mikrowelle trocknen).

Konzepte & Maßnahmen zu Beherrschung von zufälligen HW-Ausfällen

Maßnahmen zur Vermeidung systematischer Fehler

Nicht nur physische Dinge wie Hardware oder Mechanik können ausfallen, sondern auch wir Menschen können Versagen. Während wir bei der Hardware durch Maßnahmen wie Fehlerdetektion und Fehlerisolation, Bauteilausfälle beherrschen, müssen wir systematische Fehler vermeiden. Über den gesamten Sicherheitslebenszyklus ist der Mensch in Positionen wie Management, Entwickler oder Anwender eine Quelle systematischer Fehler. Den dort wo Menschen arbeiten sind auch Fehler. Es muss ganzheitlich von der Beschreibung der Produktidee bis zur Frage wie das System außerbetrieb genommen und entsorgt wird, analysiert werden. Hier spielt die Komplexität der gewählten Technologie eine wichtige Rolle. Der etwas stark abwertende Spruch „etwas idiotensicher machen…“, fasst die Bestrebungen gut zusammen.

Kompetenz & Qualifikation ohne Eitelkeiten sind sicherlich grundlegend vorhanden, jedoch ist auch das Vertrauen in die Entwicklungswerkzeuge und Prozesse erforderlich. Insbesondere zum Erreichen der systematische Software-Sicherheitsintegrität sind eine Reihe von Maßnahmen erforderlich, welche in der Strenge der Anwendung mit dem Sicherheitsintegritätslevel proportional korrelieren. Das Fehlerpotenzial fängt bereits in der Beschreibungsprache in der Konzeptphase an und zieht sich bis zur Bedienungsanleitung durch. Vor- & Rückverfolgbarkeit (Traceability) sind grundlegend erforderlich. Disziplingrenzen (Hardware / Software) und Tools (z.B. Debugger) sind typische Fehlerquellen. Compileroptimierung, Konfigurationsdatenspeicher und Zugriffsrechte, Testumgebungen und Auswerte-Hilfsprogramme – egal welches Tool sie verwenden oder welchen Prozess Sie durchlaufen. Sie müssen Fehler in Ihrer Organisation aufdecken können und damit die Möglichkeit haben, diese zu vermeiden. Typische Merkmale in den Anwendernormen sind das V-Modell und die spezifischen Verifikations- & Validierungsanforderungen.

Vor der Entwicklung Tool-Chain prüfen

Es hängt es von Ihrem Sektor bzw. der Branche ab, ob ein Standard zur Funktionalen Sicherheit vorliegt oder die Grundsicherheitsnorm IEC 61508 zur Anwendung kommt. Sie sollten vor der Entwicklung oder zumindest im Systementwurf Klarheit über die verwendete Technologie und deren Werkzeuge haben. Welche Tool- und Dokumentenlandschaft ist zu erwarten? Jeder Tool-Bruch ist eine potentielle Fehlerquelle und ist durch Maßnahmen wie Tests, Review oder Checklisten im Sinne der systematischen Fehlervermeidung zu behandeln. Eine Toolqualifikation ist bei hohen Sicherheitsintegritätslevel erforderlich. Letztendlich ist das Testen gegen die Sicherheitsanforderungen das wichtigste Mittel zur systematischen Fehlervermeidung. Black- und/oder White-Box, anforderungsbasiertes Testen mit Äquivalenzklassen- und/oder Grenzwerttests etc.

Methoden wie die Prozess-FMEA oder die FTA können zur Aufdeckung der systematischen Fehler dienlich sein. Angewandter FuSi-Standard, systematische Eignung der Technologie und ihre Prozessreife (QM, CMMI, SPICE) sind entscheidende Faktoren zur Vermeidung systematischer Fehler. Ein gefahrbringendes unendecktes „Feature“darf nicht in das Produkt gelangen. Technologische Diversität im Entwicklungsprozess kann zur Vermeidung systematischer Fehler vorteilhaft sein, sofern unterschiedliche Technologien kompatibel zueinander sind. Kommunizieren Sie die Sicherheitsziele auf allen Ebenen im Projekt und wenn Sie mehrere Sicherheitsziele mit unterschiedlichen Sicherheitsintegritätslevels zu erfüllen haben, machen Sie die Unterschiede in den Prozessverläufen deutlich! Nur so können Meilensteine erreichbar sein.

Wenn Sie grobe Schaltplanentwürfe vorliegen haben, Baugruppen wie Sensoren, Logikelemente und Aktoren technologisch von Ihnen im Entwurf festgelegt worden sind, können Sie mit einem Diagnosekonzept starten. Die Quantifizierung erfolgt im Hinblick auf einen „gefahrbringenden Ausfall“. Damit haben Sie je nach Ihrer Definition des sicheren Zustandes, die Möglichkeit, durch Diagnose und Behandlung von Ausfällen, den sicheren Zustand zu erreichen und können somit nur einen geringen Teil der Ausfallarten als gefährlich betrachten. Die Diagnose wird mittels Diagnosedeckungsgrad (DC) als prozentualer Anteil [%] in der Quantifizierung berücksichtigt.

Dokumentation & Unabhängigkeit

Die Dokumentation bedeutet in erster Linie Nachweisführung. Wenn ein Schadensfall eintritt, müssen Sie beweisen, was Sie getan haben und wie sie es getan haben. Neben dem Inhaltlichen, Umfang und Zielen einzelner Dokumente sind auch alle Merkmale eines guten Dokumentenmanagementsystems (s. QM 9001) zu erfüllen. Am Ende der Entwicklung dient die Dokumentation als Grundlage des Safety-Case. Dies ist ein Dokument, welches eine Art Gesamtgutachten ist und beschreibt, wie die Funktionale Sicherheit erreicht worden ist. Es obliegt dem Safety Manager, dieses Dokument zu erstellen.

Unabhängigkeit findet sich an vielen Stellen im Projekt. Projektmanagement und Fusi-Management sind i.d.R. getrennte Einheiten. Entwickler und Tester sind getrennte Einheiten. Reviews einzelner Arbeitsprodukte finden durch einen Unabhängigen statt. Letztendlich wird die Gesamtheit aller Dokumente und Prozesse im Hinblick auf die erreichte Funktionale Sicherheit in mehreren Audits durch den externen Assessor beurteilt. Ganz nach dem Motto, 4 Augen sehen mehr als 2.

Funktionale Sicherheit & IT-Sicherheit

Ohne Vertrauen kann Sicherheit nicht gewährleistet werden. Wenn Systeme mit anderen kommunizieren können, so muss davon ausgegangen werden, dass ein unbefugter Zugriff auf das System erfolgen kann. Wenn dies im Feld/Betrieb passiert, kann die erreichte Sicherheitsintegrität verloren gehen. Daher ist es erforderlich, dass die Funktionale Sicherheit (Safety) mit der IT-Sicherheit (Security) zusammenarbeitet, um Sicherheitsziele nicht durch Integritätsverlust zu gefährden. Hierzu wäre z.B. eine Schwachstellenanalyse gem. IEC 62443 sinnvoll.

Funktionale Sicherheit & Funktionssicherheit (SOTIF)

Das Bestreben nach autonomen Fahren im Automobilbereich hat zur Erweiterung der normierten Sicherheitsbetrachtungen geführt. Zur FuSi und IT-Sicherheit ist zusätzlich das Feld der Funktionssicherheit (SOTIF, Safety Of The Intended Functionality) hinzugekommen. SOTIF ist in ISO/PAS 21448 standardisiert. Die FuSi (ISO 26262) betrachtet als Kern die Integrität einer Funktion unter Fehlerbedingungen. Die IT-Sicherheit (IEC 62443) behandelt die Bedrohungen der Integrität durch Menschen und Maschinen mit böswilligen Absichten. SOTIF fokussiert die Funktionssicherheit der fehlerfreien Funktion und dessen Perfomance im Anwendungskontext unter Realbedingungen. Welches Verhalten ist sicher, wenn z.B. die Sicht auf die Straße durch Witterungsbedingungen schlecht ist ? Welche Tests und welche Validierung kann eine hinreichende Aussagekraft erzeugen ?

Stand: 23.06.2020