Industrial & Automotive Functional Safety: ISO 26262 & IEC 61508

Die Evolution zur „Living HARA"

Die Zukunft gehört der „Living HARA". Die Gefährdungsanalyse und Risikobewertung darf kein statisches Dokument mehr sein. Sie muss als fortlaufend gepflegtes Arbeitsergebnis behandelt werden, das direkt mit dem Systemmodell verknüpft ist und dynamisch auf Änderungen reagiert.

Das wird umso wichtiger, je kürzer die Entwicklungszyklen werden: Wo iterativ entwickelt wird und Systeme auch nach der Freigabe Updates erhalten (Over-the-Air), muss die Sicherheitsbewertung in jedem Zyklus kontinuierlich mitlaufen, statt nur einmalig zum Meilenstein zu entstehen.

Das Dokument verliert seine Rolle als einzige „Quelle der Wahrheit". Es wird stattdessen zu einer automatisch generierten Sicht auf ein zentrales Modell, in dem die eigentliche Information lebt. Dies funktioniert jedoch nur, wenn die Safety-Artefakte modellbasiert vorliegen und ihre Abhängigkeiten maschinell auswertbar sind. Analoges gilt selbstverständlich auch für die FMEA und die FTA.

Traceability: Das digitale Rückgrat der Sicherheit

Das Rückgrat dieser Verknüpfung ist die lückenlose Traceability. Erst eine durchgängige Ableitungskette vom obersten Sicherheitsziel über die verfeinerten Sicherheitsanforderungen bis hin zur Implementierung und zum Testfall macht Änderungen überhaupt beherrschbar:

• Bei Änderungen der Gefährdung: Wird ein Gefährdungsereignis neu bewertet, zeigen die Trace-Links unmittelbar, welche Anforderungen, Architekturelemente, Analysen und Testfälle betroffen sind – und welche unberührt bleiben.
• Innerhalb der Analysen: Ändert sich ein Architekturelement, müssen die zugehörigen FMEA-Einträge neu bewertet werden. Da Failure Modes aus der FMEA als Basic Events in den Fehlerbaum eingehen, pflanzt sich jede Änderung direkt bis in die FTA fort.

Der Skalierungs-Faktor: Wer diese Querbezüge nicht als digitale Trace-Links pflegt, muss sie bei jeder Änderung mühsam von Hand rekonstruieren. Bei kurzen Zyklen skaliert das nicht: Eine Impact-Analyse, die Wochen an Handarbeit kostet, passt in keinen Sprint. Ohne diese Ketten bedeutet „living" nur, dass ein Dokument häufig editiert wird – und im Sicherheitsnachweis entstehen Lücken, die im Zweifel erst der Assessor findet. Mit ihnen wird aus jeder Änderung eine beantwortbare Frage statt einer Neubewertung auf Verdacht.

Was die Normen und Qualitätsmodelle fordern

Die Normen denken diesen Schritt längst mit. Nachverfolgbarkeit zwischen Anforderungen, Umsetzung und Verifikation fordern alle Sektornormen in der einen oder anderen Form – ob ISO 26262, IEC 62304, EN 50716 oder die DO-178C, welche die Trace-Daten sogar als eigenständiges Arbeitsergebnis führt.

Und nicht nur sie: Auch Prozessqualitätsmodelle verlangen bidirektionale Traceability als Basispraktik: ISO/IEC 330xx (die genormte Assessmentfamilie), Automotive SPICE (ASPICE) (als spezifische Branchenausprägung), CMMI.

Wie durchgängige Traceability in der Praxis aufgebaut wird: von der Werkzeugintegration bis zum Traceability Information Model, zeigt unsere Seite zu Requirements Traceability.

Das Fazit: Wer Prozessreife nachweisen will, kommt an digitaler Traceability ebenso wenig vorbei wie der, der funktionale Sicherheit nachweisen will – und zwar kontinuierlich.

Die Gegenwart und Zukunft der funktionalen Sicherheit existiert nicht im Vakuum. Jede Sicherheitsanalyse beginnt zwingend mit der Abgrenzung des Betrachtungsgegenstands: Welches System wird betrachtet, wo verlaufen seine Grenzen und welche Schnittstellen gehören dazu?

Obwohl die verschiedenen Sektornormen hier unterschiedliche Begriffe verwenden und eigene Schwerpunkte setzen, ist die Kernfrage überall identisch: Was gehört zum System – und was nicht?

