Funktionale Sicherheit als Stakeholder
Das Thema Funktionale Sicherheit kurz FuSi ist eigentlich eine schwere Kost. Es handelt sich nicht um eine Produkteigenschaft einer Komponente. Vielmehr ist es ein Merkmal von sicherheitstechnischer Leistungsfähigkeit von der Gesamtheit von Komponeten zum Zwecke der Risikoreduktion. Indirekt bedeutet es 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:
- Identifizierung von spezifischen Gefährdungen & Bewertung von Risiken
- Maßnahmen zur Beherrschung von zufälligen Hardware-Ausfällen
- Maßnahmen zur Vermeidung systematischer Fehler
- Quantifizierung der Ausfallwahrscheinlichkeit
- 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.
Einstieg mittels HAZOP-Methode
Für diese Phase kommen Methoden wie z.B. die HARA, HAZOP oder die LOPA in Frage. Spfern Sie funktionsbasiert entwickeln und systematisch modellieren, können Sie mit ausreichender Methodenkompetenz die FMEA einsetzen und später im Sicherheitslebenszyklus wiederverwenden. Für den Einsteiger sind HAZOP (s. IEC 61882) und LOPA empfehlenswert.
HAZOP steht für Hazard & Operability Studies und bedeutet so viel wie Gefahren- und Funktionsfähigkeitsanalyse. Ziel ist es anhand von Leitwörtern (mehr/weniger, nein/nicht, Umkehrung, sowohl als auch, teilweise, anders als) kritische Parameterabweichungen der bestimmungsgemäßen zu identifizieren. Beispielsweise kann ein „nicht Lenken“ zu einer Kollision führen oder eine Fehlbedienung in einem Behältersystem, bei dem sowohl Säure als auch Lauge zusammenführt werden würden zu einer unkontrollierbaren thermischen Reaktion. Das identifizierte Gefahrenpotenzial kann dann im SInne eines Risikos bewertet werden. Wichtig ist die genaue Abgrenzung der Analyse (Systemgrenzen und Umwelt), die Technologie bzw. Prozesskompetenz und der gesunde Blick für Gefährdungen. Nicht selten können Sie mehr als 100 Fälle betrachten und nur wenige gemeinsame Merkmale von Gefährdungen wie z.B. Quetschen oder Exposition von Medien identifizieren.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
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.
Tipp: Nehmen Sie die Fachkraft für Arbeitssicherheit mit in das G&R-Methodenteam. Sie finden auf unseren Youtube-Kanal in einer kleinen 2 teiligen Safety-Basic-Serie einen Methodenüberblick Teil 1 (HAZOP, FMEA, FMEDA).
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
Ausfälle treten im Lebenszyklus auf. Funktionale Sicherheit bedeutet nicht, dass 100% Sicherheit erreicht werden muss. Das Funktionale sowie das Technische Sicherheitskonzept (FSC, TSC) beschreiben im Wesentlichen, welche Maßnahmen dagegen zur Anwendung kommen sollen und wie diese Maßnahmen technisch realisiert werden.
Im Funktionalen Sicherheitskonzept (FSC) wird beschrieben, welche Sicherheitsfunktionen bzw. Sicherheitsziele in Ihrer Gesamtheit notwendig sind, um das geforderte tolerierbare Risiko nicht zu überschreiten. Insbesondere ist hier die Systemcharakteristik im Hinblick auf den sicheren Zustand beschrieben. Kann / darf abgeschaltet werden? Welche Funktionsparameterabweichungen sind vertretbar? In welchen Zeiträumen ist dies zulässig?
Das FSC beantwortet also die Frage, wie das System / die bestimmungsgemäße Funktion bei einer Abweichung funktional reagiert. Das Technische Sicherheitskonzept (TSC) dagegen, beschreibt, welche Technologie zur Anwendung kommt und wie dieses Verhalten mit passender Sicherheitsintegrität realisiert werden kann.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
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.
Tipp: Setzen sie auf SysML (semi-formal) bei mittleren Sicherheitsintegritätslevel und bei komplexen hochkritischen Anwendungsfällen wie x-by-Wire (z.B. ASIL D, SIL 4) auf formale Sprachen. Achten Sie auf Ihre Firmenkultur! Dürfen Fehler gemacht, gemeldet und gemeinsam Lösungen gefunden werden oder wird bestraft und herrscht sogar Angst vor dem Rauswurf ?
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.
Quantifizierung der Ausfallwahrscheinlichkeit
Wissen Sie, wie hoch die Wahrscheinlichkeit ist, von einem Blitz getroffen zu werden? In Deutschland liegt diese bei ca. 1:6 Mio. Wir leben in einer Welt mit Risiken und das würdigt jeder Standard zur Funktionalen Sicherheit. Für Produkte oder Industrieanlagen ist der gefahrbringen Ausfall oder die mittlere Häufigkeit eines Ausfalls zu berechnen.
Diese Berechnungen basieren auf Fehlerratenkatalogen bzw. Datensammlungen zur Zuverlässigkeit, welche für viele bekannte Bauelemente (Widerstand, Transistor, Kondensator, Spule, Optokoppler, Speicher, Logikbausteine etc…) verfügbar sind. Für neue Technologien liegen noch keine oder nur Zuverlässigkeitsdaten mit geringen Konfidenzniveau vor. Die Ermittlung dieser bauteilspezifischen Ausfallkennwerte ist aufwendig, aber möglich.
Je höher der Sicherheitsintegritätslevel, desto niedriger ist die normativ geforderte Restfehlerwahrscheinlichkeit bzw. desto geringer ist die geforderte Wahrscheinlichkeit eines gefahrbringenden Ausfalls oder Ausfallhäufigkeit. Sie haben nun zwei Möglichkeiten dieses Ziel zu erreichen. Entweder Sie nehmen Bauteile hoher Güte bzw. robuste Technologien oder Sie realisieren Ihre bestimmungsgemäße Funktion in mehrkanaliger Ausführung (Redundanz). Bei SIL 4 bzw. ASIL D ist die Mehrkanaligkeit quasi Pflicht.
Iterativer Entwurf mit der richtigen Methode
Sie sollten im Entwurfstadium in der Systementwicklungsphase bereits eine Berechnung (Schätzung) mit konservativen Annahmen durchführen. Hierzu eignet sich die RBD-Methode hervorragend. Sie ist ein Grundwerkzeug, um kostenträchtige Fehlentscheidungen frühzeitig zu vermeiden.
Als Eingangsinformationen brauchen Sie jedoch immer gute Schätzwerte für jedes Systemelement. Wenn Sie ein zertifiziertes Produkt nehmen, finden Sie die Sicherheitskennzahlen im Datenblatt oder Sicherheitshandbuch. Sofern Sie Baugruppen in eigener Hardwareentwicklung realisieren wollen, so wird ein Safety Element out of Context (SEooC) ihnen viel Arbeit ersparen. Bei vielen Herstellern von zertifizierten µCs/FPGAs/DSPs/SoCs etc. ist eine Art FMEDA verfügbar. Damit lassen sich die Berechnungen einfach ausführen. Ansonsten werden Sie Fehlerratenkataloge heranziehen müssen. Mehr dazu im Video des Webinars zur RBD-Methode.
Tipp: Nehmen Sie einen interdisziplinären Mechatronik- bzw. Systemingenieur in das Methodenteam auf. Sie finden auf unseren Youtube-Kanal in einer kleinen 2 teiligen Safety-Basic-Serie einen Methodenüberblick Teil 1 (HAZOP, FMEA, FMEDA) und den Teil 2 (FTA, RBD, DFA).
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.
Beachten Sie, dass nach dem Systementwurf i.d.R. eine FMEDA durchgeführt wird. Dabei kommt es zu einer Iteration des Systementwurfs, dessen Umfang von dem Diagnosekonzept und Ihrer Erfahrung (FuSi) sowie Technologiekompetenz abhängig ist. Oft werden Hardwareänderungen und im größeren Umfang auch Softwareänderungen erforderlich sein.
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
