Pith. sign in

REVIEW 3 major objections 6 minor 31 references

eCAV: An Edge-Assisted Evaluation Platform for Connected Autonomous Vehicles

T0 review · 3 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read A distributed simulator that runs each vehicle's control loop in its own container reaches 256 simultaneous vehicles, 8 times more than the OpenCDA baseline, while preserving accuracy.

desk verdict A useful distributed CAV evaluation platform whose headline scaling claim is smaller than it looks because "step time" in the abstract means only the client half, not the paper's own definition of total step time. read the letter →

arxiv 2506.16535 v2 pith:GASSV5RE submitted 2025-06-19 cs.RO cs.MAcs.NIcs.SYeess.SY

Tyler Landle , Jordan Rapp , Dean Blank , Chandramouli Amarnath , Abhijit Chatterjee , Alexandros Daglis , Umakishore Ramachandran This is my paper · ORCID
classification cs.ROcs.MAcs.NIcs.SYeess.SY
keywords connectedautonomousvehiclessimulationplatformscalabilityedgecomputingcontainerizationcooperativedrivingCARLAOpenCDA
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

eCAV is a simulation platform for testing connected autonomous vehicle (CAV) systems, built on the CARLA environment simulator and OpenCDA's vehicle control stacks. The paper argues that the standard framework's serial execution of vehicle control loops is the scalability bottleneck, and that this bottleneck can be broken by giving each simulated vehicle its own containerized control process, parallelized across CPU cores and machines, with an asynchronous communication manager coordinating a single barrier per simulation step. The paper reports simulating up to 256 independently controlled vehicles without perception ($8\times$ more than OpenCDA) and 64 vehicles with perception enabled, with a step time under 800ms ($4\times$ more vehicles and $1.5\times$ faster than OpenCDA). The platform also adds a pluggable edge node and network emulator, letting researchers test futuristic edge-assisted control planes alongside local vehicle decision-making.

What carries the argument

The load-bearing mechanism is containerized vehicle clients. Each autonomous vehicle in a scenario is a Docker container running its own Python-based planning and control loop, which removes the single-threaded Python GIL bottleneck that forces serial execution in OpenCDA. Around that, the architecture's supporting mechanisms are: an asynchronous push-pull communication manager (gRPC, C++ server) that exchanges small event messages with the simulation manager and lets clients pull large payloads like waypoints; a barrier synchronization each simulation step, where all clients must report before CARLA ticks the world; a V2X Communications Collector with lockless queues holding time-indexed data for all actors; and a pluggable edge node plus network emulator for edge-assisted control. The performance argument is that total step time is the slowest client plus barrier overhead, not the sum of all clients, so adding machines and containers scales the simulation nearly linearly until CPU, GPU memory, or CARLA's actor limit is hit.

What would settle it

Run the same scenario with the same random seeds in OpenCDA and in eCAV, then compute per-vehicle per-timestep position and speed errors across a fleet of vehicles; the accuracy claim collapses if the maximum trajectory divergence between platforms is larger than the run-to-run divergence between two OpenCDA executions of the same scenario. Reproducing the reported scaling numbers on the same cloud VM types would equally settle the scalability claim.

Watch

Extended reading notes

Core claim

The central claim of eCAV is that scalable multi-vehicle simulation is achievable by decomposing the monolithic simulator into a centralized simulation manager and a set of independent vehicle clients, each running its own control algorithm in a separate container. Because each container has its own Python interpreter, the global interpreter lock that serializes OpenCDA's per-vehicle loops is no longer a bottleneck; the clients execute in parallel and communicate with the CARLA server (running in synchronous fixed-time-step mode) through a push-pull gRPC communication manager. The paper reports that this design runs 256 vehicles with individual control stacks and no perception, and 64 vehicles with perception enabled, on a four-node cloud deployment, while OpenCDA saturates at far smaller counts on the same hardware. The paper also claims that the containerization and distribution do not change simulation results, presenting localization traces from eCAV and OpenCDA as 'practically identical.' Finally, eCAV includes an edge node that runs pluggable coordination algorithms and a network emulator that models latency, so a scenario can include an edge-based control plane that sends waypoints to vehicles — a capability the paper says no state-of-the-art framework offers.