Systemabgrenzung im Branchenvergleich

Wer diese Systemgrenze zu eng zieht, schiebt sicherheitsrelevante Schnittstellen unbewusst aus dem eigenen Verantwortungsbereich – und stellt im Assessment schmerzhaft fest, dass sich niemand darum gekümmert hat.

Die große Schnittmenge mit der Cybersecurity

Genau an dieser Systemgrenze überschneidet sich die funktionale Sicherheit massiv mit der Cybersecurity (z. B. nach ISO/SAE 21434 und IEC 62443):

• Derselbe Gegenstand, zwei Blickwinkel: Gefährdungsanalyse (HARA) und Bedrohungsanalyse (TARA) betrachten exakt dasselbe System. Safety schützt die Umwelt vor dem System – sowohl vor unbeabsichtigten Fehlfunktionen als auch unvorhergesehenen Unzulänglichkeiten. Security schützt das System vor der Umwelt – und zwar vor beabsichtigten, böswilligen Angriffen.
• Wechselwirkungen bei Änderungen: Jede Änderung am System oder seiner Umgebung, aber auch jede neu entdeckte Schwachstelle, wirkt sich potenziell auf beide Disziplinen aus. Ein Security-Patch kann das Zeitverhalten der Software ändern und damit die Safety gefährden; eine neue Safety-Funktion kann neue Angriffsvektoren öffnen.

Fazit für die Praxis: Safety-Engineering, das diese Wechselwirkungen ignoriert und in Silos arbeitet, plant an der Realität vorbei. Nur ein integrierter Ansatz, der auf einer gemeinsamen, modellbasierten Systemarchitektur aufsetzt, stellt sicher, dass Safety und Security Hand in Hand greifen.

Wo bringt Automatisierung im Safety-Lifecycle-Engineering schon heute echten, messbaren Nutzen? Zwei konkrete Praxisbeispiele zeigen den Weg:

1. Die automatisierte Dependent Failure Analysis (DFA)

Ein Paradebeispiel ist die Dependent Failure Analysis. Wer eine ASIL-Dekomposition durchführt (etwa ein ASIL-B-Ziel in zweimal ASIL A(B) aufteilt), muss die strikte Unabhängigkeit der dekomponierten Elemente nachweisen. In der Praxis gehört dieser Beleg – beispielsweise für die Unabhängigkeit von Stromquellen oder Speicherbereichen – zu den aufwändigsten Aufgaben überhaupt.

Hier lässt sich Ingenieurswissen im Zusammenspiel mit moderner KI in eine maschinell prüfbare Form bringen:

• Die Ontologie als Regelwerk: Die zugrunde liegenden Unabhängigkeitsregeln der Normen werden als eindeutige Ontologie definiert.
• Kontinuierliche Prüfung: Das Systemmodell wird automatisiert und fortlaufend gegen die Regeln geprüft. Verletzungen fallen sofort auf, wenn sie entstehen – nicht erst Monate später im Review.
• LLM-Unterstützung als Beschleuniger: Wir nutzen durch Large Language Models (LLMs) generierte Vorschläge, um das in der Ontologie festgehaltene Expertenwissen präzise auf die domänen- und kundenspezifischen Entitäten im System zu mappen.

Der Effekt: Das ersetzt zwar keine vollständige formale Verifikation, reduziert den manuellen Review-Aufwand jedoch drastisch. Dieses Muster – Expertenwissen in Form von prüfbaren Regeln zu formalisieren und kontinuierlich gegen das zentrale Modell laufen zu lassen, ist natürlich auf weitere Safety-Anforderungen übertragbar.

2. Teilautomatisiert erzeugte Redundanz in der Toolchain

Ein weiteres mächtiges Prinzip bricht mit einem alten Dogma: Redundanz war bisher ein extrem teures Mittel zur Fehlervermeidung im finalen Produkt. Durch Teilautomatisierung wird sie zu einem bezahlbaren, hocheffizienten Mittel der Fehleraufdeckung im Entwicklungsprozess.

Das Prinzip im vertikalen Systems- und Software Engineering:

1. Unabhängige Toolketten: Zwei voneinander unabhängige, teilautomatisierte Toolketten (völlig egal, ob diese teilweise agentisiert, also KI-gestützt, arbeiten oder klassisch regelbasiert sind) leiten dieselben Engineering-Artefakte ab.
2. Der Abgleich: Entstehen beim anschließenden Testen widersprüchliche Ergebnisse, wird diese Diskrepanz zu einem extrem wertvollen Signal.
3. Die Fehleraufdeckung: Fehler in den Toolketten oder Missverständnisse in den Spezifikationen werden sofort sichtbar.

Mit diesem Ansatz sichern sich Entwicklungsteams doppelt ab, ohne den doppelten manuellen Aufwand zu haben.

Alles bisher Gesagte handelt von Gefährdungen durch Fehlfunktionen: Ein Bauteil fällt aus, ein Signal ist korrupt oder eine Software tut nicht, was sie soll.

Es gibt jedoch eine zweite Klasse von Gefährdungen, bei der absolut nichts ausfällt. Das System arbeitet exakt wie spezifiziert, und trotzdem entsteht eine gefährliche Situation. Die Spezifikation oder die physikalische Leistungsfähigkeit der Funktion reicht schlicht für die reale Situation nicht aus:

• Das klassische Beispiel: Eine Kamera erkennt ein Hindernis bei tief stehender Sonne oder starkem Schneefall nicht.
• Die Ursache: Das System ist intakt, aber das Szenario wurde bei der Auslegung nicht bedacht oder die Sensorik stößt an ihre physikalischen Grenzen.

Für diese Klasse steht im Automotive-Umfeld die ISO 21448 (SOTIF – Safety of the Intended Functionality).

Auf den Punkt gebracht: Die klassische funktionale Sicherheit fragt: Was passiert, wenn das System nicht tut, was es soll? SOTIF fragt: Reicht das, was das System tun soll, in jeder erdenklichen Situation aus?

Eine Trennung mit realen Konsequenzen, keine akademische

Wer diese beiden Disziplinen vermischt, greift im Engineering unweigerlich zum falschen Werkzeugkasten. Die Herausforderungen könnten nicht unterschiedlicher sein:

Teams ohne klare Trennung behandeln eine Performance-Grenze schnell wie eine Fehlfunktion. Sie produzieren teure Maßnahmen, die das eigentliche Problem gar nicht adressieren – während Gefährdungen ohne klares Fehlerbild in einer rein fehlerorientierten Analyse (wie einer klassischen FMEA) komplett unsichtbar bleiben.

Keine Randnotiz, sondern eine notwendige Ergänzung für moderne Systeme

Für die Frage, wohin sich Functional Safety Engineering entwickelt, ist SOTIF weit mehr als eine Randnotiz. Die Grundidee ist zwar in anderen Branchen unter anderem Namen bekannt:

• Die Luftfahrt prüft seit Jahrzehnten auf Systemebene den Betriebskontext.
• Die Medizintechnik bewertet Risiken der Zweckbestimmung unabhängig von Gerätefehlern.
• Der Maschinenbau bezieht die vorhersehbare Fehlanwendung in die Risikobeurteilung ein.

Neu an der ISO 21448 ist jedoch die strikte Systematik für Performance-Grenzen komplexer Wahrnehmungsfunktionen: die mathematisch-methodische Aufteilung in bekannte/unbekannte sowie sichere/unsichere Szenarien.

Genau diese Systematik gewinnt branchenübergreifend massiv an Bedeutung, da lernende Komponenten (KI / Machine Learning) zunehmend in sicherheitsrelevante Funktionen einziehen.

Der Grund: Machine-Learning-Funktionen besitzen keine Spezifikation im klassischen Sinn. Ihre Schwächen sind prinzipbedingte Performance-Grenzen, keine Fehlfunktionen. Das Schwergewicht der Sicherheitsarbeit verschiebt sich damit in allen Domänen unaufhaltsam von der reinen Fehlerbeherrschung hin zur systematischen Absicherung der Sollfunktion.

DISCLAIMER: Die Aussagen auf dieser Seite beziehen sich auf folgende Normen und Standards: IEC 61508 (zweite Edition, 2010), ISO 26262:2018 (zweite Edition), ISO 21448, ISO 12100, IEC 62304, IEC 60601, ISO 80601, ISO 25119, IEC 62061, EN 50716, EN 50129 sowie DO-178C einschließlich des Supplements DO-331. Diese Seite ersetzt keine normative Lektüre und stellt keine Zertifizierungsberatung dar.