Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Formalization of Operational Domain and Operational Design Domain for Automated Vehicles

Ali Shakeri

TL;DR

The paper tackles ambiguity in defining the Operational Domain (OD) and Operational Design Domain (ODD) for automated vehicles, which is critical for safety. It introduces a formal OD/ODD framework based on Olderog's real-time formalism, defining OD as a Cartesian product of attribute domains and using Local Operational Domain (LOD) and Current Operational Domain (COD) to capture environment states at specific times and places. An explicit ODD specification grammar is presented, along with its semantics, enabling evaluation of whether a given COD satisfies the ODD, and laying the groundwork for ODD monitoring. The work clarifies OD–ODD relationships, discusses permissive assumptions for unknown attributes, and outlines future extensions such as richer statement types and measurement considerations, with practical implications for safety-critical AV development.

Abstract

Specifying an Operational Design Domain (ODD) is crucial for safeguarding automated vehicle systems against conditions that exceed their capabilities. Yet, prior definitions of ODD have relied on ambiguous and unclear terms, resulting in numerous misunderstandings and misconceptions. This paper introduces a formal approach to clearly define the Operational Domain (OD) and ODD for automated vehicles. Furthermore, the absence of essential terms, such as the OD, has resulted in the creation of numerous terms that have made things more complicated and confusing. This level of complexity is unacceptable when it comes to developing safety-critical systems, where any uncertainty can lead to significant risks. This study addresses these deficiencies by providing a precise mathematical model of OD and clarifying its relationship with other terms. Also, by formalizing these terms, this work establishes a foundation for developing further concepts such as ODD specification and ODD monitoring, which are explained in this paper.

Formalization of Operational Domain and Operational Design Domain for Automated Vehicles

TL;DR

The paper tackles ambiguity in defining the Operational Domain (OD) and Operational Design Domain (ODD) for automated vehicles, which is critical for safety. It introduces a formal OD/ODD framework based on Olderog's real-time formalism, defining OD as a Cartesian product of attribute domains and using Local Operational Domain (LOD) and Current Operational Domain (COD) to capture environment states at specific times and places. An explicit ODD specification grammar is presented, along with its semantics, enabling evaluation of whether a given COD satisfies the ODD, and laying the groundwork for ODD monitoring. The work clarifies OD–ODD relationships, discusses permissive assumptions for unknown attributes, and outlines future extensions such as richer statement types and measurement considerations, with practical implications for safety-critical AV development.

Abstract

Specifying an Operational Design Domain (ODD) is crucial for safeguarding automated vehicle systems against conditions that exceed their capabilities. Yet, prior definitions of ODD have relied on ambiguous and unclear terms, resulting in numerous misunderstandings and misconceptions. This paper introduces a formal approach to clearly define the Operational Domain (OD) and ODD for automated vehicles. Furthermore, the absence of essential terms, such as the OD, has resulted in the creation of numerous terms that have made things more complicated and confusing. This level of complexity is unacceptable when it comes to developing safety-critical systems, where any uncertainty can lead to significant risks. This study addresses these deficiencies by providing a precise mathematical model of OD and clarifying its relationship with other terms. Also, by formalizing these terms, this work establishes a foundation for developing further concepts such as ODD specification and ODD monitoring, which are explained in this paper.
Paper Structure (11 sections, 15 equations, 2 figures)

This paper contains 11 sections, 15 equations, 2 figures.

Table of Contents

  1. Introduction
  2. Related Work
  3. Terminology and Definitions
  4. Preliminaries
  5. Attributes
  6. Statements
  7. Operational Domain (OD)
  8. Operational Design Domain (ODD)
  9. Discussion
  10. Conclusion
  11. Acknowledgment

Figures (2)

  • Figure 1: This illustration depicts the relationship between different concepts used in this work. The Operational Domain is characterized by a Taxonomy such as ISO 34503 iso2023, which also classifies the Operational Domain attributes. An Operational Design Domain is a subset of the Operational Domain, specified by an ODD specification that is composed of a collection of Statements defined over attributes.
  • Figure 2: (a) shows a vehicle moving in a segment of a road while facing a pedestrian zone in front. A frame of reference $(X, Y)$ is attached to the vehicle and another frame of reference $(X^{\prime}, Y^{\prime})$ to the road. (b), (c) show two different interpretation of attribute $A_2$ representing the presence of a pedestrian at a certain location, labeled with $(x_o, y_o)$ coordinates denoted by a cross at sub-figure (a).

Theorems & Definitions (4)

  • Definition 3.1: operational domain
  • Definition 3.2: Operational Design Domain
  • Definition 3.3: ODD specification
  • Definition 7.1: ODD monitoring