1 Introduction↩︎

Autonomous Driving Systems (ADS) are safety-critical software systems, and assuring their safety requires rigorous testing. Simulation-based testing has been widely studied as a mechanism for automatically generating diverse, potentially critical driving scenarios [1], [2]. However, despite significant progress in scenario generation, the community still lacks a systematic, objective criterion for determining when test generation can be safely stopped.

What makes it more challenging is that safety is an emergent system-level property. It depends on the interactions among multiple modules of ADS (e.g., perception, prediction, planning, and control modules), not merely on the standalone reliability of each component. As a result, test adequacy criteria that focus exclusively on individual modules would fail to capture system-level safety risks arising only from component interactions.

Mutation testing [3], [4] offers an appealing foundation for adequacy assessment because it makes test effectiveness claims falsifiable [4]. By systematically injecting small faults into a software system to create mutated versions (mutants) and checking whether a test suite distinguishes the mutants from the original system, mutation testing provides concrete evidence of which faults the tests can and cannot detect. A test suite that fails to distinguish specific mutants reveals precise inadequacies and, by implication, potential blind spots with respect to corresponding real faults.

However, directly porting mutation testing for source code [5], [6] or Deep Learning (DL) models [7], [8] to ADS is insufficient. This is because ADS have a mix of traditional software and DL components, and their interactions during continuous closed-loop execution, rather than the individual components, can lead to safety violations. In this vision paper, we argue for a paradigm shift from component-level code/DL mutation to system-level, safety-aware mutation. Our vision statement is as follows:

The rest of the paper is organised as follows. Section 2 provides background on mutation testing, ADS architecture, existing coverage metrics, and safety engineering principles. Section 3 outlines our vision for Safety-Aware Mutation Testing (SAMT) for ADS, detailing the key innovations and process. Section 4 discusses open challenges and future research directions for realising this vision. Finally, Section 5 concludes the paper.

2 Background↩︎

2.1 Mutation Testing↩︎

Mutation testing is a fault-based technique designed to evaluate the adequacy of a test suite by systematically injecting artificial defects, called mutants, into a software artefact using predefined transformation rules known as mutation operators (e.g., replacing ‘+’ with ‘-’ or deleting a program statement). A test suite is then executed against both the original program and its mutants; if a test case yields a different observable outcome for a mutant compared to the original, that mutant is considered killed. Killing all mutants provides a falsifiable assertion of the test suite’s effectiveness at detecting real-world faults [4]. A key hypothesis underpinning this technique is the coupling effect, which posits that tests capable of killing simple mutants are also likely to detect more complex, real faults [9]. This effect has been empirically validated in traditional software testing contexts [10]–[12].

With the advances of DL, researchers have developed specialised mutation techniques for DL models (e.g., perturb neural network weights, remove neurons, or manipulate training data) [7], [8]. While these techniques could effectively evaluate the localised robustness of an isolated DL model, they are fundamentally inadequate for testing an entire ADS.

A persistent challenge in the mutation testing paradigm, regardless of the mutated artefact, is the equivalent mutant problem: mutants that are syntactically modified but remain semantically identical to the original. The presence of equivalent mutants can lead to false negatives in test adequacy assessments. However, determining whether a mutant is equivalent is generally undecidable [13]. In practice, researchers have developed various heuristics to identify and filter out equivalent mutants [14]–[16].

[17] recently proposed Property-Based Mutation Testing (PBMT), which relates mutation to system-level safety requirements. Targeting Simulink data-flow models, PBMT effectively filters out semantically irrelevant faults by anchoring kill criteria to explicit temporal specifications. However, its scope remains confined to internal block or signal perturbations within monolithic architectures, overlooking emergent hazards arising from degraded inter-module communication in modern modular systems. Furthermore, PBMT does not systematically derive fault injections from formal hazard analyses, nor does it account for closed-loop control dynamics. These limitations underscore a critical need for mutation testing frameworks that operate at the system-interaction level and are grounded in architectural safety constraints rather than in isolated component outputs.

2.2 ADS Architecture↩︎

Broadly speaking, ADS can be categorised into End-to-End (E2E) and module-based. E2E ADS, such as NVIDIA Dave2 [18], treat the system as a single DL model that processes sensor data (e.g., camera images) and directly outputs vehicle control commands (e.g., steering and acceleration). Despite its simplicity, it requires substantial training data to achieve acceptable performance and suffers from limited explainability.

In contrast, module-based ADS, such as Apollo [19] and Autoware [20], divide the driving task across multiple dedicated modules (e.g., perception, prediction, planning, and control). This modularity offers essential explainability and debugging capabilities for safety-critical systems.

Communication among these modules is implemented via a publish-subscribe architecture. Each module publishes its output as messages to specific topics and subscribes to others to receive the necessary messages. For example, the perception module publishes bounding boxes for detected objects, which the planning module subscribes to in order to compute safe trajectories. This design enables non-blocking communication and module hot-swapping, which are vital for the real-time operation of an ADS [21].

Considering the industrial relevance of module-based ADS, we focus on them in this paper. Nevertheless, the proposed vision can be extended to E2E ADS as long as the notion of messages between functionally distinct components can be defined.

2.3 Coverage Metrics for ADS Testing↩︎

Although traditional code coverage metrics (e.g., statement or branch coverage) can assess the adequacy of test suites for deterministic software components in an ADS, they are insufficient for DL-enabled components whose logic is derived from training data.

To address this, researchers have proposed structural coverage metrics for DL models, such as neuron coverage [22] and its variants [23]. However, these metrics still focus on isolated components and fail to account for module interactions.

More recently, researchers have proposed ADS-specific coverage metrics, such as scene coverage [24] and scenario coverage [25]. However, these approaches largely treat the ADS as a black box. Because they do not account for the ADS under test’s internal architectural state or its specific fault-handling mechanisms, they cannot verify that the system’s internal safety boundaries have been adequately exercised.

2.4 Safety Engineering and Systems Thinking↩︎

In complex cyber-physical systems, safety and reliability are distinct properties [26]. A component can be highly reliable (meeting its specifications) but still lead to an unsafe system state. For example, consider a perception module that incorrectly identifies a pedestrian as a shadow due to glare. If the planning module’s logic strictly follows the “drive through shadows” policy, the vehicle will hit the pedestrian. From a reliability standpoint, one might argue the perception module “failed” and requires more training data. However, perception can never be 100% perfect in all edge cases in the real world.

To address this issue, modern safety engineering calls for systems thinking, viewing safety as a control problem rather than a component reliability problem. This involves defining safety requirements (or safety constraints), i.e., rules that specify what the system must not do (e.g., the vehicle must never proceed if the path’s safety is uncertain). Frameworks like System-Theoretic Process Analysis (STPA) [26] are used to systematically identify Unsafe Control Actions (UCAs), instances where a module’s output can lead to the violation of safety constraints (e.g., an instance where the planning module issues a “maintain speed” command when the perception module’s object classification confidence falls below a safe threshold). By applying systems thinking, we can shift focus from fixing the perception module to designing safer component interactions, such as enforcing high-confidence uncertainty propagation to the planner to safely handle perception limitations.

3 Vision: Safety-Aware Mutation Testing↩︎

This section outlines the vision for Safety-Aware Mutation Testing (SAMT) for ADS. The overall process, illustrated in Figure 1, consists of the following steps.

(1) Mutant Generation: Apply a library of safety-aware mutation operators (§ 3.2) to systematically create mutants by injecting faults into the messages shared between ADS modules, simulating realistic interaction faults (§ 3.1).

(2) High-Fidelity Execution: Execute the mutants against the test suite in a high-fidelity simulation environment (e.g., CARLA [27]). To reduce computational overhead, execution can be stopped as soon as a mutant is definitively killed.

(3) Equivalent Mutant Removal: Analyse the execution results to determine whether mutants are killed, not killed, or equivalent (§ 3.3).

(4) Test Suite Improvement: If all non-equivalent mutants are killed, the test suite is deemed adequate. Otherwise, surviving mutants provide concrete evidence of test suite blind spots, guiding further scenario generation (§ 3.4).

