{"id":"595bff42-6d96-42f0-bd2f-13259e97ee4a","arxiv_id":"2506.16535","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"eCAV is a containerized, distributed extension of OpenCDA and CARLA that scales connected-vehicle simulation to 256 vehicles without perception and 64 with perception, while adding an edge-control and network-emulation interface.","lead":"This paper presents eCAV, a distributed simulation platform that parallelizes vehicle control loops across containers and machines, extending OpenCDA and CARLA to handle up to 256 vehicles without perception and 64 with perception. A smart generalist might read it because large-scale, repeatable simulation is the bottleneck for testing connected and edge-assisted driving algorithms before real-world deployment.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline step-time claim reports only client step time, not the paper's own definition of step time (client + CARLA world tick), so the 64-vehicle/800 ms figure may be misleading.","rationale":"The reader's weakest assumption was that eCAV preserves OpenCDA's simulation accuracy when clients are parallelized, supported only by the qualitative 'practically identical' localization plots in Section 7.5. That is a real concern, but the more directly load-bearing issue for the paper's headline claim is that the reported step time appears to be only the client step time, not the total simulation step time as defined in Section 7.1. Even if accuracy were perfectly preserved, the abstract's '64 vehicles with a step time under 800 ms' and the '1.5× faster' comparison would be unsupported if the omitted CARLA world tick time pushes the total step above 800 ms or shrinks the speedup. This does not invalidate the architecture or the scalability direction; OpenCDA's serial client loop is clearly a bottleneck, and eCAV's containerized parallelization is plausible. It does mean the central performance claim is currently overstated or at least ambiguously measured. The reader's CONDITIONAL verdict remains appropriate, with an added condition: report total step time and re-derive the speedup on that basis.","tokens_in":15847,"tokens_out":5679,"duration_ms":59146,"concrete_test":"Re-run the multi-node perception experiment of §7.2.4 at N=64 with the simulation manager logging client step time and CARLA world tick time separately, and report total step time = client + world for both eCAV and OpenCDA. If total step time exceeds 800 ms, or if the speedup versus OpenCDA drops below 1.5×, the abstract's 'step time' claim must be revised to 'client step time' and the speedup recomputed on total step time.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 7.1 defines step time as the duration of one synchronized 50 ms timestep and states that each simulation step's duration is dictated by the sum of two phases: Client Step Time and World Step Time. Section 7.3 also observes that world step time is at least half of the total tick time even in sequential scenarios. Despite this, the scaling evaluation reports only the client step time: §7.4.1 says Figures 10 and 11 show the 'average client step time,' and Figure 11's axis label 'Simulation Step Time' is the client-side component. The abstract's headline claim that eCAV 'simulates up to 64 vehicles with a step time under 800 ms' therefore appears to be a client-only number. Because CARLA's world tick cost is unchanged between OpenCDA and eCAV, adding it to the reported 800 ms could push the actual end-to-end 50 ms simulation step well above 800 ms, and would reduce the claimed 1.5× speedup. The current plots do not substantiate 'step time' as the paper itself defines it; they substantiate only a client-step-time bound.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":16065,"tokens_out":6177,"duration_ms":57094,"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":[{"comment":"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.","section":"§7.1, §7.4.1, Abstract"},{"comment":"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.","section":"§7.5"},{"comment":"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.","section":"§7.2, §7.3, §7.4.1, Abstract"}],"minor_comments":[{"comment":"The abstract contains the typo 'saftey'; it should be 'safety.'","section":"Abstract"},{"comment":"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.'","section":"Figures 5 and 6"},{"comment":"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.","section":"§7.3, after Figure 7"},{"comment":"Listing 2 contains 'CLARA client port'; this should be 'CARLA.'","section":"Listing 2"},{"comment":"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.","section":"§8"},{"comment":"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.","section":"§7.1 and Listing 2"}],"recommendation":"major_revision","confidential_remarks":"The paper would benefit from an explicit statement of which experiments use which VM/GPU budgets when comparing against OpenCDA, and from per-run variance information, since none of the scaling plots show error bars or repeated-run statistics. The engineering contribution is clear, but the presentation currently mixes client-only and end-to-end metrics in a way that a careful reader cannot reconcile."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the useful part. The paper builds a distributed, containerized version of OpenCDA/CARLA and measures scaling to 256 vehicles without perception and 64 with perception. That is a real integration effort, and the architecture details (gRPC messaging, per-vehicle containers, V2X collector, pluggable edge node) are concrete enough to be reproduced. The body is also honest about what it does not parallelize: world step time is unchanged and is at least half of the total tick. Parallelizing the client loop is a genuine contribution, and the single-node versus multi-node numbers support the general claim.\n\nNow the soft spots, in order.\n\nThe abstract says \"step time under 800ms\" at 64 vehicles with perception. The paper defines step time as client step time plus CARLA world step time. The evaluation reports only client step time. The stress-test note is correct: adding a world step of at least 800ms would push the real end-to-end step well above 1.6 seconds, and it would cut the claimed 1.5x speedup. This is not a nit; it is the headline number being reported with a definition the paper itself does not use. Fixing it means either reporting total step time or clearly labeling the abstract claim as \"client step time.\"\n\nSecond, the accuracy check is qualitative: plots that look \"practically identical\" with no quantitative error metric. If the platform is to be a drop-in scalable replacement for OpenCDA, that claim needs numeric support, because containerization can change message ordering, control-loop timing, and sensor delivery. This is a moderate concern, not fatal.\n\nThird, there is no code or data artifact, despite a promise to open-source. For a systems paper, the reproducibility bar is higher than a plot. The scaling measurements would be much stronger with a release.\n\nThe comparison baseline also deserves scrutiny: the perception-enabled comparison is not clearly resource-equal across frameworks. That is a softer issue, but it is worth asking the authors to clarify.\n\nThe citation pattern is clean. The one self-citation (eCloud) is motivational only, and the scaling numbers are benchmarked against OpenCDA, so circularity is not a concern.\n\nWho this is for: researchers building or selecting CAV simulation infrastructure, especially with edge control planes. It deserves a serious referee, not a desk reject. I would accept it conditionally on the metrics being fixed and artifacts provided.","headline":"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.","tokens_in":16598,"tokens_out":2098,"would_cite":false,"duration_ms":21366,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["connected autonomous vehicles","simulation platform","scalability","edge computing","containerization","cooperative driving","CARLA","OpenCDA"],"falsifier":"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.","tokens_in":15646,"feed_emoji":"🚗","tokens_out":18530,"duration_ms":150290,"temperature":0.7,"pith_summary":"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.","feed_headline":"eCAV simulates 256 vehicles at once, 8x more than prior tools","feed_subtitle":"The platform runs 256 vehicles without perception, and 64 with perception enabled, 4x more than OpenCDA.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"OpenCDA is the baseline framework eCAV extends and the source of the per-vehicle planning/control algorithms; the scalability comparison and accuracy validation are against OpenCDA.","marker":"[25]"},{"why":"CARLA serves as the environment simulator, providing the physics engine, world tick, and sensor data generation; its synchronous fixed-time-step mode sets the world-step bottleneck.","marker":"[21]"},{"why":"AutoCastSim is the other state-of-the-art evaluation framework used in the comparison; the paper positions eCAV against its approach of removing parts of the AV stack to achieve scale.","marker":"[16]"},{"why":"The study of Python parallelism supports the core argument that the global interpreter lock limits serial simulators, motivating containerization of vehicle clients.","marker":"[20]"},{"why":"The Nvidia Docker runtime is the implementation mechanism that lets perception-enabled vehicle containers access GPUs, enabling multi-GPU scale-out beyond OpenCDA's single-GPU limit.","marker":"[15]"},{"why":"The eCloud vision of an edge-cloud continuum motivates the paper's requirement for an edge control plane and the pluggable edge node interface.","marker":"[2]"}],"fun_headline_variants":["eCAV runs 256 AVs without perception, 8x more than OpenCDA","Edge-based eCAV scales CAV sim to 256 vehicles, 8x boost","eCAV: containerized simulation hits 256 vehicles, 8x more scale","Edge control plane joins CAV sim, running 256 vehicles at once","eCAV's parallel containers beat GIL limits: 256 AVs simulated"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["eCAV runs 256 AVs without perception, 8x more than OpenCDA","Edge-based eCAV scales CAV sim to 256 vehicles, 8x boost","eCAV: containerized simulation hits 256 vehicles, 8x more scale","Edge control plane joins CAV sim, running 256 vehicles at once","eCAV's parallel containers beat GIL limits: 256 AVs simulated"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00102,"raw_usage":{"total_tokens":4338,"prompt_tokens":1016,"completion_tokens":3322,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":632,"completion_tokens_details":{"reasoning_tokens":3212}},"tokens_in":632,"tokens_out":3322,"duration_ms":21635,"temperature":1.0,"reasoning_tokens":3212,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T19:24:24.663046+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"OpenCDA is the baseline framework eCAV extends and the source of the per-vehicle planning/control algorithms; the scalability comparison and accuracy validation are against OpenCDA."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The Nvidia Docker runtime is the implementation mechanism that lets perception-enabled vehicle containers access GPUs, enabling multi-GPU scale-out beyond OpenCDA's single-GPU limit."},{"cited_title":"Arulraj, A","cited_arxiv_id":null,"evidence_quote":"The eCloud vision of an edge-cloud continuum motivates the paper's requirement for an edge control plane and the pluggable edge node interface."}],"review_version":2}