Automotive Industry Insights

ASAM OpenODD

Description
In order to establish the true capabilities and limitations of automated driving systems (ADSs), we need to first define their operational design domain (ODD). 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 highway chauffeur system, an ODD may include a four-lane divided freeway 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) is as follows: “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 reuse ODD definitions, there is a need for standards to provide guidance to the stakeholders on both the attributes to be used for the definition of ODD 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 a definition of ODD adapted 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.

• ASAM OpenODD focuses on a machine-readable format that is:
• Searchable
• Exchangeable
• Extensible
• Machine-readable
• Measurable and verifiable
• Human-readable

Current role and relevance with regards to ADAS/AD
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.
It allows for the statistical quantification of:

1. exposure of certain attribute values of the ODD,
2. the performance of a CAV and its systems against the ODD,
3. the tightening or expansion of the ODD over time.

Status
The concept paper was released in November 2021, with a follow-up standardization project starting in March 2022.
View online

Potential implications of the Operational Design Domain and associated testing standards
The study group expects the need to quantify and use ODDs for testing in ADAS/AD to grow significantly over the coming decade, with the need for common ground through, for example, standards, growing proportionately.

The operational design domain is a term that has emerged recently out of the need to more stringently restrict or more clearly delineate the design domain for ADAS/AD functionality. In the past, formal ODDs played more of a minor role in testing, particularly outside the ADAS/AD domain. Their usage was limited to natural-language formulations for on-road testing, with verification or validation against these being limited to the undefined format.

The growing need to be able to specify operational design domain limits in a clear, exchangeable manner is a critical factor in the deployment of AD systems, whose ODDs will presumably increase as the industry advances. Being able to state these limits is, of course, just one facet. As of the authoring date of this report there is but one regulation for a Level 3+ AD system (UNECE 157 ALKS). As regulatory bodies continue making inroads into defining regulations for AD systems and the automotive industry with the development and testing of AD systems, the demand for structured methods and processes to verify against such specifications will soar. This is directly supported by new and upcoming standards such as OpenODD, which provides an underlying exchange format, as well as taxonomy-driven standards like BSI PAS 1883, ISO 34503, or ASAM OpenXOntology.

ODDs will be integrated into a majority of the steps across the testing workflow, from the initial system design and risk assessments to the test specification, where the expected operating limits of a function might be described by an abstract ODD, all the way to being the accompanying artifact for the test case and scenario definition process, with ever-increasing levels of concreteness in the ODD. Validation steps, such as checking scenarios and results against an ODD, will become an integral part of a testing workflow. Test results must begin including ODD criteria, including KPIs to measure degradation of the ODD.

Exactly how ODDs will be integrated into tests remains to be determined and will become clearer as the infrastructure and standards surrounding their definition evolves.