Road Vehicles — Test scenarios for automated driving systems — Specification for operational design domain

This document specifies the requirements for the hierarchical taxonomy for specifying operating conditions which enable the definition of an operational design domain (ODD) of an automated driving system (ADS). This document also specifies requirements for the definition format of an ODD using the taxonomy. The ODD comprises specific conditions (which include the static and dynamic attributes) within which an ADS is designed to function. This document is mainly applicable to level 3 and level 4 ADS. An ODD for level 5 ADS is unlimited (i.e. operation is possible everywhere). This document can be used by organizations taking part in developing safety cases for automated vehicles, in particular, for organizations conducting trials, testing and commercial deployment. This document can also be used by manufacturers of level 3/4 ADS to define the ADS’ operating capability. It may also be of interest to insurers, regulators, service providers, national, local and regional governments to enable them to understand possible ADS deployments and capabilities. This document does not cover the basic test procedures for attributes of the ODD. It does not cover the monitoring requirements of the ODD attributes.

Véhicules routiers — Scénarios d'essai pour les systèmes de conduite automatisée — Spécification du domaine de conception opérationnelle

General Information

Status
Published
Publication Date
07-Aug-2023
Current Stage
6060 - International Standard published
Start Date
08-Aug-2023
Due Date
02-May-2023
Completion Date
08-Aug-2023
Ref Project

Buy Standard

Standard
ISO 34503:2023 - Road Vehicles — Test scenarios for automated driving systems — Specification for operational design domain Released:8. 08. 2023
English language
29 pages
sale 15% off
Preview
sale 15% off
Preview
Draft
ISO/FDIS 34503 - Road Vehicles — Test scenarios for automated driving systems — Specification for operational design domain Released:5/7/2022
English language
27 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 34503
First edition
2023-08
Road Vehicles — Test scenarios
for automated driving systems —
Specification for operational design
domain
Véhicules routiers — Scénarios d'essai pour les systèmes de
conduite automatisée — Spécification du domaine de conception
opérationnelle
Reference number
ISO 34503:2023(E)
© ISO 2023

