Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

MoDitector: Module-Directed Testing for Autonomous Driving Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-08 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read MoDitector is a search-based testing method that claims to generate collision scenarios whose root cause is a single module of an autonomous driving system, by directing the search with module-specific oracles and feedback.

desk verdict Genuinely new module-directed ADS testing objective, but the MICS oracle only checks the last 0.5s while the formal definition requires all scenes, making headline counts window-dependent. read the letter →

arxiv 2502.08504 v1 pith:476WKNFZ submitted 2025-02-12 cs.SE

Renzhi Wang , Mingfei Cheng , Xiaofei Xie , Yuan Zhou , Lei Ma This is my paper · ORCID
classification cs.SE
keywords module-inducedcriticalscenariosautonomousdrivingsystemtestingsearch-basedfuzzingrootcauseanalysismodule-specificoraclesscenariogenerationsimulation-based
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

MoDitector is a search-based testing method for module-based autonomous driving systems that aims to generate collision scenarios whose root cause is one specific module—perception, prediction, planning, or control—rather than just any system failure. The paper defines such scenarios as Module-Induced Critical Scenarios (MICS) and argues that existing black-box fuzzers, which optimize only for collisions or behavior diversity, produce few of them and distribute them unevenly across modules. MoDitector adds three components to the usual fuzzing loop: per-module oracles that decide whether each module is erroring, a feedback score that rewards scenarios where only the targeted module is at fault and the vehicle is close to a collision, and adaptive seed selection and mutation that push the search toward such scenarios. Across four representative driving scenarios on a modular ADS platform, the method reports 216.7 MICSs total, versus 79.0 for the strongest baseline. If correct, this gives developers a testing tool that not only finds crashes but attributes each one to a debuggable module.

What carries the argument

The load-bearing object is the Module-Induced Critical Scenario (MICS), defined as a collision in which, within the detection window before the crash, exactly one module shows error while all others do not. Three mechanisms carry the argument: (1) module-specific oracles—metric formulas for perception (weighted IoU), prediction (maximum deviation from perception-biased trajectories), planning (collisions between planned and predicted points), and control (deviation from planned path)—that produce a per-module error signal; (2) module-specific feedback, a scalar score equal to the target module's filtered error minus the average of other modules' filtered errors minus the safety-critical distance, so that the search is pushed toward scenarios where only the target module errs and the vehicle nearly collides; and (3) adaptive seed generation, which selects seeds with probability proportional to feedback and switches between fine-grained and coarse-grained mutation depending on how close a seed is to a MICS. These components turn the definition of MICS into a continuous optimization target.

What would settle it

Take a random sample of scenarios MoDitector labels as MICS for perception or prediction, correct the target module's outputs using independent ground truth (e.g., human-annotated bounding boxes or an offline high-precision detector), and check whether the reported collision actually disappears; if the repair rate falls substantially below the reported 89–93%, the oracle is over- or under-attributing root cause. A second check is to vary the thresholds in Eq. 7 slightly and count how many 'MICS' reclassify—high sensitivity would show the headline counts are an artifact of the chosen thresholds.

Watch

Extended reading notes

Core claim

The paper's central claim is that module-induced critical scenarios—system failures in which exactly one named module (perception, prediction, planning, or control) is responsible—can be generated efficiently by a fuzzer that uses per-module oracles, a feedback term that maximizes error in the target module while minimizing error in others, and adaptive seed selection and mutation. The key reported result is that MoDitector finds 216.7 MICSs across four scenarios and four modules, whereas the best baseline finds 79.0, and that the detected scenarios survive a repair test: when the target module's output is replaced by ground truth, the collision disappears in 89 to 100 percent of cases. This is claimed to be the first work to connect module-level root causes to system-level failures in ADS testing.

Load-bearing premise

The entire pipeline depends on the assumption that the hand-picked module error metrics and their thresholds (0.5 for perception, 0.1 for prediction, 0 for planning, 0.05 for control) correctly separate a module that is working from a module that is failing; if these proxies misjudge, scenarios get wrongly classified as MICS and the comparison to baselines measures the wrong thing.

Editorial extensions

