Requirements-driven Test Generation for Autonomous Vehicles with Machine Learning Components

I. INTRODUCTION

• Autonomous-driving systems lack universally agreed testing methods, while ML-component testing often omits the system’s closed-loop behavior.ML behavior is difficult to characterize across circumstances, and component-level attacks may not have the same effect in a closed loop.Source: §I · pp. 1–2
• Sim-ATAV tests closed-loop properties of autonomous-driving systems with ML components by perturbing scenario configurations and applying covering arrays and requirement falsification.The earlier version searched scenario configuration space rather than image space and extended covering arrays to closed-loop CPS applications with embedded ML.Source: §I · p. 2
• The framework adds lidar, radar, and sensor fusion models to search for sensor-interaction faults and component-level failures that lead to system-level failures, including collisions.Source: §I · p. 2
• Modeling whether agents are visible to sensors supports temporal requirements, such as correct classification within 1 second after lidar visibility begins.Source: §I · p. 2
• Adversarial search over agent trajectories supports automatic identification of corner cases that traditional simulation-based techniques can be difficult to find.Source: §I · p. 2
• The authors released Sim-ATAV as a publicly available add-on to the S-TaLiRo falsification toolbox for Matlab®.Source: §I · p. 2

II. RELATED WORK

• Scenario- and data-driven approaches address deployment testing, while model-based verification and test generation address early design exploration and automated fault detection.Model-based approaches may simplify or omit sensors, overlooking interactions such as changes in effective sensing range during hard turns.Source: §II · p. 2
• Prior work raises questions about physically generated adversarial inputs and their system-level safety effects; this paper extends earlier methods to multi-sensor systems and requirements-guided testing.Some methods analyze static-image counterexamples before closed-loop simulation, while others search directly over closed-loop behavior.Source: §II · p. 3

III. PRELIMINARIES

• The simulation setting models the ego vehicle, perception, controller, and environment, with scenario behavior computed by a simulator.The environment can include roads, buildings, pedestrians, and agent vehicles.Source: §III · p. 3
• A test scenario maps initial conditions, timed inputs, parameters, and simulation duration to an output signal; the setup includes continuous and discrete state and parameter values.Source: §III · p. 3
• The illustrative two-vehicle scenario treats the ego car’s ACC as a black box and searches the adversarial vehicle’s acceleration and powertrain mode; the example output includes a collision near time 4.Source: §III · p. 4

A. Signal Temporal Logic

• STL predicates and Boolean and temporal operators express properties such as bounded reachability, safety, and reactive requirements over signals.Intervals on temporal operators encode timing constraints.Source: A. Signal Temporal Logic · p. 4
• The paper uses discrete-time STL semantics so sample timing and events can be represented with the Next operator.For example, π ∧ ⃝¬π represents a high-to-low event; Eventually and Always operators are derived syntactically.Source: A. Signal Temporal Logic · pp. 4–5
• Robust semantics gives a trace a positive value when it satisfies an STL formula and a negative value otherwise, with magnitude describing a satisfaction neighborhood.Unlike Boolean semantics, it provides a real-valued measure of how robustly a trace satisfies or violates a requirement.Source: A. Signal Temporal Logic · p. 5
• A metric supports signed distance from a predicate set: membership is positive, non-membership negative, and greater distance from the boundary means more robust membership.Experiments use Euclidean distance, although the text allows other metrics.Source: A. Signal Temporal Logic · p. 5
• −1.0841 robustness shows that the requirement for vehicle separation to remain positive after time 5 is violated, with the worst violation at time 5.2446.The requirement is represented by ϕ = □[5,∞)(y(a) − y(e) > 0).Source: A. Signal Temporal Logic · p. 5

B. Robustness-Guided Falsification

• For a system Σ and requirement ϕ, verification seeks positive robustness for every trace in L(Σ).The robustness metric acts as a fitness function for individual simulations.Source: B. Robustness-Guided Falsification · p. 5
• The desired verification condition is that the infimum robustness over all traces exceed a positive threshold ε.The passage states the target as infσ∈L(Σ)[[ϕ]]d(σ) > ε > 0.Source: B. Robustness-Guided Falsification · p. 5
• Since this verification problem is generally not algorithmically solvable, the method instead searches for a trajectory that falsifies the requirement.A falsifying trace has robustness below zero.Source: B. Robustness-Guided Falsification · p. 5

C. Falsification and Critical System Behaviors

• STL falsification seeks a system trace σ whose robustness for ϕ is below zero.The section focuses on identifying critical system behaviors, including falsifying traces.Source: C. Falsification and Critical System… · pp. 5–6
• One approach poses the falsification problem as global nonlinear optimization.The passage identifies this as a successful approach to finding falsifying traces.Source: C. Falsification and Critical System… · p. 6
• A converged local minimizer with negative robustness is a counterexample that can be used for debugging or training.In the robustness heatmap example, points below zero are counterexamples to the specification.Source: C. Falsification and Critical System… · p. 6

D. Covering Arrays

• Covering arrays test every t-way combination of parameter values with a bounded test set, but can miss faults requiring more than t parameters.Their strength t can be selected to fit the testing budget; the paper pairs them with continuous-parameter falsification.Source: D. Covering Arrays · p. 6
• Four configurations show that DNN detection errors can depend on combinations of vehicle type and vehicle and pedestrian-pants colors.The paper describes cases where changing colors or vehicle type changes which objects are detected, rather than errors following a simple color rule.Source: D. Covering Arrays · p. 6

IV. REQUIREMENTS

• The five STL requirements cover system-level safety, subsystem behavior, sensor-to-system safety, and driving-comfort performance.Each requirement is intended to target a specific safety or performance aspect and inform controller design or testing.Source: §IV · p. 6, A. STL Requirements · pp. 6–7

A. STL Requirements

• R1 requires that the ego vehicle avoid collisions with each object, although the paper warns this can be overly restrictive in adversarial tests.The authors note that sufficiently adversarial moving-object trajectories may make avoidance impossible; scenarios may instead restrict the requirement to static objects or add avoidability assumptions.Source: A. STL Requirements · p. 7
• R2 requires a visible but undetected object to be detected or become invisible within t1 time units.It applies to a sensor or the combined perception system.Source: A. STL Requirements · p. 7
• R3 limits how long a visible object may remain undetected or localized with error above ϵerr.Within t1, the object must become invisible or be detected with localization error below the threshold.Source: A. STL Requirements · p. 7
• R4 tests whether a sensor-related fault is followed by a system-level fault, using a short post-fault time window.A violation indicates temporal correlation, not necessarily that the sensor fault caused the system fault.Source: A. STL Requirements · p. 7
• R5 treats excessive or frequent braking without predicted collision as a driving-comfort concern.It limits prolonged excessive braking when no collision is predicted and repeated brake on-off events occurring less than t2 apart.Source: A. STL Requirements · pp. 7–8

B. Development Process Support

• Falsified requirements should be traced back to the conditions that caused the violation, such as anomalous speed or erratic motion in a collision case.The authors describe these behaviors as useful feedback for control designers.Source: B. Development Process Support · p. 8
• Visible-obstacle detection is a relatively easy real-world experiment because it is a sensor-level requirement decoupled from other components.The requirement is violated if the sensor fails to detect the object within the specified interval.Source: B. Development Process Support · p. 8
• Localization checks concern both ego-vehicle pose and estimates of other agents, for which GPS alone may be insufficient because its signal can jump unpredictably.The paper describes dynamically refining ego pose through landmarks and estimating other agents' positions, particularly those in the planned path.Source: B. Development Process Support · p. 8
• The sensor-fault robustness requirement excludes system failure only within a specified short interval after the fault.The authors characterize this as a practical but scope-limiting condition.Source: B. Development Process Support · p. 8
• A brake-frequency requirement is one possible way to specify ride comfort, and the authors suggest refining it for particular passenger groups.They mention fuzzy-set approaches and elderly passengers as an example.Source: B. Development Process Support · p. 8

• Sim-ATAV provides a virtual environment with ego and agent vehicles, roads, and modeled CCD camera, lidar, and radar data feeding a vehicle-control system.The controller sends actuation commands back to the simulator, which updates the physics iteratively.Source: §V · pp. 8–9
• For perception, Sim-ATAV uses SqueezeDet for camera images, clusters lidar points, estimates radar object types, and fuses detections and trajectories.The framework also includes simple controller and planner algorithms, which can be replaced with production versions.Source: §V · pp. 9–10
• The environment uses Webots to model vehicle physics and render virtual-camera images corresponding to data from a front-mounted camera.The vehicle-control models are implemented in Python and simplified because the investigation evaluates testing methods rather than a production control design.Source: §V · pp. 9–10
• Covering arrays generate discrete or discretized-parameter test cases, and the most promising case seeds S-TaLiRo falsification optimization.Simulation traces are evaluated with a cost function; Fig. 10 illustrates the combinatorial-testing and falsification flows.Source: §V · p. 10, Figure 10 · p. 10

