This document is the copyrighted property of ASAM e.V. In alteration to the regular license terms, ASAM allows unrestricted distribution of this standard. §2 (1) of ASAM’s regular license terms is therefore substituted by the following clause: "The licensor grants everyone a basic, non-exclusive and unlimited license to use the standard ASAM OpenODD".

1. Foreword

The Association for Standardization of Automation and Measuring Systems (ASAM) is a non-profit organization that promotes standardization for tool chains in automotive development and testing. Our members are international car manufacturers, suppliers, tool vendors, engineering service providers and research institutes. ASAM standards are developed in work groups, composed of experts from our member companies. Our standards enable easy exchange of data or tools within a tool chain. ASAM is the legal owner of these standards and responsible for their development, maintenance, distribution and marketing.

ASAM standards focus on defining data models, file formats, communication APIs, software component APIs, and communication protocols for the data exchange between research, development, and validation systems. ASAM standardization seeks to incorporate requirements from many different global viewpoints and produce an efficient interface.

2. Introduction

2.1. Overview

Safety is fundamental to the development of public trust and acceptance of Connected and Autonomous Vehicles (CAVs) and their on board Automated Driving Systems (ADSs) and to enable deployment of automated driving. Safety of CAVs has two aspects: safe design and safe use of the system. In order to ensure safe use of the system, it is important to convey the knowledge of the true capabilities and limitations of the ADSs to the users to prevent misuse of the systems.

In order to establish the true capabilities and limitations of an Automated Driving Systems (ADSs), we need to first define their Operational Design Domain. An ODD refers to the operating environment (road type, weather conditions, traffic conditions) in which a vehicle can drive safely. For example, for Low-Speed Automated Driving (LSAD) systems such as pods and shuttles, the ODD may include urban areas with predefined routes that include pedestrians and cyclists. On the other hand, for a motorway chauffeur system, an ODD may include a four-lane divided motorway and dry conditions only. The types of scenarios a vehicle may encounter will be a function of its defined ODD, making this fundamental to any safety evaluation and scenario identification.

- A more formal definition of ODD as defined by SAE J3016 (2018) states that "Operating conditions under which a given driving automation system or feature thereof is specifically 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". -

In order to enable stakeholders to share, compare and re-use ODD definitions, there is a need for standards to provide guidance to the stakeholders on both the attributes to be used for ODD definition and a format for defining the ODD using those attributes. BSI PAS 1883 (UK) provides a taxonomy for ODD. Additionally, ISO 34503 uses the taxonomy to provide a high-level definition format for ODD. While these standardization activities address the important needs of the industry, a gap still exists in the industry for an ODD definition format for simulation.

ASAM OpenODD is a representation of the abstract ODD specification in a more well-defined syntax and semantics which enables machines to interpret and perform the required analysis. Additionally, the ASAM OpenODD specification shall be measurable and verifiable for the attributes it specifies.

2.1.1. Motivation

An Operation Design Domain definition (ODD) shall be valid throughout the whole vehicle’s lifetime. The definition of an ODD is part of the safety concept of a vehicle. Depending on the current development step different information needs to be derived from such an overall ODD.

ASAM OpenODD focuses on a machine-readable format. The ODD must be represented so it can easily be used within simulation and other machine processed environments. The content of ASAM OpenODD will be derived from any abstract ODD, providing the information in a usable manner. For the purpose of using this ODD description for simulations and post-processing the format must fulfill the following requirements:

  • Searchable

  • Exchangeable

  • Extensible

  • Machine readable

  • Measurable and verifiable

  • Human readable

In the scenario based testing workflow ASAM OpenODD will play a very important role supporting the test description, defining the boundaries of what to test and achieving a good test coverage of the operational design domain and its borders.

An example view on a scenario base testing workflow


For more details on scenario based testing workflows, consult the Paper released by the ASAM Test Specification Study Group.

Using the ASAM OpenODD specification will ensure that it is possible to statistically quantify:

  1. exposure of certain attribute values of the ODD,

  2. the performance of an CAV and its systems against the ODD,

  3. the tightening or expansion of the ODD over time.

ASAM OpenODD will be compatible with the wider ASAM OpenX suite of standards (OpenDRIVE, OpenSCENARIO and OpenXOntology). Furthermore, ASAM OpenODD will be consistent with the ongoing ISO activities (e.g. AWI ISO 34503). Compatibility of ASAM OpenODD will be achieved during a harmonization phase before the beggining of the standardization project.

2.2. Normative and non-normative statements and deliverables

This specification uses a standard information structure. The following rules apply regarding normativity of sections:

  • Statements expressed as requirements, permissions, or prohibitions according to the use of modal verbs, as defined in Section Modal verbs, are normative.

  • UML diagrams from the ASAM OpenODD UML model are normative.

  • Rules for ASAM OpenODD data structures in "Rules" sections are normative.

  • XML examples and use case descriptions are non-normative.

2.3. Conventions

2.3.1. Units

Unless stated otherwise, all numeric values within this specification are in SI units, for example:

  • position/distance in [m]

  • angles in [rad]

  • time in [s]

  • speed in [m/s]

Geographic positions are stated in the unit defined by the spatial coordinate system, for example, in accordance with WGS 84 – EPSG 4326 [1].

Some data elements allow to explicitly state the unit of a given value. If the unit is not given or if there is no means to state the unit, SI units apply. The following units may be used in explicit assignments:

Table 1. Units
Category Description Identifier








land mile



meters per second


miles per hour


kilometers per hour





metric tons





These optional units shall be used for purposes of signage and speed indication only. They shall not be used as general units, for example, to define road geometry, etc.

2.3.2. Modal verbs

To ensure compliance with the ASAM OpenODD standard, users need to be able to distinguish between mandatory requirements, recommendations, permissions, as well as possibilities and capabilities.

The following rules for using modal verbs apply:

Table 2. Rules for using modal verbs
Provision Verbal form

Requirements shall be followed strictly in order to be conform to the standard. Deviations are not allowed.

shall not

Recommendations indicate that among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others.

should not

Permissions indicate a course of action permissible within the limits of ASAM OpenODD deliverables.

need not

Possibility and capability
These verbal forms are used for stating possibilities or capabilities, being technical, material, physical, or others.

can not

Obligation and necessity
These verbal forms are used to describe legal, organizational, or technical obligations and necessities that are not regulated or enforced by the ASAM OpenODD standard.

must not

2.4. Understanding ODDs

2.4.1. What is a ODD Specification?

An ODD defines the operating conditions an ADS is designed to operate in. This includes all ranges of roads, environmental conditions, part of the dynamic elements (mainly the ego designated speed) and types of traffic participants within a macroscopic traffic during all allowed weather conditions and time-of-day restrictions. The ODD will specify the domain and its borders the ADS is designed to safely operate in or needs to be capable of handling. This opens up a multidimensional space that needs to be specified.

According to SAE J3016 an ODD is defined as follows:

SAE J3016 (2021)
Operating conditions under which a given driving automation system or feature thereof is specifically 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.

2.4.2. Operational Domain (OD) vs. Operational Design Domain (ODD )

A specific type of terminology misuse in practice is failing to distinguish between the real world and the ODD.

  • "ODD" refers to the intended ADS capability to handle operating conditions, and not the real world.

  • "Operational Domain (OD)" refers to what the world actually is, which might (in most cases will) differ from the ODD.

Thus, when the real world (OD) is outside the intended operational design environment (ODD), the vehicle has exited the ODD and is no longer in an environment it was designed to operate within. The difference between OD and ODD highlights the limitations of the ADS. Additionally, an automated driving system feature can have only one ODD. However, a vehicle can have multiple automated driving system features. Thus it is incorrect to say, for example, that a Level 4 highway feature has "multiple ODDs of day and night with fair weather" when what should be said is that the feature has "an ODD that includes both day and night in fair weather."

