Part 5 · SOTIF & Validation

5.4 Hazard analysis

Identifying hazards with HARA and STPA

10-minute readPrerequisites: 5.1 What is SOTIF?, 4.7 Three pillars of safety (ASIL)▶ Video coming soon

What you will learn

Explain the purpose of hazard analysis and the differences between the main methods (HARA, FMEA, FTA, STPA)
Build up the probability of causes with AND and OR in a fault tree (FTA) and calculate the effect of common causes
Identify unsafe control actions with STPA’s four types and link their causal scenarios to SOTIF’s triggering conditions

Build intuition

As we saw in 4.7 and 5.1, safety work starts by identifying “what dangers are possible”. This is hazard analysis. A hazard that is overlooked gets no measures and no tests, so any gap here turns straight into an unknown hazard (area 3 of 5.2). The main methods are:

Method	Approach	Good at	Mainly used in
HARA (hazard analysis and risk assessment)	Identifies, situation by situation, the hazardous events that occur when a function does not work properly, and rates them by severity, exposure and controllability	Comparing the size of dangers and setting targets (such as ASILs)	Functional safety (ISO 26262); SOTIF uses the same idea to evaluate harm
FMEA (failure mode and effects analysis)	Lists each way a part can fail and traces its effect on the whole, from the bottom up	Identifying the effects of part failures	Functional safety
FTA (fault tree analysis)	Puts an undesired event at the top and breaks its causes down, from the top, with AND and OR	Combinations of causes and estimating probabilities	Functional safety, SOTIF
STPA	Draws the system as a control structure — “who instructs what, and how are they informed” — and looks for unsafe control actions and their causes	Interactions without faults; the division of roles between people and the system	SOTIF, automated driving

FMEA and FTA were originally methods that start from “a part breaks”. STPA (System-Theoretic Process Analysis), by contrast, is suited to finding dangers that arise even when every part works to specification — dangers from interactions between parts, or between people and the system. That is why it fits well with SOTIF.

STPA draws the system as a control structure. The controller (an automated driving system, or a driver) issues control actions (braking and so on) based on its internal model (the process model: its understanding of what is going on around it), and learns about the state of the controlled process (the vehicle and its surroundings) through feedback (sensors).

STPA control structure (schematic). Even with nothing broken, if feedback fails to arrive and the process model drifts from reality, an unsafe control action results.

In the example in the figure, nothing is broken. But because low sun blocks the feedback, the process model drifts from reality to “nothing ahead”, and the result is the unsafe control action “no braking”. STPA looks for such “gaps between model and reality” as causes of danger.

Check with math

① Building up the probability of causes with a fault tree

Take “not braking for a pedestrian ahead” as the top event and break down its causes. Suppose it happens if both the camera and LiDAR miss the pedestrian (AND), or if planning wrongly decides “no need to stop” (OR). By the rules of 1.1, AND is multiplication and OR is (for small probabilities) addition:

$$P(\text{top}) \approx P(\text{camera})\,P(\text{LiDAR}) + P(\text{planning})$$

With camera 5%, LiDAR 10% and planning 0.1%, and the camera and LiDAR independent, this is 0.05 × 0.1 + 0.001 = 0.006. But if a condition that makes both miss at once (a common cause), such as dense fog, occurs in 1% of situations, that alone adds 0.01, bringing the top-event probability to about 0.016 — more than twice the estimate that assumed independence (illustrative numbers). FTA makes visible which combinations of causes matter, and alerts you to pitfalls such as common causes.

② STPA: identifying unsafe control actions by four types

For each control action, STPA considers unsafe control actions (UCAs) of four types. Here is the example of automatic braking:

Type	Example unsafe control action
Not providing it causes a hazard	Not braking although a pedestrian is crossing ahead
Providing it causes a hazard	Braking hard with nothing ahead while a vehicle is close behind
Wrong timing or order causes a hazard	Braking too late to stop in time
Wrong duration causes a hazard	Continuing to brake after the danger has passed; releasing the brake before stopping

The key is to state “in what situation” for every UCA. The same hard braking is not dangerous if there is no vehicle behind. Combining the conditions that describe the situation increases the number of cases to consider. With three control actions (brake, steer, accelerate) and four situation conditions of two or three levels each (3 × 2 × 2 × 3 = 36 combinations), there are

$$3 \times 4 \times 36 = 432\ \text{cases}$$

to check. Tables are used to work through them without gaps, and cases that are clearly not hazardous are set aside with a stated reason. Once a UCA is found, the causal scenarios that could produce it are sought: “feedback missing or wrong” (insufficient sensor performance), “process model drifting from reality” (objects absent from the training data), “control procedure not designed for the situation” (insufficient specification) and so on. These are exactly the candidate functional insufficiencies and triggering conditions of 5.3.

③ HARA’s scales are rough guides to probability

ISO 26262 gives example figures as guides for HARA’s exposure (E) and controllability (C). In summary, E is a scale of “what share of driving time is spent in the situation” (E2 roughly under 1%, E3 1–10%, E4 10% or more), and C a scale of “what share of drivers and other road users can avoid the harm” (C1 99% or more, C2 90% or more, C3 under 90%).

For example, for “unintended hard braking on a motorway”, if 10% of driving time is on motorways (E4) and 10% of following vehicles cannot avoid a collision (C2), the share of hard-braking events leading to harm is roughly

$$P(\text{situation}) \times P(\text{unavoidable}) = 0.1 \times 0.1 = 0.01$$

Combined with severity S3, this gives ASIL C, as in 4.7. The scales are coarse so that the size of dangers can be compared even early in development, when precise figures are not yet known. SOTIF, for its part, does not assign ASILs; it evaluates the severity and avoidability of harm in the same way and judges whether the result is acceptable (5.5).

Summary

Hazard analysis identifies and evaluates possible dangers. HARA evaluates the size of hazardous events, FMEA and FTA look for the causes of faults, and STPA looks for dangers from interactions without faults
FTA builds up causes with AND (multiplication) and OR (addition), and makes visible how common causes can push probabilities up sharply
STPA identifies unsafe control actions by four types and, from causal scenarios such as missing feedback or a process model drifting from reality, leads to SOTIF’s triggering conditions. HARA’s scales serve as rough guides to probability

Quick quiz

Q1. Which of STPA’s four types is each unsafe control action? (a) Braking hard with nothing ahead while a vehicle is close behind. (b) Not braking although a pedestrian is crossing. (c) Braking too late to stop.

(a) Providing it causes a hazard; (b) not providing it causes a hazard; (c) wrong timing or order causes a hazard.

Q2. In the fault tree of ①, with camera 10%, LiDAR 10% and planning 0.2%, what is the top-event probability? (Assume the camera and LiDAR are independent.)

0.1 × 0.1 + 0.002 = 0.012, about 1.2%.

Q3. What is the ASIL of a hazardous event rated S2, E3, C3?

2 + 3 + 3 = 8, so ASIL B (the adding-up rule of 4.7).

Q4. “We examined every way the parts can fail with FMEA and found no hazards, so the system is safe.” What is wrong with this view?

FMEA starts from part failures, so it has difficulty finding dangers that arise with nothing broken (SOTIF) or from interactions between parts, or between people and the system. It needs to be supplemented, for example with STPA.