ISO 34502: ISO 34502 – Tutorial (about 60 minutes)

ISO 34502 is the international standard that describes how to evaluate the safety of an automated driving system by testing it against carefully chosen scenarios rather than by driving it for an impossibly long distance. It is used by safety engineers, validation and simulation teams, system architects and the assessors and regulators who review their evidence, mainly for systems that drive a car or truck on motorways. After this tutorial you will be able to explain why scenario-based evaluation is needed, walk through the eight-step process the standard lays out, derive critical scenarios from risk factors in perception, traffic and vehicle control, and see how the results feed a SOTIF safety argument.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current and only edition is ISO 34502:2022, Road vehicles – Test scenarios for automated driving systems – Scenario based safety evaluation framework, first edition, published by ISO on 2 November 2022 (81 pages) and prepared by technical committee ISO/TC 22 (road vehicles), subcommittee SC 33, today named Vehicle dynamics, chassis components and driving automation systems testing. ISO lists it as published (stage 60.60) with no amendment or revision in progress; like every ISO standard it is due for a systematic review within five years of publication, so around 2027. This course teaches the 2022 edition. Verified 2026-10-29 against the ISO committee catalogue entry, the official preview of the standard (contents, scope, normative references and definitions) and national standards body listings.

Who it is for: engineers, test and simulation specialists, safety and quality people and project managers working on automated driving who are new to scenario-based safety evaluation, including people from functional safety (ISO 26262) or SOTIF (ISO 21448) who want to know what ISO 34502 adds.

Prerequisites: none. A rough picture of how an automated vehicle works (sensors observe the road, software decides, actuators steer and brake) helps. Every term is explained when first used.

By the end of this tutorial:

You will be able to explain why distance-based testing alone cannot show that an automated driving system is safe, and what scenario-based evaluation offers instead.
You will be able to define the core vocabulary: relevant scenario space, risk factor, critical scenario, hazardous scenario, safety test objective and concrete test scenario.
You will be able to describe the structure of ISO 34502:2022, its eight process steps in Clause 4 and the purpose of its twelve informative annexes.
You will be able to derive critical scenarios by combining risk factors from the three physics-based categories: perception, traffic and vehicle control.
You will be able to explain how test scenarios are made concrete, allocated to test platforms and evaluated against safety test objectives.
You will be able to describe how ISO 34502 evidence is reviewed, why there is no ISO 34502 certificate, and how the standard links to ISO 21448, ISO 26262 and regulations.
You will be able to apply the process to a realistic motorway automated driving feature.

Lesson 1 – Origins, purpose and scope

The problem: you cannot drive your way to proof

Imagine a company that has built an automated driving system (ADS) for motorways. While it is engaged, the person in the driver's seat may look away from the road. Before anyone sells it, someone has to answer a hard question: is it safe enough?

The obvious answer is to drive it a lot and count the incidents. The trouble is the statistics. Serious crashes are rare, so showing with confidence that a machine is at least as good as a human needs an enormous amount of driving: a widely cited 2016 RAND Corporation study estimated that a purely distance-based demonstration could require hundreds of millions to hundreds of billions of miles, depending on the safety level to be shown. Every software update would, in principle, reset the count, and most of those miles would be uneventful motorway driving that says little about the rare moments that cause crashes.

Scenario-based evaluation turns the problem around. Instead of waiting for dangerous situations to happen by chance, engineers think systematically about what makes driving dangerous, build test scenarios that concentrate on those conditions, and run them deliberately in simulation, on test tracks and on public roads. The question changes from "how many miles without a crash?" to "have we covered the situations that matter, and does the system handle them as well as it should?". ISO 34502 is the standard that organises this approach into a repeatable process.

Where it came from

Much of ISO 34502's method comes from Japan. It grew out of work by the Japan Automobile Manufacturers Association (JAMA), whose Automated Driving Safety Evaluation Framework set out a physics-based way of structuring hazardous scenarios, and out of the SAKURA project, a research programme funded by Japan's Ministry of Economy, Trade and Industry (METI) that collected real traffic data and built a scenario database. Other countries contributed during international drafting, which is why some annexes reflect other research traditions. The standard was developed in ISO/TC 22/SC 33 and published in November 2022 as part of a family of documents numbered ISO 34501 to ISO 34505 about test scenarios for automated driving.

A key idea behind the work is the safety vision adopted by the United Nations World Forum for Harmonization of Vehicle Regulations (WP.29): automated vehicles should not cause traffic accidents resulting in injury or death that are reasonably foreseeable and preventable. Those two words give scenario-based evaluation its target. The scenario catalogue has to cover what can reasonably be foreseen on the roads where the system operates, and the evaluation has to check that the system prevents what can reasonably be prevented.

