Skip to main content
Concept guide · ISO/PAS 8800 · 11 chapters

Safety-Aware Machine Learning (ISO 8800)

You learn to engineer AI and ML components that hold up in a safety case: the ISO/PAS 8800:2024 lifecycle layered on ISO 26262 and ISO 21448, covering dataset coverage, robustness, runtime monitoring, and structured assurance arguments.

Chapters
11
Chapters
Lifecycle Phases
8
Lifecycle Phases
Safety Case Pillars
4
Safety Case Pillars
Anti-Patterns
5
Anti-Patterns
Included inExpert
Why this course

Why it pays for itself

Write verifiable ML safety requirements

Flow safety goals down to AI and data requirements across five dimensions - performance, ODD, robustness, uncertainty, fallback - with per-class false-negative budgets instead of aggregate accuracy.

Make the dataset an argument

Treat the dataset as a partial specification: build ODD coverage matrices with minimum counts per cell, prove labelling quality and lineage, and document completeness against edge cases.

Supervise the model at runtime

Design doer-checker architectures with independent supervisors, embedded out-of-distribution detectors inside real latency budgets, and clean transitions to a Minimal Risk Condition.

After the course

What you’ll be able to do

Derive verifiable ML safety requirements

Flow safety goals down to AI and data requirements with per-class error budgets, ODD bounds, and defined evaluation protocols.

Build dataset coverage arguments

Specify the dataset lifecycle, map ODD cells to sample counts and label quality, and document completeness against edge cases.

Engineer runtime supervision

Design doer-checker architectures, OOD detectors, plausibility checks, and Minimal Risk Condition transitions within a real latency budget.

Verify ML beyond accuracy

Choose safety-relevant metrics, run scenario-based tests, and enforce test independence so evidence survives an assessor review.

Assemble an AI safety case

Structure a four-pillar GSN argument, bound residual risk to ALARP, and keep the case living through model updates.

Maintain safety in the field

Stand up drift monitoring, define re-evaluation triggers, and run an over-the-air update process inside the safety lifecycle.

The curriculum · 11 chapters

Chapter by chapter

  1. 01

    The AI Safety Gap

    Why the deterministic ISO 26262 fault model does not fit machine learning, and what ISO/PAS 8800:2024 adds to close the gap.

    • Specification-driven faults versus data-driven behaviour
    • Three gaps: no enumerable failures, data dependence, distributional shift
    • Where ISO 26262, ISO 21448, and ISO 8800 each apply
  2. 02

    ISO 8800 in the Landscape

    Mapping the AI safety standard ecosystem and identifying which standard owns which risk argument.

    • Nested layers: 26262, SOTIF, 8800, TR 5469, UL 4600
    • How ISO 8800 reuses the functional safety lifecycle
    • Cross-sector perspective from ISO/IEC TR 5469
  3. 03

    The ML Safety Lifecycle

    Eight lifecycle phases from concept and data through training, evaluation, deployment, and field monitoring, mapped onto the V-model.

    • Data collection and training as engineering activities with gates
    • V-model overlay with training at the bottom of the V
    • Safety review gates, not just project milestones
  4. 04

    Safety-Related ML Requirements

    Deriving verifiable AI requirements from safety goals, SOTIF performance targets, ODD constraints, and fallback design.

    • Trace from safety goal to TSR to AI to data requirement
    • Five dimensions: performance, ODD, robustness, uncertainty, fallback
    • Per-class false-negative rates, not aggregate accuracy
  5. 05

    Data and Dataset Safety

    Treating the dataset as a partial specification, with ODD coverage, labelling quality, lineage, and completeness arguments.

    • Five dataset types with distinct safety roles
    • ODD coverage matrix with minimum counts per cell
    • Inter-annotator agreement and edge-case completeness
  6. 06

    Robustness and Out-of-Distribution

    Detecting and bounding out-of-distribution behaviour, distribution shift, perturbation robustness, and calibrated uncertainty.

    • Covariate, label, domain, concept, and sensor-degradation shift
    • Softmax, Mahalanobis, ensembles, and conformal prediction
    • Expected Calibration Error and post-hoc temperature scaling
  7. 07

    Verification and Validation of ML

    Moving beyond accuracy to safety-relevant metrics, scenario-based testing, and provable test independence from training data.

    • False-negative rate and per-class recall over aggregate accuracy
    • Simulation, closed-road, and fleet shadow-mode testing
    • Temporal, location, and sensor splits to prevent leakage
  8. 08

    Runtime Monitoring

    Safety envelopes, plausibility checks, doer-checker architecture, runtime OOD detection, and transition to a Minimal Risk Condition.

    • Doer-checker pattern with an independent supervisor
    • Embedded OOD detectors within tens of milliseconds budget
    • Fallback and Minimal Risk Condition design principles
  9. 09

    The AI Safety Case

    Structuring assurance arguments for ML using a four-pillar decomposition and Goal Structuring Notation (GSN) down to concrete evidence.

    • Data, model, robustness, and supervision pillars
    • Worked GSN tree for an Automatic Emergency Braking detector
    • Residual risk argument and the living safety case
  10. 10

    Integration with ISO 26262 and ISO 21448

    Plugging ISO 8800 evidence into the functional safety case and SOTIF validation, including ASIL allocation to ML elements.

    • Three-standard safety argument for a lane-departure function
    • ASIL software intent preserved by ML-specific equivalents
    • ISO 8800 evidence feeding SOTIF Areas 1 through 4
  11. 11

    Anti-Patterns in ML Safety

    The most common ways teams undermine an AI safety argument, with a diagnostic checklist to catch them at review gates.

    • Accuracy-only metrics and train-test leakage
    • Ignoring distribution shift and unbounded model authority
    • Ten-point diagnostic checklist for safety reviews