(5) Safety Assessment & Repair: Once the test suite is adequate, verify the original ADS against it. Passing implies the ADS satisfies the defined safety requirements, while failing highlights violations that guide downstream debugging and architectural repair (§ 4.4).

In the following subsections, we elaborate on the above steps, along with key innovations.

3.1 Shift from Components to Their Messages↩︎

A key innovation in our vision is the shift from mutating each component (e.g., the planning module’s source code) to mutating the messages exchanged between ADS modules. For example, we can mutate the perception module’s output by removing detected objects, adding phantom objects, or introducing spatial perturbations to bounding boxes. This directly simulates the interaction faults and degraded feedback loops that cause system-level accidents.

Furthermore, given the closed-loop, continuous-control nature of ADS, we can extend mutation operators with temporal properties, such as the duration and triggering condition of their effects. For example, a mutation operator could suppress an obstacle specifically between simulation timestamps \(t=2\) and \(t=3\). This allows SAMT to additionally simulate subtle functionality limitations that are critical for realistic ADS evaluation.

3.2 Mutation Operators Derived from Safety Analysis↩︎

Mutation operators must represent genuine safety threats rather than arbitrary data perturbations. We propose systematically deriving them through top-down safety engineering.

First, hazard analysis techniques like STPA are applied to system-level safety constraints to identify abstract Unsafe Control Actions (UCAs) and their underlying causal factors, such as “missing vehicle-in-front data from the perception module”. These causal factors can then be directly mapped to concrete, parameterised message-level mutation operators. For the factor above, the corresponding mutation operator intercepts the perception-to-planning topic and removes a parameterised entity. By grounding mutation operators in formal hazard analysis, SAMT ensures every generated mutant simulates a realistic component interaction failure.

3.3 Equivalent Mutant Detection via Propagation Analysis↩︎

The equivalent mutant problem (§ 2.1) can be exacerbated by the complex safety mechanisms within ADS, which can often absorb internal faults without causing safety violations. To resolve this problem, we propose evaluating mutants using propagation analysis of the continuous control states:

• Weakly killed: The mutated message successfully propagates through and alters the control module’s output state (e.g., the steering angle or throttle trace diverges from the original ADS execution), but results in no difference in safety outcomes compared to the original ADS.

• Strongly killed: The state divergence forces the mutant to violate a safety constraint that was otherwise maintained in the original execution.

If a mutant is never weakly killed by any test scenario in the suite (i.e., the control traces remain identical to the original executions), we can approximate that the mutant is equivalent (safe-by-design). Otherwise, the mutant is killable, meaning a safety-adequate test suite must contain at least one scenario that strongly kills it.

3.4 Mutation-Guided Test Suite Improvement↩︎

If a non-equivalent mutant survives, it provides concrete evidence of a specific inadequacy in the test suite. We can automate the generation of new test scenarios that specifically target the surviving mutant, thereby iteratively improving adequacy. Search-Based Software Testing (SBST) [28] can be effective here. SBST has been successfully used in traditional mutation testing to automatically generate unit tests that maximize the likelihood of killing target mutants [29], [30]. Applying this to an ADS may require adapting the fitness function to search the continuous ODD parameter space (e.g., weather, NPC trajectories) to efficiently find the environmental entities that escalate a weak kill into a strong kill.

4 Open Challenges↩︎

This section outlines several open challenges and a future research agenda for realising the vision.

4.1 Empirical Validation of the Coupling Effect in ADS↩︎

The coupling effect is a fundamental hypothesis in mutation testing, but it has primarily been validated only in traditional software contexts. In the ADS context, where safety violations often arise from complex component interactions rather than isolated failures, it is crucial to empirically validate whether this effect still holds. Future research must design controlled experiments to assess whether tests that kill simple, single-message mutants are reliably capable of detecting more complex, real-world interaction faults. While recent work [31] has presented initial empirical studies of real-world bug-fix patterns in ADS, the community urgently needs a comprehensive, open-source catalogue of real-world ADS faults, similar to Defects4J for Java [32]. This foundational validation is essential to justify the use of message-level mutation as a definitive adequacy criterion for ADS certification.

