How to build a robotics safety case

What is a safety case?

GSN, CAE, and assurance case fundamentals

A safety case is a structured argument — supported by evidence — that a system is acceptably safe to operate in a defined context. It is not a document you write at the end of a project. It is a living artifact built throughout development.

The dominant notation is Goal Structuring Notation (GSN), which makes the argument explicit: goals, strategies, solutions, and the context that scopes each claim.

• Goal Structuring Notation (GSN) — goals, strategies, solutions, context
• Claims-Argument-Evidence (CAE) structure
• What counts as evidence — test results, analysis, field data
• Tooling: ASCE, Astah GSN, AdvoCATE
• Common failure modes — circular arguments, unsubstantiated claims

Which standard applies to your system?

Navigating the robotics and AV standards landscape

The answer depends on your system type, domain, and geography. These are the standards that matter most for robotics and autonomous systems.

Hazard analysis and risk assessment

HARA, SOTIF analysis, and ODD definition

Before you can argue a system is safe, you must identify what could go wrong and under what conditions. For AV and robotic systems, this is complicated by the fact that many failures are not random hardware faults — they are systematic, ML-driven, or scenario-dependent.

• HARA methodology — hazard identification, exposure, severity, controllability
• ASIL determination and decomposition
• Operational design domain (ODD) — defining the envelope your safety case covers
• SOTIF triggering conditions — known and unknown unsafe scenarios
• V&V strategy for ML and AI components
• Residual risk and acceptance criteria

Building and running a safety management system

The organizational infrastructure behind a safety case

A safety case without a functioning SMS behind it is a document, not a system. The SMS is the set of processes, roles, and governance that keep the safety case valid as the system evolves.

• Safety policy, objectives, and plans
• Hazard log — structure, ownership, and lifecycle
• Functional safety management roles and independence requirements
• Supplier safety management — what to require, how to audit
• Change impact analysis — keeping your safety case current
• Safety audits and confirmation measures