Safety Case nach ISO 26262

Vom Work Product zum Sicherheitsnachweis

In vielen ISO-26262-Projekten entstehen HARA, Sicherheitskonzepte, Anforderungen, Analysen, Reviews und Testergebnisse in unterschiedlichen Teams, Tools und Meilensteinen. Am Ende reicht es jedoch nicht, dass diese Dokumente existieren. Entscheidend ist, ob aus ihnen eine nachvollziehbare Sicherheitsargumentation entsteht.

Der Safety Case ist genau dieser argumentationsbasierte Nachweis. Er zeigt, dass die funktionale Sicherheit eines Items über den Sicherheitslebenszyklus systematisch geplant, umgesetzt, verifiziert und ausreichend abgesichert wurde. In der Praxis ist er damit mehr als eine Ablage von Work Products. Er beschreibt die Strategie und Herangehensweise, mit der der Zustand der funktionalen Sicherheit erreicht und begründet wird.

Im Kern beantwortet der Safety Case drei Fragen: Welche Sicherheitsbehauptung wird aufgestellt? Warum ist diese Behauptung plausibel? Welche Evidenzen belegen sie belastbar?

Was ein Safety Case leisten muss

Ein Safety Case soll eine schlüssige und prüfbare Begründung liefern, dass kein unangemessenes Sicherheitsrisiko verbleibt. Er verbindet die Ergebnisse aus Konzeptphase, Systementwicklung, Hardware, Software, Verifikation, Validierung und Confirmation Measures zu einer konsistenten Argumentationskette.

Die Kernaussage lautet vereinfacht: Das betrachtete Item erfüllt unter allen relevanten Betriebsbedingungen die definierten Safety Goals, setzt die daraus abgeleiteten ASIL-klassifizierten Anforderungen angemessen um und weist kein unangemessenes Restrisiko auf.

Daraus folgt ein klarer Zweck. Der Safety Case dient dazu:

• die Erfüllung aller Safety Goals zu belegen,
• die korrekte Umsetzung der ASIL-Anforderungen nachzuweisen,
• die Beherrschung relevanter Risiken zu zeigen,
• Audits, Confirmation Reviews und Functional Safety Assessments vorzubereiten,
• eine belastbare Freigabeentscheidung zu ermöglichen.

Der Safety Case muss dafür nicht zwingend ein einzelnes monolithisches Dokument sein. Gerade in größeren Programmen ist er häufig ein strukturierter Nachweisrahmen, der auf geprüfte und versionierte Work Products referenziert. Entscheidend ist nicht die Form, sondern die Nachvollziehbarkeit der Argumentation.

Safety Concept Case, Safety Confirmation Case und Safety Release Case

Eine sinnvolle Safety-Case-Struktur wächst mit dem Projektfortschritt. In der Praxis kann der Nachweis entlang von drei Reifestufen strukturiert werden, auch wenn diese Dreiteilung nicht als starres Normschema zu verstehen ist. So wird der Safety Case nicht erst kurz vor Start of Production (SOP) relevant.

Der Safety Concept Case betrachtet die frühe Sicherheitsargumentation. Er zeigt, dass Item Definition, HARA, Safety Goals, ASIL-Einstufungen und erste Sicherheitskonzepte konsistent zusammenpassen. In dieser Phase geht es noch nicht um vollständige Testergebnisse, sondern um die Tragfähigkeit der Sicherheitsstrategie.

Der Safety Confirmation Case ergänzt die Argumentation um Reviews, Audits, Assessments und Verifikationsnachweise. Er zeigt, dass die geplanten Sicherheitsaktivitäten nicht nur beschrieben, sondern mit angemessener Unabhängigkeit geprüft wurden. Dazu gehören Confirmation Reviews, Functional Safety Audit und Functional Safety Assessment.

Der Safety Release Case führt die Argumentation zur Freigabe zusammen. Er bündelt die finalen Nachweise, bewertet offene Punkte, Safety Anomalien und Abweichungen und stützt die Release Recommendation. Hier entscheidet sich, ob der Sicherheitsnachweis für die Freigabe ausreichend belastbar ist.

