This guide is a tour of the standards and frameworks that show up most often in AV safety conversations today. We will define each of the following standards and frameworks, explain how they connect to each other, and point out who on your team actually needs to care about them.

In this guide we will cover ISO 26262, 21448 (SOTIF), and 345x family; ASAM OpenODD OpenSCENARIO DSL and OpenDRIVE; IEEE 2846 and 3321; UL 4600, ISO 8800, UNECE WP.29 UN R157, UN R171 (DCAS), and UN R185 (ADS);  NCAP and NCAP 2029. 

Safety Foundations: ISO 26262 and ISO 21448 (SOTIF): 

ISO 26262 is the foundational functional safety standard for road vehicles. It covers the electrical and electronic systems in a car and provides a risk based process for making sure those systems do not fail in ways that hurt people. It introduced the ASIL (Automotive Safety Integrity Level) classification that most automotive safety engineers already live by, and it requires a safety case built on hazard analysis, risk assessment, and evidence that safety goals were met, while also supplying non-normative guidance on the safety case’s structure.

ISO 21448, known as SOTIF (Safety of the Intended Functionality), picks up where ISO 26262 leaves off. SOTIF deals with the case where nothing actually breaks, but the system still behaves unsafely because of a performance limitation or because it was used in a way that was reasonably foreseeable but not accounted for. Think of a perception system that simply cannot see well enough in heavy rain. Nothing malfunctioned. It just was not good enough for the situation. SOTIF is the standard that pushes teams to find those unknown and unsafe scenarios and reduce the risk they carry, largely through scenario based testing. SOTIF divides the scenario space into four quadrants along two axes, safe versus unsafe, and known versus unknown, and a primary goal of the SOTIF process is to shrink the unknown unsafe quadrant. Foretellix’s methodology of constrained random testing is one mechanism for searching out those unknown scenarios, and it is referenced in the annexes of this standard.

These two standards connect directly: ISO 26262 handles the “did something break” problem, and SOTIF handles the “did something work as designed but still cause a problem” problem. Together they form the backbone that almost every other standard on this list builds on or refers back to.

Who should know it: functional safety engineers, systems engineers, and safety managers responsible for the overall safety case. If your title includes the word “safety,” these two are your starting point.

Turning Safety Into Test Scenarios: The ISO 3450X Family and the ODD Standards

Knowing you need to find unsafe scenarios is one thing. Having a repeatable method for identifying, categorizing, and generating them is another. This is handled by a family of standards that people in the industry often just shorthand as “ISO 3450X,” since they share the same root number and cover different pieces of the same puzzle.

ISO 34501 starts the family off as the shared vocabulary. It defines the core terms used across the rest of the series, things like functional, abstract, logical, and concrete scenarios, so that every other standard in the family, and every team using them, means the same thing when they say “scenario.”

ISO 34502 provides the scenario based safety evaluation framework itself, currently focused on limited access highways. While the underlying engineering principles can technically be adapted, the standard itself was written with this specific operational domain in mind. The standard walks teams through identifying trigger conditions and hazards, deriving critical scenarios, and evaluating whether the system is free of unreasonable risk. Foretellix’s constrained random generation methodology, the approach for automatically producing large numbers of valid and meaningful concrete scenarios from a smaller set of abstract descriptions, fits directly into this part of the framework, and is referred to in its annexes.

ISO 34504 takes the scenarios identified through that process and defines how to categorize them, tagging each one with qualitative and quantitative information so scenarios can be organized, compared, and reused consistently across an organization rather than living as one off, ad hoc test cases.

ISO 34505 then closes the loop by defining how to evaluate those categorized scenarios and generate concrete test cases from them, turning a catalog of scenario categories into actual test cases that go beyond the scenario itself to include goals, KPIs, and measurements.

But none of this means much without a clear definition of where the vehicle is designed to operate in the first place. That is the job of the Operational Design Domain, or ODD. ASAM OpenODD and ISO 34503 both tackle this from slightly different angles. ISO 34503 specifies a hierarchical taxonomy for describing operating conditions, things like road type, weather, traffic mix, and infrastructure, so that an ODD can be defined consistently across teams and organizations. ASAM OpenODD builds a technology independent, machine readable data model for representing that same taxonomy, so ODD information can move between tools without getting lost in translation. ASAM OpenODD then goes further by adding technology specific references to represent this data model in different languages, such as ASAM OpenSCENARIO DSL and YAML.

The connection across the whole family runs in a clean line: 34501 gives everyone the same words, 34503 and OpenODD define where the vehicle is designed to operate, 34502 defines how to find and evaluate the risky scenarios within that domain, 34504 organizes those scenarios into categories, and 34505 turns the scenarios into concrete, runnable test cases.