What the standard covers

ISO 34502 gives guidance for a scenario-based safety evaluation framework that is applied during product development. Its scope has some firm boundaries that are worth remembering:

Automated driving systems only. It targets ADS as defined in ISO/SAE PAS 22736, the international version of the SAE levels of driving automation: systems at level 3, 4 or 5. Driver-assistance features at levels 1 and 2 are not the target.
Limited-access highways. The 2022 edition is written for motorway-type roads without intersections, entered and left through ramps. Urban driving is outside its scope.
Specific vehicle categories. It names vehicle categories 1 and 2 of the UNECE vehicle classification: power-driven vehicles with four or more wheels built mainly to carry people (category 1) or goods (category 2), so not, for example, motorcycles.
Safety, but not every safety topic. It does not deal with misuse by people, the human-machine interface (HMI) or cybersecurity. Other standards cover those.
Not comfort or efficiency. Ride comfort, energy efficiency and traffic flow efficiency are explicitly out of scope.

Although the document calls itself guidance, it contains real requirements. The most important is that it must be applied together with ISO 21448, the standard for the safety of the intended functionality (SOTIF). ISO 34502 is not a stand-alone safety standard: it is a detailed, scenario-focused method that plugs into the SOTIF process.

Lesson 2 – Key concepts and vocabulary

ISO 34502 takes its terms from ISO 34501 (test scenarios vocabulary) and adds four definitions of its own: critical scenario, hazardous scenario, risk factor and safety test objective. It also uses the automation levels of ISO/SAE PAS 22736 and the concepts of ISO 21448 (SOTIF). The explanations below are paraphrased in plain language.

Automated driving system (ADS) – the hardware and software that together perform the entire dynamic driving task on a sustained basis, within a defined set of operating conditions. In the SAE and ISO/SAE scheme this means levels 3, 4 and 5.
Dynamic driving task (DDT) – the real-time work of driving in traffic: steering, braking, accelerating, watching the road and reacting to events, but not route planning.
Operational design domain (ODD) – the conditions the ADS is designed to work in, such as road types, speed range, lighting, weather and traffic conditions. ISO 34503 gives a taxonomy for describing it.
Scenario – a description of how a traffic situation develops over time: the road, the subject vehicle, other road users, the environment, and the actions and events that unfold.
Subject vehicle – the vehicle whose ADS is being evaluated, often called the ego vehicle. Other vehicles in the scenario are called other traffic participants; the one that creates the danger is sometimes called the principal other vehicle.
Relevant scenario space – the whole set of scenarios the ADS could meet when operating in its ODD. It is far too large to test exhaustively, so it has to be structured and sampled.
Risk factor – a feature or condition of a scenario that, when present, makes harm more likely or more severe, or both. A car cutting in close ahead, low sun in the camera's view and a wet road surface are all risk factors.
Critical scenario – a scenario that contains at least one risk factor. Critical scenarios are where the evaluation concentrates its effort.
Hazardous scenario – a scenario in which harm will occur unless something other than the ADS prevents it, for example another driver braking or a safety driver intervening. The aim of the evaluation is to find hazardous scenarios before customers do.
Safety test objective – a safety property of the ADS that a set of tests is meant to demonstrate, for example a maximum acceptable rate of a certain hazardous behaviour, or the ability to avoid every collision a careful human driver could avoid. It also says when testing is complete.
Test scenario and concrete test scenario – a test scenario is a scenario selected for testing; a concrete test scenario fixes every parameter (speeds, distances, timing, weather) so that the test can be executed and repeated exactly.
Test platform – where a test runs: simulation, X-in-the-loop set-ups that mix simulation with real software or hardware, proving grounds (closed test tracks) or public roads.
Competent and careful human driver – a reference model of an attentive, skilled driver, with defined reaction times and braking or steering abilities, used to decide whether a collision counts as preventable.
Positive risk balance (PRB) – the principle that an automated vehicle should, overall, reduce risk compared with the human driving it replaces. It is one of several general risk acceptance principles, alongside ALARP (risk as low as reasonably practicable) and MEM (minimal endogenous mortality, meaning a new technology should not noticeably increase the natural death rate of the population), that can be used to justify safety test objectives; Annex J of ISO 34502 describes risk evaluation based on it.

Three levels of scenario detail