Diese Unterteilung ist kein Selbstzweck. Sie verhindert, dass der Safety Case am Ende als Dokumentationsprojekt gestartet wird, obwohl die eigentlichen Nachweislücken bereits viel früher entstanden sind.

Claim, Argument und Evidence

Ein belastbarer Safety Case folgt einer klaren Argumentationslogik. Die Grundstruktur lässt sich über Claim, Argument und Evidence beschreiben und wird in vielen Projekten mit Goal-Structuring-Notation-ähnlichen Mustern dargestellt.

Ein Claim ist die Sicherheitsbehauptung, die belegt werden soll. Beispiel: Alle Safety Goals des Items sind erfüllt und die verbleibenden Risiken sind akzeptabel. Ein belastbarer Claim ist nicht vage, sondern bezieht sich auf einen klaren Scope, eine Version, definierte Betriebsbedingungen und konkrete Safety Goals.

Das Argument erklärt, warum der Claim aus den vorhandenen Nachweisen folgt. Typische Argumentationslinien sind:

• Safety Goals wurden vollständig aus der HARA abgeleitet,
• ASIL wurde konsistent auf Functional Safety Requirements (FSR), Technical Safety Requirements (TSR), Hardware- und Softwareanforderungen weitergeführt,
• Architektur und Sicherheitsmechanismen adressieren die relevanten Risiken,
• systematische und zufällige Fehler wurden angemessen betrachtet,
• Verifikation und Validierung decken Anforderungen und Sicherheitsziele ab,
• unabhängige Confirmation Measures bestätigen die Reife der Work Products.

Evidence sind die Nachweise, auf die sich das Argument stützt. Dazu zählen nicht nur Testergebnisse. Evidenzen können HARA, Sicherheitskonzepte, Safety Analyses, Traceability-Auszüge, Review-Protokolle, Tool-Qualifikationsnachweise, Audit-Ergebnisse und Assessment-Berichte sein.

Die Reihenfolge in der Darstellung ist häufig Claim -> Argument -> Evidence. In der praktischen Arbeit entsteht der Safety Case jedoch oft umgekehrt: Teams sammeln Evidenzen, erkennen Lücken in der Argumentation und schärfen daraus die Claims. Entscheidend ist, dass die finale Struktur für Reviewer und Assessoren logisch nachvollziehbar bleibt.

Welche Work Products in den Safety Case einfließen

Ein Safety Case ist nur so stark wie die Work Products, auf denen er aufbaut. Er sollte deshalb nicht Inhalte duplizieren, sondern auf verfügbare, geprüfte und konsistente Artefakte referenzieren.

Zu den zentralen Evidenzen gehören insbesondere:

• Ergebnisse der HARA inklusive Hazardous Events, Safety Goals und ASIL-Einstufung,
• Safety Plan, Development Interface Agreement (DIA) und weitere Safety-Management-Nachweise,
• Item Definition, Annahmen, Betriebsgrenzen und relevante Schnittstellen,
• Funktionales Sicherheitskonzept mit Functional Safety Requirements (FSR),
• Technisches Sicherheitskonzept mit Technical Safety Requirements (TSR) und Systemarchitektur,
• Hardware Safety Requirements und Software Safety Requirements,
• Sicherheitsanalysen wie Fault Tree Analysis (FTA), Dependent Failure Analysis (DFA), Failure Mode and Effects Analysis (FMEA) oder Failure Modes, Effects and Diagnostic Analysis (FMEDA),
• Nachweise zur Beherrschung zufälliger Hardwarefehler und systematischer Fehler,
• Verifikations- und Validierungsergebnisse auf System-, Hardware- und Softwareebene,
• Review-, Audit- und Assessment-Ergebnisse,
• Nachweise zu Tool Confidence und, falls erforderlich, Tool Qualification,
• dokumentierter Umgang mit Safety Anomalien, Abweichungen und offenen Punkten.

