ADAS Test Suite with the Driving Scenario Designer

The problem

ADAS functions are validated against hundreds of traffic situations, and building each one by hand for every software change does not scale. Engineers therefore keep a scenario library with clear pass criteria and rerun it automatically. This project teaches that discipline on a small scale with MATLAB tools a student can use on a laptop.

Objectives

• Define a small operational design domain and the function under test.
• Build at least eight parameterised scenarios in the Driving Scenario Designer.
• Add simulated radar and camera detections to the ego vehicle.
• Write automatic pass/fail checks based on time-to-collision and minimum gap.
• Run the suite in batch and report results per scenario.

What you need

Key concepts

Test scenario

A described traffic situation: road layout, actors, their trajectories and speeds, and the conditions that make the test pass or fail.

Time-to-collision (TTC)

Gap to the lead object divided by closing speed. It shows how urgent a situation is and is a common pass criterion for warning and braking functions.

Operational design domain (ODD)

The conditions a function is designed for, such as road type, speed range and weather. Scenarios should cover the ODD and a little beyond its edges.

Parameterised scenario

One scenario template whose speeds, gaps or timings are variables, so a sweep can generate many concrete test runs from it.

Step-by-step guide

1. 1

   Define the function and its ODD

   Choose a simple function under test, such as a forward collision warning (FCW) that warns when TTC to the closest in-lane object falls below 2.5 s. Write its ODD: dry highway or urban road, ego speed 20–80 km/h, daylight, one lead vehicle or pedestrian. List what counts as a pass for each scenario type: warning issued before TTC drops below a threshold, no warning when the lead vehicle is in another lane. Give each requirement an ID so test results can point back to it.

   Checkpoint: A one-page specification with the function, its ODD and numbered pass criteria.

2. 2

   Learn the Driving Scenario Designer

   Open the app with drivingScenarioDesigner and rebuild one of the shipped prebuilt scenarios to learn the workflow: add a road by clicking centre points, set lane widths and markings, add the ego car and a target car, then place waypoints and set speeds. Run the simulation and use the bird's-eye plot to check motion. Save the session file so that every later scenario starts from a consistent road and ego configuration.

   Checkpoint: A saved session with a straight two-lane road, an ego car and a target that move as intended.

3. 3

   Build the scenario catalogue

   Create at least eight scenarios: stationary car ahead, slower moving car ahead, lead car braking hard, cut-in from the adjacent lane, cut-out revealing a stationary car, car in the adjacent lane on a curve (a false-alarm check), pedestrian crossing from the kerb, and a following-distance case with no hazard. Name each with an ID and save them as separate session files. Keep speeds and gaps realistic for the ODD and note the expected outcome of each before running anything.

   Checkpoint: Eight or more saved scenarios, each with a written expected outcome.

4. 4

   Add sensors to the ego vehicle

   In the app, add a front radar and a front camera to the ego car. Set the radar's field of view and range, and the camera's detection range and accuracy, to modest values. Run each scenario and check the detections on the bird's-eye plot, including when the target leaves the field of view. Note that these are statistical detection models, not raw images or waveforms, which is enough for testing decision logic.

   Checkpoint: Detections appear on the target in every scenario and disappear when it leaves the sensor coverage.

5. 5

   Export and parameterise

   Use Export > MATLAB Function so that each scenario becomes a function that returns a drivingScenario object and sensor objects. Edit the generated functions so ego speed, target speed, initial gap and manoeuvre timing are input arguments with default values. Write a small wrapper that calls any scenario by ID with a parameter structure. Check that calling a function with its defaults reproduces the scenario drawn in the app.

   Checkpoint: Each scenario can be created from a script with chosen speeds and gaps, and defaults match the app version.

6. 6

   Connect the function under test

   Implement the FCW logic as a MATLAB function that takes the detections, keeps only those in the ego lane using lateral position, and computes TTC from range and range rate. Run the scenario in a loop with advance(scenario), feed sensor outputs to the function and log warnings with timestamps. Alternatively place the logic in Simulink and read the scenario with the Scenario Reader block. Keep the logic simple; the focus is the test suite.

   Checkpoint: Running the stationary-car scenario produces a logged warning at a plausible time before impact.

7. 7

   Write automatic pass/fail checks

   From the ground-truth actor poses, compute the true gap, closing speed and TTC at every step, independent of the sensors. For each scenario, evaluate the criteria from step 1: warning time against required TTC, no warnings in false-alarm scenarios, and whether a collision would happen without intervention. Detect collisions by checking overlap of actor bounding boxes. Return a result structure with pass or fail, the margin and the requirement ID tested.

   Checkpoint: Each scenario returns a pass/fail result with a numerical margin, checked by hand for two cases.

8. 8

   Run the suite in batch

   Write a script that runs every scenario across a small parameter grid, for example three ego speeds and three gaps, and collects results into a table. Plot a pass/fail map for each scenario against speed and gap. Change one parameter of the FCW function, such as the TTC threshold, and rerun to show how the suite catches regressions. Optionally load the scenarios into Simulink Test as test cases with the same criteria.

   Checkpoint: A results table and pass/fail maps produced by one command, rerun after a deliberate change.

9. 9

   Report the suite

   Write up the ODD, the scenario catalogue with diagrams from the bird's-eye plot, the pass criteria and the results. Show which scenarios found weaknesses, for example late warnings for cut-ins or false alarms on curves, and explain why. State the limits: idealised sensor models, no weather and no road-surface effects. Include the scenario functions and the batch script so another student can rerun everything and add new cases.

   Checkpoint: A report and a script that reproduces every result in it.

Testing & validation

• Each scenario's default parameters reproduce the drawn scenario.
• Pass/fail decisions checked by hand for a sample of runs.
• False-alarm scenarios produce no warnings with the tuned threshold.
• A deliberate change to the function changes the suite results as expected.

Expected results

A parameterised, scripted scenario suite with automatic pass/fail checks and a short report showing where a simple FCW function passes and fails.

Take it further

• Add an AEB stage that commands braking and check collision avoidance.
• Import a road from ASAM OpenDRIVE to test on a real layout.
• Add sensor noise and missed detections to test robustness.
• Convert the suite into Simulink Test test cases with requirement links.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.