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

Language is one of the most important tools that we have in our toolbox - we read, write, debug, think, and communicate, in the provided language terms. The Measurable Scenario Description Language (M-SDL) is a highly developed modeling language addressing the challenges of Autonomous Vehicle (AV) and Advanced Driver Assistance Systems (ADAS) verification.

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

Additional content for you

Finding the Unknown Unknowns

The challenge: The growing complexity of automated driving systems such as Lane Keep Assist, Lane Centering and Adaptive Cruise Control challenge existing verification and validation (V&V) methodologies used in the automotive industry. As these systems become more prevalent, bugs surface and failures occur.

Read more

Time to look at Automated Virtual Testing for AV verification

Whether you are working on ADAS and about to move up to more advanced autonomous functions, or working on the long tail of L4 autonomy, one thing is for sure: you are about to face exponential growth in the number of scenarios you need to test in order to get your autonomous product out.

Read more

What The Heck Are We Measuring?

Increasingly, thought leaders and executives within the automotive industry have shared their concerns about the validity of miles and disengagements as metrics for safe deployment of autonomous vehicles, and some have started proposing alternative metrics.

Read more

Enter your details below to sign up for the Foretellix newsletter!

Your request has been sent

We’ll get back to you as soon as possible.

M-SDL Open Source Project Registration

Enter your query below and we'll get back to you shortly

Enter your query below and we'll get back to you shortly

* Required field

We're committed to your privacy. Foretellix uses the information you provide to us to contact you about our relevant content, products, and services. You may unsubscribe from these communications at any time. For more information, check out our Privacy Policy.