Certification

Try a material grade (A106), a standard (API 5L) or a term (hazardous area).

↑↓ navigate↵ openAll results & filters →
ProcessMechanicalRotating EquipmentElectricalCivil & StructuralInstrumentation & ControlHSEAutomotivePharmaceuticalLearning pathsGlossaryStandardsNotesCertification

Automotive

ISO 26262, HARA and ASIL

How a hazard analysis turns severity, exposure and controllability into an integrity level, what ASIL D actually obliges you to do, why decomposition without independence is fiction, and where functional safety stops and SOTIF begins.

AdvancedAutomotive

Standards referencedISO 26262-3ISO 26262-5ISO 26262-9ISO 21448

Every previous topic in this part described something that can fail. This one is about the discipline that decides, before anything is built, how hard you have to try — and writes the answer down in a way an auditor can check years later.

A functional safety engineering desk, two monitors side by side showing a block diagram of interconnected boxes and a branching tree structure, a large whiteboard behind them covered in a hand-drawn network of boxes and arrows annotated in red, printed analysis spreadsheets fanned across the desk with rows picked out in yellow and pink highlighter, a pen and a closed notebook beside them, an empty chair pushed back and an office beyond the window light.
The analysis is a room full of engineers arguing about one row at a time, and the argument is the point.

What it covers, and what it does not

Functional safety is the absence of unreasonable risk arising from malfunctioning behaviour of electrical and electronic systems.

That definition is narrower than it sounds, and the boundary matters:

Situation Governed by
A sensor fails, a bus goes quiet, a controller computes a wrong value ISO 26262
Everything works exactly as designed, and the design is not good enough for the situation ISO 21448 (SOTIF)
Crash structure, restraints, fuel systems Other standards entirely
An attacker deliberately causes the malfunction ISO/SAE 21434

The hazard analysis

A diagram of hazard analysis and risk assessment. The flow begins with an item definition setting the boundary of what is being analysed, then identifies hazards at vehicle level as events that happen to people rather than as component failures, then combines each hazard with an operating situation to form a hazardous event, then rates that event for severity, exposure and controllability, and finally reads the integrity level from a table and writes a safety goal. Three rating scales are given. Severity runs from S0 for no injuries through S1 light and moderate, S2 severe and life threatening with survival probable, to S3 life threatening with survival uncertain or fatal. Exposure runs from E0 incredibly unlikely through E1 very low, E2 low and E3 medium to E4 high, meaning a situation encountered on most journeys. Controllability runs from C0 controllable in general through C1 simply controllable and C2 normally controllable to C3 difficult to control or uncontrollable. The determination table is drawn as a grid of severity against exposure and controllability, with the quality management cells shaded lightly, the A, B and C cells shaded progressively, and the single cell at severity three, exposure four and controllability three highlighted as the only combination giving ASIL D. A panel warns that controllability is the parameter most often rated optimistically, because every step of optimism drops the integrity level and with it the required rigour and cost, and that the rating must reflect an ordinary driver encountering the event without warning rather than an expert who was expecting it. A further panel notes that a quality management rating is an outcome of the analysis and not an exemption from engineering.
Severity, exposure, controllability. Three judgements, one table, and a number that governs everything after it.

The sequence is fixed:

  1. Item definition — the boundary of what is being analysed, and its interfaces.
  2. Hazard identification, at vehicle level. Not “the resistor fails” but “unintended braking at motorway speed” or “loss of steering assistance in a bend”.
  3. Operating situations — combine each hazard with a situation to form a hazardous event.
  4. Rate S, E and C for each event.
  5. Read the ASIL, write the safety goal.

Step 2 is where analyses go wrong. A hazard is an event in the world, not a failed part. Starting from components gives you a list of failure modes with no way to judge risk, because the same failed component is harmless in one situation and lethal in another.

The three scales
S0 No injuries
S1 Light and moderate injuries
S2 Severe, life-threatening, survival probable
S3 Life-threatening, survival uncertain, or fatal
E0 Incredibly unlikely
E1 Very low probability
E2 Low
E3 Medium
E4 High — a situation encountered on most journeys
C0 Controllable in general
C1 Simply controllable
C2 Normally controllable
C3 Difficult to control, or uncontrollable

And the one cell that gives ASIL D

S3 + E4 + C3. The most severe outcome, in a situation encountered on most journeys, with no realistic prospect of the driver avoiding the harm.

Reduce any one of those by a single step and the answer is ASIL C. Which is precisely why the ratings are argued over.

QM is a real outcome, not an exemption. It means ISO 26262 imposes no additional safety requirements — the item is still developed under a proper quality system, still has to work, and is still someone’s responsibility.

From a safety goal to something buildable