Load-bearing premise

The load-bearing premise is that running each vehicle's control loop in its own container, with its own timing and communication delays, produces results that match OpenCDA's sequential execution closely enough that safety and performance conclusions transfer; the paper supports this only with a visual 'practically identical' comparison of localization plots and gives no quantitative error metric.

Editorial extensions

If this is right

  • CAV researchers can evaluate collision-avoidance and traffic-flow algorithms with dozens to hundreds of independent vehicles in a single scenario, instead of a handful.
  • Edge-assisted control planes become testable: developers can plug coordination algorithms into the edge node, subject them to modeled network latency, and measure traffic flow and safety metrics such as target-velocity deviation and headway violations.
  • Simulation step time at scale grows logarithmically with vehicle count rather than linearly, bounded by the slowest client plus synchronization overhead.
  • Deploying the simulator across multiple machines or cloud VMs increases the number of vehicles that can be evaluated, with network overhead on the order of tens of milliseconds at the 99th percentile even with 256 clients.

Reading between the lines

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

  • The accuracy claim is supported only by a visual comparison of one vehicle's localization trace; a quantitative test comparing trajectory errors across many vehicles and random seeds would be needed to establish that containerization preserves safety-critical behavior.
  • The scaling ceilings of 256 (no perception) and 64 (with perception) are set by CARLA's actor memory limit, which the paper identifies as a bottleneck, not by eCAV's architecture; if a future CARLA raises that limit, eCAV's numbers could rise without any change to the platform.
  • The network emulator's latency model could be used for sensitivity studies the paper does not run, such as sweeping communication delay to find the point where an edge-assisted controller's guidance is too stale to be safe.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. This paper presents eCAV, a distributed evaluation platform for connected autonomous vehicles built by containerizing and parallelizing the OpenCDA framework on top of the CARLA simulator. The architecture separates the simulation manager, vehicle clients, communication manager, V2X collector, edge node, and network emulator, and the paper evaluates scalability in single-node and multi-node setups with and without perception. The main empirical results are that eCAV can run 256 vehicles without perception and 64 vehicles with perception on the described cloud VMs, with average client step times below about 800 ms for the perception case, and that its client step time scales better than OpenCDA's sequential execution. A case study demonstrates an edge-assisted lane/velocity planning algorithm and compares it with a greedy baseline. The paper claims 8x more vehicles without perception and 4x more vehicles with 1.5x speedup over OpenCDA, and claims to preserve OpenCDA accuracy.

Significance. If the performance and accuracy claims can be substantiated after revision, eCAV would be a useful contribution to CAV evaluation: it is a modular, distributed extension of OpenCDA/CARLA with containerized per-vehicle control loops, an edge-control interface, and network modeling, and it openly reports the architecture and measurement breakdowns (processing, network, barrier). The scaling measurements are empirical and benchmarked against OpenCDA, and the paper is transparent that world step time is not improved. However, the current presentation overstates the end-to-end step-time improvement and under-supports the accuracy-equivalence claim, so the significance hinges on the requested revisions.

major comments (3)
  1. [§7.1, §7.4.1, Abstract] The paper's own definition of step time in §7.1 is the duration of one synchronized 50 ms timestep, comprising client step time plus world step time. However, Figures 10 and 11, whose axis is labeled 'Simulation Step Time,' report only the average client step time, as the text of §7.4.1 states. The abstract's headline claims—'simulates up to 64 vehicles with a step time under 800 ms' and '1.5x faster than OpenCDA'—therefore rest on a client-only component. Since §7.3 reports that world step time is at least half of the total tick time and is unchanged by eCAV, the true synchronized step for 64 perception-enabled vehicles is not shown and could be well above 800 ms, and the speedup factor versus OpenCDA is not computed on a consistent basis. The authors should report total step time (client + world) for both systems or clearly re-label the claims as client-step-time results.
  2. [§7.5] The accuracy comparison supporting hypothesis (2) is entirely qualitative. Section 7.5 states that the localization plots for eCAV and OpenCDA are 'practically identical' but provides no quantitative error metric such as RMSE, maximum deviation, or trajectory difference over the scenario. Because containerization changes process scheduling, message ordering, and sensor-data delivery timing, the equivalence of control-loop behavior is exactly what needs to be demonstrated for eCAV to be a drop-in replacement for OpenCDA. Please add a numerical comparison of the relevant state signals (position, yaw, speed) across runs.
  3. [§7.2, §7.3, §7.4.1, Abstract] The headline cross-framework comparison is not resource-matched. The 64-vehicle perception-enabled result in Figure 11 comes from the multi-node configuration of §7.2.4, which uses multiple GPU-equipped VMs, while the OpenCDA baseline in §7.3 (Figure 6) runs on a single node with a single GPU. The abstract's '4x more and 1.5x faster' claim thus compares eCAV's distributed deployment against OpenCDA's single-node deployment; it cannot be read as eCAV achieving that speedup on the same hardware. The paper should either present a same-resource comparison (e.g., eCAV and OpenCDA on the same single node) or explicitly qualify the claim as applying to the distributed setup described in §7.2.4.
