Note: Originally published on September 27, 2021, under the title “A Primer on ASAM OpenSCENARIO V2.0 and Its Importance for ADAS and AV Development,” this post has been updated to reflect subsequent events pertaining to the OpenSCENARIO standards.
In September 2021, we discussed the upcoming release of ASAM OpenSCENARIO V2.0, aimed at advancing simulation standards for advanced driver-assistance systems (ADAS) and autonomous vehicles (AV). Since its rollout, this standard has revolutionized scenario modeling with its high abstraction level and improved inter-tool compatibility. It has also undergone significant refinements, along with a rebranding to better distinguish its scope alongside V1.0. Today we reflect on these changes and explore the ongoing impact and potential of OpenSCENARIO V2.0 in shaping mobility engineering.
Initially, OpenSCENARIO V2.0 was meant to complement OpenSCENARIO V1.X, aiming to create a comprehensive standard for diverse simulation needs. However, different requirements from various automotive sectors led to them evolving separately. In January 2024, ASAM announced these versions would continue as distinct projects, renaming OpenSCENARIO 1.x to OpenSCENARIO XML, and OpenSCENARIO 2.x to OpenSCENARIO DSL. OpenSCENARIO XML now focuses on concrete scenario descriptions, while OpenSCENARIO DSL supports broader abstractions for extensive test coverage. This distinct development ensures both standards meet specific industry needs, supporting developers and researchers effectively.
Maintaining these standards separately enables them to evolve in specialized ways, meeting the diverse needs of the industry. This allows users to select the most suitable tools for their specific scenario development and testing requirements.
With this blog post we look back at the pivotal changes and forward to the future possibilities that OpenSCENARIO DSL will bring to ADAS and AV development. As we continue to integrate and expand these standards, let’s explore how they are set to shape the next generation of mobility engineering.
Understanding OpenSCENARIO Standards
Abstract, logical, and concrete scenarios
In ADAS and AV testing, scenarios are vital for evaluating the safety of automated driving systems. These scenarios are divided into three categories: abstract, logical, and concrete. Abstract scenarios offer broad descriptions of potential driving situations, logical scenarios detail the parameters within these situations, and concrete scenarios are precise, executable tests. By defining these scenarios within the vehicle’s operational domain (ODD), teams can thoroughly explore and manage the entire test space.
For instance, consider a functional requirement where an autonomous vehicle—the ego—must navigate an unprotected left turn amid oncoming traffic. The PEGASUS method recommends starting with abstract scenarios, which are high-level descriptions, such as the ego vehicle at a straight intersection with 1-3 lanes, positioned in the left-most lane, and moving at a variable speed relative to surrounding traffic. This approach helps define the complete test space of relevant scenario parameters, allowing the development of detailed logical and concrete scenarios.
Next, simulation operations, testing, and validation teams define the complete test space of relevant scenario parameters using logical scenarios. These scenarios delve deeper, specifying parameters such as the vehicle’s potential speed for making an unprotected left turn, typically ranging between 10-20 m/s, with surrounding traffic speeds matching this range. The teams then derive concrete scenarios from each logical scenario, which are detailed, executable tests specifying exact parameter values like the ego and traffic speed at 13 m/s and the gap between the ego and the oncoming vehicle at 30 m. These concrete scenarios must be deterministic to ensure they produce consistent results each time the simulation runs.
Recent updates have enhanced OpenSCENARIO DSL’s Domain-Specific Language (DSL)—a programming language that has limited expressiveness and is focused on a particular domain—providing clearer and more versatile scenario descriptions across abstract, logical, and concrete levels.
Benefits and drawbacks of creating abstract scenarios vs. logical scenarios
Different approaches to scenario creation offer distinct advantages and challenges. Utilizing abstract scenarios as a starting point for deriving logical and concrete scenarios is swift and scalable but can introduce noise and variability that may be undesirable. An alternative method involves directly initiating tests with logical scenarios, leading to the generation of concrete scenarios. This method enhances precision and detail in the scenarios, but it is less scalable due to its focus on specificity. These dynamics are increasingly relevant as OpenSCENARIO XML and OpenScenario DSL continue to evolve, offering more refined tools for scenario management across different levels of abstraction.
Creating abstract scenarios
Benefits
- Speed: Utilizing abstract scenarios accelerates the requirement verification process. By employing verification and validation (V&V) tools that automatically derive logical and concrete scenarios from abstract ones, ADAS and AV companies can significantly reduce the time and resources required to test requirements across a full test space.
- Scalability: Abstract scenarios allow for broad and efficient coverage of the parameter space for various requirements. This approach facilitates quick adaptations to different testing needs and enhances the ability to replicate and modify scenarios for extensive testing purposes.
Drawbacks
- Potential for noise and variability: Abstract scenarios can be generated quickly but may introduce noise and variability, which can be undesirable in certain testing contexts. This noise might lead to less reliable outcomes and require additional filtering or refinement steps to isolate useful data. The auto-sampling feature in Validation Toolset reduces noise via ML-based optimization.
- Lack of specificity: Abstract scenarios often lack the detailed specificity needed for precise testing requirements. This can limit their effectiveness in scenarios where detailed parameter definition is crucial for accurate simulation and validation.
Creating logical scenarios directly
Benefits
- Precision: Creating logical scenarios allows for the definition of exact parameter spaces with fine-grained adjustments. This precision ensures that scenarios are deterministic and align with the evolving capabilities of OpenSCENARIO XML, aiding in the creation of realistic and varied testing environments that mirror real-world conditions.
- Control: Directly crafting logical scenarios provides enhanced control over the inclusion and exclusion of parameters, ensuring only realistic and relevant scenario combinations are tested. This method helps optimize computational resources by focusing on feasible and significant scenarios, which is increasingly important as scenario complexity grows with advancements in simulation technologies.
Drawbacks
- Reduced scalability: Directly initiating with logical scenarios is less scalable due to its focus on specificity. This method requires more time and resources to cover an equivalent range of scenarios compared to abstract scenarios, making it less suitable for broad-scope testing needs.
- "Unknown unknowns": Utilizing only logical scenarios might overlook unforeseen failures, as they typically exclude less predictable, yet possible, real-world conditions. Abstract scenarios enhance the discovery of these critical unknowns, ensuring broader system resilience.
- Higher resource demand: The need for precision and detailed control in logical scenario creation often translates into higher computational and expertise requirements. Each scenario must be meticulously crafted and tested, which can limit the number of scenarios that can be processed in a given timeframe.
Selecting between abstract and logical scenario creation based on specific testing needs enables optimizing ADAS and AV approaches as scenario standards evolve. Applied Intuition continues to refine its methods in these areas—see “Applied Intuition’s Approach.”
Despite having an effective strategy for scenario creation, the challenge of managing and translating scenarios across different tools persists. The diversity of tools used across the requirement verification workflow often complicates the seamless transfer of scenarios. OpenSCENARIO XML and OpenSCENARIO DSL standards have been instrumental in mitigating these issues by ensuring compatibility and easing the integration process across various simulation tools.
The enhanced Domain-Specific Language (DSL) and improved tool compatibility of OpenSCENARIO DSL have significantly boosted the scalability and precision of scenario testing. These advancements allow for the creation of more detailed and diverse test environments, enhancing the overall efficacy and breadth of simulation capabilities.
Limitations of ASAM OpenSCENARIO XML
Released in March 2020 as OpenSCENARIO V1.0, OpenSCENARIO XML standardizes the description of concrete scenarios using an XML format. While this version is vendor-agnostic, facilitating the transfer of concrete scenarios between tools, its utility is somewhat restricted as it does not support the definition of abstract scenarios. This limitation confines its use primarily to lower-level autonomy applications where detailed, executable scenarios are sufficient.
Despite its advantages, OpenSCENARIO XML’s focus on concrete scenarios necessitates manual creation of these scenarios to cover a full test space, making the process labor-intensive and prone to errors. The lack of support for abstract and logical scenarios complicates the expansion of test coverage and the construction of comprehensive safety cases for automated driving systems.
A drawback of the XML format is that it is less optimized for human readability compared to DSL formats. This has led many simulation software providers to develop their own custom scenario languages that are easier to interpret. OpenSCENARIO DSL, introduced as an advancement over OpenSCENARIO XML, offers a backward-compatible solution that eases these integration challenges and enhances readability, thus addressing the major limitations of the earlier standard.
ASAM OpenSCENARIO XML and DSL: Enhancing Scenario Design with Advanced Abstraction and Compatibility
Initially slated to operate in parallel with OpenSCENARIO XML, with potential future integration, OpenSCENARIO DSL has instead continued as a separate yet complementary standard. This approach ensures specialized focus on varying levels of scenario abstraction and compatibility across diverse simulation tools. OpenSCENARIO DSL supports abstract, logical, and concrete scenarios, enhancing their seamless integration and broadening their applicative scope in AV development.
Employing a Domain Specific Language, OpenSCENARIO DSL improves readability and operational efficiency compared to the traditional XML format of OpenSCENARIO XML. This tailored language approach enables precise scenario modeling, significantly easing the creation, simulation, and testing of diverse driving conditions.
Applied Intuition’s Approach
Applied Intuition's Validation Toolset and Object Sim support the OpenSCENARIO XML and OpenSCENARIO DSL standards, enhancing the creation, viewing, and editing of scenarios across abstract, logical, and concrete levels. This comprehensive toolset facilitates seamless scenario transfer between different simulation platforms, ensuring broad compatibility and integration within the industry's ecosystem.
Beyond supporting abstract scenarios, Validation Toolset empowers teams to efficiently manage auto-generated logical and concrete scenarios using Applied Intuition’s Object Sim scenario language. This capability allows for rapid iteration from initial concept through detailed testing scenarios, without the need to manually craft each scenario stage.
Workflow integration:
- Systems engineers define functional requirements within Validation Toolset.
- Scenario creators develop or generate OpenSCENARIO DSL abstract scenarios based on these functional requirements.
- The toolset automatically produces logical and concrete scenarios, using Applied Intuition’s Object Sim scenario language for further refinement and testing.
- Test engineers edit and fine-tune auto-generated concrete scenarios for detailed verification and validation.
- Validation Toolset links auto-generated concrete scenarios to functional requirements, ensuring traceability from requirements to test results.
- Applied Intuition’s verification packs complement the process, covering a wide range of scenarios for regulatory compliance and validation within specific ODDs.
For more on this topic see our Intersect Talks webinar, Advancing ADAS/AD development with ASAM Standards with Jasvinder Singh of ASAM, or reach out to our engineering team to learn more about Applied Intuition’s support for OpenSCENARIO.
*Note: Validation Toolset was previously known as Basis and Object Sim was previously known as Simian.
.webp)
.webp)
