Close
How can I create the needed millions of scenarios?
How can I avoid the test explosion problem?
How can I find out if my tests are passed or failed?
How can I create the needed millions of scenarios?
How can I avoid the test explosion problem?
How can I find out if my tests are passed or failed?
How can I create the needed millions of scenarios?
In the automotive industry, it is widely accepted that the validation of autonomous vehicles needs a huge amount of scenarios which can only be tested in a virtual environment. But it is also obvious that this amount of scenarios can’t be created manually.
Recorded real-world scenarios can help and are even needed as part of the overall validation strategy. But recording all the needed scenarios on the road is economically infeasible. Furthermore, many interesting scenarios contain safety critical situations, where it is clearly a challenge to safely record them in the real world.
Therefore attempts are being made to introduce a high level language which allows to describe classes of scenarios (e.g. as part of OpenSCNERIO 2.0). The problem is, that they are usually text based and therefore hard to use and hard to understand.
BTC Embedded Systems addresses the described challenges with an intuitive and graphical language for high level abstract traffic scenarios. The language describes an abstract scenario in multiple phases. Every parameter including positions and velocities can be defined as a parameter range either in absolute values or relative to other traffic participants. While a graphical environment brings many advantages for the scenario creation and review process, the language aims to achieve compatibility with the upcoming ASAM OpenSCENARIO 2.0 [6] standard for flexible tool interoperability.
These abstract scenarios are the basis for all subsequent steps in the validation process including automatic generation of concrete scenarios and automatic scenario observation.
Before bringing the scenarios to a simulation environment, we are using powerful constraint solvers to check the defined scenarios regarding their feasibility. This so-called pre-simulation allows visualization of the dynamic behavior of the scenario. If no concrete instance of the scenario can be created, potential conflicts between parameter values and ranges are reported. As a consequence, unfeasible scenarios are detected very early before they even get executed, which leads to time and cost savings.
The example below shows a phase in which the ego vehicle is driving with a speed between 40 km/h and 60 km/h.
During the phase, the fellow vehicle is passing by on the right lane with an initial distance of 0 m to 10 m behind and a target distance of 0m to 10m in front of the ego vehicle.
Multiple phases, each one having its own minimum and maximum duration, are then connected to one abstract traffic scenario. Since all parameters can be defined with value ranges, each abstract scenario describes an almost infinite set of possible concrete scenarios and simulation runs.
To move from an abstract high-level scenario to concrete traffic scenarios which can be simulated, we have to define values for a large number of parameters, which is not limited to the parameters of the abstract traffic scenario. One additional aspect is the coverage of the ODD (Operational Design Domain), which describes the specific operating conditions in which the vehicle is supposed to be operated, for example, road types or even weather conditions. But how can we generate the right test scenarios?
Hans Jürgen Holberg
Chief Sales Officer (CSO)
BTC Embedded Systems AG
hans.j.holberg@btc-embedded.com
We provide intelligent and automated test solutions which enable our customers to deal with the growing complexity of embedded software while achieving high quality in compliance with the ISO 26262 standard.
Copyright © 2024 BTC Embedded Systems