Automotive Industry Insights

ASAM OpenSCENARIO

Description
OpenSCENARIO defines the dynamic content of the world, for example the behavior of traffic participants and how they are expected to interact with each other and the environment. It is used in:

• Virtual development
• Tests
• Validation of functions for:
• Driver assistance
• Automated driving
• Autonomous driving
• Testing on test tracks or proving grounds
• Testing in a mixed environment (HIL)
• Decoding real-world driving data

The OpenSCENARIO standard occupies a unique position amongst the OpenX set of standards in that ASAM currently actively develops two parallel versions of it. The two versions occupy different positions in the application toolchain. V1.0 is a low-level and concrete specification format, primarily designed to be read by simulation tools, whereas V2.0.0 allows those users that create maneuver descriptions and tests to define scenarios at a higher level of abstraction as well as providing alternative expression methods to the current XML format of OpenSCENARIO 1.0.0 via a domain-specific language (DSL).

OpenSCENARIO 2 defines an abstract road syntax that allows for the description of road geometry at varying levels of abstraction. Version 1.1 does not support the description of such static content; instead, it must be referenced through, for example, OpenDRIVE descriptions.

Status
V1.1.0 release date: March 2021
V1.2.0 release date: March 2022
V2.0.0 release date: December 2021

Current role and relevance with regards to ADAS/AD
The complexity of the systems being tested for high levels of automation has (and will continue to) grown exponentially. Whilst the full implications of this are yet to be understood, these levels of complexity need to be reduced at some stage or other in the testing workflow. This can be done at the test specification level (potentially leading to more tests) or at the scenario level. This increasing complexity is directly reflected in the capabilities of the scenario description languages being developed. It is possible that this complexity can be abstracted out significantly better through powerful scenario descriptions that can cover large solution spaces through higher levels of abstraction, which also serve to support increased automation. Further tools to reduce complexity at various points include the robust use of standards as well as ensuring a seamless exchange of data.

To better understand the target groups, the ASAM OpenSCENARIO 2.0.0 standard documents use cases and users for scenario descriptions in detail. These include various use cases specifically targeting test engineers and regulators (see the ASAM OpenSCENARIO V2.0.0 standard for details).

Whilst only OpenSCENARIO 2 explicitly targets test engineers and regulators, both versions are deemed to be relevant to testing and this report. OpenSCENARIO 1 is currently the only standardized format for scenario descriptions and is hence a key part of current scenario-based testing workflows. This will likely become less so as OpenSCENARIO 2 is released and gains traction in the industry. This is expected to be driven in part by the need to have higher levels of scenario abstraction, for example for regulatory purposes. It is hoped that a standardized format capable of a full spectrum of abstraction levels like OpenSCENARIO 2 will greatly support the use of, as well as the shared understanding of, scenarios in legislature. The roadmap at ASAM for OpenSCENARIO estimates a convergence of the two versions to one in some form within the next three years.

Study group summary of ASAM OpenSCENARIO
As detailed in section 3.5.“The Relation between Test Case and Scenario”, there is a very close interaction between a scenario and a test, which necessitates an interface within the test case description to implement higher-level concepts (e.g. parametrization) consistently in tests and scenarios. This interface must be represented in the scenario as well. It is thus expected that this standard will be extended to support such an interface. Additionally, a scenario needs to have some interface to an ODD description.

Further possible implications include a clearer separation of test-relevant parameters and fields from generic scenario fields, but this is likely to be part of a separate testing-focused standard that can be applied with the language features of OpenSCENARIO. Possibly this could be implemented as a feature set of OpenSCENARIO that is testing-specific. Other such extensions could include bindings to external languages (in addition to the aforementioned testing interface) or testing libraries.

OpenSCENARIO V1 has applied extensive focus in its ongoing development to clarifying the interaction of a scenario description with a scenario engine. Such an engine is then responsible for interacting with a simulation. It is expected that such clarifications will need to be extended to both versions, particularly with an emphasis on how one or more tests activate one or more scenarios.