minor comments (6)
  1. [Abstract] The abstract contains the typo 'saftey'; it should be 'safety.'
  2. [Figures 5 and 6] Figures 5 and 6 label the eCAV curve as 'eCloudSim,' which is inconsistent with the name used everywhere else in the paper; the label should be 'eCAV.'
  3. [§7.3, after Figure 7] The paragraph after Figure 7 cites 'Figure 5' when discussing world step time; the reference should be to Figure 4, which plots CARLA world step time.
  4. [Listing 2] Listing 2 contains 'CLARA client port'; this should be 'CARLA.'
  5. [§8] The conclusion's 'at least 5× faster than prior art' is not consistent with the abstract's 1.5× speedup and with §7.4.1's 6× figure; the claimed speedup should be stated uniformly with the conditions under which it was measured.
  6. [§7.1 and Listing 2] Section 7.1 states a 50 ms synchronized timestep, but Listing 2 sets fixed_delta_seconds to 0.035; the relationship between the default step and the configuration snippet should be clarified.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: eCAV's scalability claims are empirical measurements benchmarked against the external OpenCDA framework, and the only self-citation is background motivation for edge support, not load-bearing evidence.

full rationale

The paper's central quantitative claims are experimental scaling measurements: eCAV is deployed on Azure VMs, and the paper measures client step time, world step time, vehicle counts, and latency against OpenCDA. These are empirical comparisons to an external baseline, not predictions obtained from fitted parameters or from definitions that encode the result. Section 7.1 defines step time in terms of client step time plus world step time, and Sections 7.3 and 7.4 report measured values for both components; there is no equation or fitting step in which the claimed output is equivalent to an input by construction. The only overlap with the authors' prior work is the citation to eCloud [2] in Sections 1 and 3.2, which motivates edge-assisted CAVs as a research direction but is not used to justify the scaling numbers, to impose a uniqueness argument, or to import an ansatz. The accuracy check in Section 7.5 is qualitative ('practically identical') and is therefore weak evidence, but it is not circular: eCAV reuses OpenCDA's planning and control modules, and the comparison is against that external implementation. A separate reporting concern, namely that the abstract's 'step time under 800 ms' appears to report only client step time while the paper's own definition also includes world step time, is a metric-consistency and interpretation issue rather than a reduction of the result to its inputs, so it does not raise the circularity score.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The central performance claims depend on the trustworthiness of the underlying simulators (CARLA and OpenCDA) and on the assumption that parallelizing vehicle clients does not change simulation behavior. The edge case study adds assumptions about a simplified vehicle model and a constant-latency network model. No fitted parameters are used; the reported numbers are measured rather than derived.