Who should know it: verification and validation engineers, scenario engineers, and product teams defining where and how a vehicle is meant to operate.

Describing the World: ASAM OpenSCENARIO DSL and ASAM OpenDRIVE

NOTE: While there are few standards and approaches to describe scenarios and road networks/geographies – this blog is focusing on two that best match the rest of the suite.

Once you know what scenarios matter, you need a common language to describe them so different tools and teams can actually use them. ASAM OpenSCENARIO DSL is a human and machine readable language for describing test scenarios for ADAS and ADS development. It supports abstract, logical, and concrete levels of description, meaning a single scenario can be written once at a high level and then expanded into thousands of concrete variations without being tied to one specific map or location.

ASAM OpenDRIVE complements it by describing the road network itself. Lanes, intersections, elevation, and road geometry all live in OpenDRIVE files, giving simulation tools a standard way to represent the physical world a scenario plays out in.

The connection is almost literal: OpenSCENARIO DSL describes the actors and their behavior, while OpenDRIVE describes the stage they are performing on. Neither one works well without the other in a simulation based verification pipeline, though OpenSCENARIO DSL scenarios can also be used with other road network descriptions.

Who should know it: simulation engineers, tool developers, and anyone building or running scenario libraries for virtual testing.

Setting the Rules for Other Road Users: IEEE 2846 and IEEE 3321

An automated driving system does not just need to know its own limits. It needs reasonable assumptions about how other drivers, cyclists, and pedestrians might behave, especially in an emergency. IEEE 2846 defines a minimum set of reasonable assumptions and foreseeable behaviors for other road users that should be considered when building safety related models for an ADS. It essentially answers the question, how aggressively might that other car brake or swerve, in a way that is bounded and defensible rather than guessed at.

IEEE 3321 is the companion recommended practice. It provides guidance on how to actually apply the IEEE 2846 assumptions inside real safety related models, including how to update those assumptions as a scenario unfolds over time and how to validate that a model used them correctly.

Who should know it: planning and prediction engineers, and safety modeling teams working on collision avoidance and behavior prediction logic.

Building the Safety Case: UL 4600

Most of the standards above focus on a piece of the puzzle. UL 4600, officially the Standard for Safety for the Evaluation of Autonomous Products, focuses on the whole picture. It is a technology agnostic, goal based standard that tells you how to assemble everything, hazard analysis, testing evidence, tool qualification, data integrity, and more, into one coherent safety case. It is especially relevant for fully autonomous systems that operate without a human fallback driver, and it is designed to work alongside ISO 26262 and SOTIF rather than replace them.

Who should know it: program leads, safety case authors, and anyone who eventually has to stand in front of a regulator or an insurer and defend why a vehicle is safe enough to deploy.

Safety Meets AI: ISO 8800

AI and machine learning components, especially in perception, do not fail the way traditional software does. They can be systematically wrong in ways that hazard analysis techniques built for deterministic code were never designed to catch. ISO 8800 (published as ISO/PAS 8800) fills that gap. It defines a framework for managing AI safety in road vehicles that tailors and extends the existing ISO 26262 and ISO 21448 approaches, covering things like data quality, architectural safeguards, and the evidence needed to argue that an AI system is safe across its lifecycle.

Who should know it: machine learning engineers, data teams, and safety engineers working specifically on perception and AI powered decision making components.

The Regulations That Tie It All Together: UNECE WP.29, UN R157, UN R171 (DCAS), and UN R185 (ADS)

Everything above is guidance, industry practice, or voluntary standards, ISO standards and others carry no obligation unless an authorized authority formally mandates them. UNECE WP.29, the World Forum for Harmonization of Vehicle Regulations, is where guidance turns into binding law. The UNECE regulations are binding and mutually recognized (reciprocal recognition) across the members of the original 1958 Agreement, which includes much of Europe, Russia, Japan, South Korea, Thailand, Vietnam, and others. The companion GTR is the non-binding version which Contracting Parties such as the US, Canada, China, and India transpose into their own national law.

Under WP.29, individual regulations are issued for specific vehicle systems, and three of them matter most for anyone working on driving automation today: UN R157, UN R171, and, most recently, UN R185.

UN R157 was the first of the three, covering Automated Lane Keeping Systems, and it remains the regulation most people mean when they talk about the original ALKS rules for SAE Level 3 systems operating in constrained highway conditions*.  

