ADAS verification: when "how many test miles" stops being the right question

Key takeaways

• The "how many ADAS test miles" question still drives program budgets, but in 2026 the right answer is no longer a mileage number. It is a fraction of a triggering-condition catalog covered inside a defined Operational Design Domain (ODD).
• The RAND research report Driving to Safety (Kalra and Paddock, 2016) estimated that demonstrating an autonomous vehicle is no worse than a human driver, with statistical confidence, would require hundreds of millions to hundreds of billions of failure-free miles. That estimate is the reason mileage-only V&V plans fail program review on safety-critical ADAS features.
• ISO 21448:2022 (Safety of the Intended Functionality, or SOTIF) made the shift formal: the standard moves Advanced Driver Assistance Systems (ADAS) verification from miles driven to scenario coverage of identified triggering conditions inside a defined ODD.
• UN Regulation 157 (Automated Lane Keeping Systems) and Euro NCAP's ADAS roadmap both name specific scenarios that a feature must demonstrably handle before approval. A program that cannot map test cases to those named scenarios fails the audit regardless of miles logged.
• Hardware-in-the-Loop (HIL) coupled with scenario simulation is the architecture that lets an Original Equipment Manufacturer (OEM) or Tier-1 supplier accumulate scenario coverage at a rate physical fleet driving cannot match.

The most common question an Advanced Driver Assistance Systems (ADAS) program owner still gets from their CFO is "how many test miles do we need before we can ship?" It is a reasonable question. It made sense in 2016. In 2026, on a feature with any meaningful safety case, the answer is no longer a mileage number, and quoting one in a program review is the moment the safety lead disengages from the conversation.

This piece is about why mileage stopped being the right metric, what replaced it, and how to brief a board on ADAS verification readiness without resorting to a number that does not survive scrutiny.

Why this matters now

Three pressures have moved ADAS verification past the mileage frame in the last 36 months.

The first is the 2022 final publication of ISO 21448 (Safety of the Intended Functionality, or SOTIF). The earlier ISO/PAS 21448:2019 was already shaping internal program practice, but ISO 21448:2022 made the scenario-based framing canonical in the same way ISO 26262:2018 made fault-driven safety analysis canonical for electrical and electronic systems. Programs being audited against ISO 21448:2022 are expected to demonstrate scenario coverage of identified triggering conditions, not a mileage total.

The second is UN Regulation 157 (UN R157) for Automated Lane Keeping Systems (ALKS), which entered into force in 2021 and has been amended several times since to broaden speed envelopes and operational conditions [CITATION NEEDED - confirm amendment status as of 2026]. UN R157 explicitly names scenarios an approved ALKS must handle, including cut-in, cut-out, and lead-vehicle braking events. An approval submission that cannot show test cases mapped to each named scenario does not progress regardless of fleet mileage.

The third is Euro NCAP's evolving ADAS scoring, which has moved from binary "feature present" assessments toward scenario-resolved scoring of Assisted Driving and Highway Assist [CITATION NEEDED - confirm specific 2026 Euro NCAP scoring rubric]. The practical effect is that the marketing claim and the engineering verification both have to be tied to a named scenario set, not a mileage figure.

Where did the "X billion miles" estimate come from?

The reason mileage targets feel intuitive is that there is a real, well-known number floating around the industry. It comes from the RAND research report Driving to Safety: How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability? (Kalra and Paddock, RAND Corporation report RR-1478, 2016).

The paper asked a precise statistical question: how many failure-free miles would an autonomous fleet need to log to demonstrate, with reasonable statistical confidence, that the fleet's fatality rate is at or below the U.S. human-driver fatality rate? The answer ranged from hundreds of millions to hundreds of billions of miles depending on the confidence level required and the failure rate being claimed.

The two takeaways from that paper that matter for ADAS verification today are unchanged:

First, demonstrating safety claims at human-comparable rates through fleet mileage alone is not economically feasible for any single program. The fleet mileage required outruns the time available before a feature must be shipped.

Second, that means verification methodology has to do something more efficient than accumulating miles. The replacement is scenario coverage: enumerate the situations a feature must handle, cover each one with test cases (in simulation, on HIL, and in the field where appropriate), and report coverage of the enumerated set rather than miles logged against an open-ended denominator.

Why is mileage being replaced by scenario coverage?

The honest answer is that mileage was never the metric the standard asked for. It was the proxy programs reached for because scenario enumeration is harder.

ISO 21448:2022 frames the problem as identifying triggering conditions, which are specific combinations of environment, road geometry, traffic agents, sensor degradations, and ODD boundary conditions that could cause the intended functionality to behave unsafely. The standard does not name a mileage target. It expects the program to (a) define the ODD precisely, (b) enumerate the triggering conditions that could occur inside that ODD, (c) cover those triggering conditions through scenario-based verification, and (d) provide a credible argument that any residual triggering conditions are sufficiently improbable.

Scenario coverage works because most of the safety-relevant variation in driving sits in a small fraction of the operating envelope. A program can spend ten thousand fleet miles and not encounter the specific combination of low sun angle, pedestrian crossing against a dark background, and partial sensor occlusion that breaks a perception stack. The same combination can be exercised deterministically in simulation in seconds, with controlled variation across hundreds of parameter sweeps.

For working engineers, the practical consequence is that the verification artifact set changes. The ODD specification, the triggering-condition catalog, the scenario library, and the test-case-to-scenario traceability matrix replace the fleet-mileage logbook as the primary verification evidence.

What does scenario-based ADAS verification actually look like?

Three architectural layers carry the verification load on a current ADAS program.

