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

Modelling assumptions and principles for representing and using ODDs using OSC 2.0 language:

OpenSCENARIO 2.0 is an object oriented, aspect oriented, declarative, domain specific programming language. As such, it offers the full feature set of programming languages, in terms of operators, types and variables. It includes methods, structures, units, constraints specification and more. The examples are using OpenSCENARIO 2.0 syntax and constructs, with some assumption on a potential way to include and refer to ODD specification, in the same language in which scenarios are written, and using the same types, units and entities.

ODD definition:

We assume the full ODD ontology is defined in a type called ODD.

Sets of values are defined as enumerated types, for example:

The semantics of an ODD specification are defined as a mapping of all possible variable value assignments (continuous, integers, binary or enumerated type) to a True/False determination. Intuitively, it is equivalent to an SQL query selecting of all possible situations whereby the "WHERE" condition is provided by the ODD specifications: Situation returned by such query are included in the ODD; all other situations are excluded.

Each statement must start at a new line, but it may span multiple lines. When a statement spans multiple lines, the 2nd and subsequent lines must be indented. Each statement must start with one of the following keywords: INCLUDE, SUITABLE, UNSUITABLE, DETERMINE, ADDCOND,MEASURE. In addition, the TAG keyword can be used towards the end of certain station as a packaging mechanism to bundle a set of ODD attributes and form under a new ODD name. The keywords defined are not yet completed and need to be extended for cover all required functionalities. Each statement is associated with specific syntax rules:

For the example listed above, the MEASURE statement would be

+

During the runtime of the project the project group collected requirements, the requirements are clusters into categories. In total the categories are as follows

Requirement List

The link above leads to the extended list of requirements which form the foundation of future OpenODD language & format development work. Please note that within this list, project members have voted that requirements 60, 56a, 56b, 54, 62, 61, 37 will not be considered for the first draft of the OpenODD Format.

The Requirements are being clustered in the following clusters

The role of mandatory and optional attributes can be illustrated in combination of another key language feature (permissive/restrictive, which will be introduced in Permissive and restrictive definition). To briefly introduce, permissive means everything that is not explicitly describe in the ODD will be permitted, whereas restrictive corresponds to hte opposite. Now given the following ontology

If a blank ODD is defined in permissive mode, all the above attributes are allowed, if the blank ODD is defined in the mode restrictive, none of the above attributes would be allowed. This means that the only required attributes of an ODD defined using ASAM OpenODD are the global permissive/restrictive mode, and the reference to the underlying ontology. However, although not mandatory in nature, in some cases the attributes which can be associated with numerical values are also recommended to be specified. In the above example, the lane dimension is one such example. Let us imagine an ODD with such an ontology and a global permissive mode, this means the system can handle any lane dimensions that are listed in the ontology. While this could be true it is unlikely an ADS with a conventional vehicle size can handle extreme narrow lanes such as 1.50m.

ODD specifications are intended to be shared across wide range of stakeholders such as regulators and test engineers, it would be used as input to testing and analysis, but at the same time to be used by humans for purposes of specification, communications, analysis and debugging of systems under development. This requires ODD specification to be understandable to both technical and non-technical users. In the meantime, ODD specifications should enable machine readability for purposes such as runtime ODD coverage checking, comparisons between multiple ODDs. The language is intended to serve as input to computer programs, that should be able to parse, analyze , query and interpret the ODD information. In particular, query has been identified as an important requirement within the project group. Query could be performed between a traffic situation (corresponding to the concept of OD mentioned in the introduction) and the corresponding ODD specification utilizing an ontological approach.

Example use case:

An example ODD states that motorway is only suitable when there is no rain, up slope is not suitable as the vertical geometry.

Example representations:

The ASAM OpenODD language format should be composable, (i.e., combine ODD definitions into a new, wider one or use inheritance mechanism). In addition, the ability to re-use a defined section of an ODD should also be possible, by providing the ability to create a named subset of ODD attributes that can be defined together. Unions and intersections are examples of composing two ODDs, in addition the negation of ODDs can also be composed with other ODDs. When selecting subclasses from a parent class, the dot operator can be used such that if b is a sub-class of a, then a.b will point towards the b subclass, such convention can be seen in both syntax examples below. From a metric perspective, the language shall allow building new metrics out of existing metrics, functions and operators. This will be covered in the extensibility section.

The ability of being composable will also enable comparison of ODDs and identfiying contradicting specifications in the ODD. This can be very helpful when comparing a vehicle ODD to a City ODD, checking wether the car is able to operate safely in the streets of the city.

