STPA in ISO 26262: Finding Hazards When Nothing Fails

FMEA starts from a part and asks how it can break. FTA starts from an unwanted event and works down to the combinations of events that could cause it. Both are good at what they do, and in most projects both are driven by the same question: what has to fail for this to go wrong?

Some hazards do not need that. Every sensor reads correctly, every controller executes its requirements, every actuator delivers what it is asked for, and the vehicle still ends up somewhere it should not be. STPA (System-Theoretic Process Analysis) was built for that case. It models the system as control loops and asks when a control action that looks correct becomes unsafe in a particular context.

A one-pedal descent

Take a fictional electric car with one-pedal driving. When the driver lifts off the accelerator, the powertrain controller requests negative motor torque and the car slows at up to about 0.2 g without touching the brake. Drivers adapt within a day and start using lift-off to slow down for junctions.

The car is charged to 100% overnight outside a house at the top of a long hill, and the morning is cold. The battery management system limits charge current, because a full, cold lithium-ion cell must not be charged hard. That limit is correct, and it is what the cell supplier asked for. The powertrain controller reads it and cuts regenerative torque to almost nothing, which is what its own requirement says. The inverter delivers the reduced torque exactly. A small "regen limited" icon lights up in the cluster when the car is switched on, as specified.

At the bottom of the first descent the driver lifts off, expecting the usual deceleration, and the car coasts. The foot reaches the brake pedal later than it would in a car where lifting off had never meant braking. No part failed.

Why a failure-driven analysis misses it

Run an FMEA on this powertrain and every row describes a broken part: a current sensor stuck high, a temperature sensor drifting, a lost message on the bus. The charge limit appears nowhere, because no component has a failure mode that produces it. An FTA with "no deceleration after lift-off" as the top event could hold the scenario, because a fault tree may combine operating conditions with design properties. A branch joining "regeneration limited by a full, cold battery" and "no friction braking blended in" describes it exactly. Nothing in the method asks for that branch, though. A tree built by breaking the top event down into component faults, which is how most are built, only contains it if an analyst already thought of the condition.

STPA starts from control, not from parts. It draws who controls what, including the driver as a controller, and for each control action it asks in which contexts that action, or its absence, leads to a hazard. Here the control action is the regenerative deceleration the powertrain controller commands on lift-off. Withholding it is unsafe in one specific context: the driver expects one-pedal deceleration and is relying on it to slow down for something ahead. That is an unsafe control action, and nobody had to break anything to find it. Nobody had to think of the full battery first either: the method asks, for every control action in the structure, when its absence would be unsafe, so it prompts the search for that context instead of leaving it to someone's memory.

The mismatch sits in a process model

The second half of the analysis explains how the unsafe control action can happen. STPA does this through process models, the picture each controller holds of what it controls. The powertrain controller's picture is accurate: it knows the battery is full and cold. The driver's picture is out of date: lifting off slows the car, because it always has. The feedback that could correct it is an icon shown minutes before it matters, while the driver is still on the driveway.

Written down this way, the scenario points at design decisions rather than reliability improvements. Blending in friction braking would keep the deceleration the driver has learned. A warning at the moment of lift-off would update the driver's picture when it counts. Each is a candidate constraint that still has to be assessed, allocated and verified like any other requirement.

Where the result goes in an ISO 26262 project

ISO 26262 does not mention STPA. ISO 26262-3:2018, Clause 6 leaves the choice of hazard identification technique to the team and names FMEA approaches and HAZOP as suitable. ISO 21448:2022, Annex B includes an STPA example built around a highway pilot, and at its end the causes split: failure-related ones are carried into the ISO 26262 technical safety concept, and functional changes stay with ISO 21448.

The regen case shows why that split matters. "No deceleration after lift-off" is a vehicle-level behaviour that a fault could also produce, for example a battery temperature sensor that reads far too cold. So it is a hazard candidate for the HARA, where it gets rated and, if needed, a safety goal. The full-battery scenario has no fault in it, and no diagnostic or safe state would ever have caught it. Its fix is a change to the function's specification. STPA found both from the same control action.

The STPA concept page takes the method through every step on a complete worked example: losses and hazards, the control structure, the unsafe control action table, loss scenarios, how results are handed over to the HARA and the safety concepts without being renamed, and the errors reviewers catch most often. To practise on a control structure of your own, use the STPA simulator.