Simulation at the perception and decision layer. A scenario simulator drives synthetic sensor inputs (camera, radar, lidar) through the perception stack and exercises the decision and planning logic against parameterized scenarios. This is where the bulk of scenario-coverage volume is generated: tens or hundreds of thousands of scenario variants run unattended over a release cycle. The verification artifact is coverage of the parameter space inside each scenario class, not raw scenario count.

Hardware-in-the-Loop (HIL) at the integration layer. The HIL rig replaces synthetic perception with the real Electronic Control Unit (ECU) executing production binaries against simulated sensor feeds. HIL is where coverage of the actual production software, including timing behavior and resource contention, becomes credible. The HIL rig is also where fault injection (sensor dropouts, communication faults, degraded inputs) gets exercised against the named SOTIF triggering conditions.

Physical fleet driving at the residual-risk and ODD-validation layer. Field driving still matters, but its role is no longer to accumulate miles toward a target. It validates that the ODD assumptions hold in the real operating environment, surfaces previously-unknown triggering conditions for promotion into the scenario catalog, and provides the rare, high-value field events the simulation environment cannot synthesize credibly.

A working ADAS verification program runs all three layers continuously, with the scenario catalog and the field-event database feeding each other through a defined triage process.

How LHP approaches ADAS verification

LHP's ADAS verification practice is built around the same three layers, with two specific commitments worth naming.

The first is that the verification architecture is built to ISO 21448:2022 evidence requirements from the start, not retrofitted at the end of the program. The triggering-condition catalog is treated as a first-class engineering artifact, owned by the safety and systems engineering team, with explicit traceability into the scenario library and the test-case set.

The second is that the HIL layer is treated as the spine of the verification effort, not a downstream check. The LHP ADAS HIL Solution (lhpes.com/adas-hil-testing) is the architecture this practice sits on. The capability page details how scenario-resolved coverage gets generated against production ECU software with sensor-feed simulation, fault injection, and traceable test-case mapping back to the safety case.

This is the verification posture LHP brings to a Tier-1 supplier or OEM that needs to demonstrate ADAS feature readiness against UN R157, ISO 21448, and Euro NCAP scoring at the same time, without resorting to a fleet-mileage number that does not survive program review.

What this means for your next program

If your ADAS program is still budgeting against a fleet-mileage target, the next program review is the moment to retire the metric. Three actions move the program forward this quarter:

1. Publish the ODD specification. Even a draft ODD is more useful than an open-ended one, because every other verification artifact derives from it.
2. Start the triggering-condition catalog. The first version will be incomplete; the version that matters is the one the program updates every release as field events and simulation findings flow in.
3. Set the scenario-coverage report as the primary verification metric in the program review pack. The mileage number can stay as supporting context. It cannot stay as the headline.

For more on where ADAS engineering substance is converging, see the LHP overview of how ADAS bridges into autonomy (lhpes.com/blog/adas-bridging-todays-tech-to-tomorrows-autonomy) and the foundational LHP piece on safety in ADAS design and verification (lhpes.com/blog/how-to-ensure-safety-in-adas-design-and-verification). For the underlying SOTIF framing, the LHP ISO 21448 introduction (lhpes.com/blog/what-is-sotif-safety-of-the-intended-functionality/iso-21448) remains the entry point, though the framing in this piece reflects the 2022 final publication rather than the 2019 PAS edition.

Frequently asked questions

How many test miles does an ADAS feature need before it can ship?

There is no defensible single mileage answer for a safety-critical ADAS feature. The RAND 2016 Driving to Safety analysis showed that demonstrating human-comparable failure rates with statistical confidence requires fleet miles in the hundreds of millions to hundreds of billions, which is not economically feasible for any single program. The verification question that does have a defensible answer is "what fraction of the triggering-condition catalog for the defined Operational Design Domain (ODD) has been covered, with what method, and with what confidence?" Programs that brief the second question pass review. Programs that brief the first do not.

What does ISO 21448 (SOTIF) actually require for ADAS verification?

ISO 21448:2022 requires a precisely defined Operational Design Domain (ODD), an enumerated triggering-condition catalog inside that ODD, scenario-based verification that covers the cataloged triggering conditions, and a credible residual-risk argument for triggering conditions not yet identified. The standard does not name a mileage target. It expects evidence that the intended functionality has been verified against the situations that could cause it to behave unsafely, not against an open-ended fleet mileage denominator. ISO 21448:2022 is the canonical reference; the earlier ISO/PAS 21448:2019 framing is superseded.

Where does Hardware-in-the-Loop (HIL) fit in scenario-based ADAS verification?

HIL is the integration-layer spine. It runs the production Electronic Control Unit (ECU) binary against simulated sensor feeds, which is where coverage of the actual shipped software (including timing behavior and resource contention) becomes credible. HIL is also the natural place to inject SOTIF-relevant faults: sensor dropouts, degraded inputs, and communication faults that would be rare and uncontrolled in physical fleet driving but can be exercised deterministically on the rig. See the LHP HIL fundamentals piece (lhpes.com/blog/what-is-hil-testing) for the underlying methodology and lhpes.com/adas-hil-testing for the LHP ADAS HIL capability page.

Does this mean physical fleet driving no longer matters?

No. Fleet driving still has a defined verification role: it validates that the ODD assumptions hold in the real operating environment, it surfaces previously-unknown triggering conditions that get promoted into the scenario catalog, and it captures rare field events that simulation cannot synthesize credibly. What has changed is that fleet mileage is no longer the primary verification metric. Fleet driving feeds the scenario catalog and the residual-risk argument; scenario coverage of the catalog carries the verification case.

About LHP Engineering Solutions

Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.

LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.

In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.

When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.

Because in industries where technology must perform as intended, precision engineering matters.