Expert Talk: At ODDs with Standardization

_{(2 min read)}

In late June 2021, GEONATIVES had an inspiring talk with Siddartha Khastgir, Leader of ASAM’s OpenODD (Operational Design Domain) Concept Project. He is the “Head of Verification & Validation for Intelligent Vehicles at WMG, University of Warwick, leading various Collaborative R&D projects with industry at WMG”. He is involved in various standardization and regulatory initiatives by the “typical suspects”: ASAM, ISO, SAE, UNECE.

Our conversation was a follow-up on ASAM’s OpenODD workshop that had been held a few weeks before. A key aspect in that presentation, which got our attention as GEONATIVES, was the mentioning of a potential classification of real-world areas (or roads) according to their fitness for certain ODDs.

The Operational Design Domain describes the operating conditions a system was designed for. Thus, ODD defines its capabilities and limitations. But don’t mix up ODD with test specification and test cases because ODD is a generalized description of the conditions for operating the system without errors. The ODD will give you the boundaries for generating test scenarios and cases but will not include specific information or even examples.

Where would you store real-world information that influences your ODD? To answer this question, you first must be aware of all relevant parts of localized information that need to be correlated:

• road network layout and features such as zones, infrastructure and furniture
• environmental information about weather condition and connectivity
• static and dynamic object information (buildings, vegetation, moving and static objects, traffic participants etc.)

Now comes the tricky part: roads are represented in OpenDRIVE, behaviors may be stored in OpenSCENARIO, and environment information may be contained in an arbitrary number of other formats (e.g. CityGML). Weather information often can only be derived from temporally aggregated data, with little granularity. Linking from an ODD definition to these external data repositories must be facilitated by guaranteeing that all components are using a common terminology and allow for cross-referencing (bi-directionally).

This leads to the clear requirement – and kind of the conclusion of our talk – that there be layers of abstraction in each of the formats that allow for a higher-level linkage without having to deal with the details of each format’s implementation. An idea we came up with was something in the sense of an API that allows for this linkage and translates – as a tooling – queries in terms of ODD features into “feasibility” answers within each format’s own domain (and vice versa).

Once this is done and implemented, the different initiatives may even go one step further and incorporate the information needed for this linkage directly into their upcoming versions, thus helping to create a powerful digital twin of reality.

The linkage adds another layer to our idea of a versatile digital twin that represents aspects of various stakeholders: OEMs and users of automated vehicles (e.g., consumers and fleet operators) will become highly interested in the link between their vehicles’ features and the geographic locations where those may be used within their respective ODDs. Public authorities or industries can pre-define which capabilities are needed to be able to operate in their geo-nets.

Also, from an ODD’s point-of-view you might be interested to see what geographic coverage you can achieve with a well-balanced definition of your system’s capabilities. Any you may decide where to put in the next development effort.

You see, we had a quite productive discussion and, for sure, we will continue to follow ASAM OpenODD in its endeavor. Expect more posts on this subject.