If this is right

  • If the central claim holds, ADS developers can use MoDitector to obtain a per-module breakdown of safety weaknesses from simulation, rather than studying collisions whose cause is ambiguous.
  • Because MICSs are defined to be single-module failures, each discovered scenario is directly actionable: it suggests a targeted fix in one module, such as retraining a detector or adjusting a planner's cost function.
  • The reported overhead beyond the simulator is small (about 1.9% of processing time), so the technique can be deployed in large-scale simulation campaigns.
  • The hierarchy of detected MICS counts (prediction > planning > perception > control) gives a concrete robustness ranking of the tested ADS's modules, and the repair-rate experiment provides a way to validate any such ranking.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the single-module restriction is a design choice rather than a necessity: the same oracle and feedback machinery could be extended to multi-module root causes, a direction the paper mentions but does not explore.
  • The perception-biased trajectory trick used to isolate prediction errors might transfer to other settings where upstream and downstream error sources must be separated without extra instrumentation.
  • Because the oracles rely on ground-truth simulator observations, the method should transfer most readily to any modular ADS that exposes internal module outputs; a natural test is to rerun the same four scenarios and oracle formulas on a different modular platform and compare the yield.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes MoDitector, a fuzzing framework for module-based autonomous driving systems that generates "Module-Induced Critical Scenarios" (MICS), i.e., collision scenarios attributed to exactly one target module. It formalizes MICS in Definition 3.1, designs module-specific oracle metrics for perception, prediction, planning, and control (Eqs. 2-6), filters module errors through a detection window (Eq. 7), introduces a module-directed feedback score (Eqs. 8-9), and implements adaptive seed selection and mutation (Algorithm 3). The evaluation on Pylot/CARLA across four NHTSA-derived scenarios compares MoDitector with Random, AVFuzzer, and BehAVExplor (Table 3), reports repair-rate evidence for oracle fidelity (Table 4), and includes ablation results for the feedback and seed-generation components (Table 5).

Significance. The problem addressed is important: existing ADS testing methods typically report system-level failures without localizing the responsible module, and the paper's framing as root-cause-aware testing is a useful step forward. The paper makes concrete contributions in the form of module-specific oracle design, module-directed feedback, adaptive scenario generation, and a comparative empirical study with ablations. If the module-error oracles were properly validated, the method would be a practical tool for module-level debugging of ADSs. However, the central claim depends on the fidelity of the proxy metrics and on the detection-window interpretation of Definition 3.1, and the current evidence is not yet convincing on those load-bearing points.

major comments (4)
  1. [§4.2.3, Eq. (7), and Definition 3.1] The implemented oracle does not enforce Definition 3.1 over the full scenario. Definition 3.1(c) requires every non-target module to be error-free in every scene, and Definition 3.1(b) only requires a target-module error somewhere in the scenario. Algorithm 2, however, evaluates errors only inside the window [T−Δt, T] with Δt = 0.5 s. A scenario in which perception erred at T−1.0 s and then recovered, while planning subsequently steered into a collision at T, would be classified as a planning- or control-MICS even though a non-target module was faulty during the scene sequence. Since every count in Table 3 and the abstract's 216.7-vs-79.0 headline passes through this filtered oracle, the window-size choice is load-bearing. Please either enforce Definition 3.1 over the full trace or provide direct evidence that errors before the window cannot influence the final collision, e.g., a sensitivity analysis over Δt and a manual audit of how scenarios are re-classified when the window is extended.
  2. [§5.2.1, Table 4] The repair-rate experiment does not validate the oracle's root-cause attribution. For planning and control, the "ground truth" used in the repair test is immediate braking (Section 5.2.1); immediate braking trivially avoids any collision regardless of which module caused it, so the 100% repair rates for planning and control carry no evidential weight. For perception and prediction, replacing only the target module's outputs with ground truth can still leave a collision if another module misbehaves later, and the observed 89% repair rates do not rule out the possibility that an earlier error in a non-target module set up the dangerous state. The only direct test of oracle fidelity should be on scenarios where exactly one module is faulty by construction, e.g., via controlled fault injection into one module while all other modules are verified error-free against ground truth over the entire trace, or via human-labeled module-error annotations.
  3. [§4.2.2, Eqs. (5)-(6), and §4.2.3] The module-error metrics are proxies with hand-set thresholds, and the paper reports no sensitivity analysis. The planning oracle in Eq. (5) compares the planned trajectory against predicted object positions, which are themselves outputs of perception and prediction; if prediction is wrong, the planned trajectory can be flagged as unsafe even though planning is correct given its inputs. The control oracle in Eq. (6) mixes position and velocity deviations in unscaled units, and λ_Mctrl = 0.05 has no stated unit or independent basis; λ_Mplan = 0 means a single intersecting waypoint flags a planning error. The tolerance thresholds in Section 5 are said to be set according to the preliminary study, but no derivation or sensitivity study is given. Because the same oracle is used both to filter MICS and to guide the feedback score, all effectiveness results are potentially sensitive to these choices. Please report a sensitivity analysis over λ_M and Δt, and justify the thresholds from an independent standard or from measured distributions of module errors.
  4. [§4.2.2 and §5.1, Table 3] The contribution claim that MoDitector 'generates' more MICS than the baselines is entangled with the oracle that counts them. All methods are scored by MoDitector's module-specific oracle, so baseline counts are reduced not only by how baselines generate collisions but also by how the oracle classifies those collisions. This is not a problem per se, but it means the headline comparison inherits every limitation of the oracle. In particular, if the oracle under- or over-counts errors for certain modules (as the concerns above suggest), the per-module differences in Table 3 may reflect oracle artifacts rather than genuine differences in the generated scenarios. The paper should either justify that the oracle is module-faithful for all four modules or present a secondary analysis that does not rely solely on the proposed oracle.
