A safety case for autonomous systems is the documented argument that a system is sufficiently safe to operate in its intended environment. It starts from the hazard analysis and can be traced from every hazard to the evidence that the hazard is controlled. For automated vehicles, HORIBA MIRA’s framework notes that no single agreed way to structure a safety argument exists yet. The same framework proposes that safety be argued case by case for each system and deployment, not against one universal risk threshold. A case holds up when it is argued for the specific system and deployment, and every hazard in its log can be traced to the evidence that it is controlled.
Building a safety case for autonomous systems that survives the first review
One recognised format is a structured argument in Goal Structuring Notation (GSN) or Claims-Argument-Evidence (CAE). Either notation captures the case as a hierarchy of claims, sub-claims and the evidence behind them.
TechnoLynx can handle the engineering side of such a safety case for autonomous machines such as a forklift-class AMR. That means cataloguing the hazards specific to autonomy behaviour and motion planning in the target environment, running the behaviour and motion-planning validation tests on your hardware and software stack, and checking that the evidence is complete and traceable against both your internal checklist and the customer’s EHS criteria. The first step is a hazard catalogue for the actual site.
Assessors do not read a safety case from cover to cover. A Fennec Engineering guide describes them following threads through a typical 500-page technical file in a four-week review window: they pick a hazard and trace it to the safety function, the requirement, the design decision and the test evidence. Each break in that chain becomes a question, and questions become follow-up rounds. The same guide argues that most safety cases that generate extended review cycles fall short because the documentation does not reflect the engineering, not because the engineering is wrong. It adds that a 700-page case with poor traceability is harder to assess than a 400-page case with clean chains.
GSN and CAE both decompose claims into sub-claims. A vague top claim such as “the system is acceptably safe” is broken down into sub-claims until each leaf can be supported or refuted directly by evidence. The basic concepts of CAE are supported by ISO/IEC 15026-2:2011. A 2021 set of safety case templates for autonomous systems with machine-learning components uses defeaters, which are reasons why a claim might not be supported, together with their mitigations. Identifying and mitigating defeaters is foundational to assurance argumentation. Defeaters are the questions a reviewer will ask, answered before they are asked.
What the customer’s EHS team expects beyond your internal checklist
MIRA’s framework splits a safety case report into evidence on the nature of the vehicle and its operation, safety analysis, testing and verification and validation, and the safety management system, all tied together by a safety argument. It also asks the operator for a separate deployment case covering route-specific hazards, their mitigations and how maintenance keeps the vehicle within specification. The framework separates the Operational Design Domain (the design intent) from a Target Operating Domain (the real deployment location) and requires the two to be checked for compatibility. For a forklift-class AMR, that means documenting the site-specific route hazards and their mitigations, the maintenance regime, and behaviour at the ODD boundary.
Treat internal review criteria and customer EHS criteria as separate sets. Reconcile the two criteria explicitly. Do not assume they overlap. Treat a prior AMR sign-off as a structural template, not as proof of acceptance. MIRA notes that no single agreed way to structure a safety argument exists yet. A borrowed package also assumes a comparable hazard profile and environment. If the EHS expectations are unknown, ask early. The JARUS SORA methodology for drones recommends contacting the competent authority as early as possible to reach in-principle agreement on the safety claims, and the ORR’s rail guidance recommends involving the assessment body from the start of a project. Test reports belong in the package as evidence, but a perception validation pack is not a safety case on its own: a safety case is an argument linking hazards to evidence, and test results are only the evidence.
How should a hazard log link each hazard to its FMEA row, mitigation and evidence?
Keep the hazard log as one traceable record. In it, each hazard’s risk management and safety decisions stay traceable, and links between the argument, fault trees, FMECAs and system artefacts propagate changes both ways. The UK MOD’s SMP11 procedure uses Def Stan 00-56’s definition of the hazard log: the continually updated record of hazards, accident sequences and accidents, including the risk management for each hazard. SMP11 treats it as the configuration control mechanism for safety assessment and the primary source of the safety case’s arguments.
SMP11 sets several rules for maintaining the log. Hazards are not deleted from the log. They are closed and marked “out of scope” or “not considered credible”, with the justification recorded. SMP11 considers it best practice to keep a hazard open, with its ALARP argument provisional, until every mitigation action is confirmed complete. Closure records refer to the evidence and to the ALARP justification. Because the log could be referred to in legal proceedings, every effort should be made to keep its records accurate, attributable, up to date and complete, with clear cross-referencing to supporting documents.
The FMEA and fault tree connect to the argument directly. A paper on safety-analysis traceability links an evidence node in the GSN argument to the root node of the fault tree it relies on. BMW’s SIFAD framework records each hazardous event as a scenario paired with a system behaviour, so the log stays at vehicle level whatever the underlying cause. For driverless industrial trucks, ISO 3691-4 gives the starting list: hazards are taken from its Annex B, and the required Performance Level for each safety function comes from its Table 1.
Hazard log row: the fields a reviewer will trace
| Field | What it holds |
|---|---|
| Hazardous event | The scenario and the system behaviour assessed as a pair |
| Source | The Annex B hazard of ISO 3691-4 |
| Safety function and target | The function and its required PL or SIL, stated next to the risk analysis that set it |
| Mitigation and owner | The agreed control and the person responsible for putting it in place |
| Verification evidence | The artefact showing the requirement is met, with its representativeness justified where it is simulation or lab data |
| Residual risk | How the hazard was evaluated and either further mitigated or formally accepted with an ALARP justification |
| Status | Open, or closed with evidence and justification; never deleted |
A traceability matrix mapping the requirements to each known hazard can support the completeness claim, showing the safety analysis covers every identified hazardous situation. For e-stop and obstacle-avoidance results, present each result against its hazard with the test conditions, the measured value, the pass threshold and the location of the raw data. Under ISO 3691-4 the safety-related control parts for personnel detection and braking must meet PLr d, according to TÜV Rheinland’s reading of the 2020 edition. In our judgement, simulation results can support these entries, but they rarely close a hazard without physical timing and avoidance trials alongside them.
If AI assistants draft FMEA rows from test logs, treat each row as a proposal that a qualified engineer approves before it enters the log. This matches the templates’ insistence that requirements and analyses are reviewed by suitably qualified and experienced personnel.
Which site differences should trigger a full new hazard analysis?
Score how far a new site or mission departs from the nearest approved one. Route low-delta expansions through a documented checklist review. Send anything that crosses a threshold on any one dimension, or adds up across several, to a full hazard re-analysis. This shape has precedent in rail, drone and automotive guidance. None of that precedent was written for AMRs, so the transfer has to be argued.
One precedent is the rail Common Safety Method for Risk Evaluation and Assessment. In the ORR’s guidance, the proposer judges a change’s significance against six criteria: failure consequence, novelty, complexity, monitoring, reversibility and additionality. The proposer must document those decisions, and the independent assessment body cannot overturn the significance decision itself. MIRA’s framework gives each change a safety status such as none, minor or major. Significant changes must be agreed with the approval authority before operation, and others can be accepted through approved safety-management processes without reissuing the safety case report. JARUS SORA applies the same idea to evidence: an aircraft flying over a large city near an airport must demonstrate more to the authority than the same aircraft at a closed test range.
An ISO 26262 hazard analysis of an automotive depot autonomy system shows how far integrity requirements shift with the operating scenario. Integrity requirements ranged from QM to ASIL C depending on speed and pedestrian access, which led to a phased rollout from controlled low-speed operation to high-speed controlled and finally uncontrolled operation.
Site attributes to score for a mobile robot fleet
| Site attribute | Where it comes from | A delta that warrants full re-analysis |
|---|---|---|
| Operating zone class | ISO 3691-4 defines its zones, adding a confined zone, distinguished by active or inactive personnel detection | Entering a zone class not yet approved |
| Speed and pedestrian access | The depot study scored nominal versus high speed against controlled versus uncontrolled access | Moving from controlled to uncontrolled access, which raised several goals’ ASIL in that study |
| Environment outside standard scope | ISO 3691-4 excludes severe conditions such as freezer applications, public zones and explosive atmospheres | Any excluded condition |
| Novelty, monitoring, reversibility | CSM REA significance criteria | A capability new to the organisation, or a change that cannot be monitored or reverted |
| Additionality | CSM REA: recent changes judged individually not significant | Several small changes since the last full analysis that together amount to a large one |
The attribute list is the weak point of this scoring template. A hazard factor you never scored can let a risky site pass as routine. Recalibrate the thresholds against incident and near-miss data as the fleet accumulates experience. Document each tiering decision, as the CSM REA requires proposers to do for significance.
Turning pilot hours and e-stop times into a residual risk figure
Residual risk becomes a number once each hazard has an acceptance target and the evidence gives a conservative upper bound on the achieved rate. The target derives from the hazard analysis and is expressed as a tolerable rate or a SIL or PL. The bound is then compared with the target. Formally, the target is an upper limit on expected harm per unit of operation, E[H] < ε, for some small ε.
TechnoLynx can build the statistical pipeline that turns field-pilot hours and e-stop response measurements into residual-risk figures with stated confidence. It can also run the gap analysis that shows which scenario classes are still untested, and document the results for compliance review. The first step is mapping each hazard to its required SIL or PL target under the applicable standards. TechnoLynx treats this kind of evidence as an engineering output in its own right: a compliance owner who is not an engineer should be able to read the bound, its assumptions and its data, and sign against it.
The SIL or PL target differs from one safety function to another. Targets come from the hazard analysis. According to TÜV Rheinland’s reading of ISO 3691-4:2020, the standard lists 27 safety functions, each with a minimum required PL under ISO 13849-1, and IEC 61508 defines SIL bands as ranges of probability of failure on demand. In process-industry practice, the tolerable risk for each scenario is set by company policy or regulation, and the gap between unmitigated and tolerable risk sets the SIL. For rail, the CSM REA lets a function whose failure could directly cause a catastrophic accident stop further risk reduction at 10⁻⁹ failures per operating hour, and a critical one at 10⁻⁷. A claimed PL also depends on the architecture category. Siemens’ guidance on ISO 13849-1 caps the credited MTTFd per channel at 100 years (2,500 years for Category 4) and requires a common-cause-failure score of at least 65 points from Category 2 upwards. The chosen standard’s scope also matters. ISO 3691-4:2023 excludes trucks intended for public zones or public roads.
Worked example: why incident-free hours cannot carry a 10⁻⁷ claim alone
Assume hazardous events follow a homogeneous Poisson process, a standard risk-assessment model, and that none has been observed in T operating hours. The one-sided upper bound on the rate at confidence 1 − α is then −ln(α)/T. At 95% confidence, −ln(0.05) ≈ 3.0, so the bound is roughly 3/T. To show a failure rate at or below the CSM REA’s 10⁻⁷ per operating hour, T must be at least 3.0 × 10⁷ event-free hours, which is about 3,400 years of one machine running continuously (3.0 × 10⁷ ÷ 8,766 hours per year). The confidence level you choose matters a great deal: one 2025 analysis of ISO 21448 notes that moving from 67% to 99% confidence multiplies the required test distance by 4.6.
This is what BMW’s SIFAD authors call the approval trap: proving a black-box failure rate by field testing alone would need a large fleet and many years. RAND reached the same conclusion for road vehicles in 2016. The workable route is decomposition into component-level analyses. A 2021 component-level method splits a vehicle-level collision target into an exposure rate and a per-demand failure probability, bounds each one separately, and combines the confidences as 1 − (α₁ + α₂). For an AMR, the natural split is how often a person enters the protective field per hour, and how likely it is that detection and braking fail to stop the machine in time. Measured worst-case e-stop response feeds the second term through the stopping-distance check against the protective field. Pilot hours then corroborate the exposure model instead of carrying the whole claim. Credit for redundant channels is only valid after an independence analysis, because shared failure modes undo the decomposition.
Do we have enough test coverage, or are scenario classes missing?
Coverage is adequate only when the validated scenarios span the reasonably foreseeable events the risk assessment implies. MIRA requires evidence that the sample is large and well distributed across reasonably foreseeable events, with a justified method for selecting tests. Under ISO 21448, V&V must also show that residual risk from unknown hazardous scenarios meets the acceptance criteria. Treat untested low-light and occluded-pedestrian cases as open gaps. Close them, or risk-assess them explicitly, before claiming compliance. E-stop timing tells you nothing about detection in conditions you never tested. Waymo’s 2025 readiness guidelines make the same point at fleet scale: no single methodology or criterion is enough to establish absence of unreasonable risk on its own.
Can simulated miles be scored against ISO 34502?
ISO 34502 gives a published scenario-based safety evaluation process that a simulation campaign can be structured around. Two limits apply. First, the standard’s scope is automated driving systems on limited-access highways, so for a mobile robot or drone it is a borrowed structure, not the applicable standard. Second, mapping simulated miles onto its categories does not make them equivalent to real miles: scenario-based testing has no direct quantitative link to mileage.
The structure is still worth borrowing. Structured risk factors produce a scenario catalogue designed to maximise coverage of known hazardous scenarios. For a robot or drone simulation campaign, the parts worth borrowing are the risk-factor structure and the coverage argument. A scenario taxonomy and hazard catalogue that holds up across ODD expansion is the deeper treatment of that coverage work.
The board may also ask you to justify the simulation itself: MIRA requires the representativeness of simulation and lab evidence to be justified, and one 2025 review finds that sensor, environment and vehicle model fidelity still limit full virtualisation. Scenario-based testing still requires broadly accepted coverage metrics and thresholds, the same review notes. Treat any claim that simulated miles substitute for real ones as a separate argument, which the standard’s structure supports but does not prove.
Proving a corrective action removes the failure mode, not just the incident
A corrective action counts when it eliminates, mitigates or prevents the root cause, so the design or process no longer produces this failure on this type of unit. Retest evidence must show the effect. The FAA’s advisory circular on 14 CFR 437.73 warns that without root cause analysis, the chance that only the proximate cause gets fixed rises, and the problem returns. The circular lists analysis, test, demonstration and inspection as ways to verify that corrective actions are effective. It also says anomaly reporting should be closely linked to the hazard analysis.
For autonomy, the mechanism behind a failure is not always an implementation defect. Koopman’s 2024 analysis of the Cruise pedestrian-dragging mishap notes that no hardware or software failure was identified, which points to insufficiencies beyond implementation defects. The fix therefore has to be argued at the level of the mechanism: name the class of scenarios that share it and re-verify across that class, not only the incident replay. Where root cause cannot be determined, a residual risk assessment and escalation to higher management take the place of a clean closure.
Designing a limited field trial that corroborates a fix
Run a limited trial in stages. Validate the fix in hardware-in-the-loop and simulation first. Then propose a small number of supervised trials near representative obstacles, not at the incident site, inside a deliberately conservative envelope, with telemetry rich enough to reconstruct every decision. Agree the number of trials with the specific regulator.
The regulatory context sets the boundary. MIRA’s framework describes regulatory notices that limit operation until remedial action has taken place and been re-approved, so the trial plan has to fit inside whatever the notice permits. Simulation, including X-in-the-loop testing, saves time and cost and is safer than field testing, but it threatens validity unless the models are valid and complete. NASA’s GL-10 flight campaign shows envelope discipline in practice: the team imposed an operational wind limit found necessary in testing, and defined safe altitude as “two mistakes high”, around 300 ft above ground. SORA allows the results of the requirements phase to form the basis of a pre-application evaluation by the competent authority. That is a sensible point to agree the trial protocol before any flight.
For telemetry, the 2024 ASSURE A55 report recommends logging sensor inputs, algorithmic decision pathways and control command outputs. It argues that for autonomy levels 3 to 5, recording all inputs and outputs of the AI system is important for telling faulty hardware from automation error. It also recommends redundant recording and encryption to protect data integrity. Add synchronised timestamps across all streams so each decision can be placed against what the sensors saw. Recorder standards are not harmonised across jurisdictions, so confirm the logging specification with the specific regulator before the first trial.
Keeping the case current when the hazard log changes
A safety case is a web of interdependent requirements, argument, evidence and context, so a single change can ripple through many others. One published change method uses the goal structure itself. Changing a goal, strategy or solution challenges the elements above and below it, and changing a context element challenges every child that inherits that context. Recovery then means weakening the requirement, restricting the context, or finding new evidence. The right choice is made case by case. Tooling helps. Bidirectional links between design artefacts, fault trees, FMECAs and the argument can push change notifications across all linked safety artefacts.
Two habits make a case cheaper to keep. Build in safety margins, so that evidence exceeding its requirement acts as a “crumple zone” when the evidence is later weakened, and support key claims with diverse, independent evidence. Then monitor in service. UL 4600 defines a safety performance indicator as a metric, supported by evidence, that uses a threshold comparison to condition a claim in the safety case. The standard states that relying solely on lagging indicators is not acceptable. Depending on the risk, responses to an indicator breach range from reducing speed to geofencing or grounding the fleet.
Acceptance is argued case by case for each system and deployment. MIRA’s framework says the aggregated evidence leads to an assertion of safety with a stated level of statistical confidence, and that policy-makers must then judge whether it is certain enough. The engineering job is to make that judgement fast. Each bound, assumption and open gap should be visible on the page next to the hazard it belongs to, so the reviewer spends the four weeks deciding, not searching.
FAQ
What is the difference between an FMEA and a risk analysis?
An FMEA identifies the possible failure modes of individual components, systems, subsystems or processes. An explicit risk analysis combines how often a hazardous event occurs with how severe its harm is.
What is a safety assessment, and how does it relate to a safety case?
A safety assessment is the analysis whose results a safety case summarises. A safety case is not an alternative to it: the safety case structures and documents a summary of the assessment’s results so that a reader can follow why the system is considered safe.