UN R171 followed in 2024, and it covers a different, more common category: Driver Control Assistance Systems, or DCAS. DCAS are SAE Level 2 systems that assist a driver with steering and speed on a sustained basis but never take over the full driving task (DDT)  itself. The driver stays responsible and must keep monitoring the road and the system. UN R171 sets safety and performance requirements for these systems, including driver engagement monitoring and clear consumer facing information about what the system can and cannot do, so drivers do not become overreliant on it.

UN R185 is the newest and, for full automation, the most significant. After roughly seven years of development, WP.29 approved this regulation for the certification of Automated Driving Systems (ADS) at SAE levels 3 and 4, developed alongside a companion Global Technical Regulation for jurisdictions that use that instrument instead. 

UN R185 takes a performance based, safety case approach. Rather than prescribing exact engineering methods, it requires manufacturers to demonstrate, through a Safety Management System and a documented safety case built on claims, arguments, and evidence, that a self-driving system is free from unreasonable safety risk and performs at least as competently as a careful human driver.

Here is the part that matters most for anyone working in AV verification: coverage is a central requirement of UN R185. Manufacturers must produce data showing and analyzing the coverage achieved during development, verification, validation, and testing. That includes unified coverage aggregated across simulation, track, and real world testing pillars, a clear articulation of the methodology, metrics, and targets used to determine sufficient ODD coverage, and verification and validation plans built around those same metrics and targets. Coverage can be measured on the test scenarios themselves as well as on the behavioral competencies and key performance indicators demonstrated during testing.

Foretellix was an influential member of the team that developed this regulation, introducing coverage driven validation concepts to the forum in early 2020, concepts that evolved into the coverage requirements now written into UN R185.

This is where the whole standards landscape connects. ISO 26262 and SOTIF define what safety means. The ISO 3450X family and the ODD standards give you the tools to define, evaluate, categorize, and generate the scenarios that test that safety. OpenSCENARIO DSL and OpenDRIVE describe those scenarios and the roads they play out on. IEEE 2846 and 3321 make sure your models about other road users are reasonable. UL 4600 and ISO 8800 help you build and argue a complete safety case, including for AI components. And UN R157, UN R171, and UN R185 are where all of that work becomes the evidence a regulator actually asks for, covering ADAS and full ADS respectively, with coverage sitting at the center of the ask for the most automated systems.

Who should know it: everyone above. This section matters especially to the V&V and safety engineers who build the evidence, and to the executives, regulatory affairs teams, and program leaders accountable for it, all of whom need to know that today’s engineering work will satisfy what regulators require tomorrow.

Consumer Ratings Catch Up: NCAP and Euro NCAP Vision 2030

Euro NCAP’s current roadmap, Vision 2030, marks a shift from simply requiring safety systems to be equipped to rigorously assessing how well they perform. The roadmap runs on a three-year update cycle, with major checkpoints in 2026, 2029, and 2032. The 2026 update, already detailed, retires the current four-box rating system in favor of one organized around the phases of an accident (safe driving, crash avoidance, crash protection, post-crash safety) and expands driver/occupant monitoring requirements. Later checkpoints are expected to continue that shift toward measurable, real-world performance, rather than simple presence checks. Euro NCAP’s separate Assisted Driving grading remains complementary to the main safety rating for now; Euro NCAP has said this policy will be reviewed periodically and may eventually be folded into the main rating once real-world data supports it, but no fixed date has been set for that integration.

Who should know it: anyone responsible for a vehicle’s overall safety rating rather than just its regulatory compliance.

The Bottom Line

No single standard gets an autonomous vehicle certified. It takes the full stack, from functional safety fundamentals through scenario description languages to the regulation that finally asks for proof. Understanding how these pieces fit together, rather than treating each one as an isolated checkbox, is what separates a safety program that merely complies from one that is actually defensible. 

The Foretellix Physical AI toolchain was built with exactly that connected view in mind, helping teams generate the scenarios, measure the coverage, and produce the evidence that standards like these, and regulations like UN R157, UN R171, and UN R185, ultimately require.

Footnotes:
* While this blog refers to SAE levels of driving automation for simplicity, the regulations themselves do not use these terms as binding classifications. UN R185, for example, defines two ADS types instead: ADS Type 1, which requires a fallback driver, and ADS Type 2, which does not, a distinction similar to but not identical with SAE Levels 3 and 4.

TL;DR: Trust in simulation is now a critical part of proving AV safety. This blog explores how Foretellix is creating a unified, measurable methodology to evaluate simulation fidelity and turn simulation from a black box into a defensible part of the validation process.

