---
title: 'OpenCAMS: Integrated Co-Simulation Platform'
url: https://www.emergentmind.com/topics/opencams
type: topic
---

# OpenCAMS: Integrated Co-Simulation Platform

Searching arXiv for OpenCAMS and directly related papers to ground the article.
OpenCAMS commonly denotes an open-source connected and automated mobility co-simulation platform that tightly couples SUMO, CARLA, and OMNeT++ in a single, bidirectionally synchronized, discrete-time-step loop. In that usage, it is designed to support advanced research in transportation safety, mobility, and cybersecurity by combining large-scale microscopic traffic modeling, high-fidelity 3D perception and control simulation, and modular event-driven network communication such as C-V2X [2507.09186]. In a separate surveillance-camera literature, however, “OpenCAMS” is also used for Open Circuit Television when instantiated on a camera platform that employs cryptographic key-distribution; that camera-centric usage is distinct from the transportation platform, and distinct again from OpEnCam, a lensless optical encryption camera [2004.08602] [2312.01077].

## 1. Core simulator composition and system role

OpenCAMS is described as an open-source, synchronized, and extensible co-simulation framework that tightly couples three best-in-class simulation tools: SUMO, CARLA, and OMNeT++. SUMO manages large-scale, microscopic traffic flow, including car-following with IDM/Krauss and lane-changing with LC2013/SL2015, and controls route assignment, traffic signals, and background vehicles via TraCI. CARLA provides high-fidelity 3D environment, vehicle dynamics, and sensor emulation, including LiDAR, camera, radar, and GNSS, and runs in synchronous time-step mode for strict coupling. OMNeT++, with INET and Veins, simulates the full C-V2X protocol stack, including PC5 sidelink and Uu, from application to PHY, and uses Veins’ TraCIManager to synchronize with SUMO while assigning mobile and static nodes for V2V and V2I [2507.09186].

| Simulator | Principal role | Coupling mechanism |
|---|---|---|
| SUMO | Large-scale, microscopic traffic flow | TraCI, multi-client mode |
| CARLA | High-fidelity 3D perception, dynamics, and control | CARLA Python API, synchronous time-step mode |
| OMNeT++ | Event-driven C-V2X communication | INET, Veins, modified TraCIManager |

The architecture is organized around a high-level per-tick flow. SUMO advances one $\Delta t$ and reports vehicle positions and light phases; OMNeT++ updates node mobility and performs network events; a Python bridge forwards positions to CARLA and drives CARLA sensors and control; CARLA ticks $\Delta t$ and returns control inputs, such as acceleration, to SUMO; and SUMO waits until both clients request the next step. This arrangement preserves the native role of each simulator while placing them in a unified testbed.

## 2. Bidirectional synchronization and discrete-time coupling

The defining mechanism of OpenCAMS is bidirectional, time-synchronized coupling. SUMO runs in multi-client TraCI mode, waiting for all clients to connect and set an execution order. OMNeT++ uses a modified TraCIManager with order 1 to pull mobility from SUMO and to push mobility updates back. A Python script, `run_synchronization.py`, with order 2 connects both to SUMO and to CARLA via the CARLA Python API. Both clients must call `simStep()` in SUMO before it advances, and SUMO blocks until all clients have called `step()` [2507.09186].

All three simulators share a common discrete time-step $\Delta t$. By default, $\Delta t = 0.1\ \text{s}$, but users may configure each simulator’s step length consistently to preserve causality. In practical terms, the synchronization loop is a lock-step barrier: OMNeT++ processing can dominate wall-clock execution, while SUMO and CARLA freeze in sim-time until OMNeT++ completes each step, preserving determinism. This makes the platform suitable for studies in which traffic, perception, control, and communication must evolve coherently rather than as loosely coupled traces.

A common misconception is that OpenCAMS is merely a one-way SUMO-to-CARLA bridge with networking added afterward. The documented loop is explicitly bidirectional and synchronized: OMNeT++ both consumes and affects mobility, CARLA returns control inputs to SUMO, and SUMO will not proceed until both clients request the next step. The result is a discrete-time co-simulation rather than sequential replay.

## 3. Communication-node mapping and C-V2X modeling

For each SUMO vehicle ID, OMNeT++ spawns a corresponding Veins `TraCIMobility` module bound to the same position. Static roadside units are defined in an OMNeT++ `.ned` file, for example `StaticRSU` nodes, with fixed coordinates, and `omnetpp.ini` configures how many mobile and static nodes to instantiate and their network parameters [2507.09186].

The communication stack is described in domain-specific layers. At the application layer, INET and Veins provide BSM/CAM and SPaT/MAP message generation modules. At the network and MAC layers, the framework supports LTE/5G NR sidelink PC5, with DSRC fallback via Veins. At the PHY layer, it uses log-distance path-loss plus obstacle attenuation using SUMO `.poly.xml` building polygons. Message formats include Basic Safety Message, approximately SAE J2735, Cooperative Awareness Message and Decentralized Environmental Notification Message, and SPaT and MAP.

The significance of this mapping is methodological. SUMO supplies network-wide mobility and infrastructure context, OMNeT++ instantiates communication entities as simulation modules aligned to that mobility, and CARLA can render only the subset of vehicles that require detailed sensor emulation and control logic. This suggests that OpenCAMS is intended to preserve scale where scale is needed and fidelity where fidelity is needed, rather than forcing all entities into the same simulator.

## 4. Extensibility, interfaces, and configuration model

Although SUMO, CARLA, and OMNeT++ form the foundational core of OpenCAMS, the platform is described as expandable and future-proof, allowing additional simulators to be integrated on top of this core without requiring fundamental changes to the system architecture. SUMO’s TraCI supports $N$ clients, and any additional simulator, such as a ROS-based Autoware stack or a GNSS spoofing tool, can connect as client 3+ [2507.09186].

The extensibility model is adapter-based. The CARLA adapter is a Python client that uses `world.wait_for_tick()` to remain in lock-step without issuing ticks. The OMNeT++ adapter modifies or extends `TraCIManager` in C++ to add custom message handlers or new node types. New simulator modules need only implement a time-step request to SUMO with a unique client order, and exchange of relevant state variables such as vehicle poses or network events. The required interface functions are `connect()`, `step(delta_t)`, `getState()`, and `applyState(state)`.

The published setup sequence also emphasizes reproducibility. The platform is fully open-source and publicly available through its GitHub repository at `https://github.com/minhaj6/carla-sumo-omnetpp-cosim`. The documented environment uses CARLA 0.9.15, SUMO, OMNeT++ with Veins and INET, and the Instant-Veins VM for the OMNeT++ side with bridged networking to the CARLA host. Configuration is distributed across standard files such as `omnetpp.ini`, SUMO `.sumo.cfg`, and XML/NED artifacts. This makes scenario definition legible at the file level rather than being embedded in a monolithic runtime.

## 5. Applications, observables, and measured performance

The documented application space is organized around Safety, Mobility, and Cybersecurity. Representative scenarios include Forward Collision Warning, in which CARLA handles ego perception and braking, OMNeT++ handles BSM exchange, and SUMO models surrounding traffic ripple effects; Platoon Formation, in which CARLA handles vehicle actuation and sensors, OMNeT++ handles CAM exchange and control messages, and SUMO supplies non-cooperative background vehicles; and Sybil Attack, in which OMNeT++ injects multiple fake BSMs, CARLA ego misinterprets traffic density, and SUMO models collision and congestion [2507.09186].

| Domain | Scenario | Required domains |
|---|---|---|
| Safety | Forward Collision Warning (FCW) | CARLA, OMNeT++, SUMO |
| Mobility | Platoon Formation | CARLA, OMNeT++, SUMO |
| Cybersecurity | Sybil Attack | OMNeT++, CARLA, SUMO |

OpenCAMS also exposes observables for post-processing. Vector and scalar outputs and PCAP captures in OMNeT++ allow post-processing of PDR, latency, and network throughput. In the reported scalability observation, on an Intel i9-14th/64 GB/RTX 4090 system, a 30-vehicle scenario with 2 RSUs at $\Delta t = 0.1\ \text{s}$ runs at approximately $0.8\times$ real time. OMNeT++ processing often dominates, and the background simulators freeze in sim-time until OMNeT++ completes each step, preserving determinism.

These use cases illustrate the platform’s cross-layer purpose. The stated research implication is that, by unifying traffic, perception, and communication, OpenCAMS enables investigations such as how network latency degrades safety applications or how adversarial message injections cascade through vehicle control and traffic flow. Future extensions may include 5G NR Sidelink and Uu integration for MEC scenarios, ROS 2 / Autoware adapters, real-time GNSS spoofing or drone simulators for localization attacks, and formal security modules for C-V2X certificate validation.

## 6. Alternative camera-centric usage of “OpenCAMS” and distinction from OpEnCam

In the CryptoCam literature, OpenCAMS is not a transportation co-simulation platform. It is instead described as Open Circuit Television when instantiated on a camera platform that employs cryptographic key-distribution to realize Discoverability, Access and Restrictions, and Symmetry of Control. The OCTV framework is defined as the tuple
$$
\mathrm{OCTV} = (C, D, A, R, S),
$$
where $C$ is Configuration and Space parameters, $D$ is Discoverability, $A$ is Access and Restrictions, $R$ is Recording State disclosure, and $S$ is Symmetry of Control. CryptoCam is the concrete OpenCAMS prototype in that literature [2004.08602].

CryptoCam’s architecture comprises a Raspberry Pi Zero W with Pi Camera v2, BLE radio, and Wi‑Fi; a Node.js application with OpenSSL using AES‑256 and SHA‑256; a Bluetooth LE advertiser that periodically broadcasts key advertisements; a video segmenter and encryptor that splits capture into fixed-length segments; cloud storage; and a user listening client on Android or iOS. For segment $i$, the system generates a random key $K_i \leftarrow\$ U(\{0,1\}^{256})$, computes $H_i = \mathrm{SHA256}(M_i)$, encrypts $C_i = \mathrm{AES\text{-}256}_{K_i}(M_i)$, uploads the ciphertext, and deletes local plaintext. BLE packets carry the AES-256 key, packet sequence number, reconnect interval, video ID, and a hash prefix of the previous segment. Decryption is client-side, and subjects can retrieve and decrypt footage themselves without identifying to the operator.

That usage should also be distinguished from OpEnCam. OpEnCam is a lensless optical encryption camera in which two co-axial optical masks above a bare image sensor implement a double-mask forward model,
$$
Y = S \odot (P * X) + N,
$$
with optical encryption key $K = \{P, S\}$. It is presented as a hardware and reconstruction design for lensless optical privacy, not as Open Circuit Television and not as a mobility co-simulation platform [2312.01077].

The terminological overlap creates an obvious source of confusion. In current arXiv usage represented here, “OpenCAMS” most directly names the open-source connected and automated mobility co-simulation platform; in earlier surveillance-camera work, “OpenCAMS” names an OCTV instantiation realized by cryptographic key distribution; and “OpEnCam” is a separate lensless optical encryption camera. The names are similar, but the research objects, hardware/software stacks, and technical problem settings are different.

Source: https://www.emergentmind.com/topics/opencams