Term · Safety & Security
Safety case
The structured argument, supported by the collected work products and evidence, that an item is acceptably safe for its intended use. It is compiled progressively across the lifecycle rather than assembled at the end.
- Type
- Term
- Domain
- Safety & Security, Safety lifecycle
Notes
Assessors judge the argument, not just the document count; gaps in traceability undermine an otherwise complete file.
Overview
A safety case is a structured argument, backed by evidence, that a system or component is acceptably safe for a stated use in a stated environment. It ties the safety claims a team makes to the analyses, test results and reviews that support them, so that an assessor, customer or regulator can follow the reasoning. Automotive functional safety, rail, aviation, defence, offshore and medical sectors all use safety cases, and in automotive work a chip supplier usually contributes evidence to the vehicle maker's case.
How it works
A safety case has three parts: claims, argument and evidence. The top claim is usually that the item is acceptably safe in its intended operating context. It is broken down into narrower claims, for example that each hazard has been identified, that each safety goal is met, or that random hardware failures are detected often enough. The argument explains why the narrower claims together support the top one, and each leaf claim points to evidence such as a hazard analysis, an FMEDA, verification reports or an independent assessment.
The structure is often drawn graphically. Goal Structuring Notation (GSN), maintained as a standard by the Safety-Critical Systems Club's working group, shows claims, reasoning and evidence as linked elements, which makes gaps easier to spot. Text-based cases with clear cross-references are also common.
A safety case is built up over the whole project rather than written at the end: each stage adds work products and evidence, and the argument is updated as the design changes. Scrutiny of the argument and its evidence continues through development, operation and maintenance. Newer standards such as UL 4600, for autonomous products, are written around building and evaluating a safety case rather than following a fixed process.
Examples
- An automotive microcontroller supplier delivering a safety manual and analysis reports that the vehicle maker cites as evidence in its own safety case.
- A GSN diagram whose top goal is that a braking controller is acceptably safe, broken down by hazard and linked to test and analysis reports.
- A developer of a self-driving system building its safety case against UL 4600 for evaluation by an independent assessor.
- An offshore operator submitting a safety case to the UK Health and Safety Executive under the offshore safety case regulations.
Why it matters
For safety-related chips, the safety case is what a customer or assessor ultimately judges. Functional safety managers own the argument, safety engineers produce the analyses that feed it, and assessors check that the evidence is complete and the reasoning holds. A weak case can delay a vehicle programme or require extra analysis late in development.
In the chip lifecycle, the safety case is planned at concept and architecture, grows during design and verification as analyses and test results arrive, is completed with qualification and assessment evidence before production, and is maintained when changes or field issues affect the claims.
It matters most to: Automotive Silicon Functional Safety Manager, Functional Safety Assessor, Functional Safety Engineer, Functional Safety Manager, Safety Work Product Author
Common confusions
- Not the same as a safety manual
- A safety manual tells the integrator how to use a component safely, including its assumptions and required measures. It is one input to the safety case, not the argument itself.
- Not the same as a safety assessment
- The assessment is an independent review of the safety case and the work behind it. The case is what is being judged.
- Not the same as a collection of documents
- Simply gathering reports does not make a safety case. The argument linking the evidence to each claim is the essential part.
Related standards
- ISO 26262 (road vehicles functional safety)
- UL 4600 (evaluation of autonomous products)
Sources
- ISO 26262-1:2018 Road vehicles, Functional safety, Part 1: Vocabulary (opens in a new tab), ISO, 2026-10-22
- UL 4600: Standard for Evaluation of Autonomous Products (edition 3) (opens in a new tab), UL Standards & Engagement, 2026-10-22
- GSN Standard (opens in a new tab), Safety-Critical Systems Club, 2026-10-22
- Offshore safety cases (opens in a new tab), Health and Safety Executive (UK), 2026-10-22
- Safety case (Wikipedia) (opens in a new tab), Wikimedia Foundation, 2026-10-22
Related terms
Part of the Safety & Security glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 14 pages of the Hub. In each group, the pages that mention it most come first.
Lifecycle stages and gates
Skills
Tools
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary