OpenCDA-InfraX: Infrastructure Simulation

• OpenCDA-InfraX is an infrastructure-centric simulation platform that extends the OpenCDA ecosystem by integrating digital twin assets, real-world data, and hybrid scenario generation.
• The platform leverages a modular design with a Digital Twin Environment, Synthetic Data Generator, and an Infrastructure Manager to support scalable and reproducible infrastructure-based simulations.
• Empirical results show that late fusion techniques in OpenCDA-InfraX improve V2X and I2I perception metrics, demonstrating its potential for advanced cooperative driving and benchmarking experiments.

Searching arXiv for OpenCDA-InfraX and closely related OpenCDA papers to ground the article with current paper metadata. {"query":"OpenCDA-InfraX arXiv", "max_results": 10} {"query":"CDA-SimBoost OpenCDA-InfraX arXiv", "max_results": 10} OpenCDA-InfraX is an infrastructure-centric cooperative driving simulation platform introduced as one of the three core modules of CDA-SimBoost, alongside the Digital Twin Builder and OFDataPip. Built upon OpenCDA and deployed in CARLA, it is presented not merely as a simulator in the narrow sense but as a high-fidelity platform and full-stack CDA environment for infrastructure-based research, with support for digital twin execution, real-world data ingestion, hybrid real/synthetic data generation, use-case design, and standardized benchmarking (Zheng et al., 25 Jul 2025).

1. Position within the OpenCDA ecosystem

Within CDA-SimBoost, OpenCDA-InfraX is the execution environment in which DTB-generated assets and OFDataPip-processed data are turned into running infrastructure-centric simulations, synthetic scenarios, and evaluations. The motivating claim is that intelligent infrastructure remains insufficiently explored in CDA research even though infrastructure-mounted sensing systems provide an elevated viewpoint, larger field of view, better visibility of occluded objects, stronger computation resources, and broader situational awareness for perception, prediction, and decision-making. OpenCDA-InfraX is proposed to operationalize these advantages while addressing long-tail/rare events, real-to-sim bridging, heterogeneous sensor management, reproducibility, and scalable evaluation (Zheng et al., 25 Jul 2025).

This emphasis marks a shift from the original OpenCDA formulation. OpenCDA was introduced as a generalized open-source framework for cooperative driving automation with three major components—a co-simulation platform, a full-stack cooperative driving system, and a scenario manager—and its architectural focus was primarily on connected automated vehicles rather than infrastructure-side agents (Xu et al., 2021). A plausible implication is that OpenCDA-InfraX should be read as an infrastructure-first specialization built on top of that earlier modular basis rather than as a separate lineage.

2. Internal architecture and software stack

The internal logic flow of OpenCDA-InfraX is organized around three major parts: Digital Twin Environment, CDA Ecosystem, and Use Case Design and Evaluation. The Digital Twin Environment imports DTB assets such as roads, buildings, and infrastructure; configures simulation through files specifying weather, lighting, time units, and simulation duration; and provides a scenario manager for traffic flow generation, background road-user generation, and dynamic behavior definitions. The paper states that these scenario configurations can function as complete standalone simulation scenarios and that OpenCDA-InfraX currently includes about ten predefined testing scenarios executable in CARLA and able to generate corresponding datasets (Zheng et al., 25 Jul 2025).

A key architectural interface is the Synthetic Data Generator. Its stated functions are to ingest real-world inputs, generate interactions between real-world data and simulated scenario elements, detect potential conflicts and collisions, and synthesize hybrid datasets combining real and simulated data. The resulting datasets include vehicles, pedestrians, trucks, buses, and cyclists. This is the principal mechanism by which OpenCDA-InfraX bridges real and synthetic domains (Zheng et al., 25 Jul 2025).

The CDA Ecosystem reuses OpenCDA as its architectural basis but changes the control center of gravity from vehicle-centric to infrastructure-centric. The crucial addition is the Infrastructure Manager, which defines, manages, and operates infrastructure units, groups co-located infrastructure components at an intersection, and supports coordinated local perception and decision-making. The Infrastructure Manager includes a Sensor Manager for flexible infrastructure-sensor configuration. Some modules are reused across both the CAV Manager and Infrastructure Manager—specifically Perception, V2X Manager, and Planning—whereas Control, Localization, and Data Dumper are adapted to infrastructure-specific needs; the paper gives traffic light phase management as an example of infrastructure-side control and GPS-based positioning as an example of infrastructure localization (Zheng et al., 25 Jul 2025).

The software stack explicitly includes OpenCDA, CARLA, Unreal Engine, RoadRunner, a ROS bridge, ROSbag, and an OpenDRIVE-style vector-map export/import path through CARLA. All resources are stated to be publicly available through the CDA-SimBoost repository at https://github.com/zhz03/CDA-SimBoost (Zheng et al., 25 Jul 2025).

3. Infrastructure abstractions and sensor model

What distinguishes OpenCDA-InfraX from earlier OpenCDA formulations is the treatment of infrastructure as an intelligent cooperative agent rather than as passive scenery or static sensing equipment. Infrastructure-side elements explicitly supported in the paper include intelligent infrastructure units, roadside cameras, roadside LiDAR, radars, traffic lights, multiple intersections, I2I coordination across corridors, V2X communication, and infrastructure-side sensing and decision-making. The paper also states that 2–3 IUs can be deployed at the same intersection and that deployment strategies may be centralized, partially distributed, or fully distributed (Zheng et al., 25 Jul 2025).

Two formal definitions anchor this abstraction. The intelligent intersection region $\mathcal{I}$ is defined as

$$\mathcal{I} = \left\{ \begin{aligned} \sqrt{(x - x_c)^2 + (y - y_c)^2} \leq d_f, \ \text{ground} \leq z \leq \text{ground} + 4 \,\text{m} \end{aligned} \right\},$$

where $(x_c, y_c, z_c)$ is the center of the intersection, $(x, y, z) \in \mathbb{R}^3$ is a location point in the region, and $d_f$ is the region radius, typically 50 to 100 meters. The Individual Infrastructure Unit (IU) is defined as

$$\text{IU} = \left\{ s \in \mathcal{S} \ \middle|\ \begin{aligned} &\forall\, s_i, s_j \in \text{IU}, \ &\sqrt{(x_i - x_j)^2 + (y_i - y_j)^2} \leq 2m, \ &|z_i - z_j| \leq 4m, \ & p_i = p_j \end{aligned} \right\},$$

where sensors in the same IU are co-located and share the same processing unit (Zheng et al., 25 Jul 2025).

Sensor configuration is explicitly heterogeneous. The paper states support for configurable camera resolution, LiDAR range, radar angles, fields of view, sensor positions, and sensor orientations. It also states that fusion modules are available, including late fusion, intermediate fusion, and cooperative perception models. At the same time, it does not provide detailed low-level sensor physics models, explicit infrastructure-camera calibration equations, or a detailed synchronization protocol beyond ROS/ROSbag-based support. This suggests a platform that is strong on configuration and systems integration but less explicit, in the paper itself, on low-level sensing mathematics (Zheng et al., 25 Jul 2025).

4. Digital twin construction and real-to-sim bridging

OpenCDA-InfraX is tightly coupled to a pipeline that starts from real-world data and ends in a runnable infrastructure simulation. DTB creates an HD point cloud map, an HD vector map, and simulation assets reflecting the real intersection. These are imported into Unreal Engine and then used to generate a CARLA map. OFDataPip processes online and offline data from connected automated vehicles and smart infrastructure, standardizing object states—position, orientation, type, and tracking ID—through the ROS bridge and enabling synchronized playback via ROSbag. OpenCDA-InfraX then initializes its digital twin environment from DTB assets, replays or streams dynamic objects from OFDataPip, adds synthetic traffic and controllable ego agents, and generates hybrid real+synthetic interaction scenarios (Zheng et al., 25 Jul 2025).

The paper is explicit that real-world traffic data can be projected into simulation, with object states updating simulated actors over time. It also states that the Synthetic Data Generator can check interactions, including potential conflicts and collisions, while constructing hybrid datasets. Challenging scenario design is described as being based on NHTSA analytical data and guidelines together with real-world traffic streams; the paper reports six types of hazardous use cases and examples of traffic violation scenarios in simulated towns (Zheng et al., 25 Jul 2025).

A common misconception would be to treat this merely as map import plus playback. The architecture described in the paper is broader: OpenCDA-InfraX consumes scenario configuration, sensor configuration, and environmental configuration; produces runnable infrastructure-centric simulations, corresponding datasets, synthetic and hybrid real/synthetic data, performance analysis outputs, customized data dumps per IU, and benchmarking results; and supports both online streaming and offline replay workflows (Zheng et al., 25 Jul 2025).

5. Benchmarking framework and empirical results

OpenCDA-InfraX is positioned as a benchmark-supporting platform for synthetic data generation, cooperative perception, V2X applications, I2I applications, sensor placement evaluation, system-level traffic evaluation, individual CAV evaluation, and planning/control validation in dynamic intersections. The paper lists system-level traffic metrics—throughput, delay, and average speed—and agent-level metrics including AP at different IoU thresholds, multiclass mAP, distance-based mAP following nuScenes, and the pose-estimation metrics ATE, ASE, and AOE. The only explicit metric formula provided is the definition of Average Scale Error:

$1 - \text{scale IoU}.$

The platform also includes approximately ten predefined testing scenarios, six hazardous use-case types, traffic violation examples, and scenarios based on NHTSA pre-crash scenario typology (Zheng et al., 25 Jul 2025).

The quantitative demonstrations reported in the paper are centered on V2X and I2I perception and on simulator scalability. In the V2X setting, Late Fusion improves on No Fusion from ATE/ASE/AOE/[email protected]/AP@Dist of 0.517/0.209/0.088/0.348/0.378 to 0.409/0.190/0.076/0.481/0.507. In the I2I setting, Late Fusion improves on No Fusion from 0.430/0.221/0.153/0.487/0.515 to 0.262/0.135/0.139/0.592/0.626. The paper interprets these results as evidence that the infrastructure-centric setup can support meaningful cooperative perception experiments and that I2I late fusion yields especially strong gains (Zheng et al., 25 Jul 2025).

The scalability profiling reports CARLA performance as intersection count increases from one to four. FPS degrades from 1.10 to 0.40; CPU rises from 288% to 372%; MEM rises from 6.7% to 9.0%; and RSS rises from 2166 MB to 2869 MB. The authors interpret this as notable FPS degradation with steadily rising resource usage that nevertheless remains within practical bounds, suggesting that OpenCDA-InfraX can scale to moderately complex urban scenarios (Zheng et al., 25 Jul 2025).

6. Relation to adjacent OpenCDA-based research

OpenCDA-InfraX sits within a broader OpenCDA-based research trajectory that includes vehicle-centric simulation, V2X perception datasets, and infrastructure-adjacent benchmarks. The original OpenCDA framework established the baseline modular architecture—CARLA/SUMO co-simulation, full-stack cooperative driving, and scenario management—but did not define an infrastructure-side software stack, RSU hierarchy, or infrastructure sensor-fusion pipeline (Xu et al., 2021). The later OpenCDA ecosystem paper broadened that foundation by integrating OpenCOOD, large-scale datasets, and V2XSet, which added roadside units to enable vehicle-to-infrastructure cooperation (Xu et al., 2023).

Several adjacent works clarify the distinction between OpenCDA-InfraX and nearby concepts. “V2X-ViT” created V2XSet using CARLA and OpenCDA, with both vehicles and infrastructure agents, and is therefore a direct predecessor for OpenCDA-based vehicle–infrastructure cooperative perception (Xu et al., 2022). “Adver-City” used CARLA with OpenCDA to generate a V2X dataset containing vehicles and RSUs under adverse weather, although the reported benchmark excluded RSU data because the imported model did not support V2X (Karvat et al., 2024). By contrast, “STCLocker” evaluated OpenCDA as a modular ADS supporting cooperative communication inside CARLA but explicitly did not add RSUs, V2I coordination, or infrastructure-side control; its relevance is methodological rather than architectural (Cheng et al., 30 Jun 2025). A different neighboring direction is “eCAV,” which extends OpenCDA toward an edge-assisted evaluation substrate with a pluggable edge node and network emulation, but whose infrastructure model is mainly an abstract edge coordinator rather than the richer infrastructure-sensing and digital-twin abstractions used in OpenCDA-InfraX (Landle et al., 19 Jun 2025).

7. Limitations and significance

The paper is explicit about several omissions. It does not provide a full low-level sensor rendering model, explicit calibration-pipeline equations, a detailed network-stack implementation for V2X delays, or a formal benchmark-protocol document beyond listed scenarios and metrics. It also does not specify a more detailed synchronization protocol beyond ROS bridge streaming, ROSbag replay, and frame-by-frame updates. These absences matter because OpenCDA-InfraX is presented as high-fidelity and infrastructure-centric, yet some of the most operationally delicate elements of infrastructure systems—sensor calibration, timing discipline, and communication realism—remain only partially described in the paper (Zheng et al., 25 Jul 2025).

Even with those omissions, OpenCDA-InfraX occupies a specific place in the literature. It is the execution and experimentation core of CDA-SimBoost: a platform that combines digital twin assets, real-world stream processing, infrastructure-agent abstractions, hybrid real/synthetic scenario generation, and benchmarking in a single OpenCDA-derived environment. This suggests a broader research significance. Rather than treating infrastructure as a peripheral data source, OpenCDA-InfraX formalizes infrastructure as a first-class participant in CDA experiments, with its own agents, sensing layouts, local decision-making, and cross-intersection coordination. In that sense, it is best understood as an infrastructure-first extension of the OpenCDA line that turns digital twins, streaming real data, and intelligent roadside systems into a unified experimental substrate for cooperative driving research (Zheng et al., 25 Jul 2025).