Diagrams & Visuals

Not just text: the visual toolkit

ML Safety Lifecycle Pipeline

The eight ISO 8800 lifecycle phases overlaid on the ISO 26262 V-model, showing where data and training decisions sit.

ODD Coverage Matrix

A coverage grid of road type, lighting, weather, object class, and speed, with minimum sample counts and gap risks per cell.

Dataset Independence Venn

How training, validation, and test datasets must stay separated, with overlap shown as a source of over-optimistic results.

OOD Detection Threshold Explorer

Interactive view of how a confidence threshold trades false alarms against missed out-of-distribution inputs at runtime.

Doer-Checker Architecture

Signal flow from sensor to ML doer to independent checker to actuator, with a fallback path to the Minimal Risk Condition.

Assurance Argument Tree

A GSN-style decomposition of the top safety claim into data, model, robustness, and supervision goals down to evidence nodes.

Worked Example

AEB Pedestrian Detector at ASIL B

Follow a camera-and-radar Automatic Emergency Braking perception model through the ISO 8800 lifecycle, from safety goal to a defensible assurance argument.

  • Safety goal traced to a false-negative rate below 1% per ODD sub-condition (rain, low-sun, night)
  • Dataset coverage matrix proving minimum labelled counts per ODD cell with annotation accuracy above 98%
  • Test set held out by temporal and geographic split, locked before architecture selection
  • Doer-checker runtime monitor flagging out-of-distribution inputs and triggering the Minimal Risk Condition within 200 ms
  • Four-pillar GSN safety case linking data, model, robustness, and supervision evidence
  • Field monitoring plan with drift triggers feeding the over-the-air update process
Assurance Argument Snapshot
G1: The AEB pedestrian detector is sufficiently safe within the defined ODD at ASIL B

Unlock the full four-pillar evidence tree

Built for

Who this guide is for

  • ML engineers whose model is about to enter an automotive safety case for the first time
  • Functional safety engineers assigned an AI-based component and unsure where ISO 26262 stops
  • Safety assessors and reviewers who must judge AI safety evidence at review gates
  • Architects designing runtime supervision around a perception or planning network

Frequently Asked Questions

Common questions about Safety-Aware Machine Learning (ISO 8800)

ISO/PAS 8800:2024 is the automotive standard for safety of AI and machine learning components, layered on top of ISO 26262 and ISO 21448 (SOTIF). It exists because the deterministic ISO 26262 fault model does not fit ML: a neural network has no enumerable failure modes, its behaviour is defined by training data rather than a specification, and its performance degrades under distributional shift. ISO 8800 reuses the functional safety lifecycle shape but adds ML-specific demands - safety-related AI requirements, dataset safety arguments, robustness and out-of-distribution handling, runtime monitoring, and a structured assurance argument connecting all of it back into the vehicle safety case.
ISO 26262 assumes faults can be enumerated, analyzed and either prevented or detected - the logic behind FMEA, FTA and diagnostic coverage. Three gaps break that assumption for ML. First, an ML component fails without any fault: it simply generalizes wrongly on an input it was never trained for, so there is no failure mode to enumerate. Second, behaviour is data-driven - the dataset acts as a partial specification, so dataset gaps are specification gaps. Third, distributional shift means performance measured at release quietly degrades as the operating environment drifts. ISO 8800 addresses exactly these gaps while ISO 26262 continues to govern the surrounding deterministic system.
Doer-checker is the runtime supervision pattern where a high-performance but hard-to-verify component (the doer, typically the ML model) is paired with a simpler, independently developed checker that monitors its outputs against a safety envelope - plausibility bounds, physical limits, cross-sensor consistency. The checker does not need to match the doer's capability; it only needs to reliably detect when the doer's output could violate safety and trigger a fallback, typically a transition to a Minimal Risk Condition. Combined with runtime out-of-distribution detection operating within a budget of tens of milliseconds, it converts an unverifiable model into an architecture with a bounded safety argument.
Not with aggregate accuracy. Safety validation uses safety-relevant metrics - per-class false-negative rates and recall against the requirement budgets - measured on test data that is provably independent of training data, using temporal, location and sensor splits to prevent leakage. Scenario-based testing in simulation, on closed roads and in fleet shadow mode covers the ODD systematically, and calibration is verified so the model's confidence is meaningful for runtime monitoring. The evidence then feeds a structured assurance argument: the guide works a four-pillar GSN decomposition - data, model, robustness, supervision - down to concrete evidence nodes for an AEB pedestrian detector.
The guide has 11 chapters covering the AI safety gap, the standards landscape, the eight-phase ML safety lifecycle, requirements, dataset safety, robustness and out-of-distribution handling, verification and validation, runtime monitoring, the AI safety case, integration with ISO 26262 and ISO 21448, and five anti-patterns with a review checklist. A worked example follows an AEB pedestrian detector at ASIL B from safety goal to a four-pillar assurance argument. A free account starts you off, and the Pro and Expert plans unlock more of the library.

Start the course today

A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.