In all practical cases, an ODD definition will not be exhaustive enough to cover all attributes or occurrences in an OD. Therefore, it is essential to be able to define an ODD which is not only objective but which defines clear boundaries to enable ADSs to perform fallback manoeuvres to ensure safe operation.

2.4.3. Difference between ODD and Scenario

It is important to highlight that while ODDs and scenarios are related, they are not the same. As mentioned earlier, an ODD essentially defines the operating environment for which a system is designed. It may also be seen from the perspective of the end-user (e.g. city council authority) as the operating environment in which a system should be able to operate safely. It is essential that there is an overlap between the two perspectives of the ODD, manufacturer (or the system designer) and the end-user for ensuring the safe deployment of CAVs.

A scenario defines the behavior of various actors and entities in an ODD. Below the difference between scenario and ODD is highlighted graphically. [fig-simple-odr-odd] depicts a part of an ODD with single lane non-divided road which has passenger cars. Simple scenario with passenger cars depicts a scenario which illustrates the behavior of the vehicles in the ODD of [fig-simple-odr-odd]. In summary, once the behavior of the actors is defined in a part of an ODD, it becomes a scenario. This has no influence on the fact that a scenario is a stand alone entity regardless of the ODD definition and therefore can be defined independently

Figure 1. Simple scenario with passenger cars
Figure 2. Example ODD for the domain

In Example ODD for the domain the graph on the left side represents the ontology or taxonomy the ODD specification can chose attributes from.

Figure 6a highlights the ODD attributes as per BSI PAS 1883. If an ADS has the ODD defined as Figure 6b, then the ODD comprises of a "divided single lane" road with a "T-junction" (scenery attributes of ODD). Furthermore, from the dynamic elements attributes, ODD comprises of "passenger cars". The difference between the ODD definition and the scenario definition is that the scenario definition also includes the behavior description of the actors, i.e. passenger cars.

2.4.4. The Scope and Usage of the ASAM OpenODD Language

Figure 3. ODD Definition and surrounding use cases

Being a language for defining or describing ODDs is the main purpose of the new ASAM OpenODD language, but obviously there are many more activities in the domain of automated driving system concept, design, analysis and validation that can profit from a formalized language for ODDs. The proposed ASAM OpenODD language has been designed with many of these use cases in mind, and in the present concept phase there is no reason to consider the list as final and exhaustive. Nevertheless, usability for many stakeholders, including persons who are not specialists for complex computer languages, is a key concern for ASAM OpenODD development and entails the need to keep the core language simple and not to overburden it with lots of complex language constructs just to cover each and every potential use case. The solution chosen consists of a core language that is sufficient for the primary purpose of ASAM OpenODD, which is to describe an ODD. Around this core language, many extensions are grouped as shown in the ODD Definition and surrounding use cases. Also this list does not have to be exhaustive, according to its requirements, the ASAM OpenODD language will be designed with extension mechanisms so that future extensions can still be added. As shown in the picture, even the core part of defining ODDs makes references to external work: the ontology, on which each ODD description is based, can and should be referenced from external sources (in particular OpenXOntology) and specified in their respective standardized language.

The use of all extensions (grouped around the core language in the figure) is optional, but prepared in the structure of the language (including the ability to create "bindings" of functions to 3rd party implemented functions in any language like Python or C). For the concept phase, the following list of extensions is proposed, which could technically be released as "standard libraries" such as the standard libraries of programming languages like C form a basic ecosystem, on which users of the core language can rely.

The following extensions are proposed:

TODO add that not all chapter’s are fully flushed out due to the missing working group

2.4.5. Completeness of an ODD