assumptions (6)
  • domain assumption CARLA simulator provides physically accurate vehicle dynamics and sensor data.
    eCAV's environment simulator and all measurements (Sections 4.5, 7.3) treat CARLA as ground truth. If CARLA's physics or sensor models are inaccurate, safety conclusions from eCAV scenarios inherit that error.
  • domain assumption OpenCDA planning and control algorithms are valid and representative of CAV control stacks.
    eCAV reuses OpenCDA's ego-vehicle planning and control (Section 4.2.2) and assumes these algorithms are a suitable stand-in for real CAV controllers.
  • domain assumption The fixed 50ms simulation timestep is sufficient for control-loop stability.
    All experiments use a 50ms step, following OpenCDA's default (Section 7.1). If a scenario requires a smaller step, the reported scaling numbers may change.
  • domain assumption Containerization and parallel execution do not alter the semantics of the simulated control loops.
    The accuracy check in Section 7.5 is visual only. The claim that eCAV preserves OpenCDA behavior assumes no hidden ordering, timing, or data-delivery effects from running each vehicle in its own container.
  • domain assumption The network emulator's latency model captures the networking effects relevant to edge-assisted CAV evaluation.
    The edge case study uses a constant 51ms latency (Section 7.6.2). The pluggable model's realism is not validated against real networks, so latency-sensitive conclusions are illustrative.
  • ad hoc to paper Simplified dynamics in the edge case study (accelerate or decelerate by 1 m/s per step, lane-change commands) are sufficient to demonstrate edge-assisted control.
    Section 7.6.1 uses these toy dynamics to show a 15% velocity improvement. They are not validated against CARLA physics, so the case study is illustrative, not a realistic traffic evaluation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of eCAV: An Edge-Assisted Evaluation Platform for Connected Autonomous Vehicles." pith.science (2026). https://pith.science/paper/GASSV5RE

@misc{pith2026250616535,
  author       = {Pith},
  title        = {Pith review of: eCAV: An Edge-Assisted Evaluation Platform for Connected Autonomous Vehicles},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GASSV5RE}},
  note         = {Machine review of arXiv:2506.16535}
}
abstract

As autonomous vehicles edge closer to widespread adoption, enhancing road safety through collision avoidance and minimization of collateral damage becomes imperative. Vehicle-to-everything (V2X) technologies, which include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-cloud (V2C), are being proposed as mechanisms to achieve this safety improvement. Simulation-based testing is crucial for early-stage evaluation of Connected Autonomous Vehicle (CAV) control systems, offering a safer and more cost-effective alternative to real-world tests. However, simulating large 3D environments with many complex single- and multi-vehicle sensors and controllers is computationally intensive. There is currently no evaluation framework that can effectively evaluate realistic scenarios involving large numbers of autonomous vehicles. We propose eCAV -- an efficient, modular, and scalable evaluation platform to facilitate both functional validation of algorithmic approaches to increasing road safety, as well as performance prediction of algorithms of various V2X technologies, including a futuristic Vehicle-to-Edge control plane and correspondingly designed control algorithms. eCAV can model up to 256 vehicles running individual control algorithms without perception enabled, which is $8\times$ more vehicles than what is possible with state-of-the-art alternatives.

Figures

Figures reproduced from arXiv: 2506.16535 by the authors.