Scenario engineers usually describe the same situation at three levels of abstraction, and you will meet these words constantly when working with ISO 34502 and its companion standards. A functional scenario is a plain-language description, such as "a slower vehicle in the adjacent lane changes into the subject vehicle's lane just ahead of it". A logical scenario turns that description into parameters with ranges, such as initial gap 5 to 60 metres, relative speed 0 to 40 km/h and lateral speed of the lane change 0.5 to 2.5 m/s. A concrete scenario picks one value for every parameter, so that a simulator or a test track can reproduce it. One logical scenario can produce thousands of concrete scenarios, and much of the craft of scenario-based testing lies in choosing which ones to run.

Critical is not the same as hazardous

Beginners often mix up the two central terms. A critical scenario contains something that raises risk, but a good ADS may handle it without any danger: a car cuts in, the system brakes smoothly, nothing happens. A hazardous scenario is one where harm actually follows unless someone else steps in. The process builds a catalogue of critical scenarios, tests the ADS in them, and uses the results to discover which of them are hazardous for this particular system. That distinction drives the whole method.

Lesson 3 – Structure of the standard

ISO 34502:2022 is short in its normative core and long in its supporting material. Clauses 1 to 3 contain the scope, the normative references and four definitions. Clause 4, titled after the test scenario-based safety evaluation process, carries all the requirements. Twelve informative annexes, labelled A to L, provide methods and catalogues that illustrate how to carry out the process.

Normative references

Three documents are referenced in a way that makes them part of the requirements: ISO 34501 (the vocabulary for test scenarios), ISO 21448 (SOTIF) and ISO 26262-3 (the concept phase of functional safety, which contains the hazard analysis and risk assessment). This tells you that ISO 34502 is designed to sit inside an existing automotive safety process, not to replace it.

Clause 4 – the eight subclauses

Clause 4 is divided into eight subclauses. The first explains how the framework fits into product development; the other seven are steps of the process. Most of them follow the same pattern familiar from ISO 26262 and ISO 21448: objectives, general explanation, inputs, requirements and recommendations, and work products (the documents or data each step must produce).

Subclause	What it is about	Typical work product
4.1 Integration into the overall development process	Where scenario-based evaluation sits among the safety tasks, and its links to ISO 21448 and other standards; conformity rules	None of its own; sets the frame
4.2 Safety test objectives	Specifying the safety properties that testing must demonstrate	Safety test objectives
4.3 Specification of the relevant scenario space	Defining the scenario space from the ODD and identifying risk factors	Specification of the relevant scenario space
4.4 Derivation of critical scenarios based on risk factors	Structuring and combining risk factors into critical scenarios	Set of critical scenarios
4.5 Derivation of test scenarios covering the relevant scenario space	Selecting the scenarios to test so that coverage can be argued	Set of test scenarios
4.6 Derivation of concrete test scenarios and allocation	Fixing parameter values and choosing the platform for each test	Concrete test scenarios, their allocation to platforms, evidence that each platform is capable
4.7 Test execution	Running the tests under controlled, documented conditions	Results report for each test scenario
4.8 Safety evaluation	Judging the results against the safety test objectives to reach an overall verdict	Safety evaluation report

Figure 1 – The ISO 34502 process: seven steps from safety test objectives to safety evaluation, with a loop back when the evaluation fails.

Figure 1 shows the main line of the process. The standard's own overview chart also shows how the outcome joins the wider vehicle approval process, and stresses iteration: findings at any step can send the team back, for example when a test shows the function must be modified for safety reasons.

Conformity

Subclause 4.1 ends with requirements for conformity. The rule worth knowing by heart is that ISO 34502 has to be applied in combination with ISO 21448; its introduction describes the document as conformant with SOTIF and adding specificity to it. A conformance claim therefore rests on the SOTIF process plus the work products that each step of Clause 4 asks for.

The informative annexes

The annexes hold most of the practical know-how. They are informative (optional), but show one recognised way of doing each step. Grouped by purpose:

The physics principles approach (Annex A) – how to structure risk factors according to the physics of what an ADS does, so that the reasonably foreseeable causes of danger can be covered systematically.
Catalogues of critical scenarios (Annexes B, C and D) – traffic-related, perception-related and vehicle-control-related critical scenarios. The perception annex reasons sensor by sensor, because each sensor type has its own physical weaknesses.
Alternative derivation methods (Annex E) – criticality analysis, which studies the traffic system to find phenomena that make situations more critical and uses them to derive and structure scenarios.
Test platforms (Annex F) – how to qualify virtual test platforms so that simulation results can be trusted.
Handling the scenario space (Annexes G, H and L) – scenario databases and parameter variation, segmenting the test space into manageable parts, and checking that traffic data is sufficient to set parameter ranges.
Evaluation methods (Annexes I and J) – evaluating test results through a behavioural safety assessment, and evaluating risk using positive risk balance.
Searching for the unknown (Annex K) – constrained random testing to identify unknown critical scenarios that nobody anticipated.