Since the information of the ODD is involved in the design, testing, release and so on, the completeness of the provided information becomes relevant. However, completeness should not be understood in an absolute sense, which means that no extra information can occur if a specific procedure is conducted. This is because of the open context, which makes it impossible to specify each and every aspect beforehand. Therefore, completeness is understood in a relative sense that requires us to define a reference against which the completeness of an ODD model can be measured. For the provision of such a reference, internal references as well as external sources can be used as a structure.

The completeness of the ODD results from the two aspects. This includes 1) completeness of the underlying ontology, and 2) completeness of the ODD description. To give a quick overview of the relation between the two, an ODD description language is a language format that has the capability of assigning the relevant ODD attributes to be either inside/outside its intended ODD boundary. However, these ODD attributes originate from an external taxonomy or ontology. Only by combining the ontology and an ODD description language can an ODD be produced. The BSI PAS 1883 on the taxonomy for the ODD of ADSs comments that from the perspective of the attributes/taxonomy, the ODD attributes list can never be exhaustive. This indicates that there is no 'complete' sense in terms of the underlying ontology that is used, which also resonates with one of the core language features that will be introduced in a later chapter (the extensibility of the underlying ontology). On the other hand, from the ODD language perspective, every piece of an ODD description must be complete, i.e, all the attributes from the underlying ontology need to be assigned and a binary (non fuzzy) boundary can be introduced across all the ODD attributes. To sum up, the underlying ontology can never be exhaustive, but the ODD description format needs to ensure every ODD is complete against the underlying ontology, and the permissive and restrictive concepts help to ensure completeness.

2.5. Use cases for ASAM OpenODD

In this chapter the use cases for the ASAM OpenODD are defined. In the development process the users of ASAM OpenODD were defined beforehand and the uses cases defined according to the users.

2.5.1. Users for ASAM OpenODD

Who will use and create the ODD and therefore use the OpenODD

2.5.2. User Stories

Development engineer

  1. as a development engineer, I need to understand the relevant parameters and their ranges that can occur during automated driving within the ODD and the scenarios the automated driving system might be confronted with, and be able to trace my requirements to this kind of input data.

  2. as a development engineer, I need clear criteria how to detect at runtime that I am unintentionally leaving the ODD so that I can implement detection and reaction functions for this case.

  3. as a development engineer, I need input (e.g. List) on foreseeable situations in the ODD to test my sensor setup and software algorithms appropriately before vehicle simulation and road testing even starts.

  4. as a development engineer, I desire a machine readable ODD description that support the systematic segmentation of the ODD in sub-areas where different capabilities of the AD system are needed or different grades of AD functions are safe to operate.

  5. as a development engineer I want to check tests, scenarios, recordings, etc. against the ODD description.

Test engineer

  1. as a test engineer, I would like to be able to declare an ODD to test against

  2. as a test engineer, I would like to know that a scenario that I have created is within the ODD

  3. as a test engineer, I would like to understand which element of my driving ontology/domain model is in or out of my ODD

  4. as a test engineer, I would like to know if the ODD that I have defined is well-formed and non-contradictory

the ODD is relevant for both the test track and the simulation

Data scientist

OpenODD Data Scientist Use-Cases, extending the ontology (i.e. need to support ontology by reference)

  1. as a data scientist, given a scenario library, I need to determine the parameter distribution, and coverage, so that I can assess the confidence in the results and deliver trust.

  2. as a data scientist, given a scenario library, I need to determine which aspects of the ODD are covered, so that I can assess which scenarios need to be added to support effective ODD testing.

  3. as a data scientist, given an ODD I need to determine whether a specific scenario is included in the ODD, so that I can determine whether it needs to be included in the assessment of results.

  4. as a data scientist, given an ODD, I need to determine the exposure to a specific scenario so that I can determine the weight/contribution of the scenario results in the overall assessment.

  5. as a data scientist, given two versions of the ODD I need to determine which scenarios were added or removed, so that I can determine how the analysis needs to be adapted.

  6. as a data scientist, given an ODD, I need to determine whether an occurrence is allowed by the ODD, so that I can determine whether the vehicle behaved as per the ODD specification.

  7. as a data scientist, given an ODD, I need to determine the exposure to a specific "occurrence" so that I can determine the weight/contribution of the behavior results in the overall assessment.

    • Test use-cases

