AD-19 — Functional Safety (ISO 26262): HARA, ASIL and Safety Goals

FACT — Functional safety has a precise meaning: the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic (E/E) systems. Every word here is deliberate — the question is not “was the system designed correctly,” but “what happens when the system fails.” A camera algorithm making a wrong decision while functioning exactly as designed, with no fault present — say, misclassifying an unusual object it never saw in training — is not an ISO 26262 problem at all. That is the domain of SOTIF (ISO 21448), which we cover in AD-20.

In this lesson, you will learn:

1. The Precise Definition of Functional Safety and Its Boundary With SOTIF — “a fault occurred” versus “no fault, but a limitation.”
2. ISO 26262 Scope, Structure, and the V-Model — from the concept phase through production.
3. HARA: Hazard Analysis and Risk Assessment — Severity (S), Exposure (E), Controllability (C).
4. The ASIL Determination Matrix — how S/E/C combinations map from QM to ASIL D.
5. Safety Goals and Cascading Requirement Derivation — from HARA to Technical Safety Requirements.
6. Case Study: Unintended Acceleration Due to ACC Malfunction — a simplified end-to-end HARA.
7. Hardware Fault Metrics: SPFM, LFM, PMHF — the concrete numerical targets behind ASIL D.
8. FTTI and the Safe State — how quickly a fault must be arrested before it becomes a hazard.

---

1. The Precise Definition of Functional Safety and Its Boundary With SOTIF

ISO 26262 exists to reduce the risk from E/E systems in road vehicles caused by random hardware faults (e.g., a transistor shorting, a memory bit-flip) or systematic faults (e.g., a logic error in software, a gap in a requirements specification) to an acceptable level.

CRITICAL — The two concepts most often confused in automotive safety engineering:

• ISO 26262 (Functional Safety): “What happens when something breaks?” — a short circuit, memory corruption, a software lockup, a sensor hardware fault.
• ISO 21448 / SOTIF (AD-20): “What happens when nothing is broken, but the sensor’s physical limits or the algorithm’s inability to generalize beyond its training distribution causes a wrong decision?”

These two standards complement each other; neither substitutes for the other. A safety case for an ADAS system must cover both — a system that passes ISO 26262 but never addressed SOTIF can still be dangerous, and vice versa.

This lesson focuses on ISO 26262’s fault-driven world; in AD-20 we extend the same reasoning to “nothing failed, yet it was still unsafe” scenarios.

---

2. ISO 26262 Scope, Structure, and the V-Model

ISO 26262:2018 spans 12 Parts and covers the entire automotive E/E system lifecycle — concept, system/hardware/software development, production, operation, service, and decommissioning. At its core sits the classic V-Model process architecture, where requirements on the left leg (specification) map symmetrically to verification activities on the right leg (validation):

ISO 26262 V-Model (Simplified):

  Left Leg (Specification)              Right Leg (Verification/Test)
  ─────────────────────                 ─────────────────────────
  Item Definition
        │
        ▼
  HARA (§3)  ───────────────────────────►  Safety Validation
        │  Safety Goals (ASIL)                        ▲
        ▼                                              │
  Functional Safety Concept  ────────────►  System Verification (Sys. Test)
        │                                               ▲
        ▼                                              │
  Technical Safety Requirements  ────────►  Integration Test (HIL/SIL)
        │                                               ▲
        ▼                                              │
  Hardware / Software Design  ───────────►  Unit Test
        └──────────────► Implementation ◄──────────────┘

Every left-leg artifact must be traceable to a corresponding right-leg verification activity — a Technical Safety Requirement is meaningless without a concrete test that verifies it. This traceability chain forms the backbone of the Safety Case documentation demanded at audit. We detail the right-leg test tiers (MIL/SIL/HIL/VIL) in AD-22.

---

3. HARA: Hazard Analysis and Risk Assessment

Once an item is defined, the first step is HARA (Hazard Analysis and Risk Assessment): systematically enumerating the hazards that can result from the item’s malfunctioning behaviors, and rating each one along three independent parameters.

Parameter	What It Measures	Levels	Upper-Bound Example
Severity (S)	Degree of likely injury from the resulting accident	S0 (no harm) → S1 (light/moderate) → S2 (severe, survival probable) → S3 (critical/fatal, survival uncertain)	S3: impact speed/direction carries a fatal injury potential
Exposure (E)	Statistical frequency of the operational situation in which the fault occurs	E0 (incredible) → E1 (very low) → E2 (low) → E3 (medium) → E4 (high)	E4: a situation present for a large fraction of driving time (e.g., highway cruising)
Controllability (C)	Ability of an average driver (or the system) to avert the hazard in time	C0 (controllable) → C1 (simply controllable) → C2 (normally controllable) → C3 (difficult/uncontrollable)	C3: more than 90% of drivers cannot avoid the accident

WARNING — S/E/C values should be assigned not by subjective engineering judgment alone but backed, as much as possible, by statistical accident data, driving data, and human-factors studies. ISO 26262-3 Annex B gives guidance definitions for the three parameters, but the final rating is the responsibility of the OEM’s own HARA team (typically cross-functional: safety engineering, human factors, legal) and must be defensible under audit.