Lesson 4 – How it works in practice

Two ways to look for danger

ISO 34502 begins by placing itself within the overall safety task of finding and evaluating the hazardous scenarios of an ADS. It points out that such scenarios can be searched for from two directions. The system-based approach starts from the design: which components, algorithms and interfaces could fall short, and in what situations? The scenario-based approach starts from the world: what situations exist on the roads in the ODD, and what about them makes driving harder? The two directions complement each other, much as deductive analyses (such as fault tree analysis) and inductive analyses (such as failure mode and effects analysis) do in functional safety.

ISO 34502 concentrates on the scenario-based direction. Only general physical limits are considered (a camera needs light and a line of sight), while implementation details such as a neural network's classification errors or random hardware faults are left to system-based analysis. The advantage is that the analysis depends little on how a particular system is built, so the catalogue can be reused across products that share the same scenario space. The worst-case parameter values for a given design still have to be found by testing.

Step 1 – Specify safety test objectives (4.2)

Before deciding what to test, the team decides what the tests must prove. The standard's own definition notes that safety test objectives can be derived from the acceptance criteria or validation targets set under ISO 21448, and that they include the test end criteria. Those criteria in turn usually rest on a risk acceptance principle (ALARP, MEM or PRB) or on regulation. Typical inputs are the ODD, the intended behaviour of the ADS, applicable regulations and existing scenario catalogues.

Two common ways of expressing these objectives are:

As a bound on an occurrence rate – for example, a specific hazardous behaviour must not appear during a stated number of hours of operation within the ODD, or the perception subsystem must pass wrongly perceived objects to the planner less often than a given rate.
As a performance reference model – for example, the ADS must avoid every collision that a competent and careful human driver would have avoided in the same scenario.

Either way, an objective must be measurable and must say when enough testing has been done (the end criterion); otherwise campaigns drift.

Step 2 – Specify the relevant scenario space (4.3)

The ODD defines where the system may operate; the relevant scenario space describes what can happen there. For a motorway system this includes the road layouts (straight and curved sections, merge zones where traffic joins, departure zones where it leaves), the behaviours of the subject vehicle (keeping its lane or changing lanes), the other traffic participants and their possible actions, and environmental conditions such as light, weather and road surface. The point of this step is to bound the problem: everything later is selected from this space, so anything missing here will never be tested.

ISO 34502 links this step directly to SOTIF. It adds specificity to the ISO 21448 analysis of potential functional insufficiencies and triggering conditions by identifying the reasonably foreseeable risk factors that can lead to hazardous scenarios.

Step 3 – Derive critical scenarios from risk factors (4.4)

This is the heart of the standard. The physics principles approach in Annex A observes that an ADS, like a human driver, does three things: it perceives the surroundings, it decides what to do in traffic, and it controls the vehicle to carry out that decision. Each of these can be disturbed by something in the scenario, so risk factors are sorted into three categories that mirror those three functions.

Figure 2 – The physics principles approach sorts risk factors into three categories that mirror the three things an ADS must do: perceive, plan in traffic and control the vehicle.

Perception disturbances stop the sensors from seeing the world correctly. They can be extrinsic (heavy rain, low sun, a tunnel exit, a truck hiding a stopped car, spray) or intrinsic to the vehicle (a misaligned sensor, a load that tilts the car, dirt on a lens). Each sensor works on a different physical principle and has its own weaknesses: a camera can be saturated by bright light, a radar confused by reflections from the road surface or overhead structures, and a LiDAR loses signal in rain. The perception annex reasons sensor by sensor about how a target's signal can become too weak, too noisy or mixed with signals from non-targets.

Traffic disturbances are situations created by the road and other road users that leave the subject vehicle less room or time than planned. The traffic annex builds them systematically by combining a small number of building blocks, as Figure 3 shows.

Figure 3 – A traffic-disturbance scenario is composed from road geometry, the subject vehicle's behaviour and the position and action of another vehicle, then parameterised and made concrete.

