You will be provided with a reference and some statements. Please determine whether each statement is 'supported', 'unsupported', or 'unknown' with respect to the reference. Please note:
First, assess whether the reference contains any valid content. If the reference contains no valid information, such as a 'page not found' message, then all statements should be considered 'unknown'.
If the reference is valid, for a given statement: if the facts or data it contains can be found entirely or partially within the reference, it is considered 'supported' (data accepts rounding); if all facts and data in the statement cannot be found in the reference, it is considered 'unsupported'.

You should return the result in a JSON list format, where each item in the list contains the statement's index and the judgment result, for example:
[
    {
        "idx": 1,
        "result": "supported"
    },
    {
        "idx": 2,
        "result": "unsupported"
    }
]

Below are the reference and statements:
<reference>
ISSN 1831-9424

Interpretation of EU Regulation
2022/1426 on the Type Approval of
Automated Driving Systems

Ciuffo, B., Dona, R., Galassi, M., Giannotti, W.,
Sollima, C., Terzuoli, F., Vass, S. (eds.)

2024

EUR 31842 EN

This document is a publication by the Joint Research Centre (JRC), the European Commission’s science and knowledge
service. It aims to provide evidence-based scientific support to the European policymaking process. The contents of this
publication do not necessarily reflect the position or opinion of the European Commission. Neither the European
Commission nor any person acting on behalf of the Commission is responsible for the use that might be made of this
publication. For information on the methodology and quality underlying the data used in this publication for which the
source is neither Eurostat nor other Commission services, users should contact the referenced source. The designations
employed and the presentation of material on the maps do not imply the expression of any opinion whatsoever on the
part of the European Union concerning the legal status of any country, territory, city or area or of its authorities, or
concerning the delimitation of its frontiers or boundaries.
Contact information
Name: Biagio CIUFFO
Address: Via E. Fermi 2749 – 21023 Ispra (VA) Italy
Email: Biagio.CIUFFO@ec.europa.eu
Tel.: +39 0332 789732
EU Science Hub
https://joint-research-centre.ec.europa.eu
JRC136417
EUR 31842 EN
PDF

ISBN 978-92-68-12555-7

ISSN 1831-9424 doi:10.2760/86028

KJ-NA-31-842-EN-N

Luxembourg: Publications Office of the European Union, 2024
© European Union, 2024

