M-SDL 21.05.0.1 Release

In the last three years, we had to explain to users why abstract scenarios are much more productive than logical or concrete scenarios, and how stochastic approaches are useful for unpredictable risks.  Today, users read about these in the Pegasus family VVM papers, or get familiar with these as part of the regular ASAM standardization meetings. By the way, in ASAM, we are moving to the final stretch of closing the OpenSCENARIO2.0 standard and as usual, we highly recommend joining and influencing the effort.

Nevertheless, there is much more work to be done and we are constantly “on the move”. Here is a quick preview of a few of the many 21.05.0.1 M-SDL recently added features:

  • Supporting left-hand and right-hand traffic from the same scenario description
  • Scenario creation leveraging real-life distributions
  • Coordinating attributes and behaviors of multiple cars
  • Rise and fall events for simplifying OSC1.0 to M-SDL conversion

Left-hand traffic

Figure 1: Left and right-hand traffic

About 30% of the world’s population drives on the left side of the road, and for a human driver (e.g. me), it is always hard to make the adjustments (especially in chaotic roundabouts). Most OEMs plan to provide vehicles that can drive on both sides – does this mean they need to duplicate their development testing and V&V efforts? Well, not with M-SDL. M-SDL allows leveraging the same scenario for both left and right-hand maps. For the existing Foretify users these are great news. No need to change anything with your side parameterized scenarios. For example, to make your cut_in scenario drive on the left just use the following:

extend test_config:
    set traffic_side_request = left_hand

In one request, all your scenarios will adjust to the left-hand driving request.  This also great news for our ADAS & highway package users – all the out-of-the-box content can now run on either desired side, and we can provide a few left-hand maps if you need these.

If you want to hard-code a movement to either the center of the road or the curb direction, we added a few simple APIs for these.

map.curb_side(): av_side that returns the side nearest the road center (left for right-hand traffic, right for left-hand traffic), and the equivalent map.center_side().

For more information, please refer to the LRM.

Scenario creation leveraging real-life distributions

Figure 2. Three-dimensional representation of the speed-density relationship (Wang et al. 2009)

Relying only on distribution functions for scenario creation is not enough nor efficient. Without being too philosophical, life tends to be repetitive and boring, as you experience the same circumstances over and over again before something interesting takes place. Without M-SDL, users often express frustration as they cannot assess the effectiveness of their tests and determine whether all their concerns were verified. You can read more on how the Coverage Driven approach allows us to effectively set and meet V&V goals here.  At the same time, when you push a few attributes for edge cases, you wish to use real-life distribution on others. This will result in a more representative scenario. For example, in a scenario, you may call for a pedestrian to unexpectedly jump in front of a vehicle. Other traffic participants or pedestrians should demonstrate a typical natural behavior. M-SDL provides predefined normal and uniform distributions.

extend top.main:
  top_speed: speed
  keep(soft top_speed == random.normal(10, 120, 55.5, 7) * 1kph)
  dist: distance
  keep(soft dist == random.uniform(20, 50.5) * 1m)

The first example returns a number between 10kph to 120kph, with a mean of 55.5kph and a standard deviation of 7kph. The second example returns a number using a uniform (flat) distribution in the requested range. Note that the distribution functions are used in a soft constraint that will be ignored in case you wish to steer the generated value to a non-typical edge case.

There are more use models for the pre-provided distribution functions, and M-SDL allows you to define your own functions. See the Language Reference Manual (LRM) for more details.

Controlling and coordinating behaviors of multiple actors

Figure 3: Controlling multiple actors

Several Foretellix customers that use scenarios with multiple cars, requested the ability to configure each car in the group, using a single constraint. To meet their request, we added this constraint iterator that can be applied on any list including a car group.

The following example demonstrates a single constraint on the color is applied to the entire car group.

for c in my_group.cars:
keep(c.color == weighted(40: green, 60: blue))

In the example above, the for loop iterates on the group of cars, using the symbolic name c to point to each individual car and constrain it to be 40% green and 60% blue.

Rise and fall events, and simplifying OSC1.0 to M-SDL conversion

Assume that you wish to monitor information the first time the car TTC goes below one second. The following code achieves the desired event, but also emits multiple events at the following simulation clocks:

event cars_became_close is  (car1.get_ttc_to(car2) < 1s)

rise() and fall() were added to M-SDL to give you fine control of the event expressions. rise(Boolean-expression) in event definitions causes the event to be emitted when the Boolean-expression becomes true (but not in subsequent clocks). fall() is similar, for when the expression becomes false. The following example captures the needed event:

event cars_became_close is rise(car1.get_ttc_to(car2) < 1s)
Figure 4: An automated flow for migrating concrete or logical OSC1.0 to abstract M-SDL scenarios

This event is emitted when the time to collision becomes smaller than one second but it is not repeated every cycle after that.

This addition is useful in its own right, and also important for converting OSC1.0 scenarios. M-SDL (today) and OSC2.0 (in the future) allow abstract scenarios as well as concrete, and logical scenarios (ranges only). As such it is a superset of OSC1.0. While it is highly recommended to use abstract scenarios for newly created scenarios, users may have legacy scenarios that they would like to convert to reach the next level of abstraction and enjoy a declarative language readability. While migrating a user OSC1.0 database to M-SDL, we noticed that we miss a temporal capability of evaluating an event on a rise or fall of another signal.

If you have a large number of OSC1.0 scenarios and would like to check the ability to migrate these, we will be happy to demonstrate the automated migration and discuss the expected productivity gains.

For getting the latest complete open M-SDL Language Reference Manual click here. And do not hesitate to contact us with any questions you may have. We want to thank our customers and members of the M-SDL partners program for their constant feedback that drives M-SDL forwards for the benefit of the entire automotive industry.

Be safe,
Sharon

Subscribe to our newsletter

Additional content for you

Register to receive ALKS scenarios verification code examples

Subscribe to our newsletter