ASAM OpenODD: Concept Paper

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:

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.

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

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.

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

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:

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.

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:

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:

A specific type of terminology misuse in practice is failing to distinguish between the real world and 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.

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

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.

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:

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.

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