2. Regulatory and standards landscape

A virtual safety assessment dossier is only as credible as the standards framework it maps to. Before a single simulation log is archived or a scenario catalogue is frozen, the assessment team must decide which normative expectations govern the evidence, what each standard actually demands of virtual assessment, and how an auditor will test whether those demands are met. This chapter establishes that landscape: the three dominant standards for road-vehicle safety — ISO 26262, ISO 21448, and UL 4600 — and the practical audit expectations that determine whether virtual evidence survives scrutiny.

Three standards, three different jobs

The most common planning error is treating these standards as interchangeable checklists. They are not. Each addresses a different failure universe and therefore imposes a different burden on virtual assessment.

ISO 26262 (functional safety, derived from IEC 61508) targets malfunctioning behaviour: electrical/electronic faults, systematic design errors, and the resulting hazards. Its evidence chain runs from item definition and HARA through safety goals, functional safety requirements, technical safety requirements, and finally verification. Virtual assessment enters this chain primarily as verification and validation support — simulation used to exercise safety mechanisms, fault injection campaigns, and coverage of safety requirements. The standard's ASIL decomposition (A/B/C/D) directly scales how much rigour an auditor expects: an ASIL D safety goal demands far stronger evidence of simulation credibility, tool qualification, and traceability than an ASIL A goal.

ISO 21448 (SOTIF — Safety of the Intended Functionality) targets a completely different problem: hazards arising without any malfunction, caused by performance limitations and triggering conditions — a perception system that misses a pedestrian in low sun, an odometry drift in a tunnel, an unexpected road configuration. SOTIF is where virtual assessment carries the heaviest load, because the scenario space is effectively unbounded and physical testing cannot cover it. The standard's logic — identify and evaluate hazardous scenarios, then argue that residual risk in the unknown-unsafe region is acceptably low — is fundamentally an evidence-coverage argument, and simulation is the primary instrument for building it.

UL 4600 (Standard for Safety for the Evaluation of Autonomous Products) takes a third stance: it is a safety case standard. Rather than prescribing a process, it prescribes the structure of an argument — claims, sub-claims, evidence, and defeaters — and demands that the argument be complete, traceable, and defensible. For virtual assessment, UL 4600 is the standard that most directly asks the uncomfortable question: why should anyone believe your simulation results? It forces explicit treatment of tool validity, scenario representativeness, and the limits of the evidence.

How the standards interact in one dossier

The diagram below shows how the three standards converge on a single virtual assessment evidence package, and where each one places its audit pressure.

What auditors actually check in virtual evidence

Across all three standards, audit expectations for virtual assessment evidence cluster into four recurring themes. Understanding them early prevents the classic failure mode of producing terabytes of simulation output that no auditor will accept.

Traceability. Every simulation result must connect upward to a requirement, a safety goal, or a SOTIF scenario category, and downward to the specific scenario, model version, and tool configuration that produced it. An auditor will typically sample a result and ask: which requirement does this verify, which scenario file generated it, which simulator version and parameters were used, and who approved the scenario as representative? If any link is missing, the evidence is treated as unsupported. In practice this means the dossier needs a traceability matrix keyed on requirement ID, scenario ID, simulation run ID, and result verdict — not a folder of PDFs.

Tool credibility and qualification. ISO 26262-8 clause 11 introduces tool confidence levels based on tool impact and tool error detection; UL 4600 goes further and demands an explicit argument for why the simulation tool's results can be trusted for the intended use. Auditors look for tool qualification records, validation against reference data or physical tests, documented known limitations, and configuration management of the tool itself. A simulator used to argue ASIL D verification without any qualification evidence is a predictable audit finding.

Scenario representativeness. For SOTIF especially, the auditor will challenge whether the scenario catalogue actually represents the operational design domain. Evidence expected here includes the derivation of scenarios from field data, accident databases, and systematic hazard analysis; documented coverage of ODD parameters (weather, lighting, road geometry, traffic density); and an explicit statement of which regions of the scenario space remain unaddressed. Claiming "10,000 scenarios passed" without showing how they were selected is not an argument.

Completeness and the residual-risk statement. UL 4600's safety-case structure forces the dossier to state what is not covered. Auditors expect a residual-risk or "unknown-unsafe" statement that names the assumptions, the evidence gaps, and the rationale for accepting them. A dossier that claims full coverage is less credible than one that honestly bounds its claims.

A practical mapping table for the dossier

The following table summarises how each standard's expectations translate into concrete artefacts the virtual assessment team must produce. It is a working reference, not a substitute for reading the clauses.

Working example: building the traceability spine

Consider a lane-keeping assist function with an ASIL B safety goal ("shall not apply unintended steering torque above 3 Nm") and a SOTIF-relevant performance limitation (lane marking detection degraded in heavy rain at night). A minimal but audit-defensible traceability spine for the virtual evidence might look like this:

REQ-FUSA-014  (ASIL B)  Unintended steering torque < 3 Nm
  └─ SIM-RUN-1042   fault injection: torque sensor stuck-high
       scenario: SCN-FI-0031   tool: sim-v4.2.1   verdict: PASS
       evidence: log hash 9f3c…, coverage report cov-1042.json

REQ-SOTIF-007  Lane marking detection in rain/night
  └─ SIM-RUN-2087   scenario family SCN-SOTIF-RAIN-*
       ODD params: rain 20–50 mm/h, illuminance < 10 lux
       verdict: 94% detection, 6% miss → residual risk statement RR-07
       limitation: no wet-road glare cases in catalogue → gap G-12

Two things make this spine auditable. First, every run carries a scenario ID, tool version, and verdict, so an auditor can reproduce or sample it. Second, the SOTIF entry does not hide the 6% miss rate or the missing glare cases — it converts them into a residual-risk statement and a named gap, which is exactly what UL 4600's safety-case logic and ISO 21448's unknown-unsafe reasoning require. The gap G-12 then becomes a tracked action, either closed by additional scenarios or accepted with justification.

Key takeaways for the dossier owner

• ISO 26262 governs malfunction evidence and scales rigour by ASIL; virtual assessment supports verification of safety mechanisms and requires tool confidence justification.
• ISO 21448 governs performance-limitation evidence; virtual assessment is the primary instrument, and the burden is on demonstrating scenario representativeness and bounding the unknown-unsafe region.
• UL 4600 governs the safety argument itself; it demands explicit claims, evidence links, defeaters, and tool validity reasoning.
• Auditors converge on four checks: traceability, tool credibility, scenario representativeness, and an honest completeness/residual-risk statement.
• The traceability spine — requirement ID to scenario ID to run ID to verdict — is the single artefact that makes all three standards' expectations satisfiable from one evidence base.