In the following abstract example the underlying meaning of of composing ODDs is illustrated. As can be seen that the first tree of attributes (first ODD) differs from the second tree, by composing these two together the third tree (ODD) is obtained, which is the union of the two. Please pay attention to the conditions that the speed for highway and for urban roads are separate (these are inherited from the individual ODDs and are not mixed during the composing process).

In the following abstract example the concept of comparing ODDs is illustrated. The mentioned "City ODD" can be seen as requirements towards the capability of the ADS. ADS ODD will be the designed capability of the vehicle. By comparing the two ODD specifications the suitability of the ADS towards the City requirements can be established.

Result:

The City ODD spedifies that any vehicle there (if going in automated mode) shall expect and be capable of handling other vehicles moving with up to 60kph while the ODD specification of the automated vehicle states under development states that its own maximum speed is 50kph. This alone is not a problem for operating the vehicle in the city (ego vehicle speed capability and traffic speed capability are two different things); it is sufficient that the vehicle can cope with traffic up to 60 kph, even if it cannot reach that speed itself.

Be aware that case would be different if there were constraints on the achievable speed of our vehicle, for instance related to a highway settings, where in some countries traffic regulations require that only motor vehicles with a nominal max speed of at least 60kph are allowed to be present; then, a vehicle with a technical max speed of only 50kph would be explicitly forbidden to enter that highway.

But there are more differences between our vehicle’s ODD and the city ODD:

As a result it can be concluded that the specified vehicle is not fully capable of operating in the given ODD of the city, and thus is not allowed to enter the city on automated driving (or, respectively, allow the human user to switch on the automated driving function while running in that city).

Note: In the section on queries there are more usage examples of such comparisons between a vehicle’s ODD and other ODDs, roadmaps or scenario sets.

Example use case: Compare and Combine

Given an ODD_1 which specifies that motorway is not suitable without restriction on the remaining classes on the ODD attribute hierarchy. Given another three ODDs (ODD_2, ODD_3, ODD_4) which specify wind conditions, rainfall condition and snowfall condition. The goal is to:

Example use case: selective combination

Import a sample ODD as ODD1 which constraints on both road type and weather. Import another ODD (ODD2), construct a new ODD (ODD3) that contains the weather part of ODD1 and the whole of ODD2.

Example syntax:

In order to enable flexibility in definition, flexibility in usage for testing as well as the ability to supply templates for ODDs, the language should enable a parametrization mechanism, where actual values are replaced by variable names, and are parameterized during actual usage time.

Example use case: Variable usage

Example on how to use variable top_speed_limit in ASAM OpenODD

Example syntax:

Example use case: Variable definition

Example on how to use variable rain of type enum in ASAM OpenODD, the actual value of the enumerations can be defined during usage

Example syntax:

Language specification needs to support conditional statement or reduced ODD. This can be tackled by imposing constraints on the full operational range of specific attributes.

When defining an ODD for a vehicle or a town, it might be necessary to define constraints according to certain conditions. This might be due to environmental conditions that degrade the capability of the vehicle or geographic specific conditions that have an impact on defined constraints.

Example use case: basic constraint definition

Examples showing how basic constraints are handled.

Example representations:

Example use case: add constraint definition

Adding constraint to an existing constraint

Example representations:

Example use case: Apply basic constraints

The velocity in which an ADS system is operating is defined to be between 0 and 80kph. However, in the case of the a heavy fog ( assuming heavy fog is well defined ) , the ADS system is constrained to operate in velocity range of 0 to 40kph.

Example representations:

Example use:

Given an ODD hierarchical tree, we would like to express that Motorway is only suitable when there is no Rain (conditional ODD statement), within the Geometry, Up-Slope is not suitable, all Weather conditions are suitable.

Example representations:

Any ODD definition requires the ability to have binary decision on any constraint, specified in the ODD.

The language will define the boundaries of the ODD specification. The language shall allow the mapping of every ODD terminal element into either inside or outside of the ODD in a binary manner by any external processor. This results in an ODD representation which can be evaluated to a set of TRUE/FALSE ODD terminal statements.

From a mathematical point of view such a representation relates to the ordered binary decision diagrams (OBDDs). From a programming point of view the OBDDs can be handled through boolean logical programming that allows to efficiently apply to OBDDs many logical operations (like conjunction, disjunction and negation) promoting composability of the language

Imposing restrictions to the possible combinations of ODD elements (concurrent evaluation of specific ODD elements to TRUE) can be achieved through conditional statements

In the envisioned (declarative) ODD domain specific language an ODD definition will be a collection of statements. This can be achieved by introducing to the language the following type of statement

propositional constraint statements: A statement specifying a propositional constraint, using a logical expression over previously defined variables, which can be evaluated using "truth tables", i.e. each ODD sub-statement as well as any composite ODD statement can be evaluated to either TRUE or FALSE. The semantics of propositional constraint statements define the mapping of every possible combination of values for its input expression statements to a True/False value. Propositional constraint statements_statements may be defined over other constraint statements.

Example use cases:

A road is considered unsafe for the automated driving system, if there is heavy or medium rain.

Example representations:

linked to requirement cluster [CL12]

The operators must match the syntax of the chosen language, for example the operators of range and others should match the encapsulation language

The following operators will be build into the OpenODD Format:

The language format needs to be able to express the class hierarchy provided by the attribute group (WP01), it needs to support inheritance, be consistent with the class categories (keywords), data type and units. It shall support abstract ODD definitions by choosing different hierarchical levels.

Example use cases: Inheritance

Challenge: Define a restrictive ODD that specifies motorway as the allowed road type, and junctions are not suitable. In addition, everything else that is not mentioned is not allowed. In this case, when the hierarchical class 'Junctions' is used, the restriction will automatically inherited by all its sub-classes, this is similar to the next abstraction example.

Example representations:

Example use cases: Abstraction

Abstraction allows the user to define the ODD at any level of abstraction corresponding to the Ontology

Define a ODD that allows all dynamic elements defined in the ontology, except when there is any type of rain. In this example, ODD can be specified at the 'Dynamic elements' level, the semantic echos with the inheritance property which means all the sub-classes of 'Dynamic elements' are also applied.

Example representations:

Permissive/Restrictive modes can be considered in two levels — at the individual statement level, and at the global level.

At the individual statement level, the language should take a mixed permissive and restrictive approach within its statements in order to be flexible when defining what is inside/outside the ODD (using explicit statements for inclusion or exclusion along with conditionals). The user of the language is responsible when specifying multiple permissive/restrictive expressions to guard from changing scope.

At the global level, restrictive mode is recommended to be considered such that ODD attributes that are not defined with statements can be evaluated by default to NOT allowed. This is particularly handy in the usual case where your custom ODD definition is based on an existing ontology (see importing an existing ODD ontology at the beginning of your new ODD definition) or when expressing a narrow ODD. Below is a reference from MUSICC (Multi User Scenario Catalogue for Connected and Autonomous Vehicles) project which defines the global permissive/restrictive. Design considerations for ODD ontology by CATAPULT, March 2020. Users can choose to define an ODD using permissive at the global level where ODD attributes that are not defined with statements can be evaluated by default to allowed. This can be useful in expressing wide ODDs.

"Conditions may exist in the real world which are not modeled in the ODD ontology, and therefore cannot be represented in an ODD specification. With a restrictive ODD definition, it is clear that these are outside of the ODD, which is consistent with the SAE J3016 definition(since the ADS is unlikely to have been “specifically designed to function” with an unforeseen feature). If the ODD definition is permissive, it is unclear whether the element is allowed for the vehicle or not. […​]For a hierarchical structure to be useful, it should be possible to use combined expressions (e.g.“Rural roads except motorways”); otherwise, all but the simplest of ODDs require every leaf item to be specified."

Example use cases: ODD definition for a T-Junction

For the example t-junction represented in the image and ontology below. Lets consider what permissive and restrictive means at a global level. For this we will have no 'local' statements so that we can visualize the effects of the 'global' permissive/restrictive.

Using a restrictive base state. A 'blank' ODD definition for the attached t-junction ontology would mean that all leaf attributes can be considered as outside of the ODD: restrictive - any attributes that are not mentioned in the ODD description but are present in the ontology (T-junction ontology) are assumed outside of the ODD’s scope.

Using a permissive base state. A 'blank' ODD definition for the attached t-junction ontology would mean that all leaf attributes can be considered as inside the ODD: permissive - any attributes that are not mentioned in the ODD description but are present in the ontology (T-junction ontology) are assumed inside of the ODD’s scope.

Note that in both examples ideally attributes that require numeric input would be separately defined, as these could not be simply included/excluded. i.e lane dimensions should be defined regardless of base state for clarity of description.