Figure 1
Figure 1. eCAV Architecture. (6) Edge Support: Provides a pluggable interface that al￾lows incorporation of new edge-deployed control algo￾rithms by domain experts. (7) Network Emulation: Provides a pluggable interface that models the characteristics of connectivity between the edge node and the vehicle clients. The separation of responsibilities from a monolith to distinct components in the simulation manager, parallelizatio… view at source ↗
Figure 2
Figure 2. Intra-Simulation Communications TCP communication paradigm. We utilize a parallel, multi￾threaded, and asynchronous push-pull communication archi￾tecture to realize R6 and R8 in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Edge Node Zoomed In To integrate the edge node support into eCAV, the edge node functions as an actor, similar to any other vehicle client. Its inputs are sensor signals from the vehicle clients and its outputs are the proposed control actions that are sent back to clients, with the aim of improving traffic flow. The edge node, shown in [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: CARLA World Step Time           [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 7
Figure 7. Figure 7: Client Processing Time - Individual Client [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 6
Figure 6. Figure 6: Total Client Step Time on a Single Node with [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 8
Figure 8. Figure 8: Network Overhead Time - Network Latency including Round Trip Time and Messaging Overhead without Perception Enabled           [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 11
Figure 11. Figure 11: Multi Node Client Step Time with Perception [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: Comparison between OpenCDA and eCAV Ground Truth Data - Localization 7.5 Accuracy To verify accuracy of the simulation, we compare individual vehicle client data from a reproducible simulation between eCAV and OpenCDA. These simulations should have the same vehicle cl…
Figure 13
Figure 13. Figure 13: Traffic and Algorithm Time Metrics Gath [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 22 canonical work pages

  1. [1]

    National Highway Traffic Safety Administration. [n.d.]. Automated Vehicles for Safety. https://www.nhtsa.gov/technology-innovation/ automated-vehicles-safety

    work page

  2. [2]

    Arulraj, A

    J. Arulraj, A. Chatterjee, A. Daglis, A. Dhekne, and U. Ramachandran

    work page

  3. [3]

    Paul S Bradley, Kristin P Bennett, and Ayhan Demiriz. 2000. Con- strained k-means clustering. Microsoft Research, Redmond 20 (2000)

    work page 2000

  4. [4]

    CARLA. 2023. Traffic Manager. Retrieved October 14,2023 from https://carla.readthedocs.io/en/latest/adv_traffic_manager/

    work page 2023

  5. [5]

    Defu Cui, Yuzhong Shen, Hong Yang, Zhitong Huang, Kyle Rush, Peter Huang, and Pavle Bujanovic. [n.d.]. Extensible Co- Simulation Framework for Supporting Cooperative Driving Au- tomation Research. Transportation Research Record ([n. d.]), 03611981221121263. https://doi.org/10.1177/03611981221121263 arXiv:https://doi.org/10.1177/03611981221121263

    work page doi:10.1177/03611981221121263

  6. [6]

    Prabhjot Kaur, Samira Taghavi, Zhaofeng Tian, and Weisong Shi

    work page

  7. [7]

    Guannan Lou, Yao Deng, Xi Zheng, Mengshi Zhang, and Tianyi Zhang

    work page

  8. [8]

    A Survey on Simulators for Testing Self-Driving Cars

    A Survey on Simulators for Testing Self-Driving Cars. CoRR abs/2101.05337 (2021). arXiv:2101.05337 https://arxiv.org/abs/2101. 05337

    work page Pith review arXiv 2021

Show all 31 references
  1. [9]

    Microsoft. 2022. Dv5 and Dsv5-series. Retrieved October 14,2023 from https://learn.microsoft.com/en-us/azure/virtual-machines/dv5- dsv5-series

    2022

  2. [10]

    Microsoft. 2022. Updated NDv2-series. Retrieved October 14,2023 from https://learn.microsoft.com/en-us/azure/virtual-machines/ndv2- series

    2022

  3. [11]

    Sumbal Malik, Manzoor Ahmed Khan, and Hesham El-Sayed. 2021. Collaborative Autonomous Driving—A Survey of Solution Approaches and Future Challenges. Sensors 21, 11 (2021). https://doi.org/10.3390/ s21113783

    2021

  4. [12]

    Microsoft. 2023. NVv3-series. Retrieved October 14,2023 from https: //learn.microsoft.com/en-us/azure/virtual-machines/nvv3-series

    2023

  5. [13]

    N. J. Nilsson. 1980. Principles of Artificial Intelligence. Morgan Kauf- mann Publishers Inc., San Francisco, CA, USA

    1980

  6. [14]

    Microsoft. 2023. Microsoft Azure. Retrieved October 14,2023 from https://azure.microsoft.com/en-us

    2023

  7. [15]

    NVIDIA. 2022. Nvidia/Nvidia-Docker: Build and run Docker containers leveraging Nvidia gpus. https://github.com/NVIDIA/ nvidia-docker

    2022

  8. [16]

    Hang Qiu, Po-Han Huang, Namo Asavisanu, Xiaochen Liu, Kon- stantinos Psounis, and Ramesh Govindan. 2022. AutoCast: Scal- able Infrastructure-Less Cooperative Perception for Distributed Col- laborative Driving. In Proceedings of the 20th Annual International Conference on Mobil...

    2022

  9. [17]

    NVIDIA. 2016. NVIDIA Tesla M60 GPU Accelerator. https://www.nvidia.com/content/dam/en-zz/Solutions/design- visualization/solutions/resources/documents1/nvidia-m60- datasheet.pdf

    2016

  10. [18]

    Guodong Rong, Byung Hyun Shin, Hadi Tabatabaee, Qiang Lu, Steve Lemke, M¯artin, š Možeiko, Eric Boise, Geehoon Uhm, Mark Gerow, Shalin Mehta, Eugene Agafonov, Tae Hyung Kim, Eric Sterner, Ke- unhae Ushiroda, Michael Reyes, Dmitry Zelenkovsky, and Seonman Kim. 2020. LGSVL Simul...

    2020

  11. [19]

    Wilko Schwarting, Javier Alonso-Mora, and Daniela Rus. 2018. Plan- ning and Decision-Making for Autonomous Vehicles. Annual Review of Control, Robotics, and Autonomous Systems 1, 1 (2018), 187–210. https://doi.org/10.1146/annurev-control-060117-105157 arXiv:https://doi.org/10....

    2018 doi

  12. [20]

    Jinke Ren, Guanding Yu, Yinghui He, and Geoffrey Ye Li. 2019. Col- laborative Cloud and Edge Computing for Latency Minimization. IEEE Transactions on Vehicular Technology 68, 5 (2019), 5031–5044. https://doi.org/10.1109/TVT.2019.2904244

    2019

  13. [21]

    CARLA Team. [n.d.]. CARLA Simulator. http://http://carla.org//. https://doi.org/10.48550/arXiv.1711.03938 Accessed: 2021-08-16

    2021 doi arXiv

  14. [22]

    Tsukada, T

    M. Tsukada, T. Oi, A. Ito, M. Hirata, and H. Esaki. 2020. Au- toC2X: Open-source software to realize V2X cooperative perception among autonomous vehicles. In2020 IEEE 92nd VehicularTechnology Conference (VTC2020-Fall). 1–6. https://doi.org/10.1109/VTC2020- Fall49728.2020.93485...

    2020

  15. [23]

    Swaminathan

    Jerome Joseph T and J. Swaminathan. 2022. An Experimental Study of Parallelism in Different Python Frameworks. In 2022 International Conference on Inventive Computation Technologies(ICICT). 363–366. https://doi.org/10.1109/ICICT54344.2022.9850566

    2022

  16. [24]

    Runsheng Xu, Yi Guo, Xu Han, Xin Xia, Hao Xiang, and Jiaqi Ma. 2021. OpenCDA: An Open Cooperative Driving Automation Framework Integrated with Co-Simulation. In 2021 IEEE International Intelligent Transportation Systems Conference (ITSC). 1155–1162. https://doi. org/10.1109/IT...

    2021

  17. [25]

    Runsheng Xu, Yi Guo, Xu Han, Xin Xia, Hao Xiang, and Jiaqi Ma

  18. [26]

    LLC Waymo. 2020. Waymo safety report. Mountain View, CA, USA (2020)

    2020

  19. [27]

    Jixiang Zhou, Yi Zhang, Shengjian Guo, and Yan Guo. 2022. A Survey on Autonomous Driving System Simulators. In 2022 IEEE International Symposium on Software Reliability Engineering Workshops(ISSREW). 301–306. https://doi.org/10.1109/ISSREW55968. 2022.00084 13

    2022

  20. [29]

    In 2021 IEEE International Intelligent Transportation Systems Conference (ITSC)

    OpenCDA: an open cooperative driving automation framework integrated with co-simulation. In 2021 IEEE International Intelligent Transportation Systems Conference (ITSC). IEEE, 1155–1162

    2021

  21. [30]

    Ethan Guo, Feng Qian, and Z

    Xumiao Zhang, Anlan Zhang, Jiachen Sun, Xiao Zhu, Y. Ethan Guo, Feng Qian, and Z. Morley Mao. 2021. EMP: Edge-Assisted Multi- Vehicle Perception. In Proceedings of the 27th Annual International Conference on Mobile Computing and Networking (New Orleans, Louisiana) (MobiCom ’21...

    2021

  22. [2021]

    Computer 54, 05 (may 2021), 24–33

    eCloud: A Vision for the Evolution of the Edge-Cloud Continuum. Computer 54, 05 (may 2021), 24–33. https://doi.org/10.1109/MC.2021. 12 eCA V: An Edge-Assisted Evaluation Platform for Connected Autonomous Vehicles , , 3059737

    2021 doi

  23. [2022]

    Testing of Autonomous Driving Systems: Where Are We and Where Should We Go? arXiv:2106.12233 [cs.SE]

    arXiv

Pith tools

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