A diagram of the route from a safety goal to a safety case. A safety goal is shown as a top-level requirement stating what must not happen, carrying the integrity level of its hazardous event and accompanied by a defined safe state and a fault tolerant time interval within which that state must be reached, with a note that without the time interval the goal is unbuildable because detecting a fault in two seconds and in twenty milliseconds are different engineering problems. The goal flows into a functional safety concept describing what the system must do, then a technical safety concept allocating that to hardware and software elements, then requirements that inherit the integrity level. ASIL decomposition is shown as splitting an ASIL D requirement across two elements, for example two ASIL B elements or an ASIL C and an ASIL A element, with the notation carrying the original level in brackets, and a prominent warning that the split is only valid where the elements are demonstrably independent. A common cause panel lists the usual ways independence turns out to be false, giving a shared power supply, a shared clock, a shared sensor, identical software written by the same team from the same specification, and shared exposure to heat or vibration, and states that decomposition across dependent elements produces paperwork that reduces the rating without reducing the risk. A metrics panel gives the hardware architectural metrics, the single point fault metric and the latent fault metric with their thresholds rising with integrity level, and the probabilistic metric for random hardware failures with tighter limits at the higher levels. A final panel contrasts fault tree analysis as a top down method starting from an undesired event and working back to causes with failure mode and effects analysis as a bottom up method starting from component failures and working forward to effects, noting that each finds what the other misses and that neither substitutes for the other.
The goal, the concept, the allocation, the evidence. ASIL is inherited all the way down.

Each hazardous event produces a safety goal — a top-level requirement stating what must not happen. It carries the ASIL of its event, and it must be accompanied by two more things:

  • A safe state. What the system goes to. Torque removed, assistance disengaged with a handover, a limp mode, a controlled shutdown.
  • A fault tolerant time interval. How long the system may be in a faulted condition before reaching that state.

Without the interval the goal cannot be built against. Detecting a fault within two seconds and within twenty milliseconds are entirely different engineering problems and cost entirely different amounts.

From there: functional safety concept (what must happen), technical safety concept (which hardware and software does it), then requirements — each of which inherits the ASIL.

Decomposition, and the trap in it

An ASIL D requirement may be split across two elements at lower levels — two at ASIL B(D), or one at C(D) and one at A(D). The bracketed letter records where it came from.

The hardware metrics

For random hardware failures the standard asks for numbers, and the thresholds tighten with the level:

  • Single point fault metric — the fraction of faults that cannot alone violate the safety goal.
  • Latent fault metric — the fraction of faults that cannot sit undetected and combine with a later one.
  • Probabilistic metric for random hardware failures — a rate per hour for the whole item.

These are the reason a safety analysis needs component failure rate data and an FMEDA, not just engineering judgement.

Two analyses, in opposite directions

Fault tree analysis starts from the undesired event and works backwards to combinations of causes. It is good at finding common causes and at showing that a claimed redundancy is not one.

FMEA starts from component failure modes and works forwards to effects. It is good at finding consequences nobody anticipated.

Each finds what the other misses, which is why both are done rather than one.

What to take away

  • Functional safety is about malfunctions. Insufficient performance without a fault is SOTIF, a different standard.
  • Hazards are identified at vehicle level, as events that happen to people.
  • Severity, exposure, controllability — three judgements, one table.
  • ASIL D is one cell: S3 + E4 + C3. Any single step back gives ASIL C.
  • QM means no additional ISO 26262 requirements. It does not mean unimportant.
  • A safety goal needs a safe state and a fault tolerant time interval, or it cannot be built.
  • Decomposition requires demonstrated independence. Without a common cause analysis it is fiction.
  • FTA works backwards from the event, FMEA forwards from the component. Both, not either.

That completes the vehicle systems part of this discipline — from engine cycles and architecture through electrification, networks, perception and diagnostics to the analysis that decides how much rigour each of them deserves. The manufacturing part covers how the components themselves are made, and the two meet in software-defined vehicles and cybersecurity, where a process failure and an engineering failure become the same thing.

Check your understanding

10 questions. Nothing is recorded — this is just for you.

1What does functional safety, as ISO 26262 defines it, actually cover?
2A camera correctly performs every computation and still fails to detect a pedestrian in heavy rain. Which standard governs that?
3At what level must hazards be identified during a HARA?
4What are the three parameters rated for each hazardous event?
5Which combination yields ASIL D?
6What does a QM rating mean?
7What is a safety goal, and what must accompany it?
8What does ASIL decomposition allow, and what does it require?
9Why is a common cause analysis essential to any decomposition claim?
10Why is controllability the parameter most often rated too optimistically?

#vehicle systems#functional safety#ISO 26262#HARA#ASIL#safety goal#decomposition#FMEA#FTA#SOTIF