4.2 Comprehensive Mutation Operator Library for ADS↩︎

While specific safety requirements might vary between ADS architectures, the underlying physics and closed-loop control dynamics share commonalities. A major future direction is for the community to establish a standardised set of generic ADS safety requirements, which can serve as the foundation for a universally applicable library of parameterised mutation operators (e.g., spatial offset errors, temporal delays, classification degradation).

To achieve this, we must systematically link abstract safety analysis artefacts to executable code. This requires developing, for example, an STPA-to-Mutant Mapping Layer, where abstract UCAs are translated into formal, parameterised interfaces that can be automatically instantiated into concrete safety-aware mutants.

4.3 Efficient Equivalent Mutant Detection↩︎

Detecting “safe-by-design” equivalent mutants via full-system propagation analysis requires executing the high-fidelity simulation, which is computationally expensive. A critical open challenge is developing advanced, lightweight propagation analysis techniques that can be applied before running all mutants against a test suite.

In traditional software programs, for example, program slicing can be used to determine whether a mutated statement has the potential to affect output variables [14]. Similarly, causal data-flow analysis could identify “masking” effects without running a full simulation for some mutants. For example, if the ADS under test uses sensor fusion heavily, weighting LIDAR over camera inputs, mutants relevant to camera inputs would be masked.

4.4 Downstream Applications: Fault Localisation and Repair↩︎

Moving beyond test adequacy, the execution traces of safety-aware mutants offer rich data for downstream applications like automated fault localisation and system repair. In traditional software and DL models, mutation-based fault localisation [33]–[35] identifies suspicious program statements and model layers by correlating them with killed mutants. While some ADS-specific fault localisation [36], [37] and temporary repair techniques [38] exist, they do not yet leverage mutation analysis. Future research should integrate SAMT traces (e.g., contrasting weakly killed vs strongly killed paths) with existing localisation approaches to pinpoint exactly which module interactions are failing in the original ADS. Furthermore, surviving mutants could serve as continuous fitness functions for automated program repair tools aimed at synthesising permanent, safe control-loop patches.

4.5 Nondeterminism of ADS Simulation↩︎

Although high-fidelity simulators like CARLA provide realistic environments, they exhibit inherent nondeterministic behaviour due to various reasons, including floating-point arithmetic errors, runtime scheduling variations, and game engine setup [39], [40]. This nondeterminism can cause natural-state divergences, making it difficult to determine whether a mutant is killed. Future research must investigate statistical methods, such as threshold-based equivalence checking, to reliably assess propagation analysis over multiple simulator iterations with statistically rigorous confidence intervals.

5 Conclusion↩︎

The current landscape of ADS testing suffers from a common misunderstanding: the conflation of component reliability with system-level safety. As long as test adequacy criteria remain focused on isolated code structures or deep learning models, the community will struggle to objectively determine when scenario generation can be safely stopped.

To bridge this gap, we propose a paradigm shift toward Safety-Aware Mutation Testing (SAMT). Instead of mutating static code or DL models, SAMT injects safety-critical faults into the messages communicated between ADS modules. This message-level approach captures a wide range of realistic problems. It naturally covers traditional component crashes (since a failed component simply stops sending messages or sends corrupted data), while also exposing the subtle interaction failures that traditional metrics miss.

Realising this vision requires a collective community effort to overcome various open challenges, from empirically validating the coupling effect in ADS to managing simulation nondeterminism. Ultimately, embedding systems thinking into the mutation testing pipeline offers a falsifiable, objective foundation not only for assessing test adequacy but for driving the automated generation, localisation, and repair of next-generation autonomous systems.

Acknowledgment↩︎

This work was supported by the Institute of Information & Communications Technology Planning & Evaluation(IITP) grant funded by the Korea government(MSIT) (No. RS-2025-02218761, 50%) and by the Engineering and Physical Sciences Research Council (EPSRC) [EP/Y014219/1].

References↩︎