Safety Case per ISO 26262

From Work Product to Safety Argument

In many ISO 26262 projects, HARA, safety concepts, requirements, analyses, reviews, and test results are created by different teams, in different tools, and at different milestones. At the end, however, it is not enough that these documents exist. The decisive question is whether they form a traceable safety argument.

The safety case is exactly this argument-based evidence framework. It shows that the functional safety of an item has been planned, implemented, verified, and sufficiently assured throughout the safety lifecycle. In practice, it is therefore more than a repository of work products. It describes the strategy and approach by which the state of functional safety is achieved and justified.

At its core, the safety case answers three questions: Which safety claim is being made? Why is this claim plausible? Which evidence supports it in a robust way?

What a Safety Case Must Demonstrate

A safety case must provide a coherent and reviewable justification that no unreasonable safety risk remains. It connects results from the concept phase, system development, hardware, software, verification, validation, and confirmation measures into one consistent argument chain.

The core statement can be simplified as follows: The item under consideration fulfills the defined safety goals under all relevant operating conditions, adequately implements the derived ASIL-classified requirements, and does not present unreasonable residual risk.

This gives the safety case a clear purpose. It is used to:

• demonstrate fulfillment of all safety goals,
• show correct implementation of ASIL requirements,
• demonstrate that relevant risks are controlled,
• prepare audits, confirmation reviews, and functional safety assessments,
• enable a robust release decision.

The safety case does not necessarily have to be one monolithic document. In larger programs, it is often a structured evidence framework that references reviewed and version-controlled work products. The decisive factor is not the format, but the traceability of the argument.

Safety Concept Case, Safety Confirmation Case, and Safety Release Case

A useful safety case structure grows with project maturity. In practice, the argument can be structured along three maturity stages, even though this split should not be understood as a rigid structure prescribed by the standard. This keeps the safety case relevant before start of production (SOP), not only shortly before release.

The safety concept case covers the early safety argument. It shows that the item definition, HARA, safety goals, ASIL classifications, and initial safety concepts are consistent. At this stage, the focus is not yet on complete test results, but on the robustness of the safety strategy.

The safety confirmation case adds reviews, audits, assessments, and verification evidence to the argument. It shows that planned safety activities have not only been described, but also checked with appropriate independence. This includes confirmation reviews, functional safety audit, and functional safety assessment.

The safety release case consolidates the argument for release. It brings together the final evidence, evaluates open points, safety anomalies, and deviations, and supports the release recommendation. This is where it becomes clear whether the safety evidence is strong enough for release.

This distinction is not just a documentation exercise. It prevents the safety case from being started at the end as a documentation project after the actual evidence gaps have already been created much earlier.

Claim, Argument, and Evidence

A robust safety case follows a clear argumentation logic. The basic structure can be described through claim, argument, and evidence and is often represented using Goal Structuring Notation-like patterns.

A claim is the safety statement that needs to be demonstrated. Example: All safety goals of the item are fulfilled and the remaining risks are acceptable. A well-scoped claim is not vague; it refers to a clear scope, version, defined operating conditions, and concrete safety goals.

The argument explains why the claim follows from the available evidence. Typical argument lines are:

• safety goals were completely derived from the HARA,
• ASIL was consistently carried forward to functional safety requirements (FSR), technical safety requirements (TSR), hardware requirements, and software requirements,
• architecture and safety mechanisms address the relevant risks,
• systematic and random faults were adequately considered,
• verification and validation cover requirements and safety goals,
• independent confirmation measures confirm the maturity of the work products.

Evidence consists of the work products and results that support the argument. This includes far more than test results. Evidence may include HARA, safety concepts, safety analyses, traceability extracts, review records, tool qualification evidence, audit results, and assessment reports.

The final presentation often follows claim -> argument -> evidence. In practical work, however, the safety case often emerges in the opposite direction: teams collect evidence, identify gaps in the argument, and sharpen the claims from there. What matters is that the final structure remains logical for reviewers and assessors.

Which Work Products Feed the Safety Case

A safety case is only as strong as the work products on which it is based. It should therefore not duplicate content, but reference available, reviewed, and consistent artifacts.

Central evidence typically includes:

• HARA results, including hazardous events, safety goals, and ASIL classification,
• safety plan, development interface agreement (DIA), and further safety management evidence,
• item definition, assumptions, operating boundaries, and relevant interfaces,
• functional safety concept with functional safety requirements (FSR),
• technical safety concept with technical safety requirements (TSR) and system architecture,
• hardware safety requirements and software safety requirements,
• safety analyses such as fault tree analysis (FTA), dependent failure analysis (DFA), failure mode and effects analysis (FMEA), or failure modes, effects and diagnostic analysis (FMEDA),
• evidence for control of random hardware faults and systematic faults,
• verification and validation results at system, hardware, and software level,
• review, audit, and assessment results,
• evidence for tool confidence and, where required, tool qualification,
• documented handling of safety anomalies, deviations, and open points.