---

4. The ASIL Determination Matrix

The ASIL (Automotive Safety Integrity Level) is derived by mapping the S/E/C triple through a standardized lookup table. The result is one of five levels: QM (Quality Management — no dedicated safety process required, standard quality management suffices), A (least stringent), B, C, D (most stringent).

S \ E \ C	C1 (simple)	C2 (normal)	C3 (difficult)
S1, E1	QM	QM	QM
S1, E2	QM	QM	QM
S1, E3	QM	QM	A
S1, E4	QM	A	B
S2, E1	QM	QM	QM
S2, E2	QM	QM	A
S2, E3	QM	A	B
S2, E4	A	B	C
S3, E1	QM	QM	A
S3, E2	QM	A	B
S3, E3	A	B	C
S3, E4	B	C	D

ASSUMPTION — The table above is an educational, simplified reconstruction of the ASIL-determination logic in ISO 26262-3 Annex B. The standard itself is copyrighted text; for exact cell values and footnotes, consult the original ISO 26262:2018 Part 3. The goal here is to convey the correct structure and logic of how S/E/C combine.

The engineering conclusion that falls out of the matrix is straightforward:

$\mathrm{ASIL} = f(S, E, C), \qquad S3 \wedge E4 \wedge C3 \;\Rightarrow\; \mathbf{ASIL\ D}$

This is why steering and braking malfunctions are so often rated ASIL D: at speed (E4 — frequent exposure), a malfunction is often severe enough to be fatal (S3), and drivers cannot reliably counteract a sudden, unexpected steering or braking event within a fraction of a second (C3). By contrast, a low-severity comfort function operating at low speed (say, a seat-heater fault) is typically rated QM — it needs no dedicated ISO 26262 process, only standard quality management.

---

5. Safety Goals and Cascading Requirement Derivation

For every hazard identified in HARA, exactly one Safety Goal is written. A Safety Goal is the top-level requirement the system must satisfy to avoid or mitigate that hazard, and it directly inherits the ASIL determined in HARA.

HARA → Safety Goal → Functional Safety Concept → Technical Safety Requirements → Implementation
  │         │                    │                          │                        │
  │   "Prevent            "Monitor torque via a      "Second microcontroller    Hardware/software
  │   unintended           second independent          cross-checks torque       design + verification
  │   acceleration"        path; cut torque if         within ±5ms; on           evidence
  │   (ASIL D)             deviation exceeds X Nm      mismatch, disable the
  │                        within 100ms"                MOSFET gate driver"
  └── Hazard: "Unintended acceleration
      due to ACC malfunction"

Every arrow shows the ASIL rating cascading downward unchanged — if the Safety Goal is ASIL D, the Technical Safety Requirements realizing it (unless formally decomposed, see ASIL decomposition) are developed under the same ASIL D process rigor. HARA is therefore not a paper exercise; it directly determines how stringently each component must be designed and verified.

---

6. Case Study: Unintended Acceleration Due to ACC Malfunction

EXAMPLE — Let’s walk through a simplified HARA: the Adaptive Cruise Control (ACC) module sends an erroneous torque command to the powertrain control unit, causing unintended acceleration.

Step 1 — Define the hazard: A logic error in the ACC software, or a fault in the sensor-fusion layer, causes the system to misjudge the lead vehicle’s motion and generate a spurious acceleration command.

Step 2 — Assess Severity (S): ACC is typically active at moderate-to-high highway speeds. An uncontrolled acceleration event carries the risk of a frontal collision or a lane departure → S3 (potentially fatal).

Step 3 — Assess Exposure (E): ACC is continuously active while enabled, and many drivers use it for the majority of long highway trips → E4 (high exposure).

Step 4 — Assess Controllability (C): The driver can cancel the acceleration by braking — a recovery path exists. But surprise (a driver trusting ACC may have disengaged attention from the road) and reaction time (average detection + reaction ~1–1.5 seconds) mean that for a severe/sudden acceleration command, a meaningful fraction of drivers cannot intervene in time → typically rated C3 (difficult to control); a milder, more gradual acceleration scenario might instead rate C2 — which is why real HARAs usually split a hazard into magnitude-based sub-scenarios.

Result: $S3, E4, C3 \Rightarrow \mathbf{ASIL\ D}$.

Safety Goal: “The vehicle shall not produce an unapproved acceleration as a result of any single-point ACC malfunction.” (ASIL D)

Typical Technical Safety Requirements derived from this Safety Goal: (1) an independent plausibility check comparing requested torque against actual torque, (2) cross-validation of the torque request against pedal position and radar/camera range data, (3) an independent cutoff path that drives motor torque to a safe value (typically zero or mild engine braking) within the FTTI once a mismatch is detected.

---

7. Hardware Fault Metrics: SPFM, LFM, PMHF

ASIL C and D hardware must satisfy quantitative hardware reliability targets in addition to qualitative process requirements:

• SPFM (Single Point Fault Metric): The proportion of “single point faults” — faults that by themselves could directly cause a hazard — that the system is protected against. Typical ASIL D target: $\ge 99\%$.
• LFM (Latent Fault Metric): The proportion of latent faults — faults not hazardous on their own, but which become hazardous when combined with a second, independent fault (e.g., a redundant channel silently degrading without the driver noticing) — that are detected. Typical ASIL D target: $\ge 90\%$.
• PMHF (Probabilistic Metric for random Hardware Failures): The hourly probability that the system violates a Safety Goal due to a random hardware failure. Typical ASIL D target: $< 10^{-8}\ \text{hr}^{-1}$ (i.e., 10 FIT — Failures In Time, 10 failures per $10^9$ device-hours).

Together, these three metrics don’t claim “the system will never fail” — an impossible bar. They guarantee that faults remain statistically extremely rare, and detectable when they occur. This is precisely why redundancy and fault-detection mechanisms (lockstep cores, watchdog timers, dual-channel ADC reads) are near-universal in ASIL D systems.

---

8. FTTI and the Safe State

The FTTI (Fault Tolerant Time Interval) is the elapsed time between a fault occurring and the hazardous event materializing — the maximum window within which the system must detect the fault and transition to a Safe State.

$t_{\text{fault detection}} + t_{\text{response}} \le \mathrm{FTTI}$

CRITICAL — The Safe State can take two distinct forms:

• Fail-Safe: The system fully disables the function (e.g., an ACC fault zeroes the torque command and returns control entirely to the driver). Sufficient for L0–L2, since the driver is presumed ready to take over at any moment.
• Fail-Operational: The system must sustain a minimum level of functionality for some period despite the fault (e.g., if one steering channel fails, a second channel keeps the vehicle on the road). Mandatory for L3+, because the driver may not be ready for an immediate takeover — we detail this distinction and Minimal Risk Maneuvers (MRM) further in AD-21 and AD-22.

In our steering example, FTTI is typically on the order of 50 ms (at 130 km/h, the vehicle travels roughly 1.8 meters in that window) — which is why ASIL D systems rely on hardware-level lockstep comparators and hardware watchdogs that operate without waiting on a software loop: a software-only fault detection path typically cannot meet that budget.

---

Frequently Asked Questions (FAQ)

Q: Is an ASIL assigned to the hazard itself, or to the component/item?

FACT — ASIL is assigned to each hazard/Safety Goal identified in HARA, not to the component itself. The same ECU can host multiple functions serving different Safety Goals, each carrying its own ASIL (e.g., an ASIL D braking function can coexist on the same domain controller as a QM comfort function) — provided sufficient hardware/software isolation between them is demonstrated under the “freedom from interference” principle.

Q: Can an ASIL D requirement be met using lower-ASIL components?

INTERPRETATION — Yes, through ASIL decomposition: a single ASIL D requirement can be split across two or more mutually independent paths, each assigned a lower ASIL (e.g., ASIL D → ASIL B(D) + ASIL B(D)), provided independence is demonstrably proven. This can make it possible to use two cheaper, independent, cross-checking channels instead of one expensive ASIL D component — but the independence analysis (freedom from common cause failures) must be rigorous.

Q: Does ISO 26262 apply to software, or only hardware?

FACT — Both. Part 6 covers software development (from requirements through code, static analysis, and test coverage targets); Part 5 covers hardware. SPFM/LFM/PMHF are hardware-specific quantitative metrics; on the software side, qualitative process rigor is the governing lever (e.g., MC/DC code coverage targets at ASIL D).

---

Summary

• Functional safety targets risk arising from fault-driven malfunctioning behavior in E/E systems — distinct from SOTIF’s (AD-20) fault-free-but-insufficient scenarios.
• HARA rates every hazard along Severity (S), Exposure (E), and Controllability (C); this triple maps through a standardized matrix to an ASIL (QM, A, B, C, D).
• Every hazard produces one Safety Goal, and its ASIL cascades unchanged through the V-Model into Technical Safety Requirements and hardware/software design.
• ASIL D systems must meet quantitative hardware targets alongside qualitative process requirements: SPFM $\ge 99\%$, LFM $\ge 90\%$, PMHF $< 10^{-8}\ \text{hr}^{-1}$.
• FTTI is the maximum time available to detect a fault and reach a Safe State (fail-safe or fail-operational); for critical steering/braking functions this is typically on the order of tens of milliseconds.

Sources and Verification Note

This lesson is grounded in ISO 26262:2018 (Parts 1-12), its parent standard for general industrial E/E/programmable-electronic systems, IEC 61508, and SAE J3016’s automation-level terminology. The ASIL determination matrix and the SPFM/LFM/PMHF numerical thresholds are an educational reconstruction of the standard’s widely cited structure and are marked ASSUMPTION — for exact cell values, footnotes, and edition-specific variations, consult the original ISO 26262:2018 text. The ACC case study is a conceptual illustration; a real HARA is conducted against an OEM’s own statistical accident/exposure data.

Next Lesson

• AD-20 — SOTIF (ISO 21448): Safety of the Intended Functionality: why ISO 26262’s fault-centric framework is insufficient on its own for AI/ML-heavy perception systems, the four-area scenario-space framework, and the risks that arise even when nothing is broken.