The reuse policy of the European Commission documents is implemented by the Commission Decision 2011/833/EU of 12
December 2011 on the reuse of Commission documents (OJ L 330, 14.12.2011, p. 39). Unless otherwise noted, the
reuse of this document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence
(https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed provided appropriate credit is given and
any changes are indicated.
For any use or reproduction of photos or other material that is not owned by the European Union permission must be
sought directly from the copyright holders.
- Cover page illustration, © Freepik.com

How to cite this report: European Commission, Joint Research Centre, Ciuffo, B., Dona, R., Galassi, M.C., Giannotti, W.,
Sollima, C., Terzuoli, F. and Vass, S., Interpretation of EU Regulation 2022/1426 on the Type Approval of Automated
Driving Systems, Publications Office of the European Union, Luxembourg, 2024,
https://data.europa.eu/doi/10.2760/86028, JRC136417.

Contents
Abstract ....................................................................................................................................................................................................................................................................... 3
Acknowledgements .......................................................................................................................................................................................................................................... 4
1 Introduction..................................................................................................................................................................................................................................................... 5
2 Note regarding evidencing the requirements ................................................................................................................................................................ 6
3 Guidance on the requirements of Regulation 2022/1426 ................................................................................................................................ 7
A
ANNEX I - Information document for EU type-approval of fully automated vehicles with regard to
their automated driving system ................................................................................................................................................................................................. 7
B

ANNEX II - Performance Requirements .................................................................................................................................................................. 7

C

ANNEX III - Compliance assessment ........................................................................................................................................................................ 9

4 Conclusions ..................................................................................................................................................................................................................................................13
APPENDIX 1 - Technical Guidance on ODD description ..............................................................................................................................................14
APPENDIX 2 - Technical Guidance on Scenario Generation and Coverage..............................................................................................15
1. Introduction and global approach of driving scenarios...............................................................................................................................15
2. Scenario generation ......................................................................................................................................................................................................................15
3. Articulation between scenario-based approach and other safety demonstration activities ..................................20
APPENDIX 3 - Technical Guidance on Safety Targets and Acceptance Criteria ..................................................................................21
1. Safety Assessment Approach set in Regulation 2022/1426 ................................................................................................................21
2. Methodologies for Demonstration of Safety as a Threshold (Acceptable Means of Compliance) ...................21
3. Metrics for the Definition of the Safety Threshold .........................................................................................................................................23
4. Data sources and databases ................................................................................................................................................................................................24
APPENDIX 4 - Technical Guidance on Safety Assessment ......................................................................................................................................25
1. Introduction ...........................................................................................................................................................................................................................................25
2. The Information Document ....................................................................................................................................................................................................26
APPENDIX 5 - Technical Guidance for the Credibility Assessment of Virtual Testing Toolchain ........................................39
Definitions .....................................................................................................................................................................................................................................................39
1. Introduction ...........................................................................................................................................................................................................................................39
2.

M&S Management...................................................................................................................................................................................................................41

3. M&S Analysis and Description ............................................................................................................................................................................................46
4. Verification of the Virtual Testing toolchain ..........................................................................................................................................................51
5. Validation of the M&S toolchain .......................................................................................................................................................................................55
6. Credibility Assessment ...............................................................................................................................................................................................................66
APPENDIX 6 - Technical Guidance on In-service Reporting ....................................................................................................................................69
1. Objectives ...............................................................................................................................................................................................................................................69
2. Template for short term reporting ..................................................................................................................................................................................69
3. Template for periodic reporting .........................................................................................................................................................................................75
4. Additional Interpretation material ...................................................................................................................................................................................79
References .............................................................................................................................................................................................................................................................81
List of abbreviations ....................................................................................................................................................................................................................................83

1

List of figures .....................................................................................................................................................................................................................................................85
List of tables ........................................................................................................................................................................................................................................................86

2

Abstract
In 2022, the European Commission adopted the first worldwide legislation concerning the type-approval of
the Automated Driving Systems of fully Automated Vehicles, opening the road to their introduction to the
European market. The EU, in this way, becomes the first market in the world where this new generation of
vehicles can be placed with a complete and unambiguous legislative framework. In order to define the
conditions for the type-approval of vehicles operating without the presence of a driver, the EU Regulation
2022/1426 introduces a series of completely innovative elements that both industry and the Approval
Authorities of the European Member States have the task to operationalise. In order to support this phase and
to ensure the establishment of as harmonized as possible practices across the EU, the European Commission
has launched in 2022 the process of drafting a first interpretation of some among the most innovative
aspects of the Regulation. The present report is the result of this process. It has been drafted with the active
contribution by the experts who compose the Automated and Connected Vehicles sub-group of the Working
Group on Motor Vehicles (MVWG-ACV). In its final form the report is composed by two parts. A first part of
technical interpretation of the regulatory text and a second part composed by six appendixes providing
examples and relevant resources to support the operationalization of different aspects of the legislation.

3

Acknowledgements
The report is the result of the discussions and the contributions by the experts part of the Working Group on
Motor Vehicles (MVWG), established 1970 to assist the European Commission (in particular DG GROW) in the
preparation of legislative proposals and policy initiatives related to motor vehicles. In particular the
contributors are all part of the sub-group focusing on Automated and Connected Vehicles (ACV)1. The role of
the Editors has been to moderate the discussions within the sub-group and to consolidate the main
conclusions into the present report,
The Editors are grateful to the two JRC colleagues appointed by the JRC Editorial Review Board to review the
report, for their fruitful suggestions.
This work has been carried out in the framework of the Administrative Arrangement n. 36380 between DG
GROW and JRC
Editors
Biagio Ciuffo, European Commission Joint Research Centre
Riccardo Donà, European Commission Joint Research Centre
Maria Cristina Galassi, European Commission DG GROW
Walter Giannotti, NINE Srl
Calogero Sollima, European Commission Joint Research Centre
Fulvio Terzuoli, NINE Srl
Sandor Vass, European Commission Joint Research Centre

1

All documents produced by the MVWG-ACV sub-group are available in the relevant section of the European Commission Communication
and Information Resource Centre for Administrations, Businesses and Citizens (Circabc) Library

4

1

Introduction

1.1.
The present document provides information to support the interpretation of the requirements
established in the Commission Implementing Regulation (EU) 2022/1426 on laying down rules for the
application of Regulation (EU) 2019/2144 of the European Parliament and of the Council as regards uniform
procedures and technical specifications for the type-approval of the automated driving system (ADS) of fully
automated vehicles (“Regulation” hereinafter). The document also provides information and guidance on
possibilities to comply with those requirements, and how to provide evidence of such compliance.
1.2.
The target audience are manufacturers submitting systems for type-approval and the Technical
Services / Approval Authorities assessing those systems. The purpose is to facilitate a harmonized
interpretation and implementation of the Regulation.
1.3.
The document strictly provides information to support the interpretation of the Regulation; it does in
no form introduce new requirements. Whenever conflicting, the contents of the Regulation are legally binding.

5

2

Note regarding evidencing the requirements

2.1.
This document is intended to provide support for the interpretation of the Regulation, and provides
indications on what may constitute “acceptable means of compliance” (AMC) for the Technical Services /
Approval Authorities and on the information that manufacturers should supply. It provides information only, it
is applicable on a voluntary basis and it is not intended to be exhaustive, i.e., means of compliance other than
those illustrated here may be acceptable. The document cannot create additional obligations; moreover, it
provides material to assist in understanding what information may be useful in demonstrating compliance
and to contribute to uniform implementation. The AMCs are developed with the presumption of compliance
with the rules, so that it is recognised that conforming to this AMCs is one acceptable way of complying with
the relevant section of the Regulation.
2.2.
The standards referenced in the present document that are not referenced in the Regulation are
intended as examples only and do not constitute binding requirements at any level. The same holds for the
text included in the appendixes to the present document. They can be helpful in implementing the
requirements of the Regulation but their use is not mandatory. Depending on the vehicle type defined by the
manufacturer, and the practices and procedures they use, alternative and/or equivalent concepts may be used
and information may be supplied to comply with the requirements established in the Regulation.
2.3.
Alternative and/or equivalent methodologies used to comply with the requirements established in the
Regulation, as well as refinements or nuances of the methodologies after the implementation, can be
introduced as future amendments to update the present document with aim at contributing to uniform
implementation of the Regulation.

6

3

Guidance on the requirements of Regulation 2022/1426

3.1.

In the following, paragraph numbers refer to the same articles of the Regulation.

3.2.

In the following, text in “italic” recall the original text from the Regulation.

A

ANNEX I - Information document for EU type-approval of fully automated
vehicles with regard to their automated driving system

Guidance to support the manufacturers in the preparation of the relevant entries of the Information
Document is provided in Appendix 4 “Technical Guidance on Safety Assessment”.

B
1.

ANNEX II - Performance Requirements
DDT under nominal traffic scenarios
No guidance included in this document as regards this paragraph.

2.

DDT under critical traffic scenarios (emergency operation)
No guidance included in this document as regards this paragraph.

3.

DDT at ODD boundaries
No guidance included in this document as regards this paragraph.

4.

DDT under failure scenarios
No guidance included in this document as regards this paragraph.

5.

Minimal risk manoeuvre (MRM) and Minimal risk Condition (MRC)
No guidance included in this document as regards this paragraph.

6.

Human machine interaction
No guidance included in this document as regards this paragraph.

7.

Functional and operational safety

7.1.

The manufacturer shall demonstrate that an acceptable degree of consideration has been given to
the functional and operational safety for the ADS during its design and development processes. The
measures put in place by the manufacturer shall ensure that the fully automated vehicle is free of
unreasonable safety risks to vehicle occupants and other road users during the vehicle lifetime when
compared with comparable transport services and situations within the operational domain.

7.1.1.

The manufacturer shall define the acceptance criteria from which the validation targets of the ADS
are derived to evaluate the residual risk for the ODD taking into account, where available, existing
accident data(1), data on performances from competently and carefully driven manual vehicles and
technology state-of-the-art.

Note (1) For instance based on current accident data on buses, coaches, trucks and cars in the EU, an
indicative aggregated acceptance criteria of 10-7 fatalities per hour of operation could be considered
for market introduction of ADSs for comparable transport services and situations. The manufacturer
may use other metrics and method provided it can demonstrate that it leads to an absence of
unreasonable safety risk when compared with comparable transport services and situations within
the operational domain.
Paragraph 7.1 introduces the obligation for the manufacturer to demonstrate that the ADS is free from
unreasonable safety risks when compared to “comparable transport services and situations within the
operational domain”.
Paragraph 7.1.1 introduces the concept of validation targets and, in a footnote, provides an example of how
accident data could be used in determining the acceptability of the residual risk. The Regulation does not
define specific acceptance criteria, or metric, or approach to comply with. The regulation states that the
manufacturer shall define the acceptance criteria, and is allowed to use any metric, both qualitative and
quantitative, and approach provided that it takes into account -“where available”- current existing accident
data, data on performances from competently and carefully driven manual vehicles and technology state-of-

7

the-art, and provided that it allows to demonstrate that its safety level at least compares to comparable
services, being run in the same operational domain.
A footnote linked to “existing accident data” provides an example of one criterion based on existing EU
accident data on buses, coaches, and cars that “could be considered”: (10-7 fatalities of accident-involved road
users per hour of vehicle operation). Such threshold is considered as a possible value suitable for the market
introduction of ADS based on similar services and situation as the ones which the aggregated data refers to,
i.e. buses, coaches, trucks and cars in the EU. Depending on the use case and the availability of data, similar
threshold metrics, like fatalities per mileage (km), fatalities per trip, or involvement in fatal accidents per hour
of operation, mileage or trip might be used.
The footnote -which is merely one example of a possible use of accident data in deriving acceptance criteriaspecifically provides that: “The manufacturer may use other metrics and method provided it can demonstrate
that it leads to an absence of unreasonable safety risk when compared with comparable transport services
and situations within the operational domain”.
Therefore, a more suitable reference threshold could be specifically derived for each use-case, taking into
account the specific operational design domain (ODD) defined for it (including where relevant the country of
market introduction), and the available data.
Moreover, the rule text requires taking into account such accident and other data only “where available”, and
if data on truly comparable services are not available, there is no request to use data that is not truly
comparable. In case data are available, the link between data analysis and the safety acceptance criteria
remains under the manufacturer’s responsibility to justify.
Note that the comparison with similar services implies that the manufacturer is in charge of the identification
and selection of similar services the vehicle could be employed for, and of the evaluation of the current level
of risk of those services. The acceptability criteria and the related metric have to be defined by the
manufacturer so as to allow a comparison with those similar services on the basis of the available data.
The following table shows a conceptual example of “comparable transport services”. The selection of similar
services shall account for the specific ADS use-case and the related ODD.
Table 1. Example of comparable transport services to specific ADS use-cases

ADS service

Reference human-driven service

Shuttle

Buses

Robotaxi

Taxi

Hub to Hub

Trucks

Valet Parking

Parking
Source: JRC

The data for the identification of the acceptable residual risk for similar services in the ADS ODD can be
obtained by measured or recorded data. A collection of available data sources and databases is reported in
Appendix 3. Accident and traffic data can differ in terminology and definitions, and can be biased due to e.g.
different inclusion criteria, different degrees of underreporting, etc. These shortcomings should be considered
when using such data. In addition, it is acknowledged that data of sufficient granularity to accurately
calculate the acceptable residual risk may not be fully available for the time being. In this case, evaluations or
assumptions based on expert judgment, as well as alternative approaches to demonstrate that the ADS is
free of unreasonable risks to occupants and other road users can be adopted and proposed to the typeapproval authority.
Moreover, the aggregate safety target provided as an example in the footnote is a transportation-systemwide characteristic and, by its nature, does not reflect criteria that might logically be applied to specific use
cases, vehicle types, or ODD characteristics. The manufacturer could take into account these shortcomings of
aggregate data by defining a more particularised/suitable threshold able to compensate for the lack of
sufficient information/data in the accurate definition of the acceptable residual risk.

8

Also, aggregate accident data do not clearly distinguish the performance of competent and careful human
drivers among the broader driver population or the effects of state-of-the-art technology in avoidance of
some crashes. The manufacturer could take into account these shortcomings of aggregate data by defining a
more ambitious/suitable threshold able to compensate for the uncertainty or the lack of sufficient
information/data in the accurate definition of the acceptable residual risk. Special attention shall be given to
the situation when dealing with fatal accidents only. Accident data is usually heavily biased for such analysis,
as the road users being involved in such kind of accidents (responsible for the accident or not) do not
represent the average competent and careful driver. Any analysis provided shall consider this effect and
explain how it has been taken into account.
Further guidance for this paragraph is provided in Appendix 3, “Technical Guidance on Safety Targets and
Acceptance Criteria” and in Appendix 4 “Technical Guidance on Safety Assessment”.
7.2.

The manufacturer shall have processes to manage the safety and continued compliance of the ADS
over lifetime (wear and tear of components especially for sensors, new traffic scenarios, etc.).

This paragraph requires the manufacturers to manage the safety and continued compliance of the ADS during
the ADS lifetime. This includes the compliance with the identified safety threshold, which can be carried out
also considering data from ADS real world operations, provided that they are statistically significant.
For vehicles not owned and operated by the manufacturer that are equipped with an ADS made by the
manufacturer, this may entail making software updates and replacement ADS equipment available to owners
and operators and continued analysis of available data to permit remediation of newly discovered safety risks
related to the ADS.
Technical Guidance on the processes to manage the safety and compliance of the ADS over lifetime is also
available in Appendix 4 “Technical Guidance on Safety Assessment”.
8.

Cyber security and software updates

No guidance included in this document as regards this paragraph.
9.

ADS data requirements and specific data elements for event data recorder for fully automated
vehicles

No guidance included in this document as regards this paragraph.
10.

Manual driving mode

No guidance included in this document as regards this paragraph.
11.

Operating manual

No guidance included in this document as regards this paragraph.
12.

Provisions for periodic roadworthiness tests

No guidance included in this document as regards this paragraph.

C

ANNEX III - Compliance assessment

Part 1 Traffic scenarios to consider
1.

Minimum set of traffic scenarios

No guidance included in this document as regards this paragraph.
2.

Scenarios not covered by point 1

2.1.

Scenarios that are not listed in point 1 shall be generated to cover reasonably foreseeable critical
situations, including failures and traffic hazards within the operational design domain.

2.2.

When ADS capabilities depend on remote capabilities, scenarios shall include failures and traffic
hazards stemming from the corresponding remote capabilities.

2.3.

The method to generate scenarios that are not listed in Section 1, shall follow the principles set in
Appendix 1 to Part 1 of this Annex.

2.4.

The method used by the manufacturer to generate scenarios that are not listed in point 1 shall be
documented in the documentation package to be provided for the ADS assessment.

9

No guidance included in this document as regards this paragraph.
Appendix 1

Principles to be followed to derive scenarios relevant for the ODD of the ADS

Guidance for this paragraph is provided in Appendix 2 to the present report: “Technical Guidance on Scenario
Generation and Coverage”.
Part 2 Assessment of the ADS safety concept and audit of the manufacturer safety management
system
1.

General

No guidance included in this document as regards this paragraph.
2.

Definitions

No guidance included in this document as regards this paragraph.
3.

Documentation on the ADS

No guidance included in this document as regards this paragraph.
4.

Verification and tests

No guidance included in this document as regards this paragraph.
5.

Safety management system (SMS)

No guidance included in this document as regards this paragraph.
6.

Reporting provision

No guidance included in this document as regards this paragraph.
7.

Competence of the auditors/assessors

No guidance included in this document as regards this paragraph.
Part 3 Tests
No guidance included in this document as regards this paragraph.
Part 4 Principles for credibility assessment for using virtual toolchain in ADS validation
1.

General

No guidance included in this document as regards this paragraph.
2.

Definitions

No guidance included in this document as regards this paragraph.
3.

Components of the credibility assessment framework and related documentation requirements

Guidance for this paragraph is provided in Appendix 5 “Technical Guidance for the Credibility Assessment of
Virtual Testing Toolchain”.
4.

Documentation structure

No guidance included in this document as regards this paragraph.
Part 5: In-service reporting
1.

Definitions

1.3

‘Critical Occurrence’ means each occurrence in which the ADS is engaged at the time of a collision
event and because of which:
(a) at least one person suffers an injury that requires medical assistance as a result of being in the
vehicle or being involved in the event;
(b) the fully automated vehicle, other vehicles or stationary objects sustain a physical damage that
exceeds a certain threshold or any vehicle involved in the event experiences an airbag deployment.

2.

Notifications and reporting by the manufacturer

10

2.1.

The manufacturer shall notify without delay any safety critical occurrences to the type-approval
authorities, market surveillance authorities and the Commission.

The notification should be in clear and plain language and should aim at containing as much of the following
information as is readily available without prejudice to the applicable national law, but its dispatch is not
supposed to be delayed due to the lack of complete information (notification can be provided in separate
phases when the information becomes available):


Manufacturer, WVTA number, type, variant and version if applicable, production year, Vehicle
Identification Number



ADAS and ADS systems on-board, system active at the time of the occurrence



Name of fleet operator (if any)



Description of the critical occurrence



Number of occupants and other road users fatally or seriously injured;



The extent of damage to the vehicle as far as it is known



Date and time (local time or UTC) of the critical occurrence



GNSS coordinates of critical occurrence

Without delay, the manufacturer should submit to the type approval authorities, the market surveillance
authorities and the Commission the details omitted from the initial notification as well as other known
relevant information.
See also additional guidance material in Appendix 6.
2.2.

The manufacturer shall report within one month any short-term occurrences, as described in Appendix
1, which needs to be remedied by the manufacturer to the type-approval authorities, market
surveillance authorities and the Commission.

The short-term reporting of occurrences is required for matters of such safety importance that they may
require the manufacturer to take remedial action.
Short-term reporting is due within one month of the manufacturer’s knowledge of the matter. It is expected
that the manufacturer will be able to identify the root cause of the occurrence and the corrective action (if
any) within the one month available for reporting the occurrences.
Short-term reporting is needed to provide awareness of situations in which the ADS may be or is posing an
unreasonable risk to safety in-service.
The short-term reporting should be in plain language and contain as much of the information included in the
proposed template (see Appendix 6) as is available to the manufacturer without prejudice to the applicable
national law.
More detailed guidance on a possible template for the short-term reporting of critical occurrences is provided
in Appendix 6 to the present report.
2.3.

The manufacturer shall report every year to the type-approval authority that granted the approval on
the occurrences listed in Appendix 1. The report shall provide evidence of the ADS performance on
safety relevant occurrences in the field. In particular, it shall demonstrate that:
a) no inconsistencies are detected compared to the ADS safety performance assessed prior to
market introduction;
b) the ADS respects the performance requirements set by this Regulation;
c) any newly discovered significant ADS safety performance issues have been adequately addressed
and how.
The granting type-approval authority shall share this information with type-approval authorities,
market surveillance authorities and the Commission.

The periodic reporting of occurrences is required to evaluate ADS fleet operation and to provide a suitable
framework for the short-term occurrences normalization with respect to the ADS operation.

11

Periodic reporting is due yearly. It is expected that the manufacturer will be able to retrieve aggregated data
concerning ADS operation such as cumulative distance and operating time.
The periodic reporting should be in plain language and contain as much of the information included in the
proposed template (see Appendix 6) as is available to the manufacturer without prejudice to the applicable
national law.
More detailed guidance on a possible template for the periodic reporting of critical occurrences is provided in
Appendix 6.
2.4.

Type-approval authorities, market surveillance authorities and the Commission may request the
manufacturer supporting data used to elaborate the information provided into the in-service reporting
and notifications.
These data shall be exchanged by means of an agreed data exchange file. Type-approval authorities,
market surveillance authorities, and the Commission shall take all necessary steps to secure such
data.

No guidance included in this document as regards this paragraph.
2.5.

Any pre-processing of data should be notified to the granting type-approval authority in the in-service
Data Report.

No guidance included in this document as regards this paragraph.
Appendix 1 - List of occurrences for in-service reporting
The Annex III Part 5 Appendix 1 of the Regulation (EU) 2022/1426 provides the list of occurrences to be
reported. This list identifies four occurrence categories with some details of situation types that fall into each
category.
Guidance for this paragraph is provided in Appendix 6 - Technical Guidance on In-service Reporting

12

4

Conclusions

The EU Regulation 2022/1426 has opened the road to the market introduction and deployment of fully
automated vehicles in Europe. It defines minimum safety requirements that vehicles needs to fulfil and
different validation methods to assess their performances. Being the first regulation developed worldwide for
the type-approval of fully automated vehicles, it introduces various elements of completely innovative
character. In order to support ADS developers and Approval Authorities in the application of the Regulation
and in order to ensure that related practices around the EU may be as harmonized as possible, the European
Commission has initiated the process to provide an interpretation to some of the most innovative aspects of
the legislation. The work has been carried out by the experts of the ACV sub-group of the Working Group on
Motor Vehicles, under the lead of the European Commission. The result of this process is the present report.
The parts of the Regulation for which an interpretation and/or examples and references have been provided
have been identified by the stakeholders involved in the process. In the future, the work will continue to
include additional parts of the Regulation as well as to strengthen and consolidate the parts dealt with in the
present report in the light of the evidence that will be gathered by the application of the Regulation.

13

APPENDIX 1 - Technical Guidance on ODD description
Given a specific ODD, it is crucial for the ADS to ensure that:


it can operate safely within its ODD under conditions reasonably expected in the ODD



it will be used only within its ODD



it can monitor whether it is inside/outside its ODD and respond appropriately, especially regarding
ODD boundaries.

The conditions constituting the ODD in which the ADS was designed to operate will help determine which ADS
competencies are required. For example, if an ADS has an ODD which comprises of roads with non-signalised
junctions, one of the required behaviour competencies for the ADS in that ODD could potentially be
“unprotected left or right turn”. However, the same behaviour competency may not be required if the ODD of
an ADS is limited to motorways or highways with signalised junctions.
As the ODD defines the operating conditions of the ADS, and supports the scenario-generation process for
ADS testing, as shown in Figure 1, it is important that an appropriate taxonomy is used. The BSI PAS 1883 2,
e.g., contains a standardised set of attributes such as scenery, environmental conditions and dynamic
elements. On a similar note, the SAE AVSC00002202004 3 presents a lexicon for the ODD definition, including
additional elements such as road surface, roadway infrastructure, operational constraints, road users,
roadside objects and connectivity, to mention just a few. Other similar efforts are described in the ASAM
OpenODD4 and ISO345035.
Figure 1. Correlation between the ODD description and other pillars

Source: Oldoni and Khastgir (2023)

2

https://www.bsigroup.com/globalassets/localfiles/en-gb/cav/pas1883.pdf
https://www.sae.org/standards/content/avsc00002202004/
4
https://www.asam.net/standards/detail/openodd/
5
https://www.iso.org/standard/78952.html
3

14

APPENDIX 2 - Technical Guidance on Scenario Generation and Coverage
The present appendix provides technical guidance to the manufacturer on possible approaches they may use
to derive scenarios for the certification of ADS based on the ODD, and for assessing their coverage as
prescribed in the Commission Implementing Regulation (EU) 2022/1426, Annex III, Part 1, paragraph 2, and
the related Appendix 1.0
It proposes principles of a scenario-based approach, among which the search of sufficient coverage of driving
situations in the given ODD.
1. Introduction and global approach of driving scenarios
The interest of driving scenarios is based on three main, complementary logics:
-

Coverage: a logic of sufficient coverage, aiming at avoiding that driving scenarios wouldn’t have
been taken into account in the system’s design and validation; in line with the idea of covering
the space of possibilities, regardless of the potential severity

-

Distribution: a logic that is governed by probabilistic thinking and the evaluation of exposure to
operational scenarios that the ADS is likely to encounter and is expected to be characterised and
assessed in.

-

Classification: aiming to consider scenario categories that were defined as nominal, critical and
failure scenarios

Furthermore, the use of scenarios for the safety assessment of automated systems will have to combine
approaches focused respectively on the vehicle, and the operational conditions in which the vehicle will be
deployed that is to say considering the entire ODD, including ODD boundaries.
This appendix presents a possible approach to derive driving scenarios. The possible approach described here
aims to achieve sufficient coverage in the identification of potential risks that an ADS may encounter during
deployment. Indeed, some of the steps in the safety demonstration process are likely to use or generate
scenarios; the identification and analysis of risks allows the contextualisation of critical situations. Linking the
risk analysis to scenarios makes it possible to aim for sufficient coverage and relevance.
Working on scenario generation to assess vehicle safety, and more generally system safety constitutes a
basis, from which it is possible to deal with scenarios that:
-

cover situations within the use case’s ODD limits (also linked with ODD definition, see Appendix
1);

-

cover and combine safety demonstration activities (risk analysis and failure mode analysis);

-

update based on experience feedback or the addition of other scenario description axes as the
use cases mature (e.g. remote intervention, coordinated management of several vehicles,
interactions with first responders).

The scenario-based approach makes it possible to generate traffic scenarios from reasonably foreseeable
driving situations, involving other road users, objects, system failure, but also to characterise specific
interactions as for example with law enforcement officers and priority vehicles; and including potential high
severity situations.
2. Scenario generation
2.1. Scenario-based assessment
The main purpose of the contribution to the scenario-based safety demonstration is to verify that an ADS,
characterised by a set of specifications resulting from its internal design and validation process, is capable of
behaving safely in all reasonably foreseeable driving situations it may encounter in traffic.
The scenario approach, by aiming to inventory the driving situations that the ADS may encounter, is presented
as a process whose genesis can be found in the “ODD and OEDR analysis”, as described in the EU Regulation,
whose underlying idea is to ensure the completeness of the identification of ODD elements/objects and the
system's responses through a three-step inventory reasoning:
i.

traffic hazards ("objects and events");

ii.

detection and recognition performance (“detection”);

15

iii.

system response performance.

In that sense, behaviours of other road users that are reasonably foreseeable and presence of roadway
characteristics in the ODD are explored in more detail by mapping actors with appropriate properties and
defining interactions between the objects. Tables 1 and 2, in Appendix I of the EU Regulation (pp.25, 26) give
an example of these analysis.
The behaviour of other road users, as long as dynamic events, and the condition of physical static elements
within the ODD may fall at any point along a continuum of likelihood called the reasonably foreseeable
conditions. The reasonably foreseeable concept should be seen as the notion of conceivability regarding
traffic safety: all reasonably foreseeable situations should be taken into account when assessing system
safety. It is worth mentioning that considering all reasonably foreseeable situations does not prevent from
not considering them for testing according to risk analysis. For example, deceleration by other vehicles may
range from what is expected and reasonable in the traffic circumstances, to unreasonable but somewhat
likely rapid deceleration, to extremely unlikely (e.g., a sudden cut-in combined with full braking on a clear
high-speed road).
Figure 2. Diagram presenting the global scenario-based approach linked with ODD definition and description and OEDR
analysis – and the behavioural competencies to form a test case. The scenario-based approach has the virtue to combine
all reasonably foreseeable situations applicable

Source: JRC
The concept of reasonably foreseeable, applied to the scenario generation approach, should be distinguished
from the scenario-selection process, involving traditional safety analysis and making reference to scenario
classification.
Considering an ADS in its ODD refers to a global principle guiding safety demonstration through scenario
generation to provide a sufficient coverage of driving situations that might occur.
2.2 Scenario-based approach based on layers
Based on a large literature review on scenario-based approaches that emerged at the international level
through projects, the potential use of structural axes of scenario description has emerged.
The introduction of lists of descriptors, aiming to help describing both ODDs and scenarios, and reflecting the
concept of sufficient coverage of the scenario-based approach, might lead to consider the maximum
exhaustiveness of the descriptors themselves.
It should be noted that the selected approach, that remains at the initiative of the system manufacturer,
following the logic of sufficient coverage of driving situations by appropriate coverage of descriptors, tends to
contribute to state-of-the-art by combining different inputs from layer generation in international approaches.
It appears that the chosen scenario-based approach should represent the global ecosystem vision, without
being the only way to consider scenario generation. It is assumed that this paragraph defines the logic under
which the scenario-based approach should be built, but does not represent the only possible logical
arrangement.
16

One virtue of the scenario approach based on layers, in practice characterized by descriptors enabling to
properly describe all reasonably foreseeable conditions, which apply to an ADS, lead to consider the virtue of
combination to assume a good and sufficient coverage of the scenario space of possibilities.
Figure 3. Example of possible arrangement of layers and its decomposition based on the description of its layers (named
descriptors). Each layer is composed of an amount of independent descriptors, combined to form scenarios

Source: adapted from French Ministry for Transportation6

2.3. Scenario Identification
This part proposes to make the link between different sources of scenarios and the type of scenarios that
they can generate preferentially.
It is possible to consider four sources of scenarios, based on either a knowledge-based or data-based
identification approach:




KNOWLEDGE-BASED
o

Scenarios resulting from system design activities, induced by the intended use (operational
design domain, OEDR, route, etc.)

o

Scenarios resulting from risk analysis relating to the functional insufficiencies

DATA-BASED
o

Scenarios resulting from driving (physical or digital), which have

o

Nominal scenarios

o

Critical scenarios


6

Scenarios resulting from accidents, observed in the accidentology representative of
the intended use

https://www.ecologie.gouv.fr/sites/default/files/DGITM_Approche-par-scenarios-fevrier-2022-EN.pdf

17



Scenarios often called “Edge cases” or notable scenarios (rare, unknown, and
dangerous, from area 3 of SOTIF7)



Scenarios often called “Corner Cases” by combining at least two constraints which
lead to a critical scenario



“Near accidents” or accidents avoided by interaction between driver and users, likely
to become accident scenarios in automated driving.

On that basis, considering scenario sources makes a clear matching between scenarios and descriptors,
meaning that descriptors might be induced by:
-

Data from driving, both from accident or incidents and from edge cases, leading to consider
edge descriptors (new descriptors, larger parameter ranges);

-

Axis combination, from possible unknown combination of already known descriptors.

The notion of combination applies to the scenario-based approach as a process contributing to enhance the
concept of sufficient coverage of the set of traffic scenarios.
Aligned with the notion of combination of possible descriptors leading to feed the scenarios, it is important to
use a scenario approach keeping in mind the two main layers of OEDR approach:
i.

OED as the description of hazards that are reasonably foreseeable in the ODD;

ii.

R as the possible response of the system (being possibly affected by failures or additional hazards)

It might be appropriate to map scenarios along with the main features of the expected response of the
system, in particular in line with behavioural competencies, with the idea of prudential behaviour. For
example, driving in front of a school should suggest specific behaviours such as reducing speed, potential
pedestrians walking with unpredicted trajectories (in particular regarding children), crossing the street outside
of a pedestrian crossing.
Data-based and knowledge-based scenarios are also thought to feed the process of scenario update. That
means the scenario-based approach is a living process, where the set of scenarios for a specific system
defined to operate in its ODD, is continuously revised. Moreover, as a scenario is defined as the combination
of descriptors, which does this living process update continuously too, the set of scenarios is enhanced by the
combination of these new descriptors. Descriptors, as being central in the scenario-based approach, are able
to feed both knowledge-based scenarios (based from experts) and the list itself by new combinations induced.
Figure 4. Scenario-based approach under angle of two categories of scenario sources and its articulation with the
combined-based concept (usable both as a knowledge-based and data-based principle).

Source: Lanaud and Delache (2024)

7

ISO 21448:2022 - https://www.iso.org/standard/77490.html

18

In particular, working on scenario generation, especially through the combinatory-based approach does not
prevent from dimensioning safety based on proportionate quantitative approaches.
2.4 Scenario enrichment process
The purpose of this paragraph is to present an approach to enrich scenario generation based on the following
logic:




the comparison of scenario descriptors with different sources is likely to reveal:
o

the need for new description attributes: a scenario taken from the sources turns out to be
non-describable due to the lack of one or more lines of description

o

values of the description parameters: a scenario taken from the sources modifies the field
of “reasonably foreseeable”

the combination of scenario descriptors, enriched by new attributes, then generates more scenarios,
improving coverage

Having said that, the aim of scenario combination, although guided by the principle of sufficient coverage of
the scenario space, is not intended to assess an infinite number of scenarios in the testing validation process.
The aim of the global scenario-based approach is to be able, based on the combination of appropriate
descriptors and attributes, to identify all possible reasonably foreseeable scenarios to include in the testing
procedures.
It is worth noting that this document does not provide any indicative methodology to move from scenario
generation to a concrete scenario catalogue.
In turn, this enrichment of scenarios makes it possible to improve the mobilization of sources, for example by
deepening risk analysis or by collecting traffic or accident data reflecting the new types of scenarios
generated by the combination. This enrichment also makes it possible, if necessary, to ensure that nominal
scenarios have not been omitted in the design of the system and its ODD.
2.5 Scenarios, ODD and descriptors
Although the aim of this document is not to provide a methodology to move from scenario generation to a
concrete scenario catalogue, the link between ODD description and scenario generation is central. As
presented in Appendix I, ODD description is crucial when considering safety demonstration activities, among
those is scenario generation. Hence, the link between scenario generation and ODD description needs to be
clarified. The scenario generation process has been presented as a combinatory-based process based on five
layers, those layers enabling to precisely describe the reasonably foreseeable driving situations within the
ODD (i.e. conditions under which the system is designed to operate safely). The aim of such an approach is to
provide a sufficient coverage of the space of possibilities for a given ADS in a specific ODD, which aims to
cover the space of traffic hazards regarding ADS capabilities.
As a result, the link between scenario generation and ODD description becomes obvious. The level of details
needed to build a representative and sufficient set of traffic scenarios for a given ADS in a given ODD relies
on the representative and relevant level of details of the ODD itself, that is to say describing static elements
of the driving environment. In this consideration have not been mentioned dynamic possible elements, which
may not be part of specific ODD (named addressable hazards in the previous part 2.1). In that case, it is worth
mentioning that ODD consideration through its descriptors has to be linked with OED descriptors (provided in
previous graph in 2.2) has they constitute a set of the reasonably foreseeable conditions mentioned in graph
in 2.1. As a result, all these considerations place on one hand ODD as a central element when building a
scenario generation process, and on another hand put in the middle the concept of descriptors.
This ties in with the idea that sufficient coverage within the scenario-based approach, carried out by the
notion of a sufficient list of descriptors is the key to move from inert elements to sets of characteristics
intended to build a scenario. It remains under manufacturers’ competency to provide a consistent list of both
scenarios and ODD descriptors. The list of descriptors will fit the requirements to provide an indicator of the
corresponding level of coverage.
This global approach linking scenario generation and ODD description does not seek to describe neither
characterize triggering conditions of hazards nor ADS responses.

19

Hence, making the link between these two important notions is a possible way to move from a theoretical
approach named scenario generation to a concrete approach characterized by its intersection with ODD
description. The latter process aiming to provide a finite number of concrete scenario for testing procedures.
Figure 5. Illustration of the power of descriptors in the scenario-based approach through the possible arrangement
presented in this document, showing the complementarity between ODD descriptors and OED definition (leaving aside
failures and functional insufficiencies.

Source: Lanaud and Delache (2024)

3. Articulation between scenario-based approach and other safety demonstration activities
A major challenge of the safety demonstration approach is to ensure the greatest possible and sufficient
coverage of safety-relevant scenarios.
This quest for sufficient coverage of scenarios is central to the approach. The requirement of "reasonably
foreseeable" applies to it, to which the knowledge-based and data-based approaches presented above
contribute. These approaches must combine the search for system malfunctions and external traffic hazards.
This search for sufficient coverage of events (malfunctions + traffic hazards) is fed by the combination of
deductive approaches on possible causes (hazard -> possible causes) or inductive approaches of failure
modes (failure -> hazards). The search for coverage is also fed by the search for traffic hazards specific to
the route.
The scenario approach is based on a method of "expert" generation, by combining the axes of description of
the scenarios (driving environments * nominal manoeuvres * characteristics of the collision precursor events),
which leaves aside any reference to their likelihood and does not specifically rely on data from driving.
The main contribution expected from the scenario approach is thus to avoid the omission of certain types of
scenarios from the quantitative approaches used in traditional risk analyses. The generation of scenarios (in
particular by combining axes) is therefore a first step, normally completed by a quantification step (frequency
/ severity). The robustness of the overall approach (scenario generation / quantified risk analysis) should
therefore be based on the principle that the scenarios resulting from the generation stage are systematically
included in the quantified analyses, even if it means qualifying them as "implausible" or qualifying their
consequences as "not serious".
To ensure that the behavioural competencies identified in the previous paragraphs are ready to be assessed
through the application of simulations or physical testing, ODD-relevant scenarios must be developed.
Scenario creation involves use of assumptions concerning possible actions by road users and their
characteristics.
In a logic relative to the consideration of the global approach of vehicle type-approval, in a comparable spirit
to that underlying testing, and to avoid multiplying safety demonstrations at different levels (to remove
systems that would not maintain a sufficient level of safety), the scenario-based approach should enable to
assess separately the overall weighted analysis of scenarios that are (a) common and representative of all
deployment environments covered by the ODD; (b) easily characterized ; c) sufficiently critical that a glaring
lack or inadequacy of system response could be sufficient to disqualify it; but d) for which the expected
system response is not describable in a sufficiently simple and unambiguous way to apply the pass/fail test
logic applicable to simple scenarios (such as emergency braking in pedestrian detection, for example).

20

APPENDIX 3 - Technical Guidance on Safety Targets and Acceptance Criteria
The present appendix provides technical guidance to the manufacturers on the acceptable means of
compliance for the definition of the acceptance criteria to evaluate the residual risk of the ADS as prescribed
in the Regulation, Annex II, paragraph 7.1.1, and the related footnote.
1. Safety Assessment Approach set in Regulation 2022/1426
The safety assessment approach set out in the Regulation is based on the demonstration of compliance with:
a)

Requirements of the safety management system (Annex III, Part 2).

b)

General performance requirements (Annex II, except Paragraph 7).

c)

Specific performance requirements valid for a minimum set of traffic scenario (Annex III, Part 1).

d)

Safety acceptance criteria to demonstrate absence of unreasonable risk (Annex II, Paragraph 7).

Considering that the demonstration of compliance of the safety management system (a) follows its own
process and rules, the other three constitute a unique framework that the manufacturer should address
organically.
When dealing with the demonstration of compliance, (b) and (c) are, on the one hand, both based on explicit
requirements (the former related to the ADS general performance, the latter scenario-specific), and therefore
can be grouped as “requirements-based” safety demonstration. In these cases the compliance is
demonstrated by means of verification and validation that the ADS meets the defined requirements under the
specified as well as real-world conditions.
On the other hand, the demonstration of safety must also consider that unsafe scenarios can still be present
without explicit requirements or performance limitations so that the ADS does not meet the defined
requirements under certain (unusual) conditions. These cases are potential sources for residual safety risks.
The demonstration of compliance with the safety threshold for the acceptability of the residual risk (d) is, by
its definition, very different from the others and should be addressed with a dedicated methodology.
Establishing compliance with the requirement in Annex II, Paragraph 7, to demonstrate that the manufacturer
has given acceptable consideration to functional and operational safety in developing acceptance criteria and
validation targets sufficient to ensure that the ADS is free from unreasonable risks, should be addressed with
a full explanation of the criteria and targets and the methodologies used to develop them.
The Regulation foresees that, in some cases not covered by requirements (b) and (c), a collision may be
unavoidable, and therefore it requires quantifying the residual risk associated to such scenarios, to verify that
road users are not exposed to an increased risk.
By combining the residual risks associated with all these scenarios, a global residual risk is obtained,
characterizing the use of the considered ADS in the considered ODD. Finally, the global residual risk is
compared with a reference threshold value to demonstrate compliance.
Furthermore, the assessment of the residual risk gives also the possibility to the type-approval authority to
identify the scenarios associated with a higher residual risk and for which it will be important that proper
additional measures are taken into account to mitigate the risk.
The global residual risk can be focused on a specific kind of effect (e.g., deaths, injuries, damages to
properties): all the conditions that may lead to the selected effect are concurring to constitute the global
residual risk for the selected damage.
The selection of the reference value for the global residual risk comparison can be done by following different
approaches. According to paragraph 7.1.1., “The manufacturer shall define the acceptance criteria from which
the validation targets of the ADS are derived to evaluate the residual risk for the ODD taking into account,
where available, existing accident data, data on performances from competently and carefully driven manual
vehicles and technology state-of-the-art".
The manufacturer may take into account the particular low societal acceptance of crashes with ADS vehicles
compared to conventional vehicles. It may be good practice to increase the acceptance criteria over time.
2. Methodologies for Demonstration of Safety as a Threshold (Acceptable Means of Compliance)
The present section provides guidance on the methodologies suitable to demonstrate compliance with the
Regulation in relation to the safety as a threshold approach. It presents a collection of acceptable means of

21

compliance, namely the methodologies that would be acceptable for the type approval authorities. The
content of this section is applicable on a voluntary basis and it is not intended to be exhaustive. Depending on
the vehicle type defined by the manufacturer, and the practices and procedures they use, alternative and/or
equivalent methodologies may be used and consequently, different information may be supplied to comply
with the requirements established in the Regulation.
2.1. Probabilistic Approach
The goal of a probabilistic approach is to demonstrate how safety thresholds are met, toward determining
acceptability of the residual risk (Annex II, Paragraph 7). Residual risks can arise due to several causes,
including, but not limited to:
-

Hardware and E/E system failures (ISO 26262)

-

Security attacks

-

Functional insufficiencies (ISO 21448)

These causes for hazards differ strongly in their nature, thresholds and thus differ in the approaches to
demonstrate that an acceptable level of residual risk is met.
The evaluation of residual risks of hardware and E/E system failures is well defined and already established
since many years by standards and state-of-the-art approaches. For residual risks stemming from security
attacks, there is currently limited experience on how to evaluate these in the context of ADS in the EU.
Therefore UN Regulation No. 155 "Uniform provisions concerning the approval of vehicles with regards to
cyber security and cyber security management system" needs be interpreted and applied. The approaches
outlined in the following address the functional insufficiency category and focus on approaches on how to
establish quantitative measures of the residual risk. Due to the limited extent, it is recommended to combine
the results with qualitative arguments within a safety argumentation.
The functional insufficiency category can be separated in two types:
a) Specification insufficiencies, e.g., unknown scenarios or incorrect specification of safe and rule
conform driving behaviour in specific scenarios.
b)

Implementation insufficiencies, e.g., limited visibility of the sensors under specific environmental
conditions.

For both types of functional insufficiencies, it is expected that cases relevant for residual risk, i.e., not
addressed by demonstrating compliance to General performance requirements (Annex II, except Paragraph 7)
or to Specific performance requirements valid for a minimum set of traffic scenario (Annex III, Part 1), will in
general occur under unusual, rare conditions. A valid approach for demonstrating the acceptability of the
residual risk must consider this property. Simply adding residual risks up to evaluate the collective
acceptability of the residual risk can lead to wrong conclusions and is not suitable. While UNECE is describing
New Assessment/Test Method for Automated Driving 8 as a general approach, in the following, three
archetypes of approaches will be described which are by no means exhaustive and may be combined.
2.1.1. Simulation-based Sampling from Nominal and Critical Scenarios and Statistical Models of Performance
Limitations
In this approach, all derived nominal and critical scenarios (scenario event sequences, not entire logs of trips)
as defined in Commission Implementing Regulation (EU) 2022/1426, Annex III, Part 1, paragraph 2, and the
related Appendix 1 are tested in simulation with a structured or statistical sampling of the scenario
parameters as well as validated models of performance limitations relevant to the ADS (e.g., leading to
increased sensor noise).
To demonstrate that an acceptable level of residual risk is met, the scenarios must be weighted with
statistical weights reflecting the occurrence frequency of those scenarios. The statistical weights, the
parameter sampling distribution and the statistical models of performance limitations can be obtained from
empirical data collection considering the ODD.

8

(GRVA) New Assessment/Test Method for Automated Driving (NATM) - Master Document | UNECE

22

Although scenarios from crash data and naturalistic driving data are available, breaking the data down by the
conditions that closely reflect those of the intended ODD is not simple. Moreover, because meaningful
comparisons can be made only by considering the severity of crash outcomes (e.g., risk-based or outcomebased assessment of severity), variations in how severity is recorded in different crash data sets presents
analytical challenges, as does the limited amount of data on the most severe events.
Note that simulation-based testing enables much more extensive testing and thus enables generation of valid
performance estimates of collisions and their severity with a fraction of the time and effort as possible in real
world testing. However, the validity of the results hinges on the accurate and sufficiently complete
characterization of the scenarios as well as the statistical models of performance limitations. More details on
scenario parametrization and sampling are described e.g., in ISO 21448:2022 Annex C.5.
2.1.2. Simulation of a certain Software Version and System Configuration against Entire Historical Realworld Logs
This approach is similar to the one described in Section 2.1.1 but differs from it in the sense that entire trip
logs of data from real world testing with the ADS are used. This approach measures empirically the ADS’s
estimated collision rates and severities that would have occurred in that particular software and system
configuration, to allow comparison of those rates against human driver benchmarks and other performance
criteria. In addition, a filter based on pass criteria for nominal and critical scenarios can be evaluated to find
events in which the pass criteria are not yet violated but close to that (so called sub-critical events).
These discovered scenarios are then used to update the scenario-based testing described in Section 2.1.1 and
tested in simulation with a statistical sampling of variations of the scenario parameters as well as statistical
models of performance limitations relevant to the ADS.
2.1.3.

Real-world Testing with Analytical Decomposition of Failure Rates

In contrast to the first two approaches, the third relies on real world testing only, examining observations of
outcomes. Instead, to generate statistically valid event rates which can demonstrate the acceptability of the
residual risk, the risk acceptance criterion can be decomposed into multiple sub-criteria which can be
individually validated. To this end, functional insufficiencies are decomposed into the occurrence of multiple
individual insufficiencies. If it can be established according to the system architecture that those individual
insufficiencies can occur with a certain degree of statistical independence and a functional insufficiency will
only result if all those individual insufficiencies occur at the same time, the risk acceptance criterion can be
analytically decomposed. More details on the impact of the ADS system architecture on validation are
described e.g., in ISO 21448:2022 Annex C.6.3.
3. Metrics for the Definition of the Safety Threshold
The Regulation does not define a specific metric to be adopted by the manufacturer. The manufacturer is
allowed to use any metric (as well as any acceptance criteria and approach) provided that is able to
demonstrate that its use does not decrease the safety level in comparison with similar services in the same
operational environment, “taking into account, where available, existing accident data”.
A list of possible metrics includes (but is not limited to) fatality rate, injury rate, collision rate, energy of
impact.
3.1.

Fatality Rate

The Regulation uses the concept of validation targets and global safety threshold for the acceptability of the
residual risk. The example of acceptance criteria indicated in the footnote of Paragraph 7.1.1 is based on the
analysis of current EU road accidents aggregated data and relies on a metric based on the number of
fatalities per hour of operation. The threshold is then set to 10-7 (fatalities per hour of operation).
Such combined metric and threshold provides an example that could be used for the market introduction of
ADS, since they have been extrapolated from available state-of-the-art data. However, such data does not
take into account for the “performances from competently and carefully driven manual vehicles and
technology state-of-the-art”, which the Regulation requires to take into account “where available”.

23

4. Data sources and databases
The manufacturer is in charge of the identification and selection of similar services and situations for the
evaluation of the current level of risk of those services in similar ODDs. Such risk can be extrapolated by
analysing available data.
Some example of available data and databases is reported in the Table below. National authorities should
work to provide additional traffic data from the ODD to manufacturers beyond examples given below, to
ensure that data comparisons for acceptance criteria accurately reflect the current level of safety in the ODD
in scope.
Table 2. Example of available sources of accident data

Country
European
Union

France

Database

Link

https://roadsafety.transport.ec.europa.eu/statisticsand-analysis/methodology-andresearch/care-database_en
https://www.data.gouv.fr/fr/datasets/basesAnnual databases of road traffic de-donnees-annuelles-des-accidentsinjuries – 2005 to 2022
corporels-de-la-circulation-routiereannees-de-2005-a-2022/
Community Road Accident
Database (CARE)

Source: JRC

24

APPENDIX 4 - Technical Guidance on Safety Assessment
The present appendix provides technical guidance to the manufacturers on the assessment of the ADS safety
concept and audit of the safety management system as prescribed in the Regulation, Annex III, Part 2.
1. Introduction
The introductory part of Annex III, Part 2 (Paragraph 1, “General”) highlights two relevant aspects concerning
the assessment of the ADS safety concept, namely:
1.

The type-approval authority (or the technical service acting on its behalf) conducts spot checks and
tests to verify “that the safety argumentation provided by the documentation complies with the
requirements of Annex II and that the design and processes described in documentation are actually
implemented by the manufacturer”. The targeted spot checks and tests refers in particular to
Paragraph 4 “Verification and tests”, that states: “taking into account the results of the analysis of
the manufacturer’s documentation package, the type-approval authority shall request the tests to be
performed or witnessed by the Technical Service to check specific points arising from the
assessment.”

2.

The acceptance of the ADS by the type-approval authority implies that “the residual level of safety
risk of the type-approved ADS is deemed to be acceptable for the entry into service of the vehicle
type” according to the Regulation. The acceptance is “based on the provided documentation, audit of
the safety management system and the assessment of the ADS safety concept”. It is worth to
underline that compliance with safety requirements extends throughout the ADS lifetime and
“remains the responsibility of the manufacturer requesting the type-approval”.

Evidence of the fulfilment of the safety requirements is provided by the manufacturer through the supply of
properly prepared and exhaustive documentation. Specific indications of the contents to be included are given
in different sections of the Regulation.
In general, the documentation should be effective in showing that:
●

the system complies with the requirements laid down by the regulation,

●

supplied information and defined procedures/processes correspond to what has actually been
done and implemented by the manufacturer.

●

the system is free of unreasonable safety risks to vehicle occupants and other road users during
the vehicle lifetime,

In the documentation provided by the applicant, the safety concepts and its validation is reported; it includes
demonstration that the system takes into account fundamental principles such as redundancy, diversity,
capability to operate with reduced functions, possibility of disarming or limiting autonomous driving functions,
mitigation of the consequences of possible dangerous conditions. The applicant explicitly states and
demonstrates that the system is free from unreasonable risks concerning both the occupants of the vehicle
and the other road users.
The type-approval authority performs inspections related to the approach used by the manufacturer to
demonstrate the level of safety. This approach shall take into account selected specific hazardous conditions.
The type-approval authority assessment can be performed by checking what has been included in the design
of the system to deal with possible risks or, vice versa, considering the functions of the system to identify
which dangerous conditions the system can cope with.
The type-approval authority checks also the system behaviour by means of physical tests on tracks and
roads. The tests check the capability of the system to manage interaction with other road users and possible
system failures, the risk mitigation methods, and the ability of the system to manage disturbed situations.
Conditions considered to be critical for the behaviour of the ADS can be included. The outcome of the tests
should comply with the requirements and with the documentation issued by the manufacturer. Simulations
and mathematical models can be used to support and complement physical testing.
The documentation to be provided by the manufacturer requesting the type-approval is a key aspect of the
type-approval process, it should report the safety assessment in sufficient level of details to demonstrate the
safety, to support the conclusions stated and to provide an adequate input to independent verification and
type-approval review. The following section provides support to the manufacturers in the preparation of the
relevant entries of the Information Document (ID) as from the Regulation (EU) 2022/1426, Annex I.

25

In addition, the manufacturer should demonstrate the setting up and application of a safety management
system compliant with the requirements; this implies the provisions of methods and procedures for
requirements management, requirements implementation, performing tests, identifying gaps and noncompliances, define and applying related remedial actions, and monitor the effects obtained. In addition, the
manufacturer shows that it has implemented methods and procedures to manage and to coordinate various
aspects related to operational safety, cybersecurity and all other disciplines relevant for the safety of the
vehicle, including continuously monitoring the compliance with safety requirements of the ADS during its
whole lifetime.
The applicant shall obtain a certification of its safety management system, which is propaedeutic for the
type-approval of the ADS which the safety management system is relevant for.
The Regulation establishes that the personnel of the type-approval authority (or any supporting technical
organization acting on behalf of it) responsible for inspections and controls must have the necessary skills
and competences in technical aspects related to the evaluated system. Demonstration of such a competence
is given by appropriate qualifications or specific training.
2. The Information Document
The present section is intended to support the manufacturers in the preparation of the relevant entries of the
Information Document (ID) as from the Regulation (EU) 2022/1426, Annex I, which provides a model of the ID
for EU type-approval of fully automated vehicles with regard to their automated driving system.
The Regulation (EU) 2022/1426 states that (introduction, point 4) the Information Document “referred to in
24(1) (a) of Regulation (EU) 2018/858 to be provided by the manufacturer for the type-approval of the
automated driving system of fully automated vehicles should be based on the template laid down for the
whole vehicle type-approval in Annex II to Commission Implementing Regulation (EU) 2020/683. However, to
ensure a consistent approach, it is necessary to extract the entries of the information document that are
relevant for type-approval of automated driving system of the fully automated vehicle”.
Moreover, as pointed out in Article 3 point 1, “the relevant entries of information document, submitted in
accordance with Article 24(1), point (a) of Regulation (EU) 2018/858 with the application for type-approval of
the automated driving system of a fully automated vehicle, shall consist of the information relevant for that
system as contained in Annex I.”
The provision of the ID by the manufacturer is part of the requirements set out in Annex III, Part 2, Paragraph
3.1, which states that “the manufacturer shall provide a documentation package which gives access to the
basic design of the ADS and the means by which it is linked to other vehicle systems or by which it directly
controls output variables as well as off-board hardware/software and remote capabilities. The function(s) of
the ADS, including the control strategies, and the safety concept, as laid down by the manufacturer, shall be
explained.”
The “documentation shall be brief, yet provide evidence that the design and development has had the benefit
of expertise from all the ADS fields which are involved”, so as to report the safety assessment in sufficient
level of details to demonstrate the safety, to support the conclusions stated and to provide an adequate input
to independent verification and type-approval review.
It is worth to remind that, as set out in Annex III, Part 2, Paragraph 3.1.1 (c), “confidential material… shall be
retained by the manufacturer, but made open for inspection”. Notwithstanding, sensitive information included
in the ID and supporting reports, the unauthorised disclosure of which could compromise proprietary and
vehicle security, should be identified. Such information should be protected in accordance with guidance on
information security in force.
2.1. Format and Content of the Information Document
In the following pages, guidance is provided on the sort of content manufacturers may choose to provide to
address relevant sections of the ID, together with references to the relevant sections of the Regulation.
0.

GENERAL

No guidance included in this document as regards this section and its sub-sections.
17.

AUTOMATED DRIVING SYSTEM (ADS)

This section should include any general information not specifically included in the subsequent sections and
sub-sections, but relevant for the type-approval, e.g.:

26

a) Definitions used for the purposes of the ID.
b)

Intended use case of the fully automated vehicle, among the ones allowed by the Regulation, Article
1:
a.

“Fully automated vehicles, including dual mode vehicles, designed and constructed for the
carriage of passengers or carriage of goods on a predefined area.”

b.

“‘Hub-to-hub’: fully automated vehicles, including dual mode vehicles, designed and
constructed for the carriage of passengers or carriage of goods on a predefined route with
fixed start and end points of a journey/trip.”

c.

“‘Automated valet parking’: dual mode vehicles with a fully automated driving mode for
parking applications within predefined parking facilities. The system may use or not external
infrastructure (e.g. localization markers, perception sensors, etc.) of the parking facility to
perform the dynamic driving task.”

c)

Description of the existing approval status.

d)

Statement of any similar or identical vehicle that the type-approval authority has already reviewed
and approved and a statement of the specific differences and/or improvements that have been made
since such approval was granted, if any.

A comprehensive list of regulations, codes and standards which the ID makes reference to should be provided
in this section. Every document of the list should also be referenced in the appropriate section when relevant.
If the codes and standards have not been prescribed by the Regulation(s), a justification of their
appropriateness should be provided.
When allowed by the Regulation, any modification made to or deviation from the requirements should be
clearly stated and justified, together with the way in which the modifications/deviations have been addressed
in the different sections of the ID.
17.1.

General ADS description

The objective of this section is the description of the ADS, its mission, its limits and its overall architecture,
including the main sub-systems which the ADS is constituted by, and their relationships. This description
constitutes a high-level overview of the ADS, whereas the detailed descriptions of ADS functions, hardware
and software are included in §17.2, §17.3 and §17.4 respectively.
This section should include any general description of the ADS as set out in Annex III, Part 2, Paragraph 3.2,
but not specifically included in the following sections and sub-sections. In particular, as stated in Paragraph
3.2.1, “description shall be provided giving a simple explanation of the operational characteristics of the ADS
and ADS features”.
This section should include:
(a) The fields of application and the domain of operation including limitations and restrictions to
the use of the ADS.
(b) General description of the ADS in terms of functions, hardware and software.
(c) The “interaction concept with vehicle occupants, the on board operator (if applicable) and the
remote intervention operator (if applicable)”, as set out in Paragraph 3.2.2.5.
(d) “The means to activate or deactivate the ADS by the on-board operator (if relevant) or the
remote intervention operator (if relevant), vehicle occupants (if relevant) or other road users
(if relevant)”, as set out in Paragraph 3.2.2.6.
(e) The “operational measures (e.g. on-board operator or remote intervention operator needed)
to be met to ensure safety during the fully automated vehicle operation”, as set out in
Paragraph 3.2.2.7.
(f) The “backend, off-board infrastructure needed to ensure safety during the fully automated
vehicle operation”, as set out in Paragraph 3.2.2.8.
This section should also report the certifications adopted or applied for systems, sub-systems and
components included in the vehicles. Those already approved in different vehicles should also be identified.
17.1.1. Operational Design Domain / Boundary Conditions

27

The description of the ODD and its boundary conditions is required to comply with Annex III, Part 2, Paragraph
3.2.2.1. The description provided should include all the information relevant to its unambiguous definition,
namely all the relevant elements must be defined, described and quantified. References for the description of
ODD can be found in Appendix 1 and partly in Appendix 2.
Whatever is not reported in the description of the ODD should be considered outside the ODD, and not
relevant to its determination. Note that the type-approval authority might request additional information on
any element not mentioned or quantified.
17.1.2. Basic Performance
As set out in Annex III, Part 2, Paragraph 3.2.2.2, this section describes the response of the ADS in terms of its
behaviour and expected performances in all the possible conditions (e.g. OEDR, planning, etc.) falling within
the ODD defined in §17.1.1, for both normal and emergency operation, including the description of the
“interaction with other road users” (Paragraph 3.2.2.3).
The definition of the main triggering “conditions for minimal risk manoeuvres” (Paragraph 3.2.2.4) should be
included as well.
This section includes the description of the ADS behaviour in the conditions defined above, including a general
description of each element and logic defining the process that determines the ADS performance.
The performance of the ADS when dealing with defined unexpected conditions (i.e., conditions that are unlikely
to occur although reasonably foreseeable, but that have been used as “stress-cases” to define ADS
performance) should be also included. A list and description of those defined unexpected conditions should be
provided. The selection of such conditions can be based on the estimated frequency of occurrence, or on
analogous analysis for similar systems, or on engineering expert judgment. In that sense, a link between
frequency of exposure and severity may help in the determination and classification of such unexpected
conditions. Those unexpected conditions may even fall outside the ODD conditions or beyond the legislative
requirements (e.g., recognition of an airplane landing on the highway).
Finally, a categorisation of the logic and related performances can be also included. As an example, they can
be subdivided as follows:
1.

Detective: related to identify the cause or symptoms of an event.

2.

Preventive: to prevent a negative event from occurring.

3.

Corrective: when a modification of the response of the ADS is necessary.

It is important to provide an exhaustive description of the performances of the ADS under all reasonably
foreseeable conditions. What is explicitly excluded or not described should be considered as beyond the
capabilities of the ADS.
17.2.

Description of the functions of the ADS

This section should describe the ADS functions and logics adopted, namely, the logical processes connecting
conditions (§17.1.1) to performances (§17.1.2). The descriptions are not intended to enter the detail of the
hardware adopted, which is the subject of §17.3, while the integration between hardware and logic is the
subject of §17.4.
According to Annex III, Part 2, Paragraph 3.3, “description shall be provided giving an explanation of all the
functions including control strategies to ensure the robust and safe operation of the ADS and the methods
used to perform the dynamic driving tasks within the ODD, and the boundaries under which the automated
driving system is designed to operate, including a description on how this is ensured”. The provided description
shall include “any enabled or disabled automated driving functions for which the hardware and software are
present in the vehicle at the time of production” and “the data processing if continuous learning algorithms are
implemented”.
The functions implemented into the ADS must be described on a high level, including how they carry out
collection, analysis, synthesis, evaluation and decision making in both normal and emergency operations, as
well as all the logical processes covering the acquisition, treatment and interpretation of data, the elaboration
process including handling of contradictory information, and the definition of the actions to be performed. The
level of details provided should be consistent with the ones required by the following sub-sections. Exchange
of data between different functions should also be considered.

28

The description includes specification of “all input and sensed variables… and the working range of these
defined, along with a description of how each variable affects the ADS behaviour” (Paragraph 3.3.1), as well
as “all output variables that are controlled by the ADS”, together with “an explanation…of whether the control
is direct or via another vehicle system. The range over which the ADS is likely to exercise control on each such
variable shall be defined” (Paragraph 3.3.2).
As required by Paragraph 3.3.3, “limits defining the boundaries of functional operation including ODD-limits
shall be stated where appropriate”.
17.2.1. Main ADS Functions
This section describes the functional architecture and control strategies adopted by each function and by the
ADS to handle the different functions and the interfaces among them. Description of functional hierarchy and
decomposition of functions can be useful to give a more comprehensible insight.
Some relevant aspects to be addressed are:
(a) Logic for the decision to activate or deactivate functions during ADS operations
(b) Transitions between the various functions of the ADS
(c) Function modes, priorities and limitations, including MRM, EM and intervention request (if
applicable).
17.2.1.1. Vehicle-internal functions
Vehicle-internal functions are characterised by being fully on-board of the vehicle, namely input and output
data are all generated, collected and treated by on-board features. Those functions are independent from
external sources of data or external computational power, and all the necessary processes are performed
within the vehicle. However, interfaces with external systems can exist.
These functions are also related to the operational measures to be met (e.g. “on-board operator”, see
Paragraph 3.2.2.7) to ensure safety during the fully automated vehicle operation.
17.2.1.2. Vehicle-external functions
Vehicle-external functions (e.g., connectivity-related functions, remote intervention functions) are
characterised by not being fully on-board the vehicle. These functions usually concern information and/or
conditions not directly detectable, measurable or achievable by on-board features, and imply transfer of data
to and from external systems.
These functions are related to both infrastructures needed (e.g. “backend, off-board”, see Paragraph 3.2.2.8)
and operational measures to be met (e.g. “remote intervention operator”, see Paragraph 3.2.2.7) to ensure
safety during the fully automated vehicle operation.
The interfaces between the vehicle and the external functions should also be described in this section.
17.3.

Overview of the major components of the ADS

This section describes the units devoted to ADS technology. In this framework, hardware and software
important for driving but not related to the ADS tasks is not included (e.g., gear system, braking system,
propulsion system, steering system). These systems, although monitored and actuated by the ADS during the
DDT, are not specific features of the ADS. On the other hand, the actuators specifically used by the ADS to
perform actions on the above systems are part of the ADS and shall be included in the description.
As required by Paragraph 3.4.1, “a list shall be provided, collating all the units of the ADS and mentioning the
other vehicle systems as well as off-board hardware/software and remote capabilities that are needed to
achieve specified performance of the ADS to be approved according to its ODD”.
Moreover, “each unit shall be clearly and unambiguously identifiable (e.g. by marking for hardware, and by
marking or software output for software content) to provide corresponding hardware and documentation
association”, as stated in Paragraph 3.4.5.1; while Paragraph 3.4.5.3 affirms that “the identification defines
the hardware and software version and, where the latter changes such as to alter the function of the unit as
far as this Regulation is concerned, this identification shall also be changed”.
It is expected that the description can be general for units developed by third-parties, in which case the model
and the manufacturer shall be provided. The related specifications and certifications can be indicated and

29

made available to the type approval authority upon request. Whereas, as far as proprietary units are
concerned, it is expected that more details are provided and supported by specific documentation.
Whenever redundancy and/or diversity are implemented, they shall be declared; in this sense, indicating the
number of the elements involved could ease the clarity of the description.
The descriptions can be distributed in the following sub-sections, as appropriate.
17.3.1. Control units
This section describes the components of the control units, e.g. processors, wiring, memory banks, electronic
boards, wireless and net devices, cabling.
17.3.2. Sensors and installation of the sensors on the vehicle
This section describes the sensors, the sensed parameter, the generated signal, the sensor calibration,
reliability, working conditions, range of validity and its role in the ADS. Information concerning the possible
backup should also be included.
In order to comply with the requirements set out in Paragraph 3.4.6, “the manufacturer shall provide
information on the installation options for the individual components that comprise the sensing system. These
options shall include, but are not limited to, the location of the component in/on the vehicle, the material(s)
surrounding the component, the dimensioning and geometry of the material surrounding the component, and
the surface finish of the materials surrounding the component, once installed in the vehicle. The information
shall also include installation specifications that are critical to the ADS’s performance, e.g. tolerances on
installation angle”.
17.3.3. Actuators
This section describes the actuators, the functions connected with the actuators, the data/action accepted as
input and generated as output, the actuator calibration, reliability, working conditions, range of validity and its
role in the ADS. In addition, the information concerning the reliability of the actuators and possible backup
should also be included.
17.3.4. Maps and positioning
This section includes descriptions of the system adopted by the ADS to determine its position in terms of
standard references and in relation to the surrounding environment, e.g. Global Navigation Satellite System
(GNSS) to localise the exact position of the vehicle a place it within predetermined maps to allow proper
navigation.
17.3.5. Other hardware
This section includes descriptions of the transmission links used for conveying signals, operating data or
energy supply between inter-connected hardware described in the previous sections.
In case other hardware is present in the vehicle in addition to the ones described in the previous sections, it
should be described here. E.g.:
a) Hardware necessary for the connection with external infrastructures or external systems
(e.g., centralised systems for the automatic parking of the vehicle in dedicated/reserved
areas).
b)
17.4.

Special hardware to perform specific functions during maintenance.

ADS layout and schematics

The systems belonging to the ADS are represented in this section by schemes, namely layouts, flow charts,
Process Flow Diagrams, Process and Instrumentation Diagrams.
17.4.1. Schematic system layout
This section should graphically describe the ADS components and their connections; as required by Paragraph
3.4.1, “an outline schematic showing these units in combination, shall be provided with both the equipment
distribution and the interconnections made clear. This outline shall include:
a) Perception and objects/events detection including mapping and positioning.
b)

Characterisation of Decision-making.

30

c)

The ADS data elements.

d)

links and interface with other vehicle systems, off-board hardware/software and remote
capabilities.”

Moreover, Paragraph 3.4.2 requires that “the function of each unit of the ADS shall be outlined and the signals
linking it with other units or with other vehicle systems shall be shown. It shall include off-board systems
supporting the ADS and other vehicle systems. This may be provided by a labelled block diagram or other
schematic, or by a description aided by such a diagram”.
The diagrams presented in this section should clearly describe the main path of the input signals, the
elements and components handling and processing the signals as well as the generated output. The elements
and components should be identified by the reference ID used in §17.3, and the expected values of the
signals should be reported. Redundant and alternative paths of the signals and processes must be included in
the description. Both normal and emergency operations should be considered.
However, Paragraph 3.4.5.2 states that “where functions are combined within a single unit or indeed within a
single computer, but shown in multiple blocks in the block diagram for clarity and ease of explanation, only a
single hardware identification marking shall be used. The manufacturer shall, by the use of this identification,
affirm that the equipment supplied conforms to the corresponding document”.
17.4.2. List and schematic overview of interconnections
The interfaces and connections within the ADS are reported in this section “by a circuit diagram for the electric
transmission links, by a piping diagram for pneumatic or hydraulic transmission equipment and by a simplified
diagrammatic layout for mechanical linkages. The transmission links both to and from other systems shall
also be shown” (Paragraph 3.4.3).
The interfaces related to systems external to the vehicle are also included. In addition, this section should also
report the compatibility between interfacing systems, e.g. demonstrating that interfaces and interconnections
between systems do not interfere each-other and properly work in all the considered normal and emergency
operations.
As required by Paragraph 3.4.4, “there shall be a clear correspondence between transmission links and the
signals carried between units. Priorities of signals on multiplexed data paths shall be stated wherever priority
may be an issue affecting performance or safety”.
17.5.

Specifications

This section describes the responses obtained when the ADS functions are called to operate. The responses
must be based on a quantitative description of the behaviour of the ADS vehicle.
This section is focused on the designed behaviour of both the ADS and the vehicle. Therefore, it should include
the numerical values resulting from the output of the functions having a direct role in DDT. The numerical
values of parameters treated and elaborated in the processes internal to the functions or in functions not
directly affecting the final behaviour of the vehicle should be also documented if relevant for more complete
and comprehensive description.
The detailed specification descriptions have to be provided in sub-section §17.5.1 for normal operations and in
§17.5.2 for emergency operations, whereas §17.5.3 describes the acceptance criteria and §17.5.4 reports the
demonstration of compliance.
17.5.1. Specifications in normal operation
This section describes the specifications related to Normal Conditions.
17.5.2. Specifications in emergency operation
This section describes the specifications related to Emergency Conditions.
17.5.3. Acceptance criteria
This section describes the acceptance criteria related to the ADS specifications.
Reference could be made to relevant laws, regulations and norms and to other acceptance criteria, including
those established by the manufacturer, if relevant.
17.5.4. Demonstration of compliance

31

This section should demonstrate the fulfilment of the acceptance criteria mentioned in the previous section.
If no acceptance criteria are defined by law and the acceptance criteria are thus defined by the manufacturer,
a demonstration should be provided that the resulting numerical values are reasonable in terms of minimised
probability and extent of damage to vehicle (when relevant), passengers and other road users. In that case,
the type-approval authority could realize an evaluation of the process itself, which led to the acceptability
criteria.
17.6.

Safety concept

This section is dedicated to the safety objectives adopted by the manufacturer to ensure safe operation in
both normal and emergency operations. They act as the principles guiding the definition of the systems
details. The section should describe the approaches adopted to prevent and minimize the possible risks and to
handle them so as to minimise the consequences to vehicle occupants and other road users, as well as to
assure compliance with traffic rules.
The ADS systems, components and logics are designed to operate in both normal and emergency operations
within specific ranges of acceptability. A partial proof of safety is indirectly supported by the fulfilment of
defined acceptance criteria; however, the designed behaviour of the ADS vehicle must be actual and verified,
i.e., the ADS items and functions affecting safety must not only be designed meeting defined acceptability
criteria and included in the ADS, but their effectiveness when called to operate shall be assessed.
The approaches to ensure the designed behaviour of the ADS should be described. As an example, the
following general approaches can be used:
1.

Quality: of components, processes, manufacturing, supply-chain, etc. to ensure low failure rates.

2.

Redundancy: the most relevant functions/systems/components are provided with backups.

3.

Diversity: different systems performing the same action based on different physical phenomena.

17.6.1. Manufacturer Statement that the vehicle is free from unreasonable risks
This section should contain the statement that the manufacturer shall provide to comply with Paragraph
3.5.1, namely affirming “that the ADS is free from unreasonable risks for the vehicle occupants and other road
users”.
17.6.2. Outline of the software architecture
According to Paragraph 3.5.2, “the outline architecture” of the “software employed in the ADS” “shall be
explained and the design methods and tools used shall be identified”. This section provides graphical
descriptions (e.g. block diagram) of the software architecture, as well as identification of the methods and
tools used during the software design and development process.
This section should demonstrate consistency with the approaches defined above (and applicable to software),
with the target to prevent and minimize the probability of logic failure and to handle possible logic failures so
as to minimise the consequences to vehicle occupants and other road users, as well as to assure compliance
with traffic rules.
The identification of logic failure requires the implementation of algorithms performing the verification of
inputs and outputs, of the processes, and coherence checks to assure that the logic is working as intended.
These algorithms are typically constituted by high-level routines capable to identify and localise abnormal
situations, and to implement parallel and independent systems/routines to check and possibly to correct
errors. The description of such routines, algorithms and specific systems should be also included in this
section.
17.6.3. Means by which the realization of ADS logic is determined
As set out in Paragraph 3.5.2, in this section “the manufacturer shall show evidence of the means by which
they determined the realisation of the ADS logic, during the design and development process”.
17.6.4. General explanation of the main design provisions built into the ADS so as to generate safe operation
under fault conditions, under operational disturbances and the occurrence of conditions that would exceed the
ODD
As required by Paragraph 3.5.3, “the manufacturer shall provide the type-approval authority with an
explanation of the design provisions built into the ADS so as to ensure functional and operational safety.
Possible design provisions in the ADS are for example:

32

(a) fall-back to operation using a partial system.
(b) redundancy with a separate system.
(c) diversity of systems performing the same function.
(d) removal or limitation of the automated driving function(s).”
As required by Paragraph 3.5.4, “the manufacturer shall also provide the type-approval authority with an
explanation of the operational safety measures to be put in place for the safe operation of the ADS such as
an on-board operator or a remote intervention operator, supporting off-board infrastructure, transport and
physical infrastructure requirements, maintenance measures, etc.
This section describes also the main design provisions built into the ADS in order to ensure its safe operation
and interaction with other road users under fault conditions, under operational disturbances and under the
occurrence of planned and unplanned conditions that would lead to exceed the ODD boundaries.
The applicant should also describe the means for recognition of ODD boundaries the strategy implemented to
define and handle ADS behaviour when the limits of the ODD are approached.
The means to check the current operational status of the ADS are also part of this section. A set of high-level
functions is necessary to check and evaluate the efficiency of the ADS and its systems. These functions
continuously perform cross-checks and compare selected indicators of the ADS with reference values. If too
large discrepancies are revealed, then corrective actions are taken (e.g., actuation of alternative or back-up
systems).
The ADS behaviour should be described under expected and reasonable fault conditions, for which specific
design provisions could be implemented into the system.
A list of possible and reasonable fault conditions must be considered and justified, and the behaviour of the
ADS/vehicle should be described including the interaction with other road users. The consequence of such
conditions should be also evaluated.
17.6.5 General description of failure handling main principles, fall-back level strategy including risk
mitigation strategy (minimal risk manoeuvre)
This section should include the description of the failure handling main principles, the fall-back strategy and
the risk mitigation strategy, including the minimum risk manoeuvre.
17.6.6. Conditions for triggering a request to the on-board operator or the remote intervention operator
This section should describe how the request to the on-board operator or the remote intervention operator are
generated and managed (if applicable), namely:
a) Conditions that lead to generate the request for intervention.
b)

How the ADS generates the request to the operator.

c)

How the intervention is performed.

d)

Functions passing under the control of the operator.

e)

Confirmation of the release of the functions under the control of the operator.

f)

ADS limitation and intervention on the functions under the operator control.

g)

Functions remaining under the control of the ADS after successful intervention.

h)

ADS behaviour if the intervention is not succeeded or interrupted.

i)

Conditions for the return of functions under the ADS control.

j)

Signals given to the operator, occupants and other road users in each of the above phases.

k)

Means by which control and checks are executed in each of the above phases.

l)

Management and control of time constraints in all the phases above.

The applicant should also describe the methods and measures put in place in order to monitor and correctly
evaluate the operator status (if applicable).

33

17.6.7. Human machine interaction concept with vehicle occupants, on-board operator and remote
intervention operator including protection against simple unauthorised activation/operation and Interventions
As set out in Paragraph 3.3.4, this section describes the interface between the vehicle equipped with ADS
capabilities and the vehicle occupants (if relevant), on-board operator (if relevant) and remote intervention
operator (if relevant), hereinafter referred to as “Human Machine Interface” (HMI). The HMI concept “when
ODD limits are approached and then reached shall be explained. The explanation shall include the list of types
of situations in which the ADS will generate a support request to the on board operator/remote intervention
operator (if applicable), the way the request is performed, the procedure that handles a failed request and the
minimal risk manoeuvre. Signals and information given to the on-board operator/remote intervention operator,
vehicle occupants and other road users in each of the above aspects shall also be described”.
The applicant should describe the mechanisms put in place to inform the operator and vehicle occupant (when
relevant) about the ADS status and their responsibilities in an understandable and unambiguous way. This
section should also report on how the HMI communicates every ADS state, modes of operation, possible
limitations, as well as any additional information relevant to the operator and vehicle occupant. At a
minimum, the description should address how HMI is capable of informing the operator and vehicle occupant
(when relevant) that the ADS:
a) is functioning properly,
b)

is currently engaged,

c)

is currently unavailable,

d)

is experiencing a malfunction,

e)

is requesting an intervention request to the operator.

The applicant should describe the methods adopted to design an HMI that is comprehensible, easy, nondistracting, safe to use, and possibly promoting social inclusion. Reference to relevant guidance, best
practices, industry standards and well-established design principles is also possible (e.g., ISO 9241
“Ergonomics of human system interaction”).
The applicant should also provide descriptions, models, schemes and graphical representations of the
information provided to the operator in every mode of operation; namely: Normal operation, intervention
request (if applicable), approaching ODD boundaries, emergency operation, emergency manoeuvre, incidental
conditions, etc.
This section should also describe the measures adopted to protect against simple unauthorised
activation/operation and interventions, and to prevent the attempt to force the ADS to operate in not allowed
conditions and modify the manufacturer’s conditions.
17.7.
Verification and validation by the manufacturer of the performance requirements including the OEDR,
the HMI, the respect of traffic rules and the conclusion that the system is designed in such a way that it is free
from unreasonable risks for vehicle occupants and other road users
The manufacturer must describe the methodologies used to prove the safety of the ADS vehicle. Both testing,
verification and validation techniques are included.
The description of HMI testing (if relevant), verification and validation processes (e.g., empirical studies,
simulations, test drives, road testing) should also be included in this section.
The means implemented to protect against simple unauthorised activation/operation and interventions into
the ADS should also be verified and validated and described in this section.
The Simulation Handbook has to be provided as annex to the information document.
17.7.1. Description of the adopted approach
This section should describe the approaches adopted by the manufacturer to perform the various steps of the
verification and validation activities. The adopted approach is defined by considered objectives, data,
variables, measurements, and result expected.
17.7.2. Selection of nominal, critical and failure scenarios
This section should include the list of nominal, critical and failure scenarios, as well as the method used to
define such list.

34

According to the Regulation provisions in Annex III, Part 1, the list shall include the “minimum set of traffic
scenarios” defined in Paragraph 1. Such scenarios shall be used if relevant for the specific ODD of the specific
ADS. As an example, in case of automated valet parking not every scenario included into the minimum set is
applicable.
Each scenario included into the minimum set is characterized by a set of safety requirements and defined
parameters. When appropriate, the manufacturer can deviate from the parameters proposed in the
Regulation, provided that it can “demonstrate that the fully automated vehicle is free of unreasonable safety
risks”. “The safety performance metrics and inherent assumptions used by the manufacturer shall be
documented” (Paragraph 1.1) and reported in this section. Adopting the same example as above, in case of
automated valet parking the parameters may be adapted to take into account specific ODD and ADS
conditions such as limited driving speed and lack of visibility.
In addition, the manufacturer shall enrich the list with scenarios “generated to cover reasonably foreseeable
critical situations, including failures and traffic hazards within the operational design domain” (Paragraph 2.1);
and, if remote intervention/capabilities are envisaged, those scenarios “shall include failures and traffic
hazards stemming from the corresponding remote capabilities” (Paragraph 2.2).
The method used to generate those additional scenarios “shall be documented” (Paragraph 2.4) in this section,
and “shall follow the principles set in” Annex III, Part 1, Appendix 1 (Paragraph 2.3), that defines principles to
be followed to derive scenarios relevant for the specific ODD of the specific ADS. The adopted method should
allow to avoid duplication of scenarios, and to define scenarios that possibly envelope entire set of scenarios
so as to simplify the following analysis. The method should also allow for the demonstration of completeness
of the list of scenarios proposed, to be also documented in this section.
References for the methods to generate, feed and enrich the set of scenario can be found in Appendix 2.
17.7.3. Description of the used methods and tools (software, laboratory, others) and summary of the
credibility assessment
In this section the process and tools to perform the safety assessment are described. Validation of the
trustworthiness and reliability of information and methods are described. Accuracy assessment of input data
is also part of the content of this section.
17.7.4. Description of the results
Different methodologies for safety assessment are generally based on different procedures and data. As a
consequence, the output data can be different for different methodologies. In this section the description of
the output data is presented. The relative relevance/limitation of the output parameters is indicated. Units and
range of the meaning are also reported in this section.
17.7.5. Uncertainty of the results
Any methodology implies some approximation that is reflected in the uncertainty of the results. An estimation
of the uncertainty is typically performed. The approach used to estimate uncertainty and the resulting
uncertainty values of the output parameters are documented in this section
17.7.6. Interpretation of the results
The meaning and relevance of the result obtained by the application of the chosen methodology need to be
considered and evaluated within the wide framework of the assessment process. In this section the relevance
between the results and specific objective are described. Interpretation of the results can also include the
identification of patterns and trends.
17.7.7. Manufacturer’s declaration (same as 17.6.1)
This section should contain the statement that the manufacturer shall provide to comply with Paragraph
3.5.1, namely affirming “that the ADS is free from unreasonable risks for the vehicle occupants and other
road users”.
17.8.

ADS data elements

Learning from in-use data is a central component to the safety potential of ADS: lessons learned from a crash
involving a single ADS could lead to safety developments and subsequent corrective actions that can lead to
prevention of that crash scenario in other ADS. Also the analysis of crash avoidance data can lead to effective
safety improvements of ADS. On the other side, in order to identify legal liability in case of crash or traffic

35

rules infringement, the responsibility for the control of the DDT between the ADS, on-board or remote
intervention operator or human driver (where relevant) should be uniquely identified at every moment.
In this section, the applicant should provide evidence of the methods and means used to fulfil the legislative
requirements related to the aspects described above, through the implementation of the Event Data Recorder
(EDR) and Data Storage System for Automated Driving (DSSAD) on-board the vehicle.
References for this paragraph is provided in Appendix 6 - Technical Guidance on In-service Reporting.
17.8.1. Type of data stored
For each data element recorded, the time-history data and format should be described, including information
on the filtering process – if applicable – performed either during the recording phase or during the data
downloading phase.
17.8.2. Storage location
The storage location should be described, be it on-board the vehicle or through cloud connectivity to a remote
server, including system storage capabilities, capability to record data during a crash event (e.g., providing
information on resistance to high decelerations and mechanical stress of a severe impact), data survivability
after a crash event, trigger condition to initiate the data storage (if applicable) and means to prevent possible
malfunctions.
17.8.3. Recorded occurrences and data elements
The applicant should provide details about all the data elements recorded during the vehicle operation,
whether on a mandatory or voluntary basis, together with information on the recording interval time, data
sample rate, minimum range, accuracy and resolution. The purpose of the data element collected should also
be clarified, be it to satisfy legislative mandatory requirements, voluntary requirements or as source of
additional information. Distinction should also be made betwee

[The evaluation harness truncated this reference: showing the first 120000 of 244940 characters.]
</reference>

<statements>
1. Regulators should require clear HMI status, takeover timing, operational-domain enforcement, and accessible event data.
2. The JRC commentary on the EU ADS type-approval regulation states that the document supports interpretation but does not introduce new legal requirements, and that the regulation itself is binding
3. The JRC commentary on the EU ADS type-approval regulation states that the document supports interpretation but does not introduce new legal requirements, and that the regulation itself is binding. It describes the manufacturer’s declaration that the ADS is free from unreasonable risks for occupants and other road users, the need for HMI mechanisms to inform operators and occupants about ADS status and their responsibilities, and continuous manufacturer responsibility for safety and compliance throughout the ADS lifetime
4. The JRC commentary on the EU ADS type-approval regulation states that the document supports interpretation but does not introduce new legal requirements, and that the regulation itself is binding. It describes the manufacturer’s declaration that the ADS is free from unreasonable risks for occupants and other road users, the need for HMI mechanisms to inform operators and occupants about ADS status and their responsibilities, and continuous manufacturer responsibility for safety and compliance throughout the ADS lifetime. It also states that in-service reporting is intended to confirm safety performance and identify improvements, not to attribute blame or liability
5. The boundary between driver fault and manufacturer responsibility is drawn through naming, human-machine interface design, warning adequacy, operational-domain enforcement, and event data, each of which appears in technical standards, regulator guidance, litigation records, and statutory data rules
6. For Level 3 systems, HMI design is central to the boundary between human and machine responsibility, and JRC type-approval guidance says the applicant should describe mechanisms that inform the operator and occupants about ADS status and their responsibilities
7. The JRC commentary says the applicant should describe mechanisms to inform the operator and occupants about ADS status and their responsibilities in an understandable and unambiguous way, and at minimum the HMI should inform the operator that the ADS is functioning properly, currently engaged, currently unavailable, experiencing a malfunction, or requesting intervention
8. The JRC commentary says the applicant should describe mechanisms to inform the operator and occupants about ADS status and their responsibilities in an understandable and unambiguous way, and at minimum the HMI should inform the operator that the ADS is functioning properly, currently engaged, currently unavailable, experiencing a malfunction, or requesting intervention. That supports a regulatory recommendation: the HMI should not merely indicate that automation is available; it should state whose responsibility is active, what the system can and cannot do, and what the human must do on takeover
9. The JRC commentary says in-service reporting is for safety confirmation and improvement, not blame, although the same data can still be relevant to civil claims.
10. HMI status, in-service reporting, and analogous data-recording rules
11. Regulators should require that marketing, owner manuals, HMI displays, and dealer communications state the actual dynamic-driving-task delegation: whether the system is Level 2, Level 3, or higher; whether the driver must monitor the road; whether hands-on or eyes-on is required; what the operational design domain is; and what happens on takeover failure.
12. A safer rule would require a minimum takeover window, explicit HMI communication of remaining time, and a certified minimal-risk maneuver if the human does not respond, as in the Mercedes fallback description
13. The JRC commentary says in-service reporting is for safety improvement, not blame
14. The JRC commentary states that type-approval acceptance implies residual risk is acceptable for entry into service, but also that compliance extends throughout the ADS lifetime and remains the manufacturer’s responsibility
15. It notes that accident data can be biased, that validation cannot guarantee fidelity over unlimited parameter spaces, and that national authorities should provide additional ODD traffic data
16. Regulators should require post-market reporting, safety-critical occurrence notification, annual performance reports, and corrective-action transparency, while making clear that approval does not automatically defeat a defect or negligence claim
</statements>

Begin the assessment now. Output only the JSON list, without any conversational text or explanations.