Safety analysis¶

Safety analysis is the design-time discipline of working out how a system can fail or cause harm, then turning that into requirements and mitigations. It is to safety what threat modeling is to security: a structured analysis rather than a test. Its output supplies the oracle that later verification checks the built system against — a hazard list, a set of failure modes, a catalog of unsafe control actions. It is the first step of verifying safety-critical systems.

What it surfaces¶

Hazards and their root causes: the conditions that lead to harm, decomposed to the faults that produce them.
Component failure modes and their effects: what breaks, and what happens downstream when it does.
Process and parameter deviations: the off-nominal conditions a design has to tolerate or prevent.
Unsafe control actions: commands (or missing commands) that move the system into a hazardous state without any component having "failed."

What it does not do is verify the implementation. Safety analysis reasons about the design: it identifies what must not happen and what to check. It pairs with model checking of the critical logic, testing, and monitoring.

The techniques¶

The established techniques differ in the direction of their reasoning and in what they assume causes an accident. The failure-based methods (FTA, FMEA, HAZOP) treat it as one or more component failures; the systems-theoretic method (STPA) treats it as unsafe control, interactions that go wrong even when every component works as specified.

Fault tree analysis (FTA) (IEC 2006)¹ reasons top-down: an analyst starts from a hazard (the top event) and deductively decomposes it through Boolean gates into the combinations of lower-level faults that cause it, down to basic events. The minimal cut sets (the smallest fault combinations that trigger the top event) are the result, and if basic-event rates are known the top-event probability can be computed. Open tooling exists (SCRAM, the Open-PSA model exchange format); much of the market is commercial (Isograph, Ansys medini).

Failure mode and effects analysis (FMEA) (IEC 2018)² reasons bottom-up: an analyst enumerates each component's failure modes, traces each to its local and system effects, and rates severity, occurrence, and detection to prioritize (the risk priority number, RPN). It is exhaustive over single-component failures but, unlike FTA, largely blind to the combinations and interactions that a fault tree captures. Teams run it in dedicated FMEA tools, and still in spreadsheets.

HAZOP (hazard and operability study) (IEC 2016)³ is guideword-driven: a team walks each design parameter against a fixed set of guidewords (NO, MORE, LESS, REVERSE, AS WELL AS) to provoke the question "what if it deviates this way?" It originated in process and chemical engineering, where the parameters are flows, pressures, and temperatures, and its advantage is systematic, team-based coverage of deviations no single reviewer would enumerate.

STPA (system-theoretic process analysis) (Leveson 2011)⁴ reframes safety as a control problem rather than a failure problem. An analyst models the system's control structure (controllers, actuators, sensors, the controlled process), then identifies unsafe control actions (a command given when it shouldn't be, not given when it should, given too early or too late) and the causal scenarios that produce them. Because it does not start from component failure, it catches what the failure-based methods structurally miss: accidents from software logic, flawed requirements, or human operators in the loop. The open XSTAMPP toolset supports it.

Where it sits¶

The systems-theoretic model matters more as systems become software-intensive and the dangerous behaviors emerge from interactions rather than from the failure of any one part. The STPA-Sec variant applies the same control model to security analysis.

Hazard analysis is a regulatory obligation: avionics (DO-178C (RTCA 2011a)⁵), automotive (ISO 26262), general electronic systems (IEC 61508), and medical-device software (IEC 62304 (IEC 2006)⁶) all require it, with the rigor scaled to the assurance level.

When to use, when not¶

Use it where a failure can cause physical harm and a safety regime applies, and reach for STPA in particular on software-intensive or human-in-the-loop systems.

Don't impose the full ceremony on ordinary business or web software, where the harm from a defect is not physical and the cost is not justified, though asking which control actions would be unsafe can still sharpen reliability thinking there.

Evidence¶

The systems-theoretic case. STPA's argument for finding what the failure-based methods miss is definitional, not statistical: accidents in complex software-intensive systems often arise from unsafe interactions among non-failed components, which a model built on component failure cannot represent (Leveson 2011)⁴.
Provenance, not proof. The failure-based techniques are each codified in an international standard (IEC 2006, 2018, 2016)¹ ² ³, and the safety regimes require hazard analysis (RTCA 2011; IEC 2006)⁵ ⁶. That makes them a regulatory obligation and the field's accepted vocabulary, not evidence that they outperform alternatives or each other.

Classification¶

Quality dimensions: Functionality: safety — design-time hazard analysis, like threat modeling — no input/oracle/guarantee axes. Safety / freedom-from-risk has no separate dimension here; it folds into Functionality (hazard-avoidance verified to an assurance level) and Reliability.
Area: Safety-critical design — avionics, automotive, medical devices, rail, industrial control, energy; any system where a failure can cause physical harm, usually under a functional-safety regime (DO-178C, ISO 26262, IEC 61508, IEC 62304).

Referenced by¶

Verifying safety-critical systems · Methods