---------------------- Page: 1 ----------------------
ISO 34503:2023(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2023
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
  © ISO 2023 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 34503:2023(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Operational design domain (ODD) and target operational domain (TOD) .3
6 ODD and scenario relationship . .3
7 ODD requirements and application .4
7.1 Abstraction of ODD definition. 4
7.2 Monitoring ODD attributes . 5
7.3 Implication to scenario-based testing . 5
8 ODD taxonomy . 6
8.1 General . 6
8.2 Top level ODD classification . 6
9 Scenery elements . 7
9.1 General . 7
9.2 Zones. 8
9.3 Drivable area . 8
9.3.1 General attributes . 8
9.3.2 Drivable area type . 8
9.3.3 Drivable area geometry . 9
9.3.4 Drivable area lane specification . 10
9.3.5 Drivable area signs . 11
9.3.6 Drivable area edge . 11
9.3.7 Drivable area surface .12
9.4 Junctions . . 13
9.4.1 General .13
9.4.2 Roundabout .13
9.4.3 Intersection . 14
9.5 Basic road structures . 14
9.6 Special structures . 14
9.7 Temporary drivable area structures . 15
10 Environmental conditions .15
10.1 General . 15
10.2 Weather . 15
10.2.1 General .15
10.2.2 Ambient air temperature . 15
10.2.3 Wind . 15
10.2.4 Rainfall . 16
10.2.5 Snowfall . 17
10.3 Particulates . 17
10.4 Illumination . 17
10.5 Connectivity . 18
11 Dynamic elements .19
11.1 Traffic agents . 20
11.2 Subject vehicle . 20
12 ODD definition format .21
12.1 General . 21
iii
© ISO 2023 – All rights reserved

---------------------- Page: 3 ----------------------
ISO 34503:2023(E)
12.2 Type of definition mode . 21
12.3 Human readability . 21
12.4 Inclusion, exclusion, and conditional . 22
12.5 Extensibility and expressing relationships between ODD attributes .22
12.6 Objective boundaries . 22
12.7 Statement composition. 23
Annex A (informative) Operational design conditions (ODC): including vehicle internal
aspects to the ODD .24
Annex B (informative) Examples of ODD definition (for various regions) .26
Bibliography .29
iv
  © ISO 2023 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 34503:2023(E)
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 documents 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).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
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
© ISO 2023 – All rights reserved

---------------------- Page: 5 ----------------------
ISO 34503:2023(E)
Introduction
The move towards automated driving systems (ADSs) is being driven by the many potential benefits of
the technology, such as increased safety, reduced traffic congestion, lowered emissions and potentially
increased mobility for those unable to drive. In order to realize these benefits, it is essential that the
ADS technology is introduced safely.
The development of automated vehicle technology has received wide public attention, with countries
worldwide focusing on:
— ensuring that the introduction of ADSs for testing/trialling purposes and for commercial operations
is done safely, securely and legally; and
— building public and consumer trust and acceptance of the technology.
A key aspect of the safe use of automated vehicle technology is defining its capabilities and limitations
and clearly communicating these to the end user, leading to a state of “informed safety”. The first step in
establishing the capability of an ADS is the definition of its operational design domain (ODD). In addition
to safe operation, the ODD definition is also important for conformity with laws and regulations and
compliance with vehicle goals, e.g. mobility and comfort needs.
The ODD represents the operating conditions within which an ADS can perform the dynamic driving
task (DDT) safely during a trip. This document focuses on a taxonomy and format for the ODD definition
for a given ADS to create a common understanding of the ODD.
The ODD taxonomy and definition format specified in this document will enable ADS manufacturers
to specify, implement and communicate minimum safety requirements in their designs, and allow end
users (e.g. insurers, national, local, and regional government), operators and regulators to reference
a minimum set of ODD attributes and performance requirements in their procurements. It will also
enable ADS manufacturers, developers and suppliers of components and subcomponents to define the
operating capability and assemble sets of evidence that will improve confidence in the safety of the
resulting product (such as component specifications) and in the data obtained from test and verification
activities.
While there are a number of different testing, trialling and deployment environments, this document
provides a generic taxonomy for defining each of these environments. For a scenario-based verification
methodology for ADS, a hierarchical taxonomy for ODD definition and a definition format also enables
an efficient scenario creation and scenario parametrisation. Such a definition format standard is in
development – ASAM OpenODD.
vi
  © ISO 2023 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 34503:2023(E)
Road Vehicles — Test scenarios for automated driving
systems — Specification for operational design domain
1 Scope
This document specifies the requirements for the hierarchical taxonomy for specifying operating
conditions which enable the definition of an operational design domain (ODD) of an automated driving
system (ADS). This document also specifies requirements for the definition format of an ODD using the
taxonomy. The ODD comprises specific conditions (which include the static and dynamic attributes)
within which an ADS is designed to function.
This document is mainly applicable to level 3 and level 4 ADS. An ODD for level 5 ADS is unlimited (i.e.
operation is possible everywhere).
This document can be used by organizations taking part in developing safety cases for automated
vehicles, in particular, for organizations conducting trials, testing and commercial deployment. This
document can also be used by manufacturers of level 3/4 ADS to define the ADS’ operating capability.
It may also be of interest to insurers, regulators, service providers, national, local and regional
governments to enable them to understand possible ADS deployments and capabilities.
This document does not cover the basic test procedures for attributes of the ODD. It does not cover the
monitoring requirements of the ODD attributes.
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/SAE PAS 22736, Taxonomy and definitions for terms related to driving automation systems for on-
road motor vehicles
ISO 34501, Road vehicles — Test scenarios for automated driving systems — Vocabulary
ISO 34502, Road vehicles — Test scenarios for automated driving systems — Scenario based safety
evaluation framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/SAE PAS 22736 and ISO 34501
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
dynamic element
movable object or actor in the ODD within the DDT timeframe
Note 1 to entry: Adapted from Reference [5].
1
© ISO 2023 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 34503:2023(E)
3.2
environmental condition
weather or another atmospheric condition and other conditions of the environment which are not
defined as scenery elements (3.4) (as well as information technology connectivity)
3.3
minimal risk manoeuvre
MRM
tactical or operational manoeuvre triggered and executed by the ADS to achieve the minimal risk
condition (MRC)
3.4
scenery element
non-movable element of the ADS-equipped vehicle’s operating environment
Note 1 to entry: This definition is to be used only in the context of an ODD.
Note 2 to entry: Non-movable element is not restricted to static elements. For example, traffic lights, movable
bridges.
3.5
vulnerable road user
non-protected road user such as motorcyclists, cyclists, pedestrians, horse riders and persons with
disabilities or reduced mobility and orientation
3.6
traffic agent
anyone who uses a road including sidewalk and other adjacent spaces
3.7
target operational domain
TOD
set of operating conditions in which an ADS will be expected to operate, including, but not limited to,
environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of
certain traffic or roadway characteristics
Note 1 to entry: While the ODD defines of the operating conditions that an ADS is designed to operate in, the TOD
is the area (describing location) where the ADS will be deployed (expected to operate in). As such a TOD may have
conditions outside the ODD of the ADS. For further clarification, see Clause 5.
3.8
current operational domain
COD
specific set of operating conditions which exists presently in the immediate vicinity of an ADS,
including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the
requisite presence or absence of certain traffic or roadway characteristics
3.9
operational domain
OD
set of operating conditions, including, but not limited to, environmental, geographical, and time-of-day
restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics
Note 1 to entry: This set can be used to describe real-world conditions in certain environments, geography,
synthetic conditions for testing, and other various purposes.
4 Abbreviated terms
ADS Automated Driving Systems
2
  © ISO 2023 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 34503:2023(E)
ASAM Association for Standardization of Automation and Measuring Systems
AV Automated Vehicle
COD Current Operational Domain
DDT Dynamic Driving Task
MRC Minimal Risk Condition
MRM Minimal Risk Manoeuvre
OD Operational Domain
ODD Operational Design Domain
TOD Target Operational Domain
V2I Vehicle to Infrastructure
5 Operational design domain (ODD) and target operational domain (TOD)
An ODD defines the operating conditions under which an ADS is designed to operate safely. However,
the target operational domain (TOD) defines the real-world conditions that an ADS may experience and
is required to safely operate in. Often, the TOD will be a superset of the ODD properties.
In real world deployment of ADS, the difference between an ODD and TOD highlights the limitations of
the ADS. In all practical cases, an ODD definition will not be exhaustive enough to cover all attributes
or occurrences in a TOD. Therefore, it is important to ensure the boundary between ODD and TOD is
defined objectively and to have design mechanisms in the ADS to execute fallback manoeuvres when
an ODD exit is encountered to ensure safe operation of the ADS in a TOD. Current operational domain
(COD) refers to the real-time operational domain, i.e. real-time real-world conditions that the ADS is
experiencing.
The key difference between ODD and TOD is that ODD expresses a specification of the ADS, whereas
TOD is a description/specification of an environment in which various ADSs will be expected to operate.
In general, one can expect that an ODD of any ADS operating within the TOD, is a superset (i.e. including
all aspects) of the TOD. Another perspective is that the TOD can be viewed as a requirement to be met
by all ADS’s ODD – if these ADS are to operate within the environment described by the TOD.
Depending on the design and requirements for an ADS, the TOD may be a superset of the ODD or the
other way round. If the TOD is a superset of the ODD, it implies appropriate risk mitigation measures
will be required as part of the ADS safety measures.
6 ODD and scenario relationship
As an ODD definition needs to be testable, ODD attributes and the definition of the attributes play a key
role in scenario-based testing. It is important to highlight that ODD and scenarios are two distinct but
related constructs. While ODD describes the operating conditions of the ADS in which it is designed to
operate, a scenario along with parts of the scenery elements and environmental conditions, describe
the behaviour of the traffic participants and may also define the desired behaviour of the ego vehicle in
an instantiation (part) of an ODD or outside of an ODD.
NOTE See Annex A for the overall ADS-constraining factors apart from the ODD.
The ODD definition shall be used as one of the inputs for scenario-based safety evaluation framework
in accordance with ISO 34502. Therefore, one of the first steps in a verification and validation process
of an ADS would be to analyse the designed ODD of the ADS to create a set of test scenarios. The second
step would involve testing the desired behaviour of the ADS by choosing a set of behaviours from a
3
© ISO 2023 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 34503:2023(E)
behaviour library. The choice of the behaviours may include undesired behaviours to test the ADS’
response. An instantiation of the ODD together with a desired behaviour and the description of the
traffic participants' behaviour according to events and triggers will provide a scenario definition for
the ADS. Such a qualitative scenario can then be further detailed into functional, abstract, logical and
concrete scenarios to create a scenario library (Figure 1).
Furthermore, the ODD definition can be used as criteria for deciding whether individual test scenarios
are inside, outside or at the boundary of an ODD. Such scenarios also enable the test for activation
and deactivation of the ADS depending on ODD. It is important to test against scenarios outside the
ODD in order to ensure that the ADS is not misused in situations for which it is not designed. Also, a
comparison between a test scenario set and the ODD definition shall be performed to analyse the test
space coverage.
As a centralised scenario library will potentially have a large number of scenarios for different
[4]
ODDs, ODD attributes (see Clause 8) and behaviour labels (ASAM OpenLabel ) can play a key role
in enabling an efficient scenario search for an ADS. Every scenario will have a relationship with an
ODD. In ISO 34502, three types of scenarios are mentioned: perception-, traffic- and vehicle control.
For example, a perception related scenario focused on blind spot detections may exist on a motorway
or on a road in a city centre, where motorway and city centre roads are ODD instantiations. Compared
to an ODD definition, a scenario has additional constructs like events, triggers and other dynamically
[4]
changing behaviours. Such scenario attributes may be classified according to ASAM OpenLabel .
Figure 1 — An example relationship between ODD, behaviour and scenarios
7 ODD requirements and application
7.1 Abstraction of ODD definition
Based on the taxonomy and definition format in this document (Clauses 8-12), an ODD definition shall
be developed by an ADS developer and before deployment should be compared with the stakeholders’
requirements of the operational domain (OD), either individually or in consultation, for the safe
operation of the ADS in the operational domain.
An ODD can be defined from the perspective of an end user or a system specifier. Depending on the
perspective, the abstraction of the ODD definition can vary.
Although the end user and specifier can have different abstractions of ODD, the ODD definition should
be done objectively to avoid any misunderstandings.
Stakeholders or end users may include, but are not limited to, local authorities, regulators, ADS
system users, service providers, manufacturers, developers of an ADS or suppliers of components and
subcomponents. A city council, for example, can develop an ODD definition as part of a procurement
specification for an ADS mobility service, while a manufacturer can develop an ODD definition in order
to convey the ADS’ capabilities and limitations and create the corresponding safety case. Different
stakeholders can develop their ODD definition with varied level of detail.
4
  © ISO 2023 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 34503:2023(E)
The abstraction hierarchy to be used for the ODD definition, see Clauses 8 to 11, shall be at the discretion
of the stakeholder. Irrespective of the abstraction level chosen, stakeholders shall specify the ODD
attributes used to inform the scenario-based testing of the ADS.
A stakeholder who defines an ODD by choosing an attribute at a higher abstraction level shall ensure
that all the predefined subattrib
...

DRAFT INTERNATIONAL STANDARD
ISO/DIS 34503
ISO/TC 22/SC 33 Secretariat: DIN
Voting begins on: Voting terminates on:
2022-07-04 2022-09-26
Road Vehicles — Test scenarios for automated driving
systems — Taxonomy for operational design domain
Véhicules routiers — Scénarios d'essai pour les systèmes de conduite automatisée — Taxonomie pour le
domaine de conception opérationnelle
ICS: 43.020
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
This document is circulated as received from the committee secretariat.
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 34503:2022(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION. © ISO 2022

---------------------- Page: 1 ----------------------
ISO/DIS 34503:2022(E)
DRAFT INTERNATIONAL STANDARD
ISO/DIS 34503
ISO/TC 22/SC 33 Secretariat: DIN
Voting begins on: Voting terminates on:
2022-07-04 2022-09-26
Road Vehicles — Test scenarios for automated driving
systems — Taxonomy for operational design domain
Véhicules routiers — Scénarios d'essai pour les systèmes de conduite automatisée — Taxonomie pour le
domaine de conception opérationnelle
ICS: 43.020
COPYRIGHT PROTECTED DOCUMENT
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
© ISO 2022
THEREFORE SUBJECT TO CHANGE AND MAY
This document is circulated as received from the committee secretariat.
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
NOT BE REFERRED TO AS AN INTERNATIONAL
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on STANDARD UNTIL PUBLISHED AS SUCH.
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
IN ADDITION TO THEIR EVALUATION AS
or ISO’s member body in the country of the requester. BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
ISO copyright office
USER PURPOSES, DRAFT INTERNATIONAL
CP 401 • Ch. de Blandonnet 8
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
CH-1214 Vernier, Geneva
POTENTIAL TO BECOME STANDARDS TO
Phone: +41 22 749 01 11
WHICH REFERENCE MAY BE MADE IN
Reference number
Email: copyright@iso.org
NATIONAL REGULATIONS.
Website: www.iso.org ISO/DIS 34503:2022(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
Published in Switzerland
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
ii
  © ISO 2022 – All rights reserved
PROVIDE SUPPORTING DOCUMENTATION. © ISO 2022

---------------------- Page: 2 ----------------------
ISO/DIS 34503:2022(E)
14 Contents
15 Foreword . v
16 Introduction. vi
17 1 Scope . 1
18 2 Normative references . 1
19 3 Terms and definitions . 1
20 4 Symbols (and abbreviated terms) . 3
21 5 Operational Design Domain (ODD) and Target Operational Domain (TOD) . 3
22 6 ODD and scenario relationship . 4
23 7 ODD requirements and application . 4
24 7.1 Abstraction of ODD definition . 4
25 7.2 Monitoring ODD . 5
26 7.3 Implication to scenario-based testing . 6
27 8 ODD Taxonomy . 6
28 8.1 General . 6
29 8.2 Top level ODD classification . 6
30 9 Scenery elements . 7
31 9.1 General . 7
32 9.2 Zones . 7
33 9.3 Drivable area . 8
34 9.3.1 General attributes . 8
35 9.3.2 Drivable area type . 8
36 9.3.3 Drivable area Geometry . 9
37 9.3.4 Drivable area Lane specification . 10
38 9.3.5 Drivable area signs . 10
39 9.3.6 Drivable area edge . 11
40 9.3.7 Drivable area surface . 11
41 9.4 Junctions . 12
42 9.4.1 General . 12
43 9.4.2 Roundabout . 12
44 9.4.3 Intersection . 13
45 9.5 Basic road structures . 13
46 9.6 Special structures . 13
47 9.7 Temporary drivable area structures . 14
48 10 Environmental conditions . 14
49 10.1 General . 14
50 10.2 Outside Air Temperature . 14
51 10.3 Weather . 14
52 10.3.1 General . 14
53 10.3.2 Wind . 14
54 10.3.3 Rainfall . 15
55 10.3.4 Snowfall . 16
56 10.4 Particulates . 16
57 10.5 Illumination . 16
58 10.6 Connectivity . 17
59 11 Dynamic elements . 18
60 11.1 Traffic agents . 18
61 11.2 Subject vehicle . 19
© ISO 2022 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/DIS 34503:2022(E)
62 12 ODD definition format . 19
63 12.1 General . 19
64 12.2 Type of definition format . 19
65 12.3 Human readability . 20
66 12.4 Inclusion, exclusion, and conditional . 20
67 12.5 Extensibility and expressing relationships between ODD attributes . 21
68 12.6 Objective boundaries . 21
69 12.7 Statement composition . 21
70 Annex A . Fehler! Textmarke nicht definiert.
71 Annex B . Fehler! Textmarke nicht definiert.
72 B1. Canada . 24
73 B2. USA . 25
74 Bibliography . Fehler! Textmarke nicht definiert.
75
iv © ISO 2022 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/DIS 34503:2022(E)
76 Foreword
77 ISO (the International Organization for Standardization) is a worldwide federation of national standards
78 bodies (ISO member bodies). The work of preparing International Standards is normally carried out
79 through ISO technical committees. Each member body interested in a subject for which a technical
80 committee has been established has the right to be represented on that committee. International
81 organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO
82 collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
83 electrotechnical standardization.
84 The procedures used to develop this document and those intended for its further maintenance are
85 described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
86 different types of ISO documents should be noted. This document was drafted in accordance with the
87 editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
88 Attention is drawn to the possibility that some of the elements of this document may be the subject of
89 patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any
90 patent rights identified during the development of the document will be in the Introduction and/or on
91 the ISO list of patent declarations received (see www.iso.org/patents).
92 Any trade name used in this document is information given for the convenience of users and does not
93 constitute an endorsement.
94 For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
95 expressions related to conformity assessment, as well as information about ISO's adherence to the World
96 Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
97 www.iso.org/iso/foreword.html.
98 This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 33,
99 Vehicle dynamics, chassis components and driving automation systems testing.
100 This document belongs to a series of Standards series consisting of ISO 34501, ISO 34502 and ISO 34503.
101 Any feedback or questions on this document should be directed to the user’s national standards body. A
102 complete listing of these bodies can be found at www.iso.org/members.html.
© ISO 2022 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/DIS 34503:2022(E)
103 Introduction
[1]
104 The move towards Automated Driving Systems (ADS) is being driven by the many potential benefits of
105 the technology, such as increased safety, reduced traffic congestion, lowered emissions, and potentially
106 increased mobility for those unable to drive. In order to realize these benefits, it is essential that the ADS
107 technology is introduced safely.
108 The development of automated vehicle technology has received wide public attention, with countries
109 worldwide focussing on:
110 • Ensuring that the introduction of ADSs for testing/trialling purposes and for commercial
111 operations is done safely, securely and legally; and
112 • Building public and consumer trust and acceptance of the technology.
113 A key aspect of the safe use of automated vehicle technology is defining its capabilities and limitations
114 and clearly communicating these to the end user, leading to a state of “informed safety”. The first step in
[1]
115 establishing the capability of an ADS is the definition of its Operational Design Domain (ODD) . In
116 addition to safe operation, ODD definition is also required for conformity with laws and regulations and
117 compliance with vehicle goals e.g., mobility and comfort needs.
118 The ODD represents the operating conditions within which an ADS can perform the Dynamic Driving
[1]
119 Task (DDT) safely during a trip. This document focuses on a taxonomy and format for the ODD
120 definition for a given ADS to create a common understanding of the ODD.
121 The ODD taxonomy and definition format specified in this document will enable ADS manufacturers to
122 specify, implement and communicate minimum safety requirements in their designs, and allow end users
123 (e.g., insurers, national, local, and regional government), operators and regulators to reference a
124 minimum set of ODD attributes and performance requirements in their procurements. It will also enable
125 ADS manufacturers, developers and suppliers of components and subcomponents to define the operating
126 capability and assemble sets of evidence that will improve confidence in the safety of the resulting
127 product (such as component specifications) and in the data obtained from test and verification activities.
128 While there are a number of different testing, trialling and deployment environments, this document
129 provides a generic taxonomy for defining each of these environments. For a scenario-based verification
130 methodology for ADS, a hierarchical taxonomy for ODD definition and a definition format also enables an
131 efficient scenario creation and scenario parametrisation. Such a definition format standard is in
132 development – ASAM OpenODD.
vi © ISO 2022 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/DIS 34503:2022(E)
133 Road Vehicles - Taxonomy for Operational Design Domain for an
134 Automated Driving System
135 1 Scope
136 This document specifies the requirements for the hierarchical taxonomy for specifying operating
[1]
137 conditions which enable the definition of an Operational Design Domain (ODD) of an Automated
[1]
138 Driving System (ADS) . This document also specifies requirements for the definition format of an ODD
139 using the taxonomy. The ODD comprises specific conditions (which include the static and dynamic
[1]
140 attributes) within which an ADS is designed to function.
[1]
141 This document is mainly applicable to level 3 and level 4 ADS . An ODD for level 5 ADS is unlimited (i.e.,
142 operation is possible everywhere).
143 This document is for use by organizations taking part in developing safety cases for automated vehicle,
144 in particular, for organizations conducting trials, testing and commercial deployment. This document is
145 also for use by manufacturers of Level 3/4 ADS to define the ADS’ operating capability. It is also of interest
146 to insurers, regulators, service providers, national, local and regional governments to enable them to
147 understand possible ADS deployments and capabilities.
148 This document does not cover the basic test procedures for attributes of the ODD. It does not cover the
149 monitoring requirements of the ODD attributes.
150 2 Normative references
151 The following documents are referred to in the text in such a way that some or all of their content
152 constitutes requirements of this document. For dated references, only the edition cited applies. For
153 undated references, the latest edition of the referenced document (including any amendments) applies.
154 ISO/SAE PAS 22736: Taxonomy and definitions for terms related to driving automation systems for on-
155 road motor vehicles
156 ISO/DIS 34501: Road vehicles - Terms and definitions of test scenarios for automated driving systems
157 ISO/DIS 34502: Road vehicles - Scenario-based safety evaluation framework for Automated Driving
158 Systems
159 3 Terms and definitions
160 For the purposes of this document, the terms and definitions given in ISO/SAE PAS 22736 and ISO/DIS
161 34501 and the following apply.
162 ISO and IEC maintain terminological databases for use in standardization at the following addresses:
163 — ISO Online browsing platform: available at http://www.iso.org/obp
164 — IEC Electropedia: available at http://www.electropedia.org/
165 3.1
166 dynamic elements
167 all movable objects and actors in the ODD within the DDT timeframe.
168 {SOURCE: Ulbrich et. al, 2015 [5], modified}
© ISO 2022 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/DIS 34503:2022(E)
169 3.2
170 environmental conditions
171 weather and other atmospheric conditions (as well as information technology connectivity)
172 NOTE to entry: Environment conditions does not contain scenery elements.
173 3.3
174 Minimal Risk Manoeuvre (MRM)
175 tactical or operational manoeuvre triggered and executed by the ADS to achieve the Minimal Risk
176 Condition (MRC)
177 3.4
178 operational driving task
[1]
179 dynamic Driving Task that involves split-second reactions that can be considered pre-cognitive or
180 innate
181 NOTE to entry: Examples include making micro-corrections to steering, braking and accelerating to
182 maintain lane position in traffic or to avoid a sudden obstacle or hazardous event in the vehicle’s pathway.
183 3.5
184 scenery elements
185 non-movable elements of the ADS equipped vehicle’s operating environment
186 NOTE to entry: in the context of an ODD
187 3.6
188 tactical driving task
189 dynamic driving task which involves drivers or an ADS exercising manoeuvre control, allowing them to
190 negotiate the directly prevailing circumstances
191 {SOURCE: Michon, 1985 [9], modified}
192 3.7
193 vulnerable road user
194 non-protected road user such as motorcyclists, cyclists, pedestrians and persons with disabilities or
195 reduced mobility and orientation.
196 3.8
197 traffic agents
198 anyone who uses a road including sidewalk and other adjacent spaces
199 3.9
200 Target Operational Domain (TOD)
201 real-world conditions that an ADS may experience in during its deployment.
202 NOTE to entry: While the ODD constitutes of the operating conditions that an ADS is design to operate in,
203 the TOD is the area where the ADS will be deployed and may have conditions outside the ODD of the ADS.
204 3.10
205 Current Operational Domain (COD)
206 real-time real-world conditions that the ADS is experiencing.
207 3.11
Operational Domain (OD)
208
209 real-world conditions that an ADS may experience
2 © ISO 2022 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/DIS 34503:2022(E)
210 4 Symbols (and abbreviated terms)
211 ODD Operational Design Domain
212 ADS Automated Driving Systems
213 DDT Dynamic Driving Task
214 MRM Minimal Risk Manoeuvre
215 MRC Minimal Risk Condition
216 AV Automated Vehicle
217 V2I Vehicle to Infrastructure
218 ASAM Association for Standardization of Automation and Measuring Systems
219 OD Operational Domain
220 TOD Target Operational Domain
221 COD Current Operational Domain
222 5 Operational Design Domain (ODD) and Target Operational Domain (TOD)
223 An ODD defines the operating conditions under which an ADS is designed to operate safely. However, the
224 target operational domain (TOD) constitutes of the real-world conditions that an ADS may experience.
225 Often, the OD will generally be a superset of the ODD properties.
226 In real world deployment of ADS, the difference between an ODD and TOD highlights the limitations of
227 the ADS. In all practical cases, an ODD definition will not be exhaustive enough to cover all attributes or
228 occurrences in a TOD. Therefore, it is important to ensure the boundary between ODD and OD is defined
229 objectively and have design mechanisms in the ADS to execute fallback manoeuvres when an ODD exit is
230 encountered to ensure safe operation in a TOD. Current operational domain (COD) refers to the real-time
231 operational domain, i.e., real-time real-world conditions that the ADS is experiencing (Figure 1).
232
233 Figure 1. Relationship between ODD, TOD and COD
© ISO 2022 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/DIS 34503:2022(E)
234 6 ODD and scenario relationship
235 As an ODD definition needs to be testable, ODD attributes and its definition play a key role in scenario-
236 based testing. It is important to highlight that ODD and scenarios are two distinct but related constructs.
237
While ODD describes the operating conditions of the ADS in which it is designed to operate in, a scenario
238 along with parts of the scenery elements and environmental conditions, describes the behaviour of the
239 traffic participants and may also define the desired behaviour of the ego vehicle in an instantiation (part)
240 of an ODD or outside of an ODD.
241 NOTE See Annex A for the overall ADS-Constraining factors apart of the ODD.
242 The ODD definition shall be used as one of the inputs for scenario-based safety evaluation framework
243 according to ISO/DIS 34502. Therefore, one of the first steps in a verification and validation process of
244 an ADS would be to analyse the designed ODD of the ADS to create a set of test scenarios. Second step
245 would involve testing the desired behaviour of the ADS by choosing a set of behaviours from a behaviour
246 competency library. The choice of the behaviours may include undesired behaviours to test the ADS’
247 response. An instantiation of the ODD together with a desired behaviour and the description of the traffic
248 participant behaviour according to events and triggers will provide a scenario definition for the ADS.
249 Such qualitative scenario can then be further detailed into functional, abstract, logical and concrete
250 scenarios to create a scenario library (Figure 2).
251 Furthermore, the ODD definition can be used as a plausibility check, whether individual test scenarios
252 are inside, outside or at the boundary of an ODD. Such scenarios also enable the test for activation and
253 deactivation of the ADS depending on ODD. It is important to test against scenarios outside the ODD in
254 order to ensure that the ADS is not misused in situations for which it is not designed for. Also, a
255 comparison between a test scenario set and the ODD definition shall be performed to analyse the test
256 space coverage.
257 As centralised scenario library will potentially have a large number of scenarios for different ODDs, ODD
attributes (see clause 8) and behaviour labels (ASAM OpenLabel [3]) can play a key role in enabling
258
259 efficient scenario search for an ADS. For the proposed three types of scenarios mentioned in ISO 34502,
260 perception-, traffic- and vehicle stability, there will exist an ODD instantiation. For example, a perception
261 related scenario focussed on blind spot detections may exist on a motorway or on a road in a city centre,
262 where motorway and city centre roads are ODD instantiations. Compared to an ODD definition, a scenario
263 has additional constructs like events, triggers and other dynamically changing behaviour. Such scenario
264 attributes may be classified according to ASAM OpenLabel [3].
265
266 Figure 2. Relationship between ODD, behaviour and scenarios
267 7 ODD requirements and application
268 7.1 Abstraction of ODD definition
269 Based on the taxonomy and definition format in this document (clause 8-12), an ODD definition shall be
270 developed by an ADS developer and before deployment should be compared with the stakeholders’
4 © ISO 2022 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/DIS 34503:2022(E)
271 requirements of the operating domain (OD), either individually or in consultation, for the safe operation
272 of the ADS in the operating domain.
273 An ODD may be defined from the perspective of an end user or a system specifier. Depending on the
274 perspective, the abstraction of the ODD definition may vary.
275 Note: Although end users and specifier may have different abstractions of ODD, the ODD definition should
276 be done objectively to avoid any misunderstandings.
277 Stakeholders or end users may include local authorities, regulators, ADS system user, service providers,
278 manufacturers, developers of an ADS or suppliers of components and subcomponents. A city council, for
279 example, may develop an ODD definition as part of a procurement specification for an ADS mobility
280 service, while a manufacturer may develop an ODD definition in order to convey the ADS’ capabilities and
281 limitations and create the corresponding safety case. Different s
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.