Scenario Generation
How can I avoid the test explosion problem?
Simulating every parameter combination isn't just slow — it's impossible.
Simulating all parameter combinations ("brute force") leads to an unfeasibly high number of runs. Variation strategies based on random algorithms, on the other hand, won't sufficiently cover the interesting, safety-critical corner cases. We need a smarter approach — one that still leads to a good level of confidence in the safety of the system.
How many test scenarios do I need?
Moving from an abstract high-level scenario to concrete traffic scenarios that can be simulated means defining values for a large number of parameters — not limited to the abstract scenario's own parameters, but also the coverage of the Operational Design Domain (ODD): the specific conditions the vehicle is meant to operate in, such as road types or weather conditions.
Assume just 100 parameters with only 3 different values each.
Intelligent test scenario generation
Given this complexity, intelligent test scenario generation should achieve the required confidence in the system's safety without simulating every possible parameter combination — by focusing on the more interesting scenarios and generating fewer of the uninteresting ones. "Interesting" can mean scenarios that are very likely to happen, or scenarios that contain safety-critical situations — meaning fewer test cases for situations that are both unlikely and not safety-critical. We achieve this distribution with a two-step approach, each with its own test-end criteria.
Static probability-based variation
The first step separates parameter ranges into manageable parts following a variation strategy such as probabilistic distributions, so we get more of the likely scenarios and fewer of the unlikely ones. Each parameter's value range is sliced into individual ranges — similar to "equivalence classes" in ISO 26262 — for example a velocity range of 0–60 km/h sliced into 0–40, 40–50 and 50–60 km/h, each with its own defined probability. For each scenario variant, multiplying these probabilities gives a resulting probability, and a user-defined threshold controls which scenarios actually get executed.
Dynamic criticality variation: weakness detection
To achieve high confidence in behavior during safety-critical situations, the second variation step explores the parameter space using AI technology to detect weaknesses specific to the system-under-test. A weakness is formally defined by a weakness function evaluated after each simulation run — for example, time-to-collision, where smaller values mean a more safety-critical situation. Weakness detection can be described as an optimization problem: finding local and global maxima in an n-dimensional parameter space. The outcome is either a concrete scenario leading to critical or unwanted behavior, or a probabilistic report of the absence of weaknesses — resulting in fewer test cases for less-critical situations, and ensuring the total number of test cases never explodes.
A cut-in scenario, three iterations to a critical trajectory.
Consider a cut-in scenario monitored by Time-to-Collision (TTC). The weakness function targets situations where the minimum TTC drops to 2 seconds or below — returning a score of 1 once that threshold is breached, and 0 once TTC exceeds 10 seconds.
Exploring the parameter space, the algorithm finds a critical trajectory within three iterations — a coordinated combination of parameter values that pushes TTC below the 2-second safety threshold. The result is visualized alongside the lateral vehicle positions and the TTC signal as it degrades through the critical lane-change phase.
- Weakness function
- score = 1 if MinTTC ≤ 2s, else 0
- Search space
- n-dimensional parameter space
- Result
- Critical trajectory found in 3 iterations
Talk to our engineering team.
Tell us where your engineering problem actually is. We'll tell you whether an evaluation license, a workshop, or a conversation is the right next step.