On a motorway, road geometry reduces to a few zones: the main carriageway, merge zones and departure zones. The subject vehicle keeps its lane or changes lanes. Another vehicle sits in one of a limited number of positions around it, and its dangerous behaviours fall into a few families: moving into the subject vehicle's lane (a cut-in), leaving it so that a slower or stopped vehicle ahead is suddenly revealed (a cut-out), approaching fast from behind, or slowing sharply ahead. Because the building blocks are few, combining them gives a finite, reviewable list instead of an endless brainstorm; researchers who formalised the traffic annex count two dozen such scenarios for vehicles on motorways.

Vehicle control disturbances are conditions in which perception and planning work but the vehicle cannot carry out the planned motion as expected. Internal factors include mass and load distribution; external factors include low friction, gradients, road irregularities and crosswinds. A heavily loaded car on a wet downhill curve needs longer to stop, which can turn a routine cut-in into a hazardous one.

Risk factors from different categories can occur together, and the most informative critical scenarios often combine them, such as a cut-in at dusk with low sun behind the merging car. The goal is to structure these combinations so the reasonably foreseeable causes of danger are covered, and to record them in a scenario catalogue.

Annex E offers a complementary route, criticality analysis. It studies the traffic system itself for observable phenomena that make a situation more critical as it continues (an occluded road user, a very short time gap), works out their causes, measures criticality with metrics and organises scenarios into classes. Using both methods and comparing results is a good way to spot gaps.

Step 4 – Derive test scenarios that cover the space (4.5)

A catalogue of critical scenarios is not yet a test plan. Step 4 selects the scenarios that will actually be tested and argues that, together, they cover the relevant scenario space well enough. Coverage here is not only about known critical scenarios. Because the catalogue can never be proven complete, the test set should also search for unknown hazardous scenarios, for example by varying the parameters and attributes of known scenarios, by segmenting the test space into regions and checking each region (Annex H), or by constrained random testing that generates many plausible variations within realistic limits (Annex K).

ISO 34502 connects this step to the verification and validation strategy of ISO 21448. Defining which scenarios to test and on which platforms is an essential part of that strategy.

Step 5 – Make scenarios concrete and allocate them to platforms (4.6)

Each logical scenario has parameters with ranges. Those ranges should be realistic: wide enough to include the rare but foreseeable cases, but not so wide that they include physically impossible behaviour. The best source is real traffic data, such as drone recordings of motorway traffic or naturalistic driving data. Annex L discusses how to check that the data is sufficient to set ranges with confidence, and Annex G describes scenario databases and parameter variation methods.

Figure 4 – Scenarios move from words to parameter ranges to concrete values, and each concrete test scenario is allocated to the platform best suited to it.

Concrete values are then chosen, typically concentrating near the boundary between scenarios the system should handle and scenarios nobody could handle, and each concrete test scenario is allocated to a platform. Simulation carries the broad parameter sweeps. X-in-the-loop set-ups, where real software, control units or a vehicle on a rig interact with simulated surroundings, add realism for chosen cases. Proving grounds confirm key scenarios with real sensors and dynamics. Public roads show sensible behaviour in real traffic, though dangerous scenarios cannot be staged there.

A simulation result is only as good as the simulator, so this step requires evidence that each platform can perform the tests allocated to it. Annex F describes qualifying virtual platforms, for example by comparing simulated and real sensor responses in the same scenario.

Step 6 – Execute the tests (4.7)

Execution has its own requirements because scenario tests are easy to run sloppily. The concrete scenario must be reproduced as specified (on a track, the target really must cut in at the planned gap and speed), versions and deviations recorded, and results traced to the scenario and objective. The work product is a results report for each test scenario.

Step 7 – Evaluate safety (4.8)

Finally, the results are compared with the safety test objectives to reach an overall verdict. For a performance reference model, each scenario is checked against what a competent and careful human driver could have done: a collision in a scenario that the reference driver could have avoided is a failure; a collision the reference driver could not have avoided may be acceptable if the ADS reduced its severity. Annex I describes a behavioural safety assessment of individual test results, and Annex J describes evaluating risk using positive risk balance across the whole operating domain. The safety evaluation report states whether the objectives are met and, if they are not, what must change.

The results flow back into the SOTIF process. Hazardous scenarios found by testing become known hazardous scenarios that must be addressed by modifying the function, restricting the ODD or handing over control, and the evaluation is repeated. ISO 34502 notes that its steps from scenario space to safety evaluation contribute to the SOTIF evaluation of known and unknown hazardous scenarios: by using known hazardous scenarios as a starting point and varying them, teams can explore and shrink the space of unknown ones.

Roles and artefacts

Typical roles are a SOTIF lead who owns the safety test objectives, scenario engineers who maintain the catalogue, data analysts who set parameter ranges, simulation and test engineers who qualify platforms and run tests, developers who fix what testing reveals, and independent assessors. The artefacts form a traceable chain: safety test objectives, relevant scenario space specification, critical scenario catalogue, test scenario set with a coverage argument, concrete test scenarios and an allocation report, platform qualification evidence, results reports, and the safety evaluation report.

Lesson 5 – Assessment, certification and compliance

There is no ISO 34502 certificate

ISO 34502 is a product development standard, not a management system standard. There is no accredited certification scheme issuing "ISO 34502 certificates" to companies, and it defines no maturity levels or ratings. A testing or assessment body may review a process or tool against it and issue its own statement, but that is a private opinion, not an ISO certification.

What organisations can do is claim conformance. Under the conformity requirements in 4.1, the standard is applied together with ISO 21448, and the claim is backed by the work products described in Lesson 4, which a reviewer can inspect.

Who looks at the evidence

Internal safety assessment. ISO 34502 work products are reviewed as part of the SOTIF evidence in the reviews and assessments carmakers and suppliers already run.
Independent assessors and customers. Technical services and assessment firms review scenario-based campaigns, often before type approval, and vehicle manufacturers may ask suppliers to show how their testing follows the standard.
Regulators and type-approval authorities. Regulations for automated driving rely heavily on scenario-based testing. UN Regulation No. 157 on automated lane keeping systems, for example, contains guidance on traffic-disturbance critical scenarios such as cut-in, cut-out and deceleration and uses a competent and careful driver model, ideas closely related to the work that became ISO 34502. Conforming to ISO 34502 does not by itself grant approval, but evidence produced with it can support an approval case.

What a good assessment checks

Because the standard gives a process rather than a list of pass marks, an assessor focuses on whether the reasoning holds together. Typical questions are:

Are the safety test objectives measurable, justified by a risk acceptance principle or regulation, and do they include an end criterion?
Does the relevant scenario space match the ODD, including merge and exit zones, night, rain and other conditions the ODD permits?
Were risk factors identified systematically in all three categories, and is there a record of how the catalogue was checked for gaps, for example against accident data?
Are parameter ranges based on adequate data, and is the coverage argument convincing, including the search for unknown hazardous scenarios?
Is every platform qualified for the tests allocated to it, especially the simulators that carry most of the test volume?
Can each result be traced back to a scenario and an objective, and were failures fed back into design changes and retesting rather than explained away?

Compliance is not a one-time event

Software updates, new sensors, a wider ODD or new traffic data change the picture. Keep the scenario catalogue under configuration control, rerun affected tests after changes and feed field observations back. Unlike millions of test miles, a scenario campaign can be repeated quickly.

Lesson 6 – Worked example

To see how the pieces fit together, follow a fictional supplier, Kestrel Automotive, which is developing "Motorway Pilot", a level 3 ADS for passenger cars. Its ODD is limited-access motorways in one country, speeds up to 130 km/h, day and night, dry or wet roads with light to moderate rain, but not snow or fog. The system uses a front camera, a front long-range radar, corner radars and a roof-line LiDAR. The numbers below are illustrative choices made by the fictional team, not values taken from the standard.

Safety test objectives

Kestrel's SOTIF team has already set acceptance criteria under ISO 21448. From these, and from the regulation it plans to use for approval, the team writes two kinds of safety test objectives. The first is a performance reference objective: in every critical scenario of the catalogue, Motorway Pilot must avoid any collision that a modelled competent and careful driver would avoid, and must reduce impact speed in those that cannot be avoided. The second is a rate objective for perception: in a defined number of hours of recorded motorway data, the perception system must not report a phantom obstacle that leads to hard braking more often than an agreed threshold. Each objective has an end criterion, such as every catalogue scenario tested with at least a stated parameter coverage, and no open failures.

Relevant scenario space

The scenario engineers translate the ODD into a scenario space: main carriageways with two to four lanes, curves within the design radius of the country's motorways, merge and departure zones, the subject vehicle keeping its lane or changing lanes, other cars, vans, trucks and motorcycles around it, daylight, darkness, low sun, tunnel entries and exits, dry and wet surfaces. They check the space against the ISO 34503 style ODD description so that nothing allowed by the ODD is missing.

Risk factors and critical scenarios

Using the physics principles approach, the team builds its catalogue category by category, then adds combinations. A short extract:

Category	Risk factor	Critical scenario	Main platform
Traffic	Short gap cut-in at a merge zone	A car from the on-ramp enters the subject vehicle's lane 15 m ahead while 20 km/h slower	Simulation sweep, then proving ground
Traffic	Cut-out revealing a stopped vehicle	The lead truck swerves out of lane, uncovering a broken-down car at the end of a queue	Simulation, proving ground with a soft target
Perception	Low sun behind a vehicle ahead	Camera partly saturated while the lead car brakes	X-in-the-loop with recorded sensor data, track at sunset
Perception	Radar reflections from an overhead gantry	Stationary metal structure above the road just before a stopped vehicle	Simulation with qualified radar model, track
Vehicle control	Full load and wet downhill curve	Emergency braking needed while the car is heavily loaded on a wet slope	Vehicle dynamics simulation, track validation
Combination	Spray plus cut-in	A truck's spray reduces LiDAR range as a van cuts in	Simulation, then targeted track tests

Because the traffic scenarios are generated from the building blocks in Figure 3, reviewers can see the full combination table. To check for gaps, an analyst maps national motorway accident records onto the catalogue. Two accident types involving debris on the road match nothing, so the team adds a perception scenario for small debris.

Test scenarios, parameter ranges and allocation

For the merge-zone cut-in, the logical scenario has parameters for initial gap, subject vehicle speed, speed difference and the merging car's lateral speed. Ranges come from drone recordings of busy junctions, after checking the data includes enough rare, aggressive merges. Simulation runs tens of thousands of concrete combinations, mapping where Motorway Pilot avoids a collision, where it only mitigates one, and where the reference driver would also crash. Scenarios near that boundary, plus a sample from elsewhere, go to the proving ground.

First, the team qualifies its simulator by running twenty cut-ins both on the track and virtually; braking onset and minimum distance agree within a tolerance set in advance. The radar model is less convincing in the gantry scenario, so those cases go mainly to physical testing.

Execution and evaluation

Test execution follows a written protocol: software version, sensor calibration and target vehicle settings are logged, and every run is traced to its concrete scenario. The evaluation finds one problem. In some low-sun cut-in cases, Motorway Pilot starts braking later than the reference driver and collides at low speed in cases the reference driver avoids. Under the performance objective, this is a failure.

Following the SOTIF loop, the function is modified to trust the radar track earlier when glare lowers camera confidence, and the affected scenarios plus a regression set are rerun and pass. Meanwhile, constrained random testing around known scenarios uncovers an unexpected case, a motorcycle filtering between lanes as a car cuts in, which joins the catalogue.

The outcome

The safety evaluation report states which objectives are met, lists hazardous scenarios found and how they were fixed, records residual uncertainty about unknown scenarios and cites the platform qualification evidence. It feeds the SOTIF release decision. When the ODD later grows to include light fog, the team reuses the catalogue, adds fog risk factors and reruns only the affected tests.

Lesson 7 – Relationship to other standards and frameworks

ISO 34502 is one piece of a larger puzzle. It depends on SOTIF, shares its vocabulary with a family of scenario standards, and supplies evidence to safety cases and regulations.

Figure 5 – ISO 34502 sits in the ISO 3450x scenario series, is applied together with SOTIF, and feeds an overall ADS safety case that supports regulatory approval.

Standard or framework	What it covers	Relationship to ISO 34502
ISO 21448:2022 (SOTIF)	Hazards from functional insufficiencies and foreseeable misuse when nothing is faulty	Mandatory partner: ISO 34502 must be applied with it and adds scenario-based detail to its hazard identification, verification and validation activities
ISO 26262 series	Functional safety: hazards from malfunctions of electrical and electronic systems	Complementary; ISO 26262-3 is a normative reference, and system-based fault analysis covers what the scenario-based view leaves out
ISO/SAE 21434	Cybersecurity engineering for road vehicles	Cybersecurity is explicitly outside the scope of ISO 34502; ISO/SAE 21434 is where it is handled
ISO 34501:2022	Vocabulary for test scenarios for automated driving	Normative reference supplying the terms ISO 34502 uses
ISO 34503:2023	Taxonomy and format for specifying an ODD	Helps define the ODD from which the relevant scenario space is derived
ISO 34504:2024	Categorising scenarios with tags	Helps organise and search the scenario catalogue and database
ISO 34505:2025	Evaluating scenarios and generating test cases from them	Takes test scenarios further into traceable test cases with objectives, steps, platforms and expected results
ISO/TS 5083:2025	Overall safety for ADS design, verification and validation	Gives the umbrella safety approach; ISO 34502 provides the detailed scenario-based evaluation inside it
UN Regulation No. 157 (ALKS)	Type approval of automated lane keeping systems	Uses traffic-disturbance critical scenarios and a careful driver model similar to ISO 34502's ideas; evidence from ISO 34502 can support an approval case

How it fits with SOTIF in detail

The standard spells out its contribution to ISO 21448. Its scenario space and risk factor steps add detail to the SOTIF identification of potential functional insufficiencies and triggering conditions, by turning reasonably foreseeable risk factors into a catalogue of critical scenarios. Its step for deriving test scenarios supports the SOTIF verification and validation strategy, by deciding what is tested and on which platform. Its later steps contribute to the SOTIF evaluation of known and unknown hazardous scenarios. In short, SOTIF says what must be achieved and argued; ISO 34502 offers a structured, scenario-centred way to produce part of the evidence.

Industry frameworks and research programmes

JAMA still publishes its Automated Driving Safety Evaluation Framework, whose later versions extend beyond motorways to general roads and vulnerable road users and model sensor disturbances in detail; the SAKURA project maintains a scenario database with the same physics-based structure; and open ASAM formats are widely used to describe scenarios in simulation. These are useful, but they are not part of the standard, and their newer content goes beyond the 2022 edition's motorway scope.

Common pitfalls and best practices

Pitfalls

Treating the annex catalogues as complete. They are informative motorway examples; copying them without analysing your own ODD and sensors leaves gaps.
Using ISO 34502 without ISO 21448. Scenario tests without SOTIF acceptance criteria, hazard analysis and a release argument miss the point and break the standard's own requirement.
Applying it outside its scope silently. The 2022 edition targets limited-access highways; using it for urban driving needs explicit justification and extra analysis.
Trusting unqualified simulation. Large campaigns prove little if sensor and vehicle models have not been shown to reproduce effects such as glare, reflections or wet-road grip.
Parameter ranges from thin data. Small or unrepresentative datasets exclude rare but foreseeable behaviour or include impossible behaviour.
Testing only known scenarios. A catalogue of known critical scenarios says nothing about the unknown ones. Skipping variation and random exploration gives a false sense of completeness.
Vague safety test objectives. Objectives such as "behave safely in cut-ins" cannot be passed or failed and give no end criterion.

Best practices

Start from measurable objectives. Derive them from SOTIF acceptance criteria and a stated risk acceptance principle, with pass, fail and end criteria agreed before testing.
Combine physics-based and data-driven views. Build the catalogue from the three risk factor categories, then check it against accident and traffic data.
Test near the boundary. Concentrate concrete scenarios where behaviour turns from safe to unsafe, rather than spreading tests evenly.
Qualify every platform for its job. Allocate tests according to what each platform can credibly reproduce.
Keep full traceability. Link every test to its scenario, risk factor and objective so the effect of a change is found quickly.
Treat the catalogue as a living asset. Put it under configuration control, reuse it, and feed field observations back into it.
Close the loop honestly. When a test fails, modify the function or the ODD and retest rather than reclassifying the scenario as unforeseeable.

Summary and key takeaways

ISO 34502:2022 is the first and current edition of the ISO framework for scenario-based safety evaluation of automated driving systems on limited-access highways, developed largely from Japanese industry and government research.
Scenario-based evaluation replaces the impossible task of driving billions of miles with deliberate testing of the situations where risk concentrates.
The standard must be applied together with ISO 21448; it adds a structured, scenario-centred method for producing SOTIF evidence.
Clause 4 sets out the process: safety test objectives, relevant scenario space, critical scenarios from risk factors, test scenarios that cover the space, concrete scenarios and platform allocation, test execution and safety evaluation.
Risk factors are organised by physics principles into perception, traffic and vehicle control disturbances, and combined into critical scenarios.
Results are judged against measurable objectives, often a competent and careful human driver model, with failures fed back into design changes.
There is no ISO 34502 certificate; organisations claim conformance and present traceable evidence to internal assessors, customers and regulators.
The twelve informative annexes provide catalogues and methods, including platform qualification and the search for unknown hazardous scenarios.

Reflection questions

Think of a driving situation you have experienced on a motorway that felt dangerous. Which risk factors were present, and which of the three categories do they belong to?
Your company's simulator has never been compared with track results for rain. Which tests would you move to physical platforms, and what evidence would you collect to qualify the simulator?
Write one safety test objective for a motorway ADS in each of the two forms described in Lesson 4. How would you know when testing for each is complete?
A colleague proposes extending your motorway system to urban roads by reusing the existing scenario catalogue. What would you need to add or re-analyse before relying on it?
How would you explain to a manager why the number of test kilometres driven is not, on its own, a good measure of how safe the ADS is?