Expressing More Scenario Needs with the New M-SDL 20.7 Release

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:

• Conditional inheritance (an innovative way to model orthogonal categories)
• Recording data for various purposes
• Coverage model extensions and their important role for reuse
• Tracing changes in the value of an expression during scenario execution

If you are not already familiar with the basics of M-SDL, please refer to this link.

Conditional Inheritance

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:

• If it is kind randomized to be a truck, it should have all truck attributes and constraints
• If it is emergency_vehicle attribute randomized to be true, it should have all emergency vehicle attributes and constraints
• If both the kind is a truck and the emergency vehicle is true, we should get all attributes and constraints of both categories.

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.

The Record Feature

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:

• Check that the Ego behaved properly (by storing KPI values, for example)
• Help debug scenario execution
• Review the achieved value distribution.

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.

Coverage Extensions

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  

Adding a trace() modifier

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