Standards are safe

We’ve been going on about the importance of collaboration and standardization in automated driving for a while now. This is because such initiatives are fundamental to achieving true safety in driving automation. It’s no accident that some notable players came together recently to create a white paper on the safety of automated driving.

But the automotive industry is a kingdom of standards and regulations. The most important for automated driving systems are two, which my colleague, László Katona, examined in detail recently. ISO 26262 and ISO/PAS 21448 (SOTIF) define considerations for the development and deployment of automated driving systems. SOTIF places significant emphasis on simulation-based validation and verification. At AImotive, we have a deep understanding of how simulation for automated driving works as we’re one of the very few teams in the world that develops both software for automated driving and a simulator. One of the most vital elements of simulation is scenario testing, as detailed in our recent white paper.

Defining scenarios

Scenarios can come for several sources, but trends are already indicating a shift towards standardized scenario sets built to verify and validate ADAS solutions before deployment. The difficulty is the range of simulation tools, as each of these has its own method of defining scenarios. This means that engineers can’t take an existing scenario and run it in another simulator as a secondary test; nor can a regulatory body create standardized test scenarios for the automated driving industry.

At AImotive, we developed an internal scenario description language because there weren’t any open standards available when we started working on it. As our approach to scenario testing built on strict functional safety requirements, we implemented various testing conditions which drove development.

Scenarios can range from extremely simple "driving in a straight line" tasks, to complex situations in heavy traffic and different weather conditions. A scenario description methodology must be able to handle all these robustly.

In the early stages of development, it can be more efficient to rely on an internal system that can be modified and fine-tuned on-demand. This allows development to move in priority directions, without considering backward compatibility and general exchangeability. However, we always knew that in the long run, we’d have to take these into consideration.

Eventually, our scenario language grew to a flexible and robust system, in which complex road scenarios can be defined. However, these scenarios were all tied to aiSim, and weren’t exchangeable with other industry participants, or available to compare and benchmark other simulator solutions.

A standard is born

Naturally, the industry reacted to the need for a solution to the challenge of scenario exchangeability. This is how OpenSCENARIO evolved from being tied to a single simulator to stepping on the road to become a standard. Initially developed by Vires, the creators of an automotive simulator, the project now runs under the aegis of ASAM.

As a member of ASAM, AImotive is also part of the collaboration driving OpenSCENARIO forward. AImotive is involved in the OpenSCENARIO Transfer project. The goal of which is to create better documentation for OpenSCENARIO. Various examples and bare-bone implementations ready to be integrated into larger systems will also be provided. The hope is that these will elevate it to a properly documented ASAM specification standard and accelerate its implementation by the wider industry.

Technically, supporting standards boils down to adapting systems to complex external requirements. It’s a matter of convertibility. Adding static support for OpenSCENARIO to aiSim was relatively simple. All we needed to do was understand how each element interacts with the others, and what each parameter means. Our simulation engine was already built to communicate with the scenario system through an interface, so switching between languages was not hard.

The aiSim Scenario editor is a central tool in our development process.

The real challenge is integrating OpenSCENARIO into our pipeline in a way that all our internal tools – most importantly our scenario editor – can read, edit and save files in the open format. For this, convertibility is key. Our event-based system now has all the essential features to ensure it can handle the structure of OpenSCENARIO to enable editing. Naturally, incorporating complex functionalities is a continuous process.

It all boils down to stories

The purpose of the standard as written on the ASAM website is to “describe complex, synchronized maneuvers that involve multiple entities like vehicles, pedestrians, and other traffic participants.”

An OpenSCENARIO file contains a list of actors, actions, triggers, conditions, events, and parameters. Scenarios are defined as storyboards, which are divided into stories, acts, sequences, and maneuvers. A story contains what the participants will do in the scenario. Stories are divided into acts, which are triggered by events: something happens when a specific condition is met. Sequences then define what maneuvers the participants of the act should execute. Once all the stories are completed, or an end condition is met, the scenario ends. Each part of the scenario can be heavily parameterized on the spot, or parameter collections can be created and replaced only in runtime.

Defining so many variables, it is no surprise that the standard is complex. The difficulty is that currently, the standard’s documentation is very limited and often confusing to someone who’s not familiar with similar systems. While a mindmap is available, which showcases the connections between all parameters, adopting and moving to the standard is demanding. The goal of the Transfer project is to alleviate this limitation by providing a high-level overview of what OpenSCENARIO is, how it works, and the key fundamentals required for quick implementation.

Scenarios can be formulated based on functional safety engineering, road accident databases, and standardized test sets, or from real-world events. They are designed to test the functionality of the automated driving system.

Safety lies in numbers – Collaboration is key

At AImotive, we have always believed that safety is the most critical element of automated driving. Simulation is a driving force behind this goal. Initiatives similar to OpenSCENARIO enable a wide range of new collaborations in automated driving and simulation. In turn, they open the door on further actions to increase road safety, such as the creation of standardized regulatory scenario sets defined as minimum criteria for the deployment of ADAS or self-driving solutions.

We have built aiSim to support OpenSCENARIO and participate in the working group because it is in our DNA to utilize simulation to the maximum and help our partners do the same. aiSim is designed to be extensively flexible. Our partners can choose which elements of the system they want to utilize. We hope that OpenSCENARIO will allow them to make the most of their existing scenarios and other resources to make road transport safer for everyone.