• The framework is evaluated in three driving scenarios chosen to be challenging for autonomous driving and analogous to plausible real-world situations.The authors note that designers must identify crucial scenarios and that thorough simulation testing spans a wide range of critical driving situations.Source: §VI · p. 10
• For each scenario, the evaluation considers selected requirements and how the results can enhance the development process.The section concludes with a summary of results.Source: §VI · p. 10

Scenario 1

• Scenario 1 places a jaywalking pedestrian crossing right-to-left in front of the ego vehicle on a two-lane straightaway with parked cars along the right side.The setup is analogous to a Euro NCAP vulnerable-road-user protection test.Source: Scenario 1 · p. 10, Figure 11 · p. 11
• The parameterized case varies ego speed, lane position, pedestrian speed, agent-car model and colors, and the pedestrian’s clothing colors.The ego vehicle is positioned for a 1.4-second time-to-collision when the pedestrian is directly ahead; selected ranges challenge DNN detection and braking performance.Source: Scenario 1 · pp. 10–11
• Model M1 is evaluated against R1, R2, and R4 to demonstrate automatic identification of system-level, sensor-level, and sensor-to-system-level behaviors.Source: Scenario 1 · p. 11

Scenario 2

• In Scenario 2, the ego vehicle turns left while one opposing vehicle runs a red light and another makes a legal left turn, creating potential collision situations.The search varies ego speed and distance, both agents’ distances and speeds, and their lateral positions.Source: Scenario 2 · p. 11
• Model M2 is evaluated against R4 to identify collisions directly correlated with unacceptable sensor-processing or trajectory-estimation performance, rather than collisions not attributable to ego-vehicle behavior.The resulting cases can help designers debug specific control-algorithm aspects.Source: Scenario 2 · p. 11

Scenario 3

• In Scenario 3, the ego and one opposing agent both turn left; the search varies their speeds and target trajectories through the intersection.The scenario omits Agent 1 from Scenario 2.Source: Scenario 3 · pp. 11–12
• Model M3 is evaluated against R5 for unnecessary emergency braking that can reduce ride quality, a concern even when collision falsification is unlikely.The vehicles’ momentary movement toward each other during the turns can lead the emergency-braking algorithm to judge a collision imminent; such cases can flag overly conservative behavior.Source: Scenario 3 · p. 12

Covering array and falsification on Model M1

• The Model M1 approach runs 195 mixed-strength covering-array tests, then uses simulated annealing from low-positive-robustness cases for up to 300 additional simulations per requirement.The array uses 3-way coverage for ego speed and lateral position, pedestrian speed, and agent-vehicle model, and 2-way coverage for other parameters.Source: Covering array and falsification on… · p. 12
• R1 had 67 covering-array failures plus 5 found in falsification; R2 had 65 plus 8, and R4 had 67 plus 12.Table I summarizes requirements, models, sensors, testing approaches, and results.Source: Covering array and falsification on… · p. 12, Summary of Test Results · p. 12, Table I · p. 13

Analysis of robustness values on the falsification of Model M2

• For Model M2, Sim-ATAV found a falsifying example in 58 simulations; the trajectory shows incorrect localization delayed collision prediction until braking could not prevent impact.The stochastic optimizer's per-run robustness is non-monotonic, while the best robustness so far is non-increasing; the search stops when robustness becomes negative.Source: Covering array and falsification on… · pp. 12–13, Figure 13 · p. 13
• Even non-falsifying cases with low robustness are close to violating a requirement and may warrant closer attention from system designers.The framework computes robustness automatically and uses it to guide test cases toward falsification.Source: Covering array and falsification on… · pp. 12–13

A visual analysis of a falsifying simulation trajectory from Model M3

• For Model M3, Sim-ATAV found an R5 falsifying example in 232 simulations: the first requirement part passed, but a sequence of three brake releases falsified the second.The analysis evaluates predicted future distance and brake power against R5 thresholds, then traces the brake-release sequence that makes R5 false.Source: A visual analysis of a falsifying… · pp. 13–14

VII. CONCLUSIONS

• Sim-ATAV models camera, lidar, and radar inputs in a closed-loop autonomous-driving simulation and combines covering arrays with simulated annealing to search for critical behaviors.Camera images are rendered synthetically and processed using a pre-trained DNN.Source: §VII · p. 14
• The conclusion frames the framework's role as finding critical vehicle behaviors through discrete-parameter coverage and corner-case search.The stated methods are covering arrays for combinations of discrete parameters and simulated annealing for corner cases.Source: §VII · p. 14
• Future work includes using counterexamples to retrain the DNN-based perception system and making scene rendering more realistic with other tools.The paper also notes that formal temporal-logic requirements may be unfamiliar to many test engineers and proposes investigating visual specification languages.Source: §VII · p. 14