Autonomous vehicle safety depends on trust, both in the vehicle’s behavior and in the tools used to validate it. As simulation becomes the backbone of AV testing, the industry faces a critical challenge: proving that simulation results accurately reflect the real world. This blog explores Foretellix’s unified approach to making simulation trust measurable, explainable, and repeatable.

Simulation is essential for validating autonomous vehicles because real-world testing alone cannot cover the vast range of scenarios needed to demonstrate safety at scale. However, simulation is only useful if its results can be trusted.

That trust is hard to earn. By nature, simulation is a simplification of reality, built on models, assumptions, and abstractions. If we’re going to rely on it for safety decisions, we need to understand how well it reflects the real-world and where it falls short.

Today, there is no standard method to measure this. Regulations require simulation to be “fit for purpose,” but they do not define how to evaluate realism, coverage, or fidelity. Consequently, most AV teams are left improvising.  While some companies, such as Waymo through its published safety reports, share data and transparency frameworks, there is still no unified industry method for measuring simulation trust.

Foretellix is working to change that. We’re developing a structured methodology for simulation trustworthiness, grounded in measurable criteria and repeatable processes. The goal is to equip AV teams with a clear foundation for using simulation with confidence, grounded in realism, transparency, and measurable fidelity.

The Challenge of Proving Simulation Realism

Simulation plays a central role in AV development, but the industry still lacks a common framework for evaluating whether simulation results are reliable. While safety standards like ISO 26262 and UNECE regulations acknowledge the need for simulation tools to be “fit for purpose,” they stop short of defining how to assess that fitness, especially when it comes to simulating complex, dynamic traffic environments.

In practice, most teams resort to custom-built comparisons between simulated and real-world drives. These efforts often lack consistency, and rely on fuzzy definitions of realism. One engineer might examine actor behavior, another might focus on system-level KPIs, and a third on sensor noise or scenario variety. Without shared terminology, metrics, or methods, it is challenging to know whether the simulation is good enough, or what “good enough” even means.

The result is uncertainty. Test engineers and developers don’t always know which gaps still exist in their testing. OEMs struggle to justify simulation-based validation to regulators or internal stakeholders. And teams are left questioning whether the insights they gain from simulation can be trusted in the real world.

Foretellix’s Vision for Simulation Trustworthiness

To address the ambiguity surrounding simulation credibility, Foretellix is developing a unified methodology that makes simulation trustworthiness measurable, explainable, and repeatable. Instead of treating simulation as a black box, this approach breaks it down into two distinct but interconnected areas: toolchain qualification and simulation credibility. Together, these two pillars form the basis of Foretellix’s effort to make simulation trustworthiness not just a feeling, but a framework.

Toolchain Qualification

Before simulation results can be trusted, the tools generating and evaluating those results must be proven reliable. That’s the role of toolchain qualification: to ensure that every component of the internal Foretellix toolchain works correctly, and is consistently proven by thorough testing.

This qualification process includes:

• Robust development practices: Including modular design, secure coding, and continuous integration to prevent defects early in the development lifecycle.
• Comprehensive QA processes: Combining unit tests, regression tests, and integration tests to validate both individual components and the toolchain as a whole.
• Integration testing: Ensuring that behavioral, physical, and evaluation components interact correctly across abstraction levels and real-world usage scenarios.
• Tool certification: Supporting formal assessments, such as ISO 26262 certification, to demonstrate alignment with industry safety and quality standards.

The primary objective of toolchain qualification is not to directly enhance simulation realism. Rather it aims to establish confidence in the underlying infrastructure, thereby ensuring that simulation results are not being distorted or misreported due to issues in the tools that produce, process, or evaluate them.

Simulation Fidelity

Simulation fidelity refers to the degree to which a simulation accurately replicates real-world driving behavior, conditions, and system performance. It’s a structured collection of evaluation categories, each targeting a different aspect of realism and trustworthiness.

Foretellix’s methodology distinguishes between system-level and sub-system-level fidelity. System-level fidelity assesses the end-to-end vehicle behavior in simulation, while sub-system-level fidelity evaluates the fidelity of an isolated simulation component. Both system- and sub-system-level  simulation fidelity are further defined through the following dimensions.

1. System-Level Simulation Fidelity

1.1 System Performance Fidelity

Evaluates whether the autonomous system behaves similarly in simulation and in the real world under comparable conditions. This is typically assessed through statistical comparison of real-world drive logs and simulation logs, focusing on system responses and critical events.

1.2 Scenario Reproduction Fidelity

Measures how accurately a specific real-world scenario can be replayed in simulation.

