
ASAM OpenSCENARIO 2.0 – A Fairly Big Step for Mankind
You may think that I got carried away with the title here … but look at it like this: the future of the automotive industry ignites the imagination.
This blog introduces the new features in the recent release of M-SDL (M-SDL 20.07).
At Foretellix, we will continue evolving M-SDL to meet industry needs, with the intention of converging Open M-SDL with OpenScenario2.0. I want to take this opportunity to thank the multiple customers, M-SDL partners, as well as OpenScenario 2.0 committee members for their priceless feedback. If you wish to get updated or contribute, I recommend joining ASAM by following this link, and the M-SDL community by using this link.
M-SDL version 20.07 introduces several important features, including:
If you are not already familiar with the basics of M-SDL, please refer to this link.
M-SDL allows users to create a partial, abstract description of a scenario together with a set of legality rules. This enables technology to create multiple concrete scenarios from a single abstract description.
In order to thoroughly verify an AV or ADAS, users often need to take into account multiple ways of categorizing actors or scenarios. For example, a vehicle can be a truck, a car or a motorcycle, and at the same time it might be an emergency vehicle or not. This can be easily modeled in M-SDL as follows:
Each one of these categories can have additional attributes. For example a truck might have a num_of_trailers attribute, and an emergency vehicle might have a siren attribute. Once a user randomizes a vehicle, he expects the following:
Traditional object-oriented inheritance does not support this auto-adapting modeling requirement, but M-SDL’s new conditional inheritance allows users to write the following:
Declaring a vehicle as follows:
allows technology to randomize v1 to be one of many types, including a truck vehicle (with a num_of_trailers attribute), an emergency vehicle (with a siren attribute) or an emergency truck (with num_of_trailers and siren attributes). The resulting type is conditioned on the value of randomized fields, and this is why the feature is called conditional inheritance.
Conditional inheritance allows test-writers to create the required instances simply by constraining the attributes of the parent class. For example:
For more information on inheritance please refer to section 5.4 on the M-SDL LRM.
M-SDL’s coverage features precisely and objectively capture verification goals. Throughout the verification process, coverage data is used to indicate the completion status of verification goals. However, at times, users might want to record data for other purposes. For example, they might want to accumulate information to:
M-SDL 20.07 provides a new record() capability for these purposes. As with coverage, users can flexibly define the required values, sampling time, ranges, and filtering:
For more information on the record() feature, refer to section 7.1.2 of the M-SDL LRM.
In order to facilitate reuse, M-SDL allows users to extend types and classes to match different tests, projects, or ODD needs. A library of reusable scenarios should include base coverage definitions, while allowing users to refine them to meet their needs. For example, if users are working on a specific ODD speed limit, they might want to remove faster speeds from their coverage goals. Going faster than the ODD speed limit could be either impossible or not interesting for the project requirements.
M-SDL 20.07 allows users to easily refine coverage goals by adding or overriding the predefined coverage definitions:
For more information on coverage extensions, refer to section 7.1.4 on the M-SDL LRM
For debugging purposes, users might want to trace the value of an attribute or expression throughout scenario execution. A new trace() scenario modifier allows simple exploration of the changes in an expression’s value. For example, users might want to trace the Ego’s speed, the speed of the NPC (the other car), as well as their relative speed, in order to better understand the actual scenario execution:
For more information on trace(), please refer to section 15.4 of the M-SDL LRM.
Many more modifications are part of the recent MSDL 20.07 release. We have added clarifications and improved descriptions throughout the LRM document. To get the complete list of additions and clarifications, please refer to the log in section 18.1 of the LRM.
Drive safe!
— Sharon
You may think that I got carried away with the title here … but look at it like this: the future of the automotive industry ignites the imagination.
Hectic times in Foretellix. It seems like in a coordinated move, much of the industry realized that abstract scenarios, automation, and coverage measurement are the right path for productivity and safety.
At Foretellix, we continue evolving M-SDL to meet industry needs, with the intention of converging Open M-SDL with OpenSCENARIO 2.0. As in previous versions, updates were made in response to customer needs, partner feedback, and inputs we get through our participation in ASAM’s OpenSCENARIO 2.0 development project. We want to thank them all.
We’ll get back to you as soon as possible.