Our goal is to develop a A public specification, which has been developed by experts in a defined consensus-driven development process and was released by officials that represent a significant share of the industry for which it is targeted, giving the specification the necessary legitimacy to be called a 'Standard'.Standard that is widely used and adopted. For that reason, we are asking for support from all potiantial future users of ASAM OpenODD and collect your feedback, ideas and further requirements.
About ASAM OpenODD
Defining the Operational Design Domain for Automated Vehicles
ASAM OpenODD (Operational Design Domain) is still a very young standardization initiative within the ASAM Is the process of imitation of the behavior of a modeled real-world system over time.Simulation domain. ASAM has started a concept project in Sep 2020, to create the base concept for a future ASAM OpenODD A public specification, which has been developed by experts in a defined consensus-driven development process and was released by officials that represent a significant share of the industry for which it is targeted, giving the specification the necessary legitimacy to be called a 'Standard'.Standard. The aim is to provide a format that is capable of representing a defined Operational Design Domain for connected automated vehicles (CAV).
An Operational Design Domain Definition (ODD) should be valid throughout the entire operating life of a vehicle and is part of its safety and operational concept. The ODD is used for the functional A document, which describes in detail the interfaces and behavior of a technical system for the purpose of implementing, integrating and operating the system.Specification of connected automated vehicles. It specifies what environment parameters (static and dynamic) the CAV must be able to manage. They include all types of traffic participants, the weather conditions, the infrastructure, the location, the time of day and everything else that can have an impact on the driving situation.
To give an example: Looking at the picture of a country road, an ODD would define the following parameters as suitable for the vehicle:
• Paved road
• Right hand traffic
• Country road
• No visibility limitation due to weather or time of day
• Expect all possible traffic participants
• Expect animals
• …
But there will be many more attributes in the ODD to describe this road and the environmental conditions.
The goal of the ASAM OpenODD project is to create a machine-interpretable format to represent the ODD A document, which describes in detail the interfaces and behavior of a technical system for the purpose of implementing, integrating and operating the system.Specification. With this format an ODD description becomes exchangeable, comparable and processable. This new format will enable for example the following use case:
- A city defines an ODD for its inner city, using the ASAM OpenODD format. Now car manufactures can compare vehicle ODDs, defined in ASAM OpenODD, to their vehicle to find out if it is allowed to drive in this specific inner city. The advantage for homologation bodies will be that they can define ODDs against which they can check the vehicle’s ODD.
- A second use case which will support the development of ADAS and AD systems is the use of the ODD to define the testcases that are necessary to validate the vehicle. There can be obvious limitations e.g. if the vehicle is not capable of speeds above 50 km/h, therefore highway tests are not necessary. This application of an ODD will help to focus the limited validation resources on the really needed scenarios.
The ODD must be represented so it can easily be used for Is the process of imitation of the behavior of a modeled real-world system over time.Simulation and other machine processed environments. The content of ASAM OpenODD will be derived from an abstract „Vehicle ODD“, that provides the information in a usable manner. For the purpose of using an abstract vehicle ODD description (represented in ASAM OpenODD) for simulations and post-processing the format must fulfil the following requirements:
- searchability
- exchangeability
- extensibility
- machine readability
- measurability and verification
- human readability / constrained natural language
The concept project consists of five work packages targeting individual aspects of the A public specification, which has been developed by experts in a defined consensus-driven development process and was released by officials that represent a significant share of the industry for which it is targeted, giving the specification the necessary legitimacy to be called a 'Standard'.Standard:
- ATTRIBUTES: This work package aims to provide a base set of relevant attributes for the ASAM OpenODD format.
- SPECIFICATION: This work package is responsible for developing the semantics and syntax for the ASAM OpenODD description language, also enabling the use of different ontologies/taxonomies for the definition of ODDs.
- METRICS: This subgroup discusses the possibility of measurable metrics and what the ODD needs to be able to represent, so any application can perform analysis on the ODD.
- REPRESENTING UNCERTAINTY: This work package addresses the issue of representing uncertainty with the goal to enable the ODD format to handle rare events and misuse.
- USER GUIDE: The last work package will start formulating a user guide for the ODD format. The first draft of the user guide will be completed in the subsequent standardization project.
The ASAM OpenODD standardization initiative takes into account and aims to complement the activities of BSI (BSI PAS 1883 provides a taxonomy for ODD) and International Organization for StandardizationISO (International Organization for StandardizationISO 34503 uses the taxonomy to provide a high-level definition format for ODD). All three projects are in close contact to avoid contradictions.
Please send your feedback to
nicco.dillmann(at)asam.net