Safety Case
A safety case is the structured argument that a system is acceptably safe in its context of use — supported by traceable evidence from the development process. ISO 26262 requires it as a central work product for safety-related E/E systems. The crucial point is: a safety case is not a mere collection of documents, but an argument — it must justify why the evidence presented actually covers the safety goals.
What does a safety case consist of?
A sound safety case combines three elements that build on each other:
| Element | Question | Example |
|---|---|---|
| Claims | What is claimed to be safe? | “The safety goal ‘avoid unintended braking’ (ASIL D) has been achieved.” |
| Argument | Why does the claim follow from the evidence? | “All derived safety requirements are implemented and verified; the residual fault analysis is within the target values.” |
| Evidence | Which evidence supports the argument? | HARA, safety analyses (FMEA, FTA), reviews, test results, metrics |
If one of the three elements is missing, the case collapses: evidence without an argument is an unstructured pile of documents, arguments without evidence are mere assertion.
The safety case in ISO 26262
ISO 26262 anchors the safety case in safety management (part 2): it is built up progressively over the safety lifecycle and bundles the work products of the development — from the item definition and the HARA through the functional and technical safety concept to safety analyses, verification reports and test results. Before release, independent parties examine the safety case as part of the confirmation measures; depending on the ASIL, different requirements apply to the independence of the reviewers.
The concept is older and broader than the automotive industry: other safety-critical sectors — such as rail — also explicitly require structured safety cases. The basic idea is the same everywhere: safety is not assumed, but argued.
How is the argument represented?
For the structure of the argument, the Goal Structuring Notation (GSN) has become established alongside textual and tabular forms: a graphical notation in which top-level goals are decomposed via strategies into sub-goals until every leaf of the structure is supported by a concrete piece of evidence. The advantage of an explicit notation: gaps in the argument — a goal without evidence, evidence without a reference — become visible before the assessor finds them.
The safety case in practice: evidence lives in many tools
The biggest practical hurdle is rarely the argument structure, but the state of the evidence: requirements live in the requirements management tool, safety analyses in specialised tools, architecture models in the MBSE tool, test results in the CI pipeline. A safety case maintained as a static document is outdated the moment one of these artifacts changes — and late changes are the rule in real projects, not the exception. The case only becomes sound when the argument references the current work products directly via trace links: then every change immediately shows which parts of the chain of argument need to be re-evaluated — and which remain untouched.