Wichtig ist die bidirektionale Traceability. Der Safety Case muss zeigen können, welches Safety Goal welche Anforderungen, Architekturentscheidungen, Sicherheitsmechanismen, Tests und Nachweise treibt. Ebenso muss rückwärts nachvollziehbar sein, warum ein Test, eine Analyse oder ein Review sicherheitsrelevant ist.

Ohne diese Traceability wirkt ein Safety Case schnell wie eine Sammlung plausibler Dokumente. Mit sauberer Traceability wird daraus eine prüfbare Argumentationskette.

Der Weg zur Release Recommendation

Der Safety Case ist die fachliche Grundlage für eine Freigabeempfehlung. Er ersetzt keine Managemententscheidung, liefert aber die strukturierte Sicherheitsargumentation, auf der diese Entscheidung beruhen kann.

Für eine Release Recommendation muss der Safety Case typischerweise zeigen:

• alle relevanten Safety Goals sind identifiziert und erfüllt,
• die Anforderungen wurden vollständig und ASIL-konsistent abgeleitet,
• Architektur und Sicherheitsmechanismen sind geeignet und verifiziert,
• Verifikation und Validierung decken den sicherheitsrelevanten Scope ab,
• Safety Anomalien sind bewertet, begründet und kontrolliert,
• offene Punkte haben eine klare Risikobewertung und einen Abschlussplan,
• Confirmation Measures wurden durchgeführt und ihre Ergebnisse berücksichtigt.

Gerade offene Punkte verdienen besondere Aufmerksamkeit. Ein Safety Case darf nicht so tun, als gäbe es keine Abweichungen. Er muss zeigen, dass Abweichungen bekannt, bewertet und kontrolliert sind. Für Reviews und Assessments ist diese Transparenz oft entscheidender als eine formal perfekte, aber unrealistische Darstellung.

Die Freigabeempfehlung entsteht deshalb nicht aus einem einzelnen finalen Dokument, sondern aus der Reife der gesamten Sicherheitsargumentation. Je früher Claims, Evidenzen und Lücken sichtbar werden, desto stabiler wird die spätere Release-Diskussion.

Im Functional Safety Assessment wird der Safety Case als wesentliche Grundlage bewertet. Dort zeigt sich, ob die Argumentation vollständig, widerspruchsfrei und durch geeignete Evidenzen gestützt ist.

Safety Case nicht erst am Ende beginnen

Ein Safety Case wird während des gesamten Sicherheitslebenszyklus aufgebaut. Wer ihn erst am Ende erstellt, dokumentiert häufig nur noch, welche Nachweise fehlen.

Der sinnvolle Startpunkt liegt bereits nach der HARA und den ersten Sicherheitskonzepten. Zu diesem Zeitpunkt lassen sich Claims, Argumentationslinien und erwartete Evidenzen definieren. Noch bevor alle Tests abgeschlossen sind, kann geprüft werden, ob die geplanten Work Products den späteren Nachweis überhaupt tragen.

Ein pragmatischer Aufbau folgt typischerweise diesen Schritten:

1. Scope und Safety Goals festlegen.
2. Haupt-Claims und Argumentationsstruktur definieren.
3. Erwartete Evidenzen je Claim zuordnen.
4. Traceability zwischen Safety Goals, Requirements, Architektur und Tests aufbauen.
5. Work-Product-Reife in Reviews regelmäßig prüfen.
6. Lücken, Annahmen und offene Punkte aktiv verfolgen.
7. Safety Case vor Release final konsolidieren und bewerten.

Dieser Ansatz macht den Safety Case zu einem Steuerungsinstrument. Er zeigt früh, ob die Sicherheitsarbeit in die richtige Richtung läuft oder ob ein Projekt zwar viele Dokumente produziert, aber noch keine tragfähige Argumentation besitzt.

Toolunterstützung und Dokumentationsdisziplin

