Safety Case (Sicherheitsnachweis)
Ein Safety Case (Sicherheitsnachweis) ist die strukturierte Argumentation, dass ein System in seinem Einsatzkontext hinreichend sicher ist — gestützt auf nachvollziehbare Evidenzen aus dem Entwicklungsprozess. Die ISO 26262 fordert ihn als zentrales Arbeitsergebnis für sicherheitsrelevante E/E-Systeme. Entscheidend ist: Ein Safety Case ist keine bloße Dokumentensammlung, sondern ein Argument — er muss begründen, warum die vorgelegten Belege die Sicherheitsziele tatsächlich abdecken.
Woraus besteht ein Safety Case?
Ein tragfähiger Safety Case verbindet drei Elemente, die aufeinander aufbauen:
| Element | Frage | Beispiel |
|---|---|---|
| Behauptungen (Claims) | Was wird als sicher behauptet? | „Das Sicherheitsziel ‚Ungewolltes Bremsen vermeiden’ (ASIL D) ist erreicht." |
| Argumentation (Argument) | Warum folgt die Behauptung aus den Belegen? | „Alle abgeleiteten Sicherheitsanforderungen sind umgesetzt und verifiziert; die Restfehlerbetrachtung liegt innerhalb der Zielwerte." |
| Evidenzen (Evidence) | Welche Belege stützen das Argument? | HARA, Sicherheitsanalysen (FMEA, FTA), Reviews, Testergebnisse, Metriken |
Fehlt eines der drei Elemente, kippt der Nachweis: Evidenzen ohne Argument sind ein unstrukturierter Dokumentenberg, Argumente ohne Evidenzen bloße Behauptung.
Safety Case in der ISO 26262
Die ISO 26262 verankert den Safety Case im Safety Management (Teil 2): Er wird schrittweise über den Sicherheitslebenszyklus aufgebaut und bündelt die Arbeitsergebnisse der Entwicklung — von der Item-Definition und der HARA über das funktionale und technische Sicherheitskonzept bis zu Sicherheitsanalysen, Verifikationsberichten und Testergebnissen. Vor der Freigabe prüfen unabhängige Instanzen den Safety Case im Rahmen der Bestätigungsmaßnahmen (Confirmation Measures); je nach ASIL gelten dabei unterschiedliche Anforderungen an die Unabhängigkeit der Prüfer.
Das Konzept ist dabei älter und breiter als die Automobilindustrie: Auch andere sicherheitskritische Branchen — etwa die Bahntechnik — fordern explizit strukturierte Sicherheitsnachweise. Die Grundidee ist überall dieselbe: Sicherheit wird nicht unterstellt, sondern argumentiert.
Wie wird die Argumentation dargestellt?
Für die Struktur der Argumentation hat sich neben textuellen und tabellarischen Formen die Goal Structuring Notation (GSN) etabliert: eine grafische Notation, in der übergeordnete Ziele über Strategien in Teilziele zerlegt werden, bis jedes Blatt der Struktur durch eine konkrete Evidenz belegt ist. Der Vorteil einer expliziten Notation: Lücken in der Argumentation — ein Ziel ohne Beleg, ein Beleg ohne Bezug — werden sichtbar, bevor der Assessor sie findet.
Safety Case in der Praxis: Evidenzen leben in vielen Werkzeugen
Die größte praktische Hürde ist selten die Argumentationsstruktur, sondern die Evidenzlage: Anforderungen liegen im Requirements-Management-Werkzeug, Sicherheitsanalysen in Spezialwerkzeugen, Architekturmodelle im MBSE-Tool, Testergebnisse in der CI-Pipeline. Ein als statisches Dokument gepflegter Safety Case ist in dem Moment veraltet, in dem sich eines dieser Artefakte ändert — und späte Änderungen sind in realen Projekten die Regel, nicht die Ausnahme. Tragfähig wird der Nachweis erst, wenn die Argumentation über Trace-Links direkt auf die aktuellen Arbeitsergebnisse verweist: Dann zeigt jede Änderung sofort, welche Teile der Argumentationskette neu bewertet werden müssen — und welche unberührt bleiben.