• Ego reproduction fidelity: How closely the ego vehicle’s trajectory, velocity, and other behaviors match between the real-world and re-simulated run.
• Actor reproduction fidelity: How precisely other agents (e.g., vehicles, pedestrians) are recreated in simulation relative to the original scene.

1.3 Scenario Realism

Assesses how natural and believable the simulation looks and feels, both from a technical and human perspective.

• Actor model realism: Do agents behave in ways consistent with real-world norms?
• Physical maneuver realism: Are motions physically plausible (e.g., no instantaneous sideways jumps, acceleration within vehicle performance limits)?
• Behavioral maneuver realism: Do agents make reasonable decisions within the given context (e.g., yielding, overtaking, obeying traffic signals)?
• Scenario composition realism: Are the elements of the scene, such as the number of agents, placement, and diversity, consistent with actual road environments?
• Interaction realism: Do agents respond to each other in socially and contextually realistic ways?
• Event flow frequency and distribution realism: Do key events (e.g., cut-ins, near-misses) occur at rates similar to what’s observed in real-world data?

1.4 Scenario Coverage

Quantifies how comprehensively the simulation explores the Operational Design Domain (ODD) and performance space.

• ODD coverage: Are we testing across the full range of relevant conditions (e.g., road types, curvatures, intersections)?
• Performance coverage: Are we exposing the system to sufficiently challenging or critical conditions to assess safety and robustness?

2. Sub-System-Level Simulation Fidelity

2.1 Sensor Simulation Fidelity

Evaluates the realism of synthetic sensor outputs. This includes how accurately lidar, radar, and camera simulations reflect actual sensor limitations, noise, and environmental effects.

• Synthetic sensor data fidelity: How close is the simulated raw sensor data to real data in terms of resolution, distortion, and latency?
• Environmental realism: Are lighting, reflectivity, weather, and occlusions accurately modeled to influence sensor behavior?
• Repeatability & determinism: Is the sensor output deterministic under the same conditions, enabling reliable comparisons and regression testing?

2.2. Vehicle Model Fidelity

Assesses the accuracy of the simulated vehicle’s physics and dynamics compared to a real vehicle. This includes:

• Kinematic and dynamic fidelity: How accurately do the simulated vehicle’s acceleration, braking, steering, and suspension match a real vehicle’s performance under various conditions?
• Tire-road contact model realism: Does the tire model accurately represent real-world tire behavior including surface conditions affecting grip, slip, and temperature effects?
• Powertrain realism: Does the simulated powertrain (engine, engine type, transmission) accurately replicate the performance and characteristics of a real vehicle’s powertrain?

The Data Backbone for Measuring Simulation Credibility

To evaluate simulation fidelity in a meaningful way, you need comparable data across both simulated and real-world domains. Foretellix addresses this through a centralized database that brings together enriched simulation logs, drive logs, and re-simulations, providing a unified foundation for credibility assessment.

This infrastructure includes:

• Ingest of drive logs: Real-world recordings from the AV system, which serve as the reference point for evaluating simulated performance and behavior.
• Generation of simulation logs: Logs generated from Foretellix’s scenario-based simulation runs, including both abstract and concrete test cases.
• Resimulations via Smart Replay: Specific real-world events are reconstructed in simulation using Smart Replay. These replays provide a one-to-one comparison between observed and simulated behavior, especially for ego and actor trajectories.
• Enrichment and annotation with Foretify Evaluate: Both drive and simulation logs are processed through Foretify Evaluate to add critical context, such as scenario labels, KPI calculations, safety metrics, and coverage classifications.

Once unified, this annotated dataset enables both trajectory-based comparisons (for reproduction fidelity) and statistical analyses (for system-level and scenario-level fidelity). The result is a structured, traceable, and scalable way to assess whether simulated behavior aligns with the real world, and where deviations or uncertainties remain.

From Measurement to Confidence

The goal of Foretellix’s approach is not just to describe realism, but to make it actionable. By measuring simulation fidelity across well-defined dimensions, backing those measurements with data, and providing insightful visualizations, AV teams can begin to answer critical questions with clarity:

• Where are the gaps in our current test coverage?
• How much uncertainty is present in our simulation results?
• Which deviations matter, and what’s causing them?
• When can simulation-based findings be trusted to reflect real-world outcomes?

This framework supports both debugging (e.g., identifying why a simulated behavior diverges from its real-world counterpart) and strategic validation (e.g., determining whether enough of the operational domain has been explored to release a system safely).

Ultimately, this shift from intuition-driven evaluation to structured, data-backed assessment lays the foundation for simulation to become a defensible, auditable, and trusted part of the AV safety case.