Die ISO 26262 schreibt kein konkretes Werkzeug für den Safety Case vor. Sie verlangt aber eine systematische Erstellung, Pflege und Nachvollziehbarkeit sicherheitsrelevanter Work Products. Toolunterstützung ist deshalb in der Praxis ein wesentlicher Enabler.

Geeignete Werkzeuge unterstützen unter anderem:

• bidirektionale Traceability zwischen Safety Goals, Anforderungen, Architektur, Implementierung, Tests und Nachweisen,
• konsistente Versionierung und Konfigurationskontrolle,
• Änderungsverfolgung und Impact Analysen,
• Transparenz über Abhängigkeiten zwischen Work Products,
• Statusverfolgung von Reviews, Findings, Anomalien und offenen Punkten.

Die unterstützenden Prozesse der ISO 26262-8 sind dafür besonders relevant, etwa Requirements Management, Konfigurationsmanagement, Änderungsmanagement, Dokumentationsmanagement sowie Tool Confidence und Tool Qualification. In der Praxis haben sich spezialisierte Plattformen wie cplace bewährt, wenn Safety-Argumentation, Work-Product-Status und Traceability über mehrere Rollen und Lieferanten hinweg geführt werden müssen.

Wichtiger als das konkrete Werkzeug ist die Disziplin im Umgang mit den Daten. Alle sicherheitsrelevanten Work Products müssen dokumentiert, geprüft und unter Konfigurationskontrolle stehen. Änderungen müssen über Impact Analysen bewertet werden. Der Safety Case sollte referenzieren statt kopieren, weil duplizierte Inhalte fast zwangsläufig inkonsistent werden.

Offene Punkte dürfen enthalten sein, wenn sie kontrolliert, bewertet und mit einem Abschlussplan versehen sind. Was nicht funktioniert, ist ein Safety Case, der Lücken verdeckt oder Widersprüche zwischen Work Products stehen lässt.

Was ein belastbarer Safety Case im Projekt leistet

Ein belastbarer Safety Case schafft Transparenz über den tatsächlichen Reifegrad der funktionalen Sicherheit. Er macht sichtbar, welche Annahmen tragen, welche Nachweise fehlen und welche Entscheidungen vor einer Freigabe noch fachlich geklärt werden müssen.

Für Engineering-Leads und Safety Management ist er damit ein Führungsinstrument. Er verbindet technische Work Products mit Projektentscheidungen: Reicht die Testabdeckung? Ist die ASIL-Traceability konsistent? Sind Safety Anomalien akzeptabel begründet? Können Lieferantennachweise in die eigene Argumentation integriert werden?

Für Reviews und Assessments schafft er eine gemeinsame Sprache. Statt einzelne Dokumente isoliert zu diskutieren, wird die Argumentationskette geprüft: Claim, Argument, Evidence. Genau diese Struktur reduziert späte Überraschungen, weil Schwächen nicht erst im finalen Assessment sichtbar werden.

Fazit

Der Safety Case ist der strukturierte Sicherheitsnachweis hinter der ISO-26262-Entwicklung. Er zeigt nicht nur, dass Work Products erstellt wurden, sondern warum diese Work Products gemeinsam belegen, dass Safety Goals erfüllt, ASIL-klassifizierte Anforderungen angemessen umgesetzt und Restrisiken akzeptabel beherrscht sind.

Seine Stärke liegt in der Verbindung aus Claim, Argument und Evidence. HARA, Sicherheitskonzepte, Anforderungen, Architektur, Safety Analyses, Tests, Reviews, Audits und Assessments werden nicht nebeneinander abgelegt, sondern zu einer nachvollziehbaren Sicherheitsargumentation verbunden.

In der Projektrealität entscheidet die Qualität des Safety Case früh über Freigabefähigkeit, Assessment-Risiko und Nachweissicherheit. Je früher Struktur, Traceability und Evidenzlücken sichtbar werden, desto belastbarer wird die spätere Release Recommendation - und desto weniger wird der Safety Case zum späten Dokumentationsproblem.