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
