"The pedestrian did not read the standard. My perception stack failed in a way ISO 26262 never called a fault, which is exactly why the next three documents in the stack exist."
A Well-Certified AI Agent
The Big Picture
The previous sections built defenses: redundancy, envelopes, runtime monitors, gates. This section explains the language regulators, auditors, and safety engineers use to decide whether those defenses are enough. Functional-safety standards are not paperwork bolted on at the end; they are a rigor budget, allocated up front, that tells you how much evidence a given hazard demands. Four documents govern the sensor-AI world, and they form a stack rather than a menu. IEC 61508 is the generic root for any electrical, electronic, or programmable safety system. ISO 26262 specializes it for road vehicles and reasons about faults: a malfunctioning sensor, a corrupted register, a stuck bus. ISO 21448 (SOTIF) covers the case that broke classical safety thinking: the system has no fault at all, yet its intended function is insufficient, which is precisely how a perception network misclassifies. ISO/PAS 8800 is the newest layer, addressing artificial intelligence directly. This section answers, for each, what it governs, why it exists, how its integrity levels are assigned, and when a sensor-AI team must reach for it.
A note on prerequisites and placement. This section assumes the redundancy and safety-envelope vocabulary of Section 68.3 and the runtime-monitoring ideas of Section 68.4; it also leans on the calibration and confidence notions of Chapter 18, because a standard cares less about a point prediction than about whether the system knows when it is unreliable. The broader regulatory landscape, including the EU AI Act and medical-device rules, lives in Chapter 70. Here we stay narrowly on the functional-safety stack that governs whether a perception system may command a physical action.
IEC 61508: the generic root and the SIL machinery
IEC 61508 is the umbrella standard for the functional safety of electrical, electronic, and programmable electronic (E/E/PE) safety-related systems. Its central idea is a Safety Integrity Level (SIL), an ordinal from SIL 1 (lowest) to SIL 4 (highest) that quantifies how much we trust a safety function to perform on demand. For a continuously operating function the target is a tolerable probability of dangerous failure per hour (PFH); SIL 4 demands \(10^{-9}\) to \(10^{-8}\) per hour, and each SIL below relaxes that band by a decade, so SIL 1 sits at \(10^{-6}\) to \(10^{-5}\). The standard's second key distinction shapes everything downstream in the stack: random hardware failures (a transistor that degrades, quantifiable with failure-rate statistics) versus systematic failures (a design or specification error that is present in every unit and cannot be captured by a failure rate). You buy down random failures with diagnostics and redundancy; you buy down systematic failures with process rigor, which is why higher SILs mandate stricter development, review, and verification. Every domain standard we discuss next is a specialization of IEC 61508 for a particular industry.
ISO 26262: ASIL and the fault-driven automotive lifecycle
ISO 26262 (second edition, 2018) adapts IEC 61508 to road vehicles, defining functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems. Its integrity level is the Automotive Safety Integrity Level (ASIL), ranging from A (least stringent) through D (most stringent), with a QM ("quality managed") tier below A for hazards needing no safety measures beyond normal quality practice. Crucially, ASIL is not chosen by intuition. It is derived from a hazard analysis and risk assessment over three factors: Severity (how bad the harm, S0 to S3), Exposure (how often the operational situation occurs, E0 to E4), and Controllability (how likely a driver or other actor can avert the harm, C0 to C3). The worst combination, a life-threatening injury (S3) in a common situation (E4) that no one can control (C3), yields ASIL D. From the ASIL flow concrete quantitative targets on the hardware: for ASIL D the Probabilistic Metric for random Hardware Failures (PMHF) must fall below roughly 10 FIT (\(10^{-8}\) per hour), and the single-point fault metric must exceed 99 percent. The standard governs a full V-model lifecycle, from item definition through the safety case, and it permits ASIL decomposition: splitting a requirement across independent, redundant channels so each channel carries a lower ASIL than the whole, which is the formal justification for the diverse voting of Section 68.3.
def determine_asil(S: int, E: int, C: int) -> str:
"""ISO 26262-3 hazard classification -> ASIL.
S in 0..3 (Severity), E in 0..4 (Exposure), C in 0..3 (Controllability).
S0, E0, or C0 means no unreasonable risk -> no safety goal (QM)."""
if S == 0 or E == 0 or C == 0:
return "QM"
idx = S + E + C # ISO 26262-3 determination index
return {7: "A", 8: "B", 9: "C", 10: "D"}.get(idx, "QM")
# A pedestrian-AEB perception goal: severe harm, common situation, hard to avert
print(determine_asil(S=3, E=4, C=3)) # -> D (full rigor)
# A comfort feature failing on a rare, easily handled situation
print(determine_asil(S=1, E=2, C=1)) # -> QM (quality-managed only)
Code 68.5.1 makes the point that rigor is earned by the hazard, not the algorithm. The same pedestrian-detection network is QM when it drives a dashboard chime and ASIL D when it commands automatic emergency braking, because Severity and Controllability change even though the model does not.
Key Insight: fault versus insufficiency
ISO 26262 asks "did something break?" A misclassifying perception network usually answers no. Every transistor toggled correctly, the software executed its specification exactly, no bit flipped. The network simply was not good enough at recognizing a pedestrian in fog, a truck painted like the sky, or a pattern absent from its training distribution. This is a functional insufficiency, not a fault, and it is invisible to a fault-centric standard. That single gap, that the most dangerous failures of machine perception involve no malfunction at all, is the entire reason ISO 21448 and ISO/PAS 8800 had to be written. If you take one idea from this section, take this one.
ISO 21448 (SOTIF): safety when nothing is broken
ISO 21448:2022, the Safety Of The Intended Functionality, closes the fault gap. SOTIF governs hazards that arise from performance limitations of the intended function and from foreseeable misuse, with no malfunction present. Its organizing device is a four-way partition of the scenario space into known-safe, known-unsafe, unknown-unsafe, and unknown-safe scenarios. The engineering goal is explicit: shrink the two unsafe regions by turning unknown-unsafe scenarios into known ones through analysis and field data, then engineering them into the known-safe region. A triggering condition is any input pattern (glare, an unusual pose, a distribution shift of the kind studied in Chapter 66) that provokes the insufficiency. Because you can never enumerate all triggering conditions, SOTIF is inherently statistical and validation-heavy: it accepts residual risk, requires argument that the residual is acceptable, and leans hard on the runtime monitors of Section 68.4 to catch what design-time analysis missed. For any sensor-AI perception system, SOTIF, not ISO 26262 alone, is the standard that actually describes your dominant failure mode.
Step-Through: an AEB supplier that passed ISO 26262 and still shipped a hazard
An automotive tier-one built a camera-and-radar automatic-emergency-braking (AEB) function and closed its ISO 26262 work cleanly: the ECU met its ASIL D PMHF budget, the watchdog caught stuck frames, the bus had end-to-end CRC protection. In validation, a white trailer crossing a bright sky went undetected until dangerously late. No component had failed. The camera delivered a perfect image; the network, trained on a distribution thin on high-glare side-on trailers, simply produced a low-confidence output that the fusion logic discarded. This is a textbook SOTIF triggering condition, invisible to the fault analysis. The fix was a SOTIF program layered on top of the existing 26262 case: a scenario catalogue that named the glare-and-trailer case as known-unsafe, targeted data collection to move it toward known-safe, a calibrated-confidence gate (per Chapter 18) so the radar retained authority when the camera was uncertain, and a runtime monitor that flagged the low-confidence regime for the safety envelope. The lesson generalizes to wearables, robotics, and clinical devices: passing the fault standard proves your hardware works, not that your perception is adequate.
ISO/PAS 8800: the artificial-intelligence layer
Even SOTIF leaves a gap. It tells you insufficiencies exist and must be argued down, but it was not written for the peculiarities of machine-learned components: opaque decision boundaries, data-dependent behavior, distribution shift, and the impossibility of exhaustive specification. ISO/PAS 8800 (Road vehicles, Safety and artificial intelligence, published 2024) is the Publicly Available Specification that fills it. It defines an AI safety lifecycle that plugs into the 26262 and SOTIF processes, introduces AI safety requirements and measurable safety-related properties (robustness, and the honest expression of uncertainty), and treats the training data as a first-class safety artifact whose coverage, provenance, and leakage properties must be argued, echoing the leakage-safe discipline of Chapter 65. In the stack, 8800 does not replace anything: IEC 61508 supplies the generic frame, ISO 26262 handles the faults, ISO 21448 handles the insufficiencies, and ISO/PAS 8800 supplies the AI-specific method for arguing that a learned perception component's residual risk is acceptable. That layered argument is the raw material for the explicit safety case assembled in Section 68.6.
Right Tool: FMEDA tooling instead of hand-rolled PMHF integration
Demonstrating an ASIL D hardware target means an FMEDA (Failure Modes, Effects, and Diagnostic Analysis) that sums failure rates across hundreds of components, weights each by its diagnostic coverage, and integrates to a single PMHF and single-point-fault metric. Done by hand in a spreadsheet with the fault-tree math from IEC 61508, that is easily 300 to 500 lines of bookkeeping per item, and every base-failure-rate edit forces a full recompute. Dedicated safety-analysis tools (for example ANSYS medini analyze, or an open fault-tree-analysis library that propagates basic-event rates to a top-event probability) own that computation, keep the requirements-to-evidence traceability matrix live, and regenerate the metrics on any change. Reserve your effort for the SOTIF and ISO/PAS 8800 arguments, the insufficiency and data-coverage claims that no tool can compute for you.
Research Frontier
The 2024 arrival of ISO/PAS 8800 is the current center of gravity, alongside UL 4600 (Standard for the Evaluation of Autonomous Products), which pioneered the goal-based safety-case-first approach for systems with no human driver, and ISO/IEC TR 5469 on AI functional safety across domains. The open problems are sharp: there is still no agreed method for quantifying the residual risk of a deep perception network to a PMHF-like number, no consensus metric for "sufficient" training-data coverage of the operational design domain, and no accepted way to argue safety against an adaptive adversary of the kind seen in Section 68.2. The pragmatic frontier has therefore shifted from static robustness proofs toward continuous, field-monitored assurance, treating the safety case as a living argument updated by fleet telemetry rather than a document frozen at release.
Choosing and combining the standards
The four documents are cumulative, not alternatives. A sensor-AI team building a safety function reads them top down: use IEC 61508 (or the domain child) to fix the integrity target, ISO 26262 to discharge the fault-based hardware and systematic requirements, ISO 21448 to confront the performance insufficiencies that dominate learned perception, and ISO/PAS 8800 to argue the AI component specifically. Outside automotive the shape recurs under different names: medical devices route through IEC 62304 and the clinical-validation regime of Chapter 34, industrial machinery through IEC 61508 directly, but the fault-versus-insufficiency split and the demand for a graded, evidence-backed argument are universal. The most expensive mistake in this area is to treat a passed ISO 26262 assessment as proof that a perception system is safe, when it only proves the electronics did not malfunction. The perception adequacy argument lives in SOTIF and ISO/PAS 8800, and it is where a sensor-AI engineer earns their keep.
Exercise
Take a wearable fall-detection function that, on detecting a fall, auto-dials emergency services. (a) Assign S, E, and C for the hazard "failure to detect a genuine fall of a frail user" and run Code 68.5.1 to derive the ASIL-equivalent rigor; justify each factor. (b) Now classify the two most likely insufficiency failure modes (not hardware faults) using the SOTIF known/unknown, safe/unsafe partition, and for each name a triggering condition. (c) Sketch one ISO/PAS 8800 safety-related property you would place a measurable requirement on, and describe the field data you would collect to argue its residual risk is acceptable.
Self-Check
1. A camera network misclassifies a stationary truck and the vehicle fails to brake, yet every electronic component operated to specification. Which standard in the stack governs this failure, and why is ISO 26262 alone insufficient to address it?
2. Two independent, diverse channels each carry ASIL B, and their combination is argued to meet an ASIL D goal. What ISO 26262 mechanism is this, and what independence assumption must hold for it to be valid?
3. Why does ISO/PAS 8800 treat the training dataset as a safety artifact rather than an engineering convenience, and which earlier chapter's discipline does that requirement echo?
What's Next
In Section 68.6, we assemble these standards into a single, explicit safety case for ML perception: a structured argument, with goals, strategies, and evidence, that ties the ASIL target, the SOTIF scenario coverage, the ISO/PAS 8800 AI properties, and the runtime monitors of Section 68.4 into one auditable claim that the system's residual risk is acceptable. If this section named the standards, the next shows how to argue you have met them.