Bidirectional traceability is essential. The safety case must be able to show which safety goal drives which requirements, architecture decisions, safety mechanisms, tests, and evidence. It must also be possible to trace backward why a test, analysis, or review is safety-relevant.

Without this traceability, a safety case quickly looks like a collection of plausible documents. With clean traceability, it becomes a reviewable argument chain.

The Path to Release Recommendation

The safety case is the technical basis for a release recommendation. It does not replace a management decision, but it provides the structured safety argument on which such a decision can rely.

For a release recommendation, the safety case typically needs to show:

• all relevant safety goals have been identified and fulfilled,
• requirements have been derived completely and ASIL-consistently,
• architecture and safety mechanisms are suitable and verified,
• verification and validation cover the safety-relevant scope,
• safety anomalies have been evaluated, justified, and controlled,
• open points have a clear risk assessment and closure plan,
• confirmation measures have been performed and their results considered.

Open points deserve particular attention. A safety case should not pretend that deviations do not exist. It must show that deviations are known, assessed, and controlled. For reviews and assessments, this transparency is often more important than a formally perfect but unrealistic presentation.

The release recommendation therefore does not arise from a single final document, but from the maturity of the overall safety argument. The earlier claims, evidence, and gaps become visible, the more stable the later release discussion becomes.

In the functional safety assessment, the safety case is evaluated as a key basis. This is where it becomes visible whether the argument is complete, free of contradictions, and supported by suitable evidence.

Do Not Start the Safety Case at the End

A safety case is built throughout the safety lifecycle. Starting it only at the end often means merely documenting which evidence is missing.

A sensible starting point is already after the HARA and the first safety concepts. At that point, claims, argument lines, and expected evidence can be defined. Even before all tests are completed, it is possible to check whether the planned work products will actually support the later argument.

A pragmatic build-up typically follows these steps:

1. Define scope and safety goals.
2. Define main claims and argument structure.
3. Assign expected evidence to each claim.
4. Establish traceability between safety goals, requirements, architecture, and tests.
5. Review work product maturity regularly.
6. Actively track gaps, assumptions, and open points.
7. Consolidate and assess the safety case before release.

This turns the safety case into a control instrument. It shows early whether the safety work is moving in the right direction or whether a project is producing many documents without yet having a robust argument.

Tool Support and Documentation Discipline

ISO 26262 does not prescribe a specific tool for the safety case. It does, however, require systematic creation, maintenance, and traceability of safety-relevant work products. Tool support is therefore an important enabler in practice.

Suitable tools support, among other things:

• bidirectional traceability between safety goals, requirements, architecture, implementation, tests, and evidence,
• consistent versioning and configuration control,
• change tracking and impact analyses,
• transparency over dependencies between work products,
• status tracking for reviews, findings, anomalies, and open points.

The supporting processes of ISO 26262-8 are particularly relevant here, including requirements management, configuration management, change management, documentation management, and tool confidence or tool qualification. In practice, specialized platforms such as cplace have proven useful when safety argumentation, work product status, and traceability must be maintained across multiple roles and suppliers.

More important than the specific tool is discipline in the data. All safety-relevant work products must be documented, reviewed, and under configuration control. Changes must be assessed through impact analyses. The safety case should reference rather than copy, because duplicated content almost inevitably becomes inconsistent.

Open points may be included if they are controlled, assessed, and have a closure plan. What does not work is a safety case that hides gaps or leaves contradictions between work products unresolved.

What a Robust Safety Case Contributes in a Project

A robust safety case creates transparency about the actual maturity of functional safety. It makes visible which assumptions hold, which evidence is missing, and which decisions still need technical clarification before release.

For engineering leads and safety management, it is therefore a leadership instrument. It connects technical work products with project decisions: Is test coverage sufficient? Is ASIL traceability consistent? Are safety anomalies acceptably justified? Can supplier evidence be integrated into the own argument?

For reviews and assessments, it creates a shared language. Instead of discussing individual documents in isolation, the argument chain is reviewed: claim, argument, evidence. This structure reduces late surprises because weaknesses do not first become visible in the final assessment.

Conclusion

The safety case is the structured safety evidence behind ISO 26262 development. It does not only show that work products have been created, but why these work products together demonstrate that safety goals are fulfilled, ASIL-classified requirements are adequately implemented, and residual risks are acceptably controlled.

Its strength lies in the connection of claim, argument, and evidence. HARA, safety concepts, requirements, architecture, safety analyses, tests, reviews, audits, and assessments are not placed next to each other, but connected into one traceable safety argument.

In project reality, the quality of the safety case determines release readiness, assessment risk, and confidence in the evidence early. The earlier structure, traceability, and evidence gaps become visible, the more robust the later release recommendation becomes - and the less the safety case turns into a late documentation problem.