M-SDL 20.10 Release

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.

This feedback allows us to enhance the language to address critical user needs in a timely manner. M-SDL version 20.10 includes several important features introduced over the past few months:

  • Refined control over the randomly selected scenario locations with new road elements.
  • Directed and explicit control of movements with arbitrarily shaped movements.
  • Ability to use the same scenario for both left and right-hand side traffic flow to avoid duplicating scenario creation and maintenance efforts.

If you wish to be updated or to contribute to the development of M-SDL, please join ASAM and the M-SDL community.

Road elements

AV and ADAS verification may require driving on a specific road type or road segment with specific properties. These may be available on either basic OpenDrive maps or only on complex proprietary maps.
On the other hand, unlike very directed tests, abstract scenario creation requires you to be able to describe these properties in an abstract manner so that all relevant places on the map can be used for that scenario. To meet these requirements, M-SDL 20.10 includes a new struct type: road_element.

A road element represents a road segment that has specific parameters. These parameters could be physical properties of the road itself (such as the number of lanes or the lanes’ width) or be related to the surrounding environment (e.g. a road on a cliff or a tree-lined road). The movement of an actor takes place on a sequence of road elements.

An M-SDL library of road elements may include several basic elements such as a generic road, a town junction, a highway, and so on. Users can extend the library’s set of road elements to include elements with features specific to their verification needs.

For example, assuming that the library has elements that describe a junction, a vehicle can follow a specific path through the junction.

scenario car.pass_thru:
    j: town_junction
    in_road: junction_entry with(junction: j)
    out_road: junction_exit with(junction: j)
do serial(duration: [1..10]second):
    enter: car1.drive() with:
        path(in_road) # approach the junction
    inside: car1.drive() with:
        path(j) # traverse the junction
    exit: car1.drive() with:
        path(out_road) # leave the junction

Road elements enable the description of scenarios that can be re-targeted on multiple maps or different locations within the same map.

Arbitrarily shaped movements

As part of the development process and throughout the verification flow, users want actors to perform explicit and fully specified maneuvers.

This need is exemplified by test protocols published by safety assessment agencies such as NHTSA and NCAP. Such test protocols outline in great detail the tested vehicle trajectory with exact distances and angles. The new shape modifier meets this requirement by fully controlling desired aspects of a maneuver.

Figure 1: An Automatic Emergency Breaking test maneuver, according to the NCAP test protocol

 

Figure 2: A Traffic Jam Assist test maneuver, based on NHTSA working document

Although these examples demonstrate the immediate need to constrain the position of an actor, users may want to constrain other attributes (e.g. speed or acceleration). Users can create their desired variations based on the basic shapes added to the M-SDL library:

  • any_position_shape constrains the actor’s position to a specific trajectory.
  • any_speed_shape constrains the actor’s speed to a specific trajectory.
  • any_acceleration_shape constrains the actor’s acceleration to a specific trajectory.
  • any_direct_control_shape constrains the actor’s pedal and brake to a specific trajectory.

For example, assume that a user needs to create an arc shape. The arc may inherit the any_position_shape object. To use this arc shape, the user first creates an instance of the shape in a scenario and then constrains the movement scenario of an actor to the shape using the shape() modifier. In phase 1 of the scenario shown below, car1 drives for 10 seconds on a highway. In phase 2, car1 drives along the arc shape until the maximum duration is reached.

scenario car.drive_with_shape:
    arc1: arc_shape with (radius: 15m, angle: 10deg)
    hw: highway
    car1: car
    do serial:
        p1: car1.drive(duration: 10s) with: path(hw)
        p2: car1.drive() with: shape(arc1)

Traffic flow

Most OEMs sell vehicles that must perform safely regardless of whether traffic flows on the left-hand side or right-hand side of the road. Having to re-write every scenario so that it runs on the other side of the road is a tedious, error-prone, and resource-intensive task, which also doubles the scenario maintenance. M-SDL enables you to write scenarios that can be run on either side of the road and avoid the need of duplicating scenarios.

For example, you can use a test parameter to run the cut_in_and_slow() scenario either on the right-hand side of the road (Figure 5) or on the left-hand side (Figure 6).

Figure 5: Right-hand side traffic flow
Figure 5: Right-hand side traffic flow
Figure 6: Left-hand side traffic flow

Several other modifications were made in the recent M-SDL 20.10 release. We have added clarifications and improved descriptions throughout the LRM. To get the complete list of additions and clarifications, please refer to the log in section 18.1 of the LRM.

Drive safe!

— Sharon

Subscribe to our newsletter

Additional content for you

ASAM OpenSCENARIO® DSL 2.1.0 (OSC DSL 2.1.0) is a human-readable scenario definition language that is a standardized format used to describe test scenarios for the development, testing, and validation of Advanced Driver-Assistance Systems (ADAS) and Automated Driving Systems (ADS) functions....
Today’s interview is in a Q&A format, giving you the chance to gain firsthand insights from Gil into a deeper dive into how Operational Design Domain (ODD)-based scenario generation and coverage analysis can streamline V&V processes and ensure the safety and success of autonomous vehicles....

Register to receive ALKS scenarios verification code examples

Subscribe to our newsletter