minor comments (5)
  1. [§4.2.2, Perception metric, Eq. (2)] The text says the perception error is measured by comparing bounding boxes between 'Simulator observation Y(s) and ADS observations Y(s)'; the second Y(s) should presumably be A(s), the ADS observation.
  2. [Algorithm 1, line 5] The return value of ModuleSpecificOracle is described with inconsistent notation: the text says it returns 'module errors δA and safety-critical distance δA,' but the algorithm and Section 4.2.4 show the safety-critical distance as δ_safe. Please unify the notation.
  3. [Abstract and Table 3] The abstract reports 216.7 MICS in total, while summing Table 3 gives 216.6; also, 'the best-performing baseline detects only 79.0' refers to BehAVExplor's total across modules, whereas the best baseline per module differs (AVFuzzer for prediction). Please state this explicitly to avoid confusion.
  4. [§5.4, Table 6] The efficiency comparison reports mean processing times without variance, scenario counts, or statistical testing; given that only three runs are averaged, please add the range or standard deviation and state the number of executed scenarios per run.
  5. [§5, Baselines] AVFuzzer and BehAVExplor were originally evaluated with Apollo/LGSVL and are adapted here to Pylot/CARLA; the paper should state what configuration parameters were preserved or re-tuned in the adaptation, since this affects the fairness of the comparison.

Circularity Check

1 steps flagged · score 4.0 of 10

Planning/control oracle validation is circular because the 'repair' is immediate braking; the headline MICS counts otherwise rely on external baselines and are not circular.

  1. other [Section 5.2.1 (RQ2 setup), Table 4]
    "Considering the vast space of possible planned trajectories and control commands, we use the safest solution, which involves immediate braking, as the ground truth. This approach ensures that both the planning module and the control module consistently make the safest possible decisions."

    For the Planning and Control rows of Table 4, the 'repair' is not a correction of the module under test but immediate braking. Any collision scenario satisfying Definition 3.1.a is detected by Eq. 1 as zero distance between the ego vehicle and another object; braking immediately prevents any such collision by construction, irrespective of which module actually caused the failure. Therefore the reported 100% repair rates for Planning and Control are guaranteed by the repair strategy itself, not by the oracle's root-cause attribution. This makes the RQ2 validation for two of the four modules circular: the experiment cannot fail, so it provides no independent evidence that the target module's error was the true cause.

full rationale

MoDitector's headline claim—generating more MICSs than baselines—is not circular: the comparison is against external baselines (Random, AVFuzzer, BehAVExplor) using the same module oracle, and the search objective is stated independently of the outcome metric. No load-bearing uniqueness theorem or self-citation chain is used; the authors' prior BehAVExplor work appears only as a baseline. The main circularity is confined to RQ2's validation of the oracle for Planning and Control: the 'ground truth' repair is immediate braking, which prevents any collision by construction (Eq. 1), so the 100% repair rates in Table 4 are guaranteed regardless of whether the target module was the true cause. This does not make the central MICS counts circular, but it does mean the paper's claim that the oracle 'can accurately identify the module whose errors are the root cause' is not independently supported for two of four modules. A separate, non-circular validity concern is that Eq. 7 checks module errors only in [T−0.5s, T], while Definition 3.1(c) requires all other modules to be error-free in all scenes; the counted scenarios may therefore include earlier non-target errors. That is a measurement-definition gap rather than an equation-to-input reduction, so it is not scored as circularity.

Assumptions & free parameters 6 free parameters · 5 assumptions · 2 invented entities

The central claim rests on a small number of hand-set thresholds (lambda values, Delta_t, perception range), a set of proxy error metrics validated indirectly, and the assumption that a collision is the only failure. The invented entities (MICS and perception-biased trajectory) are definitional constructs, not new physical entities. The use of immediate braking as planning/control ground truth heavily influences the reported repair rates.

free parameters (6)
  • Tolerance threshold for perception lambda_Mperc = 0.5
    Set in Section 5 Implementation. Determines when a perception error is counted as an error in Eq. 7. Not derived from data or external standard; chosen by the authors.
  • Tolerance threshold for prediction lambda_Mpred = 0.1
    Set in Section 5 Implementation. Controls the sensitivity of the prediction oracle in Eq. 7.
  • Tolerance threshold for planning lambda_Mplan = 0
    Set in Section 5 Implementation. Any planned trajectory intersection with a predicted object counts as a planning error.
  • Tolerance threshold for control lambda_Mctrl = 0.05
    Set in Section 5 Implementation. Determines when deviation from planned trajectory counts as a control error.
  • Detection window size Delta_t = 0.5 seconds
    Set in Section 5 Implementation, justified as the smaller length of Pylot's prediction and planning module output. Directly affects which module errors are counted in Eq. 7 and Eq. 8.
  • Perception range D = not specified in text
    Used in Eqs. 2-4 to weight errors by distance. The paper does not state its value, but it is a parameter of the oracle.
assumptions (5)
  • domain assumption Collisions are the only considered system-level failure.
    Section 4.2.1 defines safety-critical failures exclusively by minimum distance = 0. The paper explicitly mentions future work on non-safety metrics, so this is a stated but restrictive assumption.
  • domain assumption The module error metrics (Eqs. 2-6) are valid proxies for true module correctness.
    The entire MICS definition is evaluated through these metrics. The paper validates them indirectly through repair rates, but the metrics are not shown to match human or ground-truth module assessments.
  • ad hoc to paper Immediate braking is a valid ground truth for planning and control.
    In RQ2 setup, the safest solution (immediate braking) is used as ground truth for planning and control. This makes the 100% repair rates for those modules unsurprising and weakens the oracle validation.
  • domain assumption The adaptation of AVFuzzer and BehAVExplor from Apollo/LGSVL to Pylot/CARLA preserves the methods' intended behavior.
    Section 5 states the baselines were adapted because LGSVL was sunsetted. The adaptation is not described and no code is provided, so the baseline comparison depends on this unverified assumption.
  • domain assumption CARLA's simulator state is treated as ground truth for perception and prediction evaluation.
    The perception oracle compares ADS bounding boxes to simulator observations, and the prediction oracle uses simulator positions. This assumes the simulator's rendering of object positions is accurate enough to serve as ground truth.
invented entities (2)
  • MICS (Module-Induced Critical Scenario)
    purpose: A scenario is a critical scenario (collision) where exactly one module exhibits errors; the central object the fuzzer generates and counts.
    This is a definition introduced by the paper (Definition 3.1), not an independently observable entity. Its operational meaning depends entirely on the module error metrics.
  • Perception-biased trajectory (Eq. 3)
    purpose: A synthetic trajectory used to measure prediction error while removing perception errors, by adding the perception position shift to the ground-truth trajectory.
    This is a constructed construct used in the prediction oracle. It assumes the position shift Delta_p stays constant over the prediction window, which is an unstated modeling assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MoDitector: Module-Directed Testing for Autonomous Driving Systems." pith.science (2026). https://pith.science/paper/476WKNFZ

@misc{pith2026250208504,
  author       = {Pith},
  title        = {Pith review of: MoDitector: Module-Directed Testing for Autonomous Driving Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/476WKNFZ}},
  note         = {Machine review of arXiv:2502.08504}
}
read the original abstract

Testing Autonomous Driving Systems (ADS) is crucial for ensuring their safety, reliability, and performance. Despite numerous testing methods available that can generate diverse and challenging scenarios to uncover potential vulnerabilities, these methods often treat ADS as a black-box, primarily focusing on identifying system failures like collisions or near-misses without pinpointing the specific modules responsible for these failures. Understanding the root causes of failures is essential for effective debugging and subsequent system repair. We observed that existing methods also fall short in generating diverse failures that adequately test the distinct modules of an ADS, such as perception, prediction, planning and control. To bridge this gap, we introduce MoDitector, the first root-cause-aware testing method for ADS. Unlike previous approaches, MoDitector not only generates scenarios leading to collisions but also showing which specific module triggered the failure. This method targets specific modules, creating test scenarios that highlight the weaknesses of these given modules. Specifically, our approach involves designing module-specific oracles to ascertain module failures and employs a module-directed testing strategy that includes module-specific feedback, adaptive seed selection, and mutation. This strategy guides the generation of tests that effectively provoke module-specific failures. We evaluated MoDitector across four critical ADS modules and four testing scenarios. Our approach represents a significant innovation in ADS testing by focusing on identifying and rectifying module-specific errors within the system, moving beyond conventional black-box failure detection.

Figures

Figures reproduced from arXiv: 2502.08504 by the authors.

Figure 1
Figure 1. Overview of MoDitector only perturbing one module’s output. To mitigate the effects of randomness, each experiment was repeated three times [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Cases of MICSs detected by MoDitector for different specific modules. Planning #Mplan, and Control #Mctrl. From the results, we can find that MoDitector achieves signifi￾cantly better performance than other baselines in generating MICS for each module. Specifically, in terms of the Sum. numbers of #M𝑘 , MoDitector substantially outperforms the best baseline: BehAV￾Explor on #Mperc (55.3 vs. 18.3), AVFuzzer on #Mpred… view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. STCLocker: Deadlock Avoidance Testing for Autonomous Driving Systems

    cs.SE 2025-06 conditional novelty 6.0 of 10

    STCLocker uses spatial and temporal conflict signals to generate multi-autonomous-vehicle deadlock scenarios in CARLA and finds significantly more such scenarios than baseline methods.

  2. Causality-aware Safety Testing for Autonomous Driving Systems

    cs.SE 2025-06 conditional novelty 6.0 of 10

    Causal-Fuzzer uses causal graphs of scene, action, and violation relationships to guide simulation fuzzing, and reports finding more diverse violations and better testing sufficiency than three baselines on Apollo.

Reference graph

Works this paper leans on

54 extracted references · 43 canonical work pages · cited by 2 Pith papers

  1. [1]

    [n. d.]. GitHub - autowarefoundation/autoware: Autoware - the world’s leading open-source software project for autonomous driving — github.com. https://github.com/autowarefoundation/autoware. [Accessed 08-Jul-2023]

    work page 2023

  2. [2]

    Comma ai. 2023. Openpilot. https://comma.ai/openpilot

    work page 2023

  3. [3]

    Karl Johan Åström, Tore Hägglund, Chang C Hang, and Weng K Ho. 1993. Automatic tuning and adaptation for PID controllers-a survey. Control Engineering Practice 1, 4 (1993), 699–714

    work page 1993

  4. [4]

    Baidu. 2023. Baidu-Apollo. https://www.apollo.auto

    work page 2023

  5. [5]

    Shruti Bothe, Usama Masood, Hasan Farooq, and Ali Imran. 2020. Neuromorphic AI empowered root cause analysis of faults in emerging networks. In 2020 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom). IEEE, 1–6

    work page 2020

  6. [6]

    Mattias Brännström, Erik Coelingh, and Jonas Sjöberg. 2010. Model-based threat assessment for avoiding arbitrary vehicle collisions. IEEE Transactions on Intelligent Transportation Systems 11, 3 (2010), 658–669

    work page 2010

  7. [7]

    Alessandro Calò, Paolo Arcaini, Shaukat Ali, Florian Hauer, and Fuyuki Ishikawa. 2020. Generating avoidable collision scenarios for testing autonomous driving systems. In 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST). IEEE, 375–386

    work page 2020

  8. [8]

    Mingfei Cheng, Yuan Zhou, and Xiaofei Xie. 2023. Behavexplor: Behavior diversity guided testing for autonomous driving systems. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis . 488–500

    work page 2023

Show all 54 references
  1. [9]

    Mingfei Cheng, Yuan Zhou, and Xiaofei Xie. 2024. DriveTester: A Unified Platform for Simulation-Based Autonomous Driving Testing. arXiv preprint arXiv:2412.12656 (2024)

    2024 arXiv

  2. [10]

    Mingfei Cheng, Yuan Zhou, Xiaofei Xie, Junjie Wang, Guozhu Meng, and Kairui Yang. 2024. Evaluating Decision Optimality of Autonomous Driving via Metamorphic Testing. arXiv preprint arXiv:2402.18393 (2024)

    2024 arXiv

  3. [11]

    Hongjun Choi, Zhiyuan Cheng, and Xiangyu Zhang. 2022. RVPLAYER: Robotic Vehicle Forensics by Replay with What-if Reasoning. In 29th Annual Network and Distributed System Security Symposium, NDSS 2022 . The Internet Society

    2022

  4. [12]

    Wenhao Ding, Chejian Xu, Mansur Arief, Haohong Lin, Bo Li, and Ding Zhao. 2023. A survey on safety-critical driving scenario generation—A methodological perspective. IEEE Transactions on Intelligent Transportation Systems (2023)

    2023

  5. [13]

    Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun. 2017. CARLA: An open urban driving simulator. In Conference on robot learning . PMLR, 1–16

    2017

  6. [14]

    Electrek. 2023. Damning Footage Shows Tesla Vehicles on Autopilot Crashing into Police. https://electrek.co/2023/08/ 09/damning-footage-shows-tesla-vehicles-autopi , Vol. 1, No. 1, Article . Publication date: February 2025. 20 Renzhi Wang, Mingfei Cheng, Xiaofei Xie, Yuan Zhou...

    2023

  7. [15]

    Jin Fang, Dingfu Zhou, Feilong Yan, Tongtong Zhao, Feihu Zhang, Yu Ma, Liang Wang, and Ruigang Yang. 2020. Augmented LiDAR simulator for autonomous driving. IEEE Robotics and Automation Letters 5, 2 (2020), 1931–1938

    2020

  8. [16]

    Shuo Feng, Haowei Sun, Xintao Yan, Haojie Zhu, Zhengxia Zou, Shengyin Shen, and Henry X Liu. 2023. Dense reinforcement learning for safety validation of autonomous vehicles. Nature 615, 7953 (2023), 620–627

    2023

  9. [17]

    Shiwei Feng, Yapeng Ye, Qingkai Shi, Zhiyuan Cheng, Xiangzhe Xu, Siyuan Cheng, Hongjun Choi, and Xiangyu Zhang

  10. [18]

    Weiwei Fu, Heqing Huang, Yifan Zhang, Ke Zhang, Jin Huang, Wei-Bin Lee, and Jianping Wang. 2024. ICSFuzz: Collision Detector Bug Discovery in Autonomous Driving Simulators. arXiv preprint arXiv:2408.05694 (2024)

    2024 arXiv

  11. [19]

    Ross Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. 2014. Rich feature hierarchies for accurate object detection and semantic segmentation. In Proceedings of the IEEE conference on computer vision and pattern recognition . 580–587

    2014

  12. [20]

    Ionel Gog, Sukrit Kalra, Peter Schafhalter, Matthew A Wright, Joseph E Gonzalez, and Ion Stoica. 2021. Pylot: A modular platform for exploring latency-accuracy tradeoffs in autonomous vehicles. In 2021 IEEE International Conference on Robotics and Automation (ICRA). IEEE, 8806–8813

    2021

  13. [21]

    Seunghee Han, Jaeuk Kim, Geon Kim, Jaemin Cho, Jiin Kim, and Shin Yoo. 2021. Preliminary evaluation of path-aware crossover operators for search-based test data generation for autonomous driving. In 2021 IEEE/ACM 14th International Workshop on Search-Based Software Testing (SB...

    2021

  14. [22]

    Fitash Ul Haq, Donghwan Shin, and Lionel Briand. 2022. Efficient online testing for DNN-enabled systems using surrogate-assisted and many-objective optimization. In Proceedings of the 44th international conference on software engineering. 811–822

    2022

  15. [23]

    Fitash Ul Haq, Donghwan Shin, and Lionel C Briand. 2023. Many-objective reinforcement learning for online testing of dnn-enabled systems. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 1814–1826

    2023

  16. [24]

    Md Abir Hossen, Sonam Kharade, Bradley Schmerl, Javier Cámara, Jason M O’Kane, Ellen C Czaplinski, Katherine A Dzurilla, David Garlan, and Pooyan Jamshidi. 2023. C a RE: Finding Root Causes of Configuration Issues in Highly- Configurable Robots. IEEE Robotics and Automation Le...

    2023

  17. [25]

    Dmytro Humeniuk, Foutse Khomh, and Giuliano Antoniol. 2022. A search-based framework for automatic generation of testing environments for cyber–physical systems. Information and Software Technology 149 (2022), 106936

    2022

  18. [26]

    Michael A Johnson and Mohammad H Moradi. 2005. PID control. Springer

    2005

  19. [27]

    Chijung Jung, Ali Ahad, Jinho Jung, Sebastian Elbaum, and Yonghwi Kwon. 2021. Swarmbug: debugging configuration bugs in swarm robotics. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Enginee...

    2021

  20. [28]

    Taegyu Kim, Chung Hwan Kim, Altay Ozen, Fan Fei, Zhan Tu, Xiangyu Zhang, Xinyan Deng, Dave Jing Tian, and Dongyan Xu. 2020. From control model to program: Investigating robotic aerial vehicle accidents with{MAYDAY}. In 29th USENIX Security Symposium (USENIX Security 20) . 913–930

    2020

  21. [29]

    Friedrich Kruber, Jonas Wurst, and Michael Botsch. 2018. An unsupervised random forest clustering technique for automatic traffic scenario categorization. In 2018 21st International conference on intelligent transportation systems (ITSC). IEEE, 2811–2818

    2018

  22. [30]

    lgsvl. 2022. LGSVL Sunsetting. https://github.com/lgsvl/simulator

    2022

  23. [31]

    Guanpeng Li, Yiran Li, Saurabh Jha, Timothy Tsai, Michael Sullivan, Siva Kumar Sastry Hari, Zbigniew Kalbarczyk, and Ravishankar Iyer. 2020. Av-fuzzer: Finding safety violations in autonomous driving systems. In 2020 IEEE 31st international symposium on software reliability en...

    2020

  24. [32]

    Zhuo Li, Xiongfei Wu, Derui Zhu, Mingfei Cheng, Siyuan Chen, Fuyuan Zhang, Xiaofei Xie, Lei Ma, and Jianjun Zhao

  25. [33]

    Guannan Lou, Yao Deng, Xi Zheng, Mengshi Zhang, and Tianyi Zhang. 2022. Testing of autonomous driving systems: where are we and where should we go?. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engine...

    2022

  26. [34]

    Chen Ma, Ningfei Wang, Qi Alfred Chen, and Chao Shen. 2024. Slowtrack: Increasing the latency of camera-based perception in autonomous driving using adversarial examples. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38. 4062–4070

    2024

  27. [35]

    Wassim G Najm, John D Smith, Mikio Yanagisawa, et al. 2007. Pre-crash scenario typology for crash avoidance research . Technical Report. United States. National Highway Traffic Safety Administration

    2007

  28. [36]

    Qi Pang, Yuanyuan Yuan, and Shuai Wang. 2022. Mdpfuzz: testing models solving markov decision processes. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis . 378–390

    2022

  29. [37]

    Ashish Rana and Avleen Malhi. 2021. Building safer autonomous agents by leveraging risky driving behavior knowledge. In 2021 International Conference on Communications, Computing, Cybersecurity, and Informatics (CCCI) . IEEE, 1–6. , Vol. 1, No. 1, Article . Publication date: F...

    2021

  30. [38]

    Guodong Rong, Byung Hyun Shin, Hadi Tabatabaee, Qiang Lu, Steve Lemke, M¯artin, š Možeiko, Eric Boise, Geehoon Uhm, Mark Gerow, Shalin Mehta, et al. 2020. Lgsvl simulator: A high fidelity simulator for autonomous driving. In 2020 IEEE 23rd International conference on intellige...

    2020

  31. [39]

    Jieke Shi, Zhou Yang, Junda He, Bowen Xu, Dongsun Kim, DongGyun Han, and David Lo. 2024. Finding Safety Violations of AI-Enabled Control Systems through the Lens of Synthesized Proxy Programs. arXiv preprint arXiv:2410.04986 (2024)

    2024 arXiv

  32. [40]

    Andrea Stocco, Paulo J Nunes, Marcelo d’Amorim, and Paolo Tonella. 2022. Thirdeye: Attention maps for safe autonomous driving systems. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering. 1–12

    2022

  33. [41]

    Andrea Stocco, Michael Weiss, Marco Calzana, and Paolo Tonella. 2020. Misbehaviour prediction for autonomous driving systems. In Proceedings of the ACM/IEEE 42nd international conference on software engineering . 359–371

    2020

  34. [42]

    Yun Tang, Yuan Zhou, Tianwei Zhang, Fenghua Wu, Yang Liu, and Gang Wang. 2021. Systematic testing of autonomous driving systems using map topology-based scenario classification. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1342–1346

    2021

  35. [43]

    Eric Thorn, Shawn C Kimmel, Michelle Chaka, Booz Allen Hamilton, et al. 2018. A framework for automated driving system testable cases and scenarios . Technical Report. United States. Department of Transportation. National Highway Traffic Safety

    2018

  36. [44]

    Robin van der Made, Martijn Tideman, Ulrich Lages, Roman Katz, and Martin Spencer. 2015. Automated generation of virtual driving scenarios from test drive data. In 24th International Technical Conference on the Enhanced Safety of Vehicles (ESV) National Highway Traffic Safety ...

    2015

  37. [45]

    Zhijie Wang, Yuheng Huang, Lei Ma, Haruki Yokoyama, Susumu Tokumoto, and Kazuki Munakata. 2022. An Exploratory Study of AI System Risk Assessment from the Lens of Data Distribution and Uncertainty.arXiv preprint arXiv:2212.06828 (2022)

    2022 arXiv

  38. [46]

    Xuan Xie, Jiayang Song, Zhehua Zhou, Fuyuan Zhang, and Lei Ma. 2023. Mosaic: Model-based Safety Analysis Framework for AI-enabled Cyber-Physical Systems. arXiv preprint arXiv:2305.03882 (2023)

    2023 arXiv

  39. [47]

    Guangba Yu, Gou Tan, Haojia Huang, Zhenyu Zhang, Pengfei Chen, Roberto Natella, and Zibin Zheng. 2024. A Survey on Failure Analysis and Fault Injection in AI Systems. arXiv preprint arXiv:2407.00125 (2024)

    2024

  40. [48]

    Qingzhao Zhang, Shengtuo Hu, Jiachen Sun, Qi Alfred Chen, and Z Morley Mao. 2022. On adversarial robustness of trajectory prediction for autonomous vehicles. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 15159–15168

    2022

  41. [49]

    Qingzhao Zhang, Shuowei Jin, Ruiyang Zhu, Jiachen Sun, Xumiao Zhang, Qi Alfred Chen, and Z Morley Mao. 2024. On data fabrication in collaborative vehicular perception: Attacks and countermeasures. In 33rd USENIX Security Symposium (USENIX Security 24) . 6309–6326

    2024

  42. [50]

    Ziyuan Zhong, Gail Kaiser, and Baishakhi Ray. 2022. Neural network guided evolutionary fuzzing for finding traffic violations of autonomous vehicles. IEEE Transactions on Software Engineering 49, 4 (2022), 1860–1875

    2022

  43. [51]

    Ziyuan Zhong, Yun Tang, Yuan Zhou, Vania de Oliveira Neves, Yang Liu, and Baishakhi Ray. 2021. A survey on scenario-based testing for automated driving systems in high-fidelity simulation. arXiv preprint arXiv:2112.00964 (2021)

    2021 arXiv

  44. [52]

    Yuan Zhou, Yang Sun, Yun Tang, Yuqi Chen, Jun Sun, Christopher M Poskitt, Yang Liu, and Zijiang Yang. 2023. Specification-based autonomous driving system testing. IEEE Transactions on Software Engineering 49, 6 (2023), 3391–3410. , Vol. 1, No. 1, Article . Publication date: Fe...

    2023

  45. [2023]

    In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE)

    Generative model-based testing on decision-making policies. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 243–254

    2023

  46. [2024]

    arXiv preprint arXiv:2409.07774 (2024)

    ROCAS: Root Cause Analysis of Autonomous Driving Accidents via Cyber-Physical Co-mutation. arXiv preprint arXiv:2409.07774 (2024)

    2024 arXiv

Pith tools

Reviewed August 8, 2026 · model on record in the stance chip above.