Tool developer

  1. as a tool developer, I would like to have a common format that I can share to define an ODD.

  2. as a tool developer, I would like the ODD format to be formal enough that I can execute and process the containing information.

  3. as a tool developer, I would like to be able to substitute multiple driving ontologies and still use the same ODD Format.

  4. as a tool developer, I would like to test my test bench capabilities against the ODD, with the goal if the capabilities suite the ODD needs.

Scenario editor

  1. as a scenario editor, I want to create the scenarios for an ADS which are within the defined ODD of the ADS.

  2. as a scenario editor, I want to create scenarios to test the ODD attribute boundaries to test the fall-back or Minimal Risk Manoeuvre capability of the ADS.

  3. as a scenario editor, I want to create ​scenarios at different levels of abstraction.

Data annotation engineer

  1. as a label annotator I need to assemble a data library which is relevant to the ODD so the data (recordings, synthetic sensor data, etc) can be annotated accordingly

  2. as a label annotator I need to analyze data to identify ODD related situations and occurrences so that I can annotate them.

  3. as a label annotator I need to estimate the completeness of data to be annotated relative to the ODD so that users of the annotations can estimate achievable coverage.

  4. as a label annotator I need to estimate the coverage of annotations relative to the ODD so that users of the annotations can estimate coverage achieved.

Safety Engineer

  1. as a safety engineer I want to (semi-automatically) derive a situation catalog for Hazard Identification from the formal ODD definition.

  2. as a safety engineer I want to demonstrate the metrics of coverage of my considered scenarios w.r.t. the total ODD and estimate the remaining risk of hazardous scenarios within the ODD that were not covered by my safety concept and my validation approach.

  3. as a safety engineer I want to identify scenarios of unintentionally leaving the ODD from a formal definition of the limits of the ODD, in order to handle these situations using appropriate detection and reaction possibilities.

  4. as a safety engineer I want to get an understandable representation which partitions or sub-areas of the ODD exist, which failures or degradations could lead to hazards in each of them and grades of AD functions or which behaviors ensure acceptably safe operation in each of them.

Infrastructure operator (include regulators, authorities)

  1. as an infrastructure operator, I want to have easy access to ODD specifications in order to have a clear view on current and future demands on my road network

  2. as an infrastructure operator, I want to have the ability to warn vehicles in advance if they are about to chose a route through my road network which most likely is exceeding their ODD

  3. as an infrastructure operator, I want to give recommendations to automated vehicles which routes/roads/lanes to use depending on their ODD capabilities

  4. as an infrastructure operator, I want to have the ability to provide current ODD restrictions of parts of my network easily

  5. as an infrastructure operator, I want to be able to have a version controlled ODD Format

  6. as a regulator, I want to have a human-readable and exchangeable ODD format

  7. as a regulator, I want the ODD to be expandable when new regulations are introduced

3. Relations to other standards

Table 3. relations to ASAM Standards
Name of the Standard Description


Description and exchange format for scenario descriptions

ASAM OpenXOntology

defines an ontology (and set of attributes) for the ASAM OpenX Domain


defines a standardized format for multi-sensor data labelling and scenario tagging. The format is based on a JSON schema


standardized exchange format for the description of road-networks and the static entities on and along the road. ASAM OpenDRIVE is based on a xsd schema, using xml as an format


a binary format to define road elevation or friction profiles


allows to store information in a database context and exchange it between tools. Based on a standardized meta-model (the base model) application-domain specific data models (the application models) may be defined. This may lead to consistent data sets e.g. combining ODDs with scenario based test definitions and corresponding test results for evaluations and long term storage.

3.1. Positioning of ASAM OpenODD within ASAM activities