It has the potential to revolutionize our daily routines, our social life, and even the demographic structure of our cities. Between current reality and this utopian future stands the barrier of an infinite scenario space versus a finite set of resources. Unfortunately, by using mostly manual and siloed solutions we can’t cross this barrier… but now (soon) comes OpenSCENARIO 2.0.

What is OpenSCENARIO2.0?

ASAM (Association for Standardization of Automation and Measuring Systems) is a non-profit organization that promotes standardization in automotive development and testing.

For example, ASAM OpenDRIVE is a standard format to provide a common base for describing road networks with extensible markup language (XML) syntax. OpenSCENARIO 2.0 (OSC2.0) is the upcoming ASAM standard language to develop, verify, and validate the safety and efficiency of automated driving systems. It offers a modern syntax resulting in a concise and readable format.

What makes OpenSCENARIO 2.0 so powerful?

Since OSC2.0 is not yet released, we can’t show code snippets, but while some great decisions were made around the language syntax, the key OSC2.0 revolution is the ability to capture scenario intent in a machine-readable formal way. The language allows capturing dependencies over time between actors (such as vehicles and persons) and their behaviors, using mathematical constraints. This means that OSC2.0 scenarios can be processed by an intelligent machine to create tests that would require an army of human test writers to manually. I’ve collected a few examples of this efficiency below.

Automation – OSC2.0 makes it possible to teach an intelligent machine abstract maneuvers and locations and then ask it to produce and execute test scenarios intelligently and repeatedly according to this acquired knowledge. For example, using constraints, I can teach a machine what is a cut-in scenario (start behind on the side of the Ego and finish ahead in the same lane) and request the machine to perform it in various locations, with various speeds and distances, etc. The machine can automate scenario creation interacting with both physical (e.g. HIL) and virtual (e.g. SIL) testing platforms. It can auto-adjust the scenario to any desired location and speed or intelligently mix it with other scenarios. Inferences and calculations between the scenario phases and parameters that in the past required human intervention using a trial-and-error process, can now be achieved by a machine. This allows the generation of millions of meaningful and valid scenarios from one abstract scenario.

With proficiency and speed, intelligent machines can reach a high scale of meaningful and fine-controlled scenarios more quickly than by any other means. The machine can even adjust the progression of the scenario to the unpredictable behavior of the autonomous vehicle.

Measurability – OSC2.0 allows users to accurately describe the testing goals for the intelligent machine to work towards. The Verification and Validation (V&V) coverage goals can come from real-life statistics, ODD requirements, risk calculations, or engineering judgment. The machine digests the user-specified goals, tries to meet all requests, and produces an accurate report of achieved and non-achieved coverage goals. Setting goals and being able to measure them at scale is key in order to deal with the infinite test space.

Optimization – Note that since the intelligent machine understands the scenario intent as well as the ODD or project goals, it can create a test regression optimized for specific needs and avoid executing already explored areas. Trying to manually analyze hundreds of thousands of scenarios to understand which ones are relevant or redundant for a specific requirement is extremely time-consuming for a human being, but can be easily automated by a machine. For example, I can ask the machine to create a regression that focuses on ACC automation functions and avoids running redundant, irrelevant scenarios.

Finding unknown scenarios – The challenge of ensuring that your autonomous driving system has been adequately tested in the unknown scenario space of the ODD (e.g. as required by SOTIF) is yet another place where OSC2.0 can help. If the machine understands and randomizes a cut-in independently, it may explore multiple conditions that the user may have overlooked. Even if I specify a few scenario attributes or mix two known scenarios, the rest of the scenario is randomly generated, so there is a surprise element in every test. Note that OSC2.0 semantics enable true randomization of the scenario and not shallow fuzzing of parameters that are easy to vary — there are dependencies between speed and distance, acceleration and speed, and the combination of these may require a totally different road segment. The real value is resolving the interdependencies to randomize distances, latencies, and locations, and having the machine plan a scenario around the user goals.  The user can always select between real-life distributions or edge-case scenarios to explore risk dimensions.

The video below shows an execution that was randomized from a merge into a highway abstract scenario. In many previous randomized scenarios, the Ego was able to successfully merge onto the highway. However, this video demonstrates a failure to merge. We need to analyze the reasons for the Ego’s poor decision to drive off the road, but by generating the scenario with randomized location, distances, speed, and other parameters, a potential bug has been exposed.

A standard language across test execution platforms   – There is a big overlap between the scenarios that we want to execute on SIL, HIL, test tracks, street driving, and more. The various simulators available today offer different strengths such as better perception vs. better vehicle dynamics capabilities; therefore use of multiple simulators is required. OSC2.0 allows porting the same scenarios and correlating the result across all platforms, bridging between the different teams while leveraging the strength of each testing platform. Using a simulator proprietary language locks the user into a specific simulator, which may result in compromising on quality or a painful duplicated effort. Having the entire industry support and develop technologies around OSC2.0 is the right formula to globally move the industry forward.

Reuse and ODD agnostic ready-made content – The digital transformation caught the automotive industry unprepared. Basic software capabilities such as type inheritance, extensibility, and modularity were not part of the scenario creation jargon. For example, I can define a vehicle’s category to be a truck or a sedan. If a truck was randomized or requested in a scenario, the vehicle will automatically have a truck’s dimensions and dynamics. Such fundamental software capabilities further minimize the amount of OSC2.0 code that you need to write and maintain. If you add these software practices to the location and ODD agnostic capabilities of OSC2.0, then the industry finally has the necessary capabilities to create truly reusable, OSC2.0 compliant test suites.

To summarize, the OSC2.0 revolution—the automation, measurability, optimization, standard language across test execution platforms, reuse, and ready-made content—will revolutionize industry efficiency and thoroughness. Solutions that provide the value described above already exist today, and we will experience more solutions that can leverage the unique capability of OSC2.0 to capture scenario intent.

Now that we reviewed the value of OSC2.0, let’s discuss a little bit the past, present, and future of the OSC2.0 standard.

Where did open scenario 2.0 come from?

The figure below illustrates the M-SDL to OpenSCENARIO 2.0 journey.

The ability to capture scenario intent via constraints, set measurable coverage goals, perform optimization and enable SW capabilities, were introduced by Foretellix in January 2017 as part of the open M-SDL language. As strong believers in standards, we opened the language to the public domain and allowed hundreds of companies to download it. Eventually, we contributed our open M-SDL syntax and concepts to the public domain and to the ASAM organization and invested a lot of effort, jointly with multiple dedicated partners to develop OpenSCENARIO 2.0.

Will Foretellix continue its contribution to OSC2?

Foretellix is committed to continuing to contribute to the evolution of OpenSCENARIO 2 and its future versions for the benefit of the industry. In parallel, we will continue to serve the needs of our user base, pushing both the technology and the language forward.

When will OSC2.0 intelligent machines be available?

At least nine vendors have already announced their plans to support the upcoming OSC2.0 language syntax. Over the past several years, Foretellix has developed native engines within the Foretify intelligent machine that are necessary to fully realize OSC2.0’s potential. Our technology has been used at leading OEM and Tier1 companies for years, to develop and test AD and ADAS functions. The technology is always accompanied by expert V&V consulting on automation, methodology, and the overall virtualization process.

Register to the OSC2.0 Webinar

If you wish to know more, register for our ‘Taming Infinity with OpenSCENARIO 2.0‘ webinar. This is the first out of a series of webinars led by our experts, touching on various OpenSCENARIO 2.0 language features. The series will build your knowledge starting from scenario coding guidelines all the way to methodology and flows. We will also review the intelligent machine and its various engines, such as the constraint solver and optimizer.

If you wish to check out Foretellix’s OSC2.0 automated flows and solutions, drop us an email at info@foretellix.com.

BTW, we are hiring. If you are interested in an exciting role, joining a winning team that is building the next generation of AD and ADAS test automation solutions, click here.

As usual, drive safe,
Sharon

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.

 

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).

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

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