Content uploaded by Léo Mendiboure
Author content
All content in this area was uploaded by Léo Mendiboure on Aug 15, 2023
Content may be subject to copyright.
Operational Design Domain for Automated Driving Systems:
Taxonomy Definition and Application
Leo Mendiboure (Member, IEEE) 1, Mohamed Lamine Benzagouta1, Dominique Gruyer 2, Tidiane Sylla1,
Morayo Adedjouma3, Abdelmename Hedhli1
Abstract—To allow the large-scale deployment of automated
and connected vehicles, their safety must be ensured. The
Operational Design Domain (ODD) aims to define under which
conditions an Automated Driving System (ADS) can operate
safely: speed, type of road, weather conditions, etc. Clearly
identifying the characteristics and boundaries of the ODD is an
important issue today for ADS. To this end, the design and use of
an ODD taxonomy seems to be a relevant approach considered by
both the industrial and academic worlds. Therefore, in this paper,
we propose an analysis and comparison of the main existing
taxonomies. We also define a new generic taxonomy, combining
the different approaches proposed in the literature, applicable to
both vehicles and road sections. Then, this taxonomy is applied
to a specific use case (Bus Station Automated Service). Finally,
we identify potential directions for an extended ODD taxonomy.
Index Terms—Automated Driving Systems, Operational Design
Domain, Taxonomy, Modeling, Implementation
I. INTRODUCTION
Automated Driving Systems (ADS) appear to be the future
in the road sector. Their operation is based on the integration of
several sensors in vehicles (Radar, Lidar, etc.) and the imple-
mentation of high performance systems (obstacle perception,
trajectory calculations, etc.) [1]. They could improve both road
safety, traffic fluidity, energy efficiency and productivity.
This will only be possible if the safety of ADS is ensured
[2]. The Operational Design Domain (ODD) is an important
concept in this context [3], [4]. The ODD can be defined
as the conditions under which a driving automation system
is designed to perform the Dynamic Driving Task (DDT).
A vehicle, depending on the type of service, its level of
automation (level 3 or level 4), or even on the types of sensors
it is equipped with, may be characterised by a larger or smaller
ODD: speed range, traffic conditions, weather conditions, etc.
Therefore, several projects are now focusing on the spec-
ification of the ODD for ADS [13]. A commonly used ap-
proach is to design an ODD taxonomy accurately defining
the conditions under which an ADS could operate [5]. ADS
manufacturers will require such a taxonomy to implement
safety requirements in the system’s design. It will also enable
This work has been carried out under the PRISSMA project. The project
addresses pillar 2 of the ”Great Challenge about AI” which aims to study the
safety, reliability, and possibly the certification of AI-based systems in the
context of automated mobility as an application field.
1Univ Gustave Eiffel, COSYS, ERENA, F-33067 Pessac, France
leo.mendiboure/ mohamed-lamine.benzagouta/
abdelmename.hedhli@univ-eiffel.fr
2Univ Gustave Eiffel, COSYS, PICS-L, 25 all´
ee des Marronniers, F-78000,
Versailles, France dominique.gruyer@univ-eiffel.fr
3Universit´
e Paris-Saclay, CEA List, F-91120, Palaiseau, France
morayo.adedjouma@cea.fr
TABLE I
SYNTHETIC COMPARISON OF EXISTING ODD TAXONOMIES
ODD Taxonomy Subject
Vehicle Connectivity Other
Users
Geo-Fenced
Areas
[5] Partial Yes Yes Yes
[6] No No No No
[7] No Yes Yes Yes
[3] Yes No No No
[8] No Yes No No
[9] No No Yes No
[10] No No No No
[11] No No No No
[12] Yes Yes No Yes
[13] No Yes Yes No
users, operators, and regulators to reference ODD attributes
and performance requirements in their procurement. Finally,
it could be helpful for ADS manufacturers, developers, and
suppliers of components and sub-components to define the
operating capability and assemble sets of evidence that will
improve confidence in the safety of the resulting product.
This is why, in this paper, we focus on ODD taxonomies.
Our objective is to explore the different existing solutions, to
build a new taxonomy and to study its potential applications.
The main contributions of this paper are:
•A comparison of existing ODD taxonomies for ADS;
•The definition of a new generic taxonomy integrating all
existing approaches and highlighting their advantages;
•The application of this taxonomy in a real use case;
•The identification of different directions for the applica-
tion of this ODD taxonomy for ADS safety.
The rest of the paper is organised as follows. In Section 2
state-of-the-art ODD taxonomies are presented and compared.
Section 3 introduces a new generic taxonomy. Then, Section 4
presents an application of the proposed taxonomy to a real use
case. Finally, Section 5 highlights different research directions
for work related to ADS safety and ODD taxonomies.
II. COMPARISON OF EXISTING ODD TAXONOMIES
Numerous ODD taxonomies have been proposed for ADS.
In this section, we chose to compare taxonomies with signifi-
cant differences. A first differentiating element between these
taxonomies is the entity that defined them. Four types of efforts
can be identified: 1) standards [5], 2) institutional works [6],
[7], 3) academic works [3], [8]–[12], and 4) Working Group
(WG) documents [13]. Note that some documents, especially
those produced by institutions, are used as a basis by both
research work and standardization bodies.
All these studies are based on the ODD definition introduced
by the Society of Automotive Engineers (SAE) [14]: ”operat-
ing conditions under which an ADS is designed to function,
including (but not limited to) environmental, geographical,
and time-of-day restrictions, and/or the requisite presence or
absence of certain traffic or roadway characteristics.” Thus,
proposed taxonomies include several common elements:
•Physical road infrastructure: Physical infrastructure status
information that could be useful for ADS, such as road-
way type (e.g., divided/undivided motorway), roadway
surface (e.g., asphalt), roadway edge (e.g., line mark-
ers), roadway geometry (e.g., width), junctions (e.g., sig-
nalized/unsignalized roundabout), temporary structures
(e.g., constructions), fixed surrounding structures (e.g.,
buildings), special structures (e.g., pedestrian crossing),
signage (e.g., traffic signs). Information related to the
scene (specific zones (e.g., school), region/states (e.g.,
speed), interference zones (e.g., tunnels)) could also be
included or separated into another category [12];
•Environmental conditions: Weather-related information
such as weather, particles (e.g., smoke), lighting (e.g., sun
elevation, brightness), temperature, and weather-induced
road conditions (e.g., slippery road). Weather conditions
can affect ADS functions in both perception and actuation
control. Visibility, sensor fidelity, and communication
systems are some examples of ADS functions;
•Traffic conditions: It includes information related to traf-
fic conditions such as traffic density (e.g. LOS AF [15]),
current speed limits, and road operations.
Besides these common features, some elements only appear
in some of these taxonomies:
•Subject vehicle: This idea is to include 1) the use of
specific, safe, predefined routes for the vehicle and 2)
theoretical or measured vehicle capabilities (vehicle speed
range, maximum load supported, minimum tire inflation,
etc.). The inclusion of the vehicle in the ODD taxonomy
could enable a more specific application of the ODD;
•Connectivity: This refers to the ability of a vehicle to
exchange with its environment through different Radio
Access Technologies (5G, ITS-G5) to receive informa-
tion regarding traffic density, remote fleet management
systems, GPS [13];
•Other users: These ”other users” are usually classified
into two categories: road users (e.g., vehicles, pedestrians)
and non-road users (e.g., animals) [7]. Taking these
entities into account could be used to assess the ability
of a vehicle to operate in their presence ;
•Geo-fenced areas: In the automotive space, some manu-
facturers, such as Ford and Lyft, have limited the road
networks to automation eligible routes. The main chal-
lenge is that unforeseen factors in the scene, situation,
and environment can never be entirely excluded. Such an
idea has been proposed in [5] for example.
III. A NE W GEN ER IC ODD TAXONOMY
A quick overview of the elements that are included in each
of the ODD taxonomies presented in Section 2 is provided
in Table 1. Different elements can be noted: 1) none of the
proposed taxonomies incorporate all seven identified elements,
2) some taxonomies ( [5], [12], [16]) contain the majority of all
the identified items (6/7), 3) each of the identified components
is at least included in two of the taxonomies.
That is why the proposed generic taxonomy includes all the
identified features. They are classified into six main categories,
as shown in Figure 1:
•Physical infrastructure: roadway type, roadway surface,
roadway edge, roadway geometry, junctions, temporary
structures, fixed surrounding structures, special structures,
signage);
•Scenery: specific zones, region/states, interference zones,
geo-fencing;
•Environmental conditions: precipitations, particulates, il-
lumination, temperature, weather-induced roadway con-
ditions (e.g., slippery road);
•Traffic conditions: traffic density, road users (type, speed),
road users’ behaviour (e.g., accidents);
•Digital infrastructure: type of information, radio access
technology (e.g., 5G cellular network);
•Vehicle capabilities: maximal/authorized speed, manoeu-
vres, vehicle dimensions.
IV. PRISSMA PRO JE CT: A PPLYING ODD TAXONOMY IN
TH E BUSAS US E CA SE
The French PRISSMA project aims to design and use
models, metrics, tools and facilities to build a generic frame-
work for evaluation and validation of systems involved in
the design of Automated Vehicles. In this framework, a
POC (Proof Of Concept) has been proposed: BuSAS (Bus
station automated service). BuSAS aims 1) to implement a
full Bus station automated service with some functionalities
requiring AI-based functions (for detection, identification, and
tracking of obstacles) both in real and virtual conditions, 2)
to propose a complete and generic simulation architecture to
test/evaluate/validate the full system, 3) to develop a generic
validation methodology with dedicated and representative met-
rics and 4) to implement on the real prototype and on the real
test track the same validation methodology.
Several requirements have to be tackled in this BuSAS
framework:
•The full mobility service needs to be designed, imple-
mented, and working in real/virtual conditions;
•ODD needs to be defined very accurately;
•The evaluation platform needs to involve the different
tools and models allowing to reproduce the full environ-
ment and the main important situation and conditions;
•The first and second level of evaluation needs to have an
access to ground truth;
•In the simulation step, the availability of a physical and
realistic digital twin is essential and probably mandatory.
Fig. 1. ODD Taxonomy Definition and Application
This POC clearly faces a strong challenge. For the first
requirement, we chose to design and implement in a real
prototype and in a virtual platform/environment a full Bus
station automated service. It is interesting to note that the
Bus station automated service will consider 6 different scenes
continuously on a trajectory covering 3.4 km on the Satory’s
test track with 4 or 5 bus stations. The environment will have
bends with very small radius of curvature and intersections
that may contain vehicles entering the main road and the ego-
vehicle traffic lane. Moreover, with an application of a strong
constraint on the ego-vehicle. It does not have the capability to
make lane changing and collision avoidance by lane changing.
The ego-vehicle will only keep the same lane during all the
evaluation and validation process.
To give an answer to the first requirement, the POC BuSAS
will be modelled by at least 6 possible scenes. The figure
2 represents the upstream and downstream scenes for the
docking at a bus station:
•The first scene corresponds to the nominal driving mode.
In this mode the shuttle or automated vehicle is driving on
the right lane with a max speed of up to 20 km/h. With a
moving vehicle in front, it will manage the inter-distance
and apply a car following manoeuvre;
•The second scene occurs when the distance between the
ego-vehicle and the bus station is lower than a threshold
(bus station identified by the perception system). In this
context, the vehicle will apply dedicated profiles both
longitudinal and lateral to reach the bus station with
constraints about ego-vehicle’s speed and lateral deviation
•The third scene concerns the stop period in the bus station
allowing passengers to get on and off;
•The fourth scene focuses on the restarting from the bus
station with dedicated longitudinal and lateral profiles
allowing to reach the centre on the right lane;
•The fifth scene is similar to the first one;
•The last scene concerns the reaction on a critical event
like an object stopped on the right lane or a cut in
manoeuvre of another vehicle. In this situation, the ego-
vehicle will have to apply either a braking for the inter
distance regulation, or an Emergency Braking allowing
to avoid or to mitigate the collision. In this scene, it is
possible to have a combination of elements building the
risk situation. For instance, dense fog or string rain could
reduce strongly the visibility distance and prohibit the
detection of an obstacle on the traffic lane.
Regarding the second requirement, an ODD has been de-
rived from the generic taxonomy (cf. Section 3) to fit not only
with the service deployed on the Satory’s test track but also
with the service developed in Paris. Figure 1 presents the ODD
taxonomy designed for this POC, the elements presented in red
corresponds to the elements that were considered in this use
case. The tested system in the framework of the POC BuSAS
could cover the following Operational Domain:
•Urban area;
•Narrowing/narrow roads;
•Ego speed range up to 20 kph:
•Fluid and congested traffic conditions;
•Roadway edges and markings;
•Signage: traffic signs/road markings/traffic lights in ur-
ban;
Fig. 2. Definition of the BuSAS use case with the 6 different addressed scenes
•Objects: mobile objects in urban (non-
classified/classified);
•Large/small static objects;
•All weather (i.e light/light and medium rain) and light
(daylight) conditions.
Nevertheless the ODD will be limited to the Satory’s test
track. Of course, in the simulation platform, features and furni-
ture will be added. It is important to highlight that in nominal
conditions, the test track is fully involved in the ODD of the
tested system. The following description (cf. figure 3) is an
adaptation of the ADS Tactical and Operational Manoeuvres
proposed by NHTSA and is apply to the taxonomy.
Regarding the ODD and its application to the considered
use case, a set of requirements has been identified:
•Requirement 1: Opening and closing of doors as well
as vehicle starting signalling (alert) are not considered;
•Requirement 2: Vehicle does not restart if an obstacle
(e.g. VRU) is present in its restart path;
•Requirement 3: The vehicle moves on the bus lane
(always the same lane);
•Requirement 4: No overtaking manoeuvre. The vehicle
always stays on the same lane (bus/bike lane). The vehicle
is using the far right lane;
•Requirement 5 : The road surface and road material
conditions are: asphalt, cobblestone, concrete. No snowy
surface. It is possible to consider the vibration of the
tires and the shock absorbers produced by the pavement
roughness (high frequencies). These vibrations have an
impact on both the vehicle and the sensor behaviour;
•Requirement 6 : The types of users that the vehicle
may encounter: car, bus, scooter, motorcycle, bicycle,
pedestrian, van (i.e. moving company, delivery);
•Requirement 7 : The vehicle does not change lanes. It
stays in its lane;
•Requirement 8 : The vehicle does not overtake an object
in its lane;
Fig. 3. ODD description and constraints for BuSAS POC
Fig. 4. Scenario description and execution for an Evaluation process of BuSAS
•Requirement 9 : The vehicle can not cross the speed
limit fixed to 20km/h;
•Requirement 10 : The vehicle can move backward
(reversing speed);
•Requirement 11 : The vehicle in nominal mode cannot
apply accelerations of more than 3m/s2and decelerations
of more than 3m/s2;
•Requirement 12 : In critical situation (T T C <= 1s),
the vehicle must apply an emergency braking (1G:
9.81m/s2).
The full evaluation process is presented in the figure 4 and
is composed of 3 main stages. The first stage involving the
ODD allows to describe, to define, and to generate scenarios
including the system under test and the full application with
specific scenes and events. The second stage concerns the
execution of the defined scenarios. The last stage is dedicated
to the evaluation and validation process. A parallel process is
applied in the 3 stages in order to generated the references
and ground truths needed for the evaluation stage.
V. DISCUSSION AND PERSPECTIVES FOR AN EXTENDED
ODD TAXONOMY
In this section we present three future areas of applications
that could be considered for ODD taxonomies.
A. Lightweight and embeddable ODD structure
ODD taxonomy application generally consists in breaking
it down into a set of scenarios that could be used with two
main objectives: 1) to define assessment scenarios for ADSs
to verify that they are able to operate in the associated ODD
and 2) the verification, in real life, of the ADS’s compliance
with its ODD by comparing the current situation to a set of
pre-defined scenarios based on the taxonomy. Works related to
this subject directly apply the taxonomy to define a maximum
number of scenarios that define the boundaries of an ADS’s
ODD [17]. Some other studies such as [18] aim to optimize the
number of pre-defined scenarios. According to them, defining
the ODD at the vehicle level as an unlimited set of use cases
is not realistic. Since the objective is to verify in real time
that the vehicle is within its ODD, the ODD must be defined
minimally at the vehicle level (embeddable ODD structure).
Therefore, they proposed methods to define a minimum set of
use cases that could be used to describe all the scenarios that
the vehicle ODD addresses. However, the research is still in
its infancy and much work remains to be done in this area.
B. Multi-Layer/Hierarchical ODD Definition
When an ADS exceeds its ODD limits, i.e., goes outside a
safe zone, the response is currently a return to control by the
driver (MRM, TOC). Alternative solutions using new terms
such as Restricted Operational Domain (ROD) or Degraded
Operation Mode (DOM) are now proposed [16]: exiting from
the ODD limits could involve a restricted redefinition of the
ODD and not a TOC. The idea could thus be to define
multi-layered or hierarchical ODDs and to select the most
appropriate ODD for the actual conditions. Mechanisms to
select the most appropriate ODD for the actual conditions
have already been proposed [19], as well as solutions to
redefine the limits of the ODD according to the capacity of the
sensors in case of bad weather conditions or a sensor failure.
Communications and infrastructure could play a key role in
this process. Indeed, Infrastructure Support for Automated
Driving (ISAD) is nowadays an essential element to determine
the level of adaptation of a Physical and Digital Infrastructure
(PDI) to ADS. Studies are beginning to measure the impact
that this connected infrastructure could have on ADS systems
and to assess the capacity of these PDI to maintain ADS in
its ODD, even under critical conditions (e.g., weather). Many
issues still need to be addressed in this area.
C. Towards Operational Road Sections
An important objective today for road operators is to
determine, for a given road section, its Level of Service for
Automated Driving (LOSAD) [20]. The idea is therefore to
determine the suitability of these sections for ADSs [21].
These LOSADs range from A (road segment compatible with
the vast majority of vehicle ODDs) to E (road segment presents
nearly null compatibility with most automation systems). Ar-
ticles are now beginning to introduce the idea of Operational
Road Sections [22]. The idea here is to determine for each
section its LOSAD and to do so, the ODD taxonomy could
play an essential role. Indeed, since the objective is to adapt
this infrastructure to the maximum number of ADS, it seems
relevant to use the definition of the vehicle’s ODD as a starting
point for defining the Operational Road Sections [23]. This is
why the ODD definition proposed in this article is meant to be
generic. This can be applied to both road sections and ADSs.
Thus, in a second step, it will be possible to compare these
two pieces of information to determine 1) if an ADS is able
to operate or not on a road section and 2) how to improve this
road section to meet the ODD of the ADS. Another major
issue for these Operational Road Sections is the cybersecurity
risk that could be associated with this area [24]. Indeed, this
could have a direct impact on the ODD of the ADS operating
in the area and more broadly on their safety. This is therefore a
significant risk to quantify and limit. The perspectives are thus
numerous for future work related Operational Road Sections.
VI. CONCLUSIONS
The definition of Automated Driving Systems’ Operational
Design Domain seems to be today an essential element to
guarantee their safety. To achieve this goal, the definition of
an ODD taxonomy is currently underway in the industry and
academic communities.
In this article we have identified the main similarities and
differences between the taxonomies proposed so far in the
literature, whether they were developed by standardisation
bodies, governmental institutions, research laboratories or
Working Groups. This allowed us to define a generic taxonomy
that includes all the elements currently mentioned in the
literature that appear to be relevant: Physical Infrastructure,
Scenery, Environmental Conditions, Traffic Conditions, Digital
Infrastructure and Vehicle Capabilities.
We have also applied the proposed taxonomy to a specific
use case to demonstrate the potential benefits of such an
approach: a Bus Station Automated Service. In the same way,
we highlighted some future directions that could be considered
for the application of this ODD taxonomy for ADS safety
and to extend ODD. In this context, additional work would
seem particularly relevant in relation to 1) the design of multi-
layered/hierarchical ODDs to adapt to real-time changes in
external or vehicle conditions, 2) the specification of Opera-
tional Road Sections based on a generic definition of ODD,
and 3) the use of the ODD taxonomy to design ADS evaluation
scenarios and a lightweight and embeddable ODD structure.
REFERENCES
[1] D. Gruyer, V. Magnier, K. Hamdi, L. Claussmann, O. Orfila, and
A. Rakotonirainy, “Perception, information processing and modeling:
Critical stages for autonomous driving applications,” Annual Reviews in
Control, vol. 44, pp. 323–341, 2017.
[2] M. Gyllenhammar, C. Bergenhem, and F. Warg, “Ads safety assurance–
future directions,” in CARS 2021: 6th International Workshop on Critical
Automotive Applications: Robustness & Safety, 2021.
[3] K. Czarnecki, “Operational world model ontology for automated driving
systems–part 2: Road users, animals, other obstacles, and environmental
conditions,”,” Waterloo Intelligent Systems Engineering Lab (WISE)
Report, University of Waterloo, 2018.
[4] T. Geißler and E. Shi, “Taxonomies of connected, cooperative and
automated mobility,” in 2022 IEEE Intelligent Vehicles Symposium (IV).
IEEE, 2022, pp. 1517–1524.
[5] B. PAS, “Operational design domain (odd) taxonomy for an automated
driving system,” Specification, standard by BSI Group, vol. 31, 2020.
[6] H. Kim, K. Lim, J. Kim, and W. Son, “Operational design domain for
testing of autonomous shuttle on arterial road,” The Journal of The Korea
Institute of Intelligent Transport Systems, vol. 19, no. 2, pp. 135–148,
2020.
[7] E. Thorn, S. C. Kimmel, M. Chaka, B. A. Hamilton et al., “A
framework for automated driving system testable cases and scenarios,”
United States. Department of Transportation. National Highway Traffic
Safety . . . , Tech. Rep., 2018.
[8] M. Scholtes, L. Westhofen, L. R. Turner, K. Lotto, M. Schuldes,
H. Weber, N. Wagener, C. Neurohr, M. H. Bollmann, F. K¨
ortke et al.,
“6-layer model for a structured description and categorization of urban
traffic and environment,” IEEE Access, vol. 9, pp. 59 131–59 147, 2021.
[9] G. Bagschik, T. Menzel, and M. Maurer, “Ontology based scene creation
for the development of automated vehicles,” in 2018 IEEE Intelligent
Vehicles Symposium (IV). IEEE, 2018, pp. 1813–1820.
[10] W. Chen and L. Kloul, “An ontology-based approach to generate
the advanced driver assistance use cases of highway traffic,” in 10th
International Joint Conference on Knowledge Discovery, Knowledge
Engineering and Knowledge Management., 2018.
[11] T. Griffon, J. Sauvaget, S. Geronimi, and R. Brouwer, “Description and
taxonomy of automated driving functions,” Deliverable D4, vol. 1, 2019.
[12] J. Vreeswijk, A. Wijbenga, and J. Schindler, “Cooperative automated
driving for managing transition areas and the operational design domain
(odd),” Proceedings of 8th Transport Research Arena TRA 2020, 2020.
[13] AVSC, “Best practice for designing an operational design domain:
conceptual framework and lexicon (avsc00002202004),” Proposed by
Automated Vehicle Safety Consortium (AVSC) (2020), 2020.
[14] SAE, “Taxonomy and definitions for terms related to driving automation
systems for on-road motor,” SAE J3016-202104, 2021.
[15] S. M. Khan, K. C. Dey, and M. Chowdhury, “Real-time traffic state
estimation with connected vehicles,” IEEE Transactions on Intelligent
Transportation Systems, vol. 18, no. 7, pp. 1687–1699, 2017.
[16] I. Colwell, B. Phan, S. Saleem, R. Salay, and K. Czarnecki, “An
automated vehicle safety concept based on runtime restriction of the
operational design domain,” in 2018 IEEE Intelligent Vehicles Sympo-
sium (IV). IEEE, 2018, pp. 1910–1917.
[17] M. Gyllenhammar, R. Johansson, F. Warg, D. Chen, H.-M. Heyn,
M. Sanfridson, J. S¨
oderberg, A. Thors´
en, and S. Ursing, “Towards an
operational design domain that supports the safety argumentation of an
automated driving system,” in 10th European Congress on Embedded
Real Time Systems (ERTS 2020), 2020.
[18] M. Khatun, M. Glaß, and R. Jung, “A systematic approach of reduced
scenario-based safety analysis for highly automated driving function.”
in VEHITS, 2021, pp. 301–308.
[19] A. Salvi, G. Weiss, M. Trapp, F. Oboril, and C. Buerkle, “Fuzzy
interpretation of operational design domains in autonomous driving,”
in 2022 IEEE Intelligent Vehicles Symposium (IV). IEEE, 2022, pp.
1261–1267.
[20] A. Garc´
ıa Garc´
ıa, F. J. Camacho-Torregrosa, D. Llopis-Castell´
o, and
J. F. Monserrat del R´
ıo, “Smart roads classification,” Routes-Roads, no.
391, pp. 23–27, 2021.
[21] C. W. Lee, N. Nayeer, D. E. Garcia, A. Agrawal, and B. Liu, “Identifying
the operational design domain for an automated driving system through
assessed risk,” in 2020 IEEE Intelligent Vehicles Symposium (IV). IEEE,
2020, pp. 1317–1322.
[22] A. Garcia and D. e. a. Llopis-Castell´
o, “From the vehicle-based concept
of operational design domain to the road-based concept of operational
road section,” Frontiers in Built Environment, 2022.
[23] O. Tengilimoglu, O. Carsten, and Z. Wadud, “Implications of automated
vehicles for physical road environment: A comprehensive review,”
Transportation research part E: logistics and transportation review, vol.
169, p. 102989, 2023.
[24] M. A. Cappelli, “A semantic-based artificial intelligence (ai) reasoning
tool to analyse the link between cyber security and safety for internet
of vehicle (iov) and autonomous vehicles (avs),” Ph.D. dissertation,
University of Geneva, 2022.
