ISO 34505:2025
(Main)Road vehicles — Test scenarios for automated driving systems — Scenario evaluation and test case generation
Road vehicles — Test scenarios for automated driving systems — Scenario evaluation and test case generation
This document defines a methodology to evaluate scenarios and provides a procedure for extending test scenarios to test cases. This document also defines the necessary characteristics of test cases, which include but are not limited to unified identifiers, test objectives, inputs, steps, platforms and expected results. This document describes methods and criteria to evaluate test cases (e.g. frequency, criticality, complexity of a scenario), the coverage concerning functional and technical requirements, operational domain (OD), test criteria, and also the optimization of sets of prioritized test cases. This document is applicable to Level 3 and higher ADSs as defined in ISO/SAE PAS 22736. The focus of this document is on scenarios, which will be tested to evaluate safety (functional safety and safety of the intended functionality (SOTIF)). The content, in general, is also applicable to non-safety related test scenarios.
Véhicules routiers — Scénarios d'essai pour les systèmes de conduite automatisée — Évaluation de scénarios et génération de cas de test
General Information
Standards Content (Sample)
International
Standard
ISO 34505
First edition
Road vehicles — Test scenarios
2025-06
for automated driving systems —
Scenario evaluation and test case
generation
Véhicules routiers — Scénarios d'essai pour les systèmes de
conduite automatisée — Évaluation de scénarios et génération
de cas de test
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Introduction and overview . 4
4.1 General .4
4.2 Requirements for compliance .5
5 Evaluation of scenario characteristics . 5
5.1 Purpose .5
5.2 Set of scenarios .6
5.2.1 Objectives .6
5.2.2 General .6
5.2.3 Input to this clause .6
5.2.4 Requirements .7
5.2.5 Work products .7
5.3 Relations between the scenarios and functional and technical requirements .7
5.3.1 Objectives .7
5.3.2 General .7
5.3.3 Input to this clause .8
5.3.4 Requirements .8
5.3.5 Work products .9
5.4 Relation between scenarios and ODD .9
5.4.1 Objectives .9
5.4.2 General .9
5.4.3 Input to this clause .9
5.4.4 Requirements .9
5.4.5 Work products .10
5.5 Relation between the scenarios and test objectives .10
5.5.1 Objectives .10
5.5.2 General .10
5.5.3 Input to this clause .10
5.5.4 Requirements .10
5.5.5 Work products .11
6 Test case generation before test execution .11
6.1 Purpose .11
6.2 Selection of scenarios .11
6.2.1 Objectives .11
6.2.2 General .11
6.2.3 Input to this clause . 12
6.2.4 Requirements and recommendations . 12
6.2.5 Work products . 12
6.3 Scenario priority . 13
6.3.1 Objectives . 13
6.3.2 General . 13
6.3.3 Input to this clause . 13
6.3.4 Requirements .14
6.3.5 Work products .14
6.4 Extend scenarios to test cases . 15
6.4.1 Objectives . 15
6.4.2 General . 15
6.4.3 Input to this clause . 15
6.4.4 Requirements .16
iii
6.4.5 Work products .17
6.5 Methods to optimize the set of test cases .17
6.5.1 Objectives .17
6.5.2 General .17
6.5.3 Input to this clause .17
6.5.4 Requirements .17
6.5.5 Work products .17
7 Test case evaluation during test execution .18
7.1 Purpose .18
7.2 Test initialization.18
7.2.1 Objectives .18
7.2.2 General .18
7.2.3 Input to this clause .18
7.2.4 Requirements .18
7.2.5 Work products .18
7.3 Monitoring of test execution .18
7.3.1 Objectives .18
7.3.2 General .18
7.3.3 Input to this clause .19
7.3.4 Requirements .19
7.3.5 Work products .19
8 Test case evaluation after test execution . 19
8.1 Purpose .19
8.2 Comparison of specified and executed test case after execution .19
8.2.1 Objectives .19
8.2.2 General . 20
8.2.3 Input to this clause . 20
8.2.4 Requirements . 20
8.2.5 Work products . 20
8.3 Evaluation of executed test cases concerning validity of simulation (for virtual testing
only) .21
8.3.1 Objectives .21
8.3.2 General .21
8.3.3 Input to this clause .21
8.3.4 Requirements .21
8.3.5 Work products .21
8.4 Evaluation of executed test cases concerning exposure in reality . 22
8.4.1 Objectives . 22
8.4.2 General . 22
8.4.3 Input to this clause . 22
8.4.4 Requirements . 22
8.4.5 Work products . 22
8.5 Evaluation of traceability . 22
8.5.1 Objectives . 22
8.5.2 General . 23
8.5.3 Input to this clause . 23
8.5.4 Requirements . 23
8.5.5 Work products . 23
8.6 Evaluation of coverage based on executed test cases. 23
8.6.1 Objectives . 23
8.6.2 General . 23
8.6.3 Input to this clause . 23
8.6.4 Recommendations.24
8.6.5 Work products .24
Annex A (informative) Methodology to classify the relation between ODD and scenario .25
Annex B (informative) Methodology to sort the test priority based on multiple criteria .27
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 33, Vehicle
dynamics, chassis components and driving automation systems testing.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
The rapid development of automated driving technology with the goal of improving safety and comfort has
become an important aspect in the development of modern automobile technology. The evaluation of tests of
automated driving systems (ADSs) based on test scenarios has become a common method.
A scenario is a sequence of scenes usually including the ADS(s)/subject vehicle(s) and their interactions in the
process of performing a dynamic driving task (DDT). A test scenario is a scenario intended for the testing
and assessment of ADS(s) or subject vehicle(s) in their operational environment (see ISO 34501). A test case
is a set of test inputs (stimulation), steps, test platforms and expected results (pass/fail criteria) developed
for a particular test objective (the test case is defined later in this document). In order to execute the test,
some additional items are needed to supplement the scenario. Another important topic is how to choose the
right test scenarios for a particular automated driving system (ADS) function.
This document is the basis of generating and evaluating scenario-based test cases for ADSs.
This document is intended to be used to harmonize and standardize the evaluation of scenarios and the
procedure and methodology of the generation of test cases for ADSs.
vi
International Standard ISO 34505:2025(en)
Road vehicles — Test scenarios for automated driving
systems — Scenario evaluation and test case generation
1 Scope
This document defines a methodology to evaluate scenarios and provides a procedure for extending test
scenarios to test cases. This document also defines the necessary characteristics of test cases, which include
but are not limited to unified identifiers, test objectives, inputs, steps, platforms and expected results.
This document describes methods and criteria to evaluate test cases (e.g. frequency, criticality, complexity
of a scenario), the coverage concerning functional and technical requirements, operational domain (OD), test
criteria, and also the optimization of sets of prioritized test cases.
This document is applicable to Level 3 and higher ADSs as defined in ISO/SAE PAS 22736. The focus of this
document is on scenarios, which will be tested to evaluate safety (functional safety and safety of the intended
functionality (SOTIF)). The content, in general, is also applicable to non-safety related test scenarios.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 21448:2022, Road vehicles — Safety of the intended functionality
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 34501, Road vehicles — Test scenarios for automated driving systems — Vocabulary
ISO 34502:2022, Road vehicles — Test scenarios for automated driving systems — Scenario based safety
evaluation framework
ISO 34503:2023, Road vehicles — Test scenarios for automated driving systems — Specification for operational
design domain
ISO 34504, Road vehicles — Test scenarios for automated driving systems — Scenario categorization
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 34501, ISO 34502, ISO 34503,
ISO 34504 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
prospective scenario criticality
measurable criteria to reflect the number and weighting of the risk factors in the scenario
Note 1 to entry: This definition is focus on field of safety, for other field like to test the energy economy of ADS could
have other criteria.
Note 2 to entry: The prospective scenario criticality describes in prospective the possible collision and its impact to the
safety of the traffic participants and the passenger(s) of the ADS equipped vehicle, and is based on ISO 34502:2022, 3.1.
Note 3 to entry: The measurement for the prospective scenario criticality can be a weighted sum of the expected time
to collision and expected relative velocity at the collision time.
Note 4 to entry: Knowledge of the ADS can be considered while estimating the criticality of the scenario, but it is not
necessary to consider it as the real safety assessment of ADS is done after testing the scenario.
Note 5 to entry: Due to the different operational design domain (ODD) and DDT definition of each ADS, the prospective
scenario criticality rating may be different for each ADS.
Note 6 to entry: For some ODD attributes, the scenarios at the boundary of ODD are more critical compared to the non-
ODD boundary. Attributes inside ODD can also cause risks.
EXAMPLE A rather uncritical scenario is driving with low velocity (e.g. on traffic jam) on a highway with a leading
vehicle and nominal weather conditions and standard road infrastructure [see nominal scenario (3.6)]. A rather critical
scenario is driving with an ADS at higher velocity on a multi-city road having a cut in with a much lower velocity close
in front of the ADS. The relative velocity of the ADS and the cut in vehicle is high and thus the probability of a collision
and impact is potentially high. In this example the prospective scenario criticality metric as described in Note 2 to
entry can be used.
3.2
scenario complexity
measurable criteria to reflect dimensionality factors
Note 1 to entry: Dimensionality factors are factors or conditions of a scenario that, if present, increase the number of
possible combinations of relevant scenario parameters that may influence the ADS driving task.
EXAMPLE 1 Dimensionality factors can describe the behaviour of the participating road users, the defined road
infrastructure and the environmental conditions.
Note 2 to entry: The more dimensionality factors there are, the more complex the scenario typically is.
Note 3 to entry: Factors, influencing the complexity, can be systematically classified into the following (see
ISO 34502:2022 Annexes A, B, C and D):
— the complexity factor information of road, e.g. road construction;
— the complexity factor information of infrastructure;
— the complexity factor information of temporary modifications and events;
— the complexity factor information of objects, e.g. the number and the type of dynamic traffic participants and their
behaviours;
— the complexity factor information of environment, e.g. various weather conditions;
— the complexity factor information of digital information.
Note 4 to entry: The complexity of a scenario can correlate with the amount of effort that is necessary to realise the
scenario because of the high number of scenario attributes to be considered.
Note 5 to entry: As far as virtual testing is concerned, a higher scenario complexity means a bigger effort to implement
the higher number of scenario attributes. When the scenario is tested in the real world, the effort can be defined by the
time or costs to realise the scenario.
EXAMPLE 2 A rather noncomplex scenario is driving on main roadway of a 2-lane highway without other influencing
traffic participants. A rather complex scenario is driving on a 4-lane highway with dense traffic in rainy conditions
while other traffic participants change the speed and lane frequently.
3.3
scenario exposure
measurable criteria to reflect the probability of occurrence of a scenario
Note 1 to entry: From a mathematical perspective the probability of a concrete scenarios (concrete values of continuous
parameters) is zero. Nevertheless, a scenario can represent a set of concrete scenarios such that this scenario has a
probability greater than zero.
Note 2 to entry: It can be measured via calculating the occurrence frequency of a scenario in real driving.
3.4
scenario evaluation
systematic determination of the extent to which a scenario meets a specified criterion
[SOURCE: ISO/IEC 25040:2011, 4.16, modified — Term was originally "evaluation", "entity" was replaced by
"scenario" in the definition. ]
3.5
test case
set of test inputs (stimulation), steps, platforms and expected results (pass/fail criteria) developed for a
particular test objective
Note 1 to entry: Test objectives can be used to exercise a particular programmed path or to verify compliance of the
system under test (SUT) with a specific requirement or architectural element (e.g. software unit level or vehicle level).
Note 2 to entry: The test case includes test scenarios and considers the ODD or target operational domain (TOD).
Details on TOD are provided in ISO 34503.
Note 3 to entry: Subclause 6.4 describes how to extend scenarios to test cases and defines the characteristics of test cases.
Note 4 to entry: Depending on the detailed definition of a test scenario, the test case can be equal to the test scenario
or a superset of a test scenario. For example, the pass/fail criteria can be included in the test scenario or can be added
to the test scenario such that the test case compound by the test scenario and the pass/fail criteria.
Note 5 to entry: The evaluation of the test case can be ADS specific.
Note 6 to entry: The effectiveness of a test case depends on the overall test goal. The overall test goals can be to give
evidence for argumentation (e.g. safety, laws, regulations) or find failure/error/problems or challenge the ADS.
3.6
nominal scenario
traffic scenario containing reasonably foreseeable situations that reflect normal condition and non-critical
driving manoeuvres
Note 1 to entry: Traffic scenario means a description of one or more real-world driving situations that may occur
during a given trip.
[SOURCE: Reference [12]]
3.7
macroscopic evaluation
evaluation of the performance of an ADS based on multiple executed test scenarios
Note 1 to entry: Details on macroscopic evaluation are stated in ISO 34502:2022, F.3.
3.8
microscopic evaluation
evaluation of the performance of an ADS based on a single, executed test scenario
Note 1 to entry: Details on microscopic evaluation are stated in ISO 34502:2022, F.3.
3.9
ADS feature
ADS’s design-specific functionality at a given level of driving automation within a particular ODD, if
applicable
[SOURCE: ISO/TS 5083:2025, 3.3, modified — Notes to entry and the example were removed.]
3.10
diagnostics
process including the detection process of possible malfunctions, the identification of the likely root cause of
these malfunctions and the appraisal of its relevance for the operation of the vehicle
[SOURCE: ISO 20077-1:2017, 3.2, modified — The original term entry included the admitted term “diagnostics
process”.]
3.11
in-vehicle information and control system
in-vehicle system that manages the information from inside the vehicle and from its environment to
influence the state or behaviour of the vehicle
Note 1 to entry: The system includes hardware (e.g. physical sensors, actuators, and hardware controller) and
software.
Note 2 to entry: The system refers to subsystems or the entire system.
4 Introduction and overview
4.1 General
The traceability over all artefacts is a clause-overarching topic which is further described in
ISO 26262-2:2018. In Clause 5 the inputs are defined to evaluate the scenarios. Before the scenario evaluation
the test objective is defined. In Clause 6 the scenario evaluation activities that need to be performed before
the test execution are described. This is done by evaluating the scenario characteristics, extending the
scenarios to test cases and optimizing the set of test cases. The relations between the scenarios and other
artefacts which are defined in Clause 5 will be used as an input to Clause 6, to evaluate whether the selected
scenarios are appropriate for the tested ADS feature. The test case generation is described in chapter 6.4.
The investigations to analyse the test cases concerning initialization of the test run and monitoring during
test execution are described in Clause 7. After test execution, the comparison of the initial specified and the
resulting test case, the evaluation of the resulting test case concerning physical principle and probability in
reality can be found in Clause 8. A detailed representation of the workflow described in this document can
be found in Figure 1.
Key
general in/outputs of 34505
evaluation of scenarios
evaluation of test cases
Figure 1 — ISO 34505 workflow to evaluate scenarios and generate test cases
4.2 Requirements for compliance
When claiming compliance with this document, each requirement shall be met unless a rationale is provided
demonstrating that the non-compliance is deemed acceptable, i.e. the corresponding objectives are still
achieved.
5 Evaluation of scenario characteristics
5.1 Purpose
In this clause the inputs and their connection to the scenario evaluation are described. The scenario
characteristics include scenarios and their relation to other artefacts, like ODD or requirements. The relation
of scenarios to functional requirements, technical requirements, ODD or test objectives can be direct
or indirect (e.g. the functional requirement is linked to ODD, and the scenario is linked to the functional
requirement, then the scenario is indirectly linked to the ODD). In this clause the inputs (from ISO 34502
and ISO 21448) are detailed with focus of scenario evaluation.
The scenarios can include, but are not limited to, reasonably foreseeable misuse and triggering conditions.
5.2 Set of scenarios
5.2.1 Objectives
Scenario-based verification and validation methods include an adequate representation or coverage of
relevant scenarios to effectively verify and validate an ADS as a specific in-vehicle information and control
system. The objective of 5.2 is to define and specify the set of scenarios that are required during scenario-
based verification and validation.
For detailed descriptions of the set of scenarios, see ISO 34502:2022, 4.4.
5.2.2 General
ISO 34502 describes a scenario-based approach of how to generate the set of scenarios (multiple scenario
abstraction levels possible) for safety test objectives and related safety requirements. This set of scenarios
can be extended to reflect the non-safety test objectives. When scenario is used in general in this document,
it could refer to a functional, abstract, logical or concrete scenario.
In case there is a general, pre-existing scenario set (e.g. a scenario database), the scenarios are analysed to
determine whether they fit to the defined ADS, ODD, and whether they are relevant concerning the safety
concept and the specified requirements.
There are a number of approaches for identifying scenarios to verify and validate ADS. For example,
scenarios can be identified based on:
a) analysing human driver behaviour, including evaluating naturalistic driving data;
b) analysing collision data of crash databases (e.g. collected by law enforcement, insurance companies);
c) analysing traffic patterns in specific ODD (e.g. by recording and analysing road user behaviour at
intersections);
d) analysing data collected from ADS’ sensors (e.g. accelerometer, camera, RADAR and global positioning
systems);
e) using especially configured measurement vehicle, onsite monitoring equipment, drone measurements,
etc. for collecting various traffic data (including other road users);
f) knowledge or experience acquired during ADS development;
g) synthetically generated scenarios from key parameter variations;
h) engineered scenarios based on functional safety requirements and SOTIF; and
i) using the selection of tags of ISO 34504 that apply for the ADS and the ODD under consideration.
5.2.3 Input to this clause
5.2.3.1 Prerequisites
The following information shall be available (see ISO 34502:2022, 4.3.3.1 and 4.3.3.2):
a) safety test objectives in accordance with ISO 34502:2022, 4.2;
b) item definition in accordance with ISO 26262-3:2018, Clause 5;
c) specification of the functionality in accordance with ISO 21448 (e.g. functional requirements);
d) capabilities of the ADS (e.g. according to ISO/IEC 25040:2011, Annex F);
e) description of ODD;
f) description of the design and the functionality of the ADS, including the intended behaviour;
g) other safety-relevant scenario catalogues (e.g. consumer ratings);
h) sources of information based on which parameter ranges can be defined (e.g. traffic monitoring data,
accident data, field operational test, naturalistic driving data, insurance data, map and road data, expert
knowledge, coverage requirements);
i) scenario attributes (e.g. as defined in ISO 34504).
NOTE Non-safety inputs or details can be inputs to define the set of scenarios (e.g. comfort test objectives).
5.2.3.2 Further supporting information
The following information can be considered:
a) regulations (e.g. Reference [13]);
b) government guidelines (e.g. References [14], [15], [16]);
c) regional-specific social norms (e.g. Reference [17]).
5.2.4 Requirements
5.2.4.1 Based on the procedure in ISO 34502, the scenarios shall be specified to be realisable.
5.2.4.2 The relevant scenario space shall be specified in accordance with ISO 34502:2022, 4.3.
5.2.4.3 The scenarios shall be evaluated whether the development of scenarios was done based on a
defined process, such as in ISO/IEC 25040 or ISO 26262-8. For safety test objective, ISO 34502 shall be used
for the development of test scenarios. For other test objectives, additional methods can be applied.
5.2.4.4 The scenario format shall be evaluated to determine whether it is capable of sufficiently describing
the scenario.
5.2.4.5 The scenario format shall be well defined (e.g. ASAM OpenSCENARIO XML), such that scenarios
can be checked against the format definition.
NOTE Format definition includes syntactic and semantic definitions.
5.2.5 Work products
Set of scenarios with specification of scenario space.
5.3 Relations between the scenarios and functional and technical requirements
5.3.1 Objectives
The objective of 5.3 is to relate the scenarios to the functional and technical requirements.
5.3.2 General
In 5.3 the connection of the scenario
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.