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 arbitrarilyshaped 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.
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.
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.
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)
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).
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.
Safety, together with its Verification and Validation, is the largest unsolved problem in autonomous driving. Safety is also simultaneously a purpose, blocker, enabler, and expected consequence of autonomous driving. Solving it requires radical innovations exceeding those enabling core autonomy capabilities like Perception, Prediction, and Planning. This is because truly effective Safety solutions address not only technology but also mindset, development methodology, and culture. Foretellix is leading the charge, which makes it tremendously exciting to be here.
On July 20th, 2022, the Association for Standardization of Automation and Measuring Systems (ASAM) released its latest standard language and domain model for scenario-based testing – ASAM OpenSCENARIO® 2.0.0 (OSC2.0). OSC2.0 offers abstraction and power features to advance industry best practices.
The Foretellix V-Suites™ are the most comprehensive V&V packages available today, aggregating extensive industry knowledge gained from working with multiple users, regulation requirements, and from collision databases.