Pith. sign in

REVIEW 3 major objections 6 minor 35 references

OpenCAMS: An Open-Source Connected and Automated Mobility Co-Simulation Platform for Advancing Next-Generation Intelligent Transportation Systems Research

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

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

Pith's one-line read OpenCAMS couples SUMO, CARLA, and OMNeT++ in a synchronized discrete-time loop so traffic, perception, and C-V2X communication evolve coherently in one reproducible platform.

desk verdict Useful open-source co-simulation stack, but the synchronization guarantee is unverified; deserves peer review with a required validation section. read the letter →

arxiv 2507.09186 v3 pith:CWPMO3UQ submitted 2025-07-12 cs.SE

Minhaj Uddin Ahmad , Akid Abrar , Sagar Dasgupta , Mizanur Rahman This is my paper
classification cs.SE
keywords co-simulationconnectedandautomatedmobilitySUMOCARLAOMNeT++C-V2XTraCIintelligenttransportationsystems
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

OpenCAMS tries to establish that a coherent, reproducible co-simulation of connected and automated mobility is possible by coupling three open-source simulators in a single discrete time-step loop: SUMO for network-wide traffic, CARLA for high-fidelity perception and vehicle control, and OMNeT++ for C-V2X communication. The paper's claim is that this loop, driven by SUMO's multi-client TraCI mode, keeps all three domains synchronized so that closed-loop interactions—a vehicle sensing a hazard, receiving a V2X message, and changing its motion—unfold in the same simulated instant. This matters because existing tools simulate traffic, perception, and networking in isolation, which hides the cross-layer effects that safety, mobility, and cybersecurity applications depend on. The platform is designed without an abstraction layer over the simulators, so users retain full access to each tool's native features.

What carries the argument

The load-bearing mechanism is SUMO's multi-client TraCI loop running as a synchronous discrete time-step scheduler. TraCI (Traffic Control Interface) lets clients read and control the traffic simulation; here OMNeT++ registers as client order 1 and a Python synchronization script, which bridges CARLA, registers as client order 2, and SUMO refuses to step until both have finished their work for the current tick. The synchronization script pushes SUMO's vehicle and signal states into CARLA, which runs in synchronous mode, and reports CARLA-controlled vehicle states back to SUMO; OMNeT++ updates node positions from SUMO and runs the C-V2X protocol stack, ignoring broadcast responses meant for the other client. This loop, with no extra abstraction layer, is what the paper claims converts three independent simulators into one coherent platform.

What would settle it

Run a long multi-client scenario while deliberately slowing CARLA's sensor computation and log the simulation-time timestamp of every state update in SUMO, CARLA, and OMNeT++; any divergence in simulation time across the three, or any OMNeT++ packet processed from a broadcast intended for the Python client, would refute the claimed synchronization. A simpler check is to watch whether SUMO ever advances before both clients request the next step.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that OpenCAMS achieves time-synchronized, bidirectional coupling of SUMO, CARLA, and OMNeT++ by making SUMO the synchronization hub. OMNeT++ connects as TraCI client 1, and a Python bridge to CARLA connects as client 2; SUMO advances to the next simulation step only after both clients request it, so each tick contains a traffic update, a CARLA sensor and control update, and a C-V2X communication round. Vehicle positions and traffic-light states flow from SUMO to CARLA, while CARLA-controlled vehicle states flow back; OMNeT++ maps its communication nodes to the same vehicles and ignores broadcast responses not intended for it. The paper argues this design preserves the full capability of each simulator while keeping state evolution consistent and the whole simulation reproducible.

Load-bearing premise

The load-bearing premise is that SUMO's 'wait for all clients' rule, combined with CARLA's synchronous mode, actually produces one global clock with no causality violations across the three simulators; the paper states this coordination works but does not report measurements that verify it.

Editorial extensions

If this is right

  • Closed-loop safety scenarios such as forward collision warning, vulnerable road user protection, and blind-spot warning can be tested with perception, traffic, and V2X messaging all responding within the same time step.
  • Cyberattacks such as Sybil, replay, and traffic-signal manipulation can be injected with controlled timing and evaluated for their traffic and safety consequences in the same synchronized environment.
  • Additional clients, including GNSS simulators, Autoware stacks, ROS-based controllers, or Python scripts that manipulate traffic lights, can attach to the SUMO hub without redesigning the core loop.
  • Digital-twin experiments for intersections or corridors can mirror traffic state, ego-vehicle perception, and communication flows simultaneously, enabling real-time anomaly detection and attack testing.
  • Benchmarks for trajectory prediction, misbehavior detection, and cooperative driving become reproducible across traffic densities and weather conditions because every domain shares one simulation clock.

Reading between the lines

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

  • If the synchronization claim holds, temporal alignment itself becomes a controlled variable: researchers can attribute V2X-related failures to protocol or attack logic rather than to clock skew between simulators.
  • The freeze semantics imply that end-to-end throughput is bounded by the slowest simulator in each tick; a testable extension would measure how CARLA sensor load, such as LiDAR, degrades C-V2X update frequency, turning fidelity into a tunable trade-off.
  • Correctness rests on OMNeT++ ignoring broadcast responses intended for the other client; an empirical log comparing response routing across many ticks would strengthen the central claim beyond the paper's current statement.
  • Because the design keeps each simulator fully accessible, the platform could serve as a neutral testbed for comparing misbehavior-detection and V2X security algorithms across research groups, provided the multi-client clock is validated independently.
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

3 major / 6 minor

Summary. The paper introduces OpenCAMS, an open-source co-simulation platform that couples SUMO, CARLA, and OMNeT++ through a multi-client TraCI loop together with CARLA's synchronous mode. The authors claim that the platform executes the three simulators in a discrete time-step synchronized loop, enabling bidirectional coupling of traffic, perception, and communication domains. The manuscript describes the architecture, synchronization workflow, file organization, setup steps, an example command, and a range of envisioned use cases in safety, mobility, cybersecurity, and digital twins. The central claim is that this design ensures consistent state evolution and minimizes causality violations. No experimental validation is reported: there are no timing logs, no synchronization-error measurements, no event-ordering checks, and no end-to-end scenario with reported results; the only runtime evidence is the screenshots in Figure 5.

Significance. If the synchronization guarantee holds, OpenCAMS addresses a genuine gap by providing a fully open-source testbed that jointly models scalable microscopic traffic, high-fidelity sensing and vehicle dynamics, and full-stack C-V2X communication. Strengths of the paper include its use of widely adopted, actively maintained simulators; the absence of a monolithically imposed abstraction layer over the individual simulators; a clear description of the expected file structure and workflow; and a publicly available repository. The paper also usefully identifies limitations of existing co-simulation frameworks. However, the paper's advertised contribution is the synchronized execution loop, and that claim is currently supported only by architectural description and screenshots. Because the central value proposition is reproducible, coherent co-simulation, the absence of any empirical demonstration of synchronization is the decisive weakness of the manuscript as it stands.

major comments (3)
  1. [Section 3, Fig. 1] The central claim that SUMO advances only when OMNeT++ (client 1) and the CARLA-side Python script (client 2) both request the next step, and that OMNeT++ ignores broadcast responses not meant for it, is asserted in prose but never empirically verified. The manuscript reports no simulation-time logs, no wall-clock vs. simulation-time drift measurement, no event-ordering or causality-violation check, and no test of the response-discard logic under a competing or additional TraCI client. Because this barrier semantics is the load-bearing guarantee of the platform, the paper needs a validation section reporting representative runs: per-step simulation time in all three simulators, proof that both clients' advance requests are required, evidence that OMNeT++ consumes only its own responses, and edge cases such as client disconnection, concurrent requests, and operation with a third TraCI client using -n 3.
  2. [Section 4 and Figure 5] The paper claims the platform enables reproducible scenario-based benchmarking of safety, mobility, and cybersecurity applications, but it does not instantiate or evaluate any such scenario. Figure 5 only shows that the three simulator interfaces are open; it does not demonstrate synchronized state, consistent vehicle positions, or aligned simulation time. Please include at least one complete end-to-end run, for example a CARLA ego vehicle, SUMO background traffic, and periodic C-V2X messages in OMNeT++, with reported synchronization data, message counts, and a consistency check between vehicle positions across SUMO and CARLA. Without such a run, the claim that the platform is ready for the listed use cases remains untested.
  3. [Section 3.3] The statement in Section 3.3 that additional clients should not call world.tick() and should instead use world.wait_on_tick() is underspecified with respect to which component actually ticks CARLA in the synchronization loop. If run_synchronization.py is the tick-owning client, the paper should state this explicitly and explain the ordering guarantee between world.tick(), the TraCI step requests, and OMNeT++'s simulation-time advancement. If tick ownership is implemented differently, the CARLA branch of the synchronization claim needs a precise description, because an unstated tick owner makes the claimed coherence of the CARLA/SUMO/OMNeT++ loop impossible to verify independently.
minor comments (6)
  1. [Section 2, Table 1] The legend for Table 1 is unclear: the text uses "G #" and "#" but the reader cannot infer the intended gradation without examining each row twice; please define the markers explicitly in the table caption.
  2. [Abstract and Section 1] There are several typos, including "featues" in Section 1 and "relaated" in Section 2; the paper also uses inconsistent spellings such as "OMNet++" and "OMNeT++".
  3. [Section 3.2, Fig. 2-3] The file tree shows town5.sumo.cfg and town5.rou.xml, while the example command uses examples/Town05.sumocfg with different capitalization; this mismatch should be corrected so the documented workflow is unambiguous.
  4. [References] Reference [7] appears to contain corrupted author text ("M ¯artin, š Možeiko"); please verify the author list of the LGSVL paper.
  5. [Section 3.2] The sentence "We will updated the documentation at the repository for any future changes" is grammatically incomplete and should be rewritten.
  6. [Figure 1] The sequence-diagram labels mix capitalization styles ("Sumo", "Carla", "VEINS"), which makes the figure harder to read; please adopt a single convention.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular reasoning found: this is a systems-integration paper whose synchronization mechanism is an implementation claim, not a derivation from its own inputs.

full rationale

OpenCAMS contains no mathematical derivation, no fitted parameters, and no statistical prediction that could reduce to its inputs by construction. The central claim is that the platform runs SUMO, CARLA, and OMNeT++ in a synchronized discrete time-step loop. Section 3 presents this as an engineering mechanism: the modified Veins TraCIManager connects as TraCI client 1, run_synchronization.py connects as client 2, and the paper states that 'SUMO proceeds to the next simulation step only when all the connected clients ask SUMO to proceed.' That is a behavioral assertion about an externally documented simulator (SUMO multi-client TraCI mode), not a tautology or a definition of the conclusion. The claimed synchronization is also not justified by self-citation: the paper cites Veins, CARLA, SUMO, and other third-party tools as components, and no load-bearing argument rests on the authors' own prior work. The skeptic's concern that the multi-client handshake and the OMNeT++ response-discard logic are not empirically validated is a correctness and evidence gap, but it is not circularity: the implementation could be tested against SUMO's documented behavior and would be falsified if the loop desynchronized. No step in the paper renames a known result, imports a uniqueness theorem, or fits a parameter and calls it a prediction. Therefore the appropriate finding is no significant circularity, score 0.

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

The framework has no fitted parameters or invented entities. Its central reliance is on the correct and synchronized operation of the underlying simulators and on the custom coordination logic achieving true temporal alignment; these are domain assumptions rather than mathematically derived guarantees.

assumptions (3)
  • domain assumption Lock-step sequential execution of SUMO, CARLA, and OMNeT++ at each time step preserves temporal consistency and does not introduce simulation artifacts that invalidate scenario results.
    The paper asserts in Section 3 that 'consistent state evolution and minimizing causality violations' are achieved, but provides no experimental verification. This is the core assumption underpinning the co-simulation's validity.
  • domain assumption SUMO's multi-client TraCI mode broadcasts responses to all clients, and OMNeT++ can ignore responses not addressed to it without corrupting the simulation state.
    Stated in Section 3: 'We have added a logic such that OMNeT++ can ignore the client responses that is not meant for OMNeT++.' This relies on undocumented behavior of SUMO's TraCI implementation.
  • domain assumption CARLA's synchronous mode and the Python client's control of the simulation clock can be externally driven without conflicting with the co-simulation timing.
    The paper relies on this to maintain a common time step, but no verification is shown for the exact behavior over long runs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of OpenCAMS: An Open-Source Connected and Automated Mobility Co-Simulation Platform for Advancing Next-Generation Intelligent Transportation Systems Research." pith.science (2026). https://pith.science/paper/CWPMO3UQ

@misc{pith2026250709186,
  author       = {Pith},
  title        = {Pith review of: OpenCAMS: An Open-Source Connected and Automated Mobility Co-Simulation Platform for Advancing Next-Generation Intelligent Transportation Systems Research},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CWPMO3UQ}},
  note         = {Machine review of arXiv:2507.09186}
}
read the original abstract

We introduce OpenCAMS (Open-Source Connected and Automated Mobility Co-Simulation Platform), an open-source, synchronized, and extensible co-simulation framework that tightly couples three best-in-class simulation tools: (i) SUMO, (ii) CARLA, and (iii) OMNeT++. OpenCAMS is designed to support advanced research in transportation safety, mobility, and cybersecurity by combining the strengths of each simulation domain. Specifically, SUMO provides large-scale, microscopic traffic modeling; CARLA offers high-fidelity 3D perception, vehicle dynamics, and control simulation; and OMNeT++ enables modular, event-driven network communication, such as cellular vehicle-to-everything (C-V2X). OpenCAMS employs a time-synchronized, bidirectional coupling architecture that ensures coherent simulation progression across traffic, perception, and communication domains while preserving modularity and reproducibility. For example, CARLA can simulate and render a subset of vehicles that require detailed sensor emulation and control logic; SUMO orchestrates network-wide traffic flow, vehicle routing, and traffic signal management; and OMNeT++ dynamically maps communication nodes to both mobile entities (e.g., vehicles) and static entities (e.g., roadside units) to enable C-V2X communication. While these three simulators form the foundational core of OpenCAMS, the platform is designed to be expandable and future-proof, allowing additional simulators to be integrated on top of this core without requiring fundamental changes to the system architecture. The OpenCAMS platform is fully open-source and publicly available through its GitHub repository https://github.com/minhaj6/carla-sumo-omnetpp-cosim, providing the research community with an accessible, flexible, and collaborative environment for advancing next-generation intelligent transportation systems.

Figures

Figures reproduced from arXiv: 2507.09186 by the authors.

Figure 1
Figure 1. Simulation synchronization loop bidirectional because the traffic signal controller and the vehicles can be controlled by either SUMO or CARLA. All the vehicles in the simulation can be mixed, where some are controlled by SUMO and others are controlled by CARLA. This bi-directionality provides the user with design flexibility to utilize the co-simulation platform for vari￾ous research needs. For example, an AV with … view at source ↗
Figure 2
Figure 2. Project file organization Our GitHub repository contains a structured set of scripts and configuration files enabling co-simulation be￾tween CARLA, SUMO, and OMNeT++. The carlascripts/ directory contains Python scripts, such as run\_synchronization.py, which manages time synchronization across simulators. This script accepts con￾figurable parameters, and no changes is required in the provided scripts. The sumo-launc… view at source ↗
Figure 3
Figure 3. Workflow for customized simulation setup [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: SUMO clients SUMO provides a flexible TraCI interface that allows for the control of all simulation aspects and enables data collec￾tion. In the integrated co-simulation environment, the communication with OMNeT++ and CARLA are implemented through the TraCI interface. …
Figure 5
Figure 5. Figure 5: All three simulators running synchronously. [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

35 extracted references · 31 canonical work pages

  1. [1]

    Microscopic traffic sim- ulation using sumo

    Pablo Alvarez Lopez, Michael Behrisch, Laura Bieker-Walz, Jakob Erdmann, Yun-Pang Flötteröd, Robert Hilbrich, Leonhard Lücken, Johannes Rummel, Peter Wagner, and Evamarie Wießner. Microscopic traffic sim- ulation using sumo. In The 21st IEEE International Conference on Intelligent Transportation Systems . IEEE, 2018

    work page 2018

  2. [2]

    PTV Vissim – Multimodal Traffic Simulation Software

    PTV Group. PTV Vissim – Multimodal Traffic Simulation Software. https://www.ptvgroup.com/en-us/ products/ptv-vissim, 2025. Accessed: 2025-05-29

    work page 2025

  3. [3]

    CARLA: An open urban driving simulator

    Alexey Dosovitskiy, German Ros, Felipe Codevilla, Antonio Lopez, and Vladlen Koltun. CARLA: An open urban driving simulator. In Proceedings of the 1st Annual Conference on Robot Learning, pages 1–16, 2017

    2017

  4. [4]

    Omnet++ discrete event simulator

    OMNeT++ Community. Omnet++ discrete event simulator. https://omnetpp.org/, 2025. Accessed: 2025- 05-29

    work page 2025

  5. [5]

    ns-3: A discrete-event network simulator for internet systems

    ns-3 Project. ns-3: A discrete-event network simulator for internet systems. https://www.nsnam.org/, 2025. Accessed: 2025-05-29

    work page 2025

  6. [6]

    Aimsun: Mobility intelligence for decisions that count

    Aimsun. Aimsun: Mobility intelligence for decisions that count. https://www.aimsun.com/, 2025. Accessed: 2025-05-29

    work page 2025

  7. [7]

    Lgsvl simulator: A high fidelity simulator for autonomous driving

    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. Lgsvl simulator: A high fidelity simulator for autonomous driving. arXiv preprint arXiv:2005.03778, 2020

    arXiv 2005

  8. [8]

    Taxonomy and definitions for terms related to on-road motor vehicle automated driving systems

    SAE On-Road Automated Vehicle Standards Committee et al. Taxonomy and definitions for terms related to on-road motor vehicle automated driving systems. SAE Standard J, 3016:1, 2014

    work page 2014

Show all 35 references
  1. [9]

    Autoware: Open-source software for autonomous driving

    Autoware Foundation. Autoware: Open-source software for autonomous driving. https://autoware.org/,

  2. [10]

    Congested traffic states in empirical observations and microscopic simulations

    Martin Treiber, Ansgar Hennecke, and Dirk Helbing. Congested traffic states in empirical observations and microscopic simulations. Physical review E, 62(2):1805, 2000

    2000

  3. [11]

    German aerospace center

    Stefan Krauß and Mobility Department Systems Engineering. German aerospace center. Technical report, Tech. rep, 1998

    1998

  4. [12]

    Traffic simulation with sumo–simulation of urban mobility

    Daniel Krajzewicz. Traffic simulation with sumo–simulation of urban mobility. In Fundamentals of traffic simulation, pages 269–293. Springer, 2010

    2010

  5. [13]

    Sumo’s lane-changing model

    Jakob Erdmann. Sumo’s lane-changing model. In Modeling Mobility with Open Data: 2nd SUMO Conference 2014 Berlin, Germany, May 15-16, 2014, pages 105–123. Springer, 2015

    2014

  6. [14]

    Sumo 2016–traffic, mobility, and logistics

    Robbin Blokpoel, Mahtab Joueiai, Mirko Barthauer, Bernhard Friedrich, Andreas Richter, Hartmut Friedl, Michael Scholz, Mario Krumnow, Yun-Pang Flötteröd, Jakob Erdmann, et al. Sumo 2016–traffic, mobility, and logistics. In Proceedings of the SUMO2016, 2016

    2016

  7. [15]

    Traci: an interface for coupling road traffic and network simulators

    Axel Wegener, Michał Piórkowski, Maxim Raya, Horst Hellbrück, Stefan Fischer, and Jean-Pierre Hubaux. Traci: an interface for coupling road traffic and network simulators. In Proceedings of the 11th communications and networking simulation symposium, pages 155–163, 2008

    2008

  8. [16]

    Airsim: High-fidelity visual and physical simulation for autonomous vehicles

    Shital Shah, Debadeepta Dey, Chris Lovett, and Ashish Kapoor. Airsim: High-fidelity visual and physical simulation for autonomous vehicles. In Field and Service Robotics, 2017. 15 A PREPRINT - SEPTEMBER 7, 2025

    2017

  9. [17]

    Apollo: Open source autonomous driving platform

    ApolloAuto. Apollo: Open source autonomous driving platform. https://github.com/ApolloAuto/ apollo, 2025. Accessed: 2025-05-29

    2025

  10. [18]

    A novel traffic simulation framework for testing autonomous vehicles using sumo and carla

    Pei Li, Arpan Kusari, and David J LeBlanc. A novel traffic simulation framework for testing autonomous vehicles using sumo and carla. arXiv preprint arXiv:2110.07111, 2021

    2021 arXiv

  11. [19]

    Customized co-simulation environment for autonomous driving algorithm development and evaluation

    Mustafa Ridvan Cantas and Levent Guvenc. Customized co-simulation environment for autonomous driving algorithm development and evaluation. arXiv preprint arXiv:2306.00223, 2023

    2023 arXiv

  12. [20]

    A co-simulation frame- work for autonomous mobility in urban mixed traffic context

    Michele Roccotelli, Gaetano V olpe, Maria Pia Fanti, and Agostino Marcello Mangini. A co-simulation frame- work for autonomous mobility in urban mixed traffic context. In 2024 IEEE 20th International Conference on Automation Science and Engineering (CASE), pages 812–817. IEEE, 2024

    2024

  13. [21]

    Inet framework for omnet++

    INET Framework Community. Inet framework for omnet++. https://inet.omnetpp.org/, 2025. Accessed: 2025-05-29

    2025

  14. [22]

    Veins: The open source vehicular network simulation framework

    Veins Development Team. Veins: The open source vehicular network simulation framework. https://veins. car2x.org/, 2025. Accessed: 2025-05-29

    2025

  15. [23]

    Poster: A case for heterogenous co-simulation of cooper- ative and autonomous driving

    Tobias Hardes, Ion Turcanu, and Christoph Sommer. Poster: A case for heterogenous co-simulation of cooper- ative and autonomous driving. In 2023 IEEE Vehicular Networking Conference (VNC), pages 151–152. IEEE, 2023

    2023

  16. [24]

    Ms-van3t-carla: An open-source co-simulation framework for cooperative perception evaluation

    Carlos Mateo Risma Carletti, Claudio Casetti, Jérôme Härri, and Fulvio Risso. Ms-van3t-carla: An open-source co-simulation framework for cooperative perception evaluation. In 2024 19th Wireless On-Demand Network Systems and Services Conference (WONS), pages 93–96, 2024

    2024

  17. [25]

    A simulator for cooperative and automated driving security

    Mohammed Lamine Bouchouia, Jean-Philippe Monteuuis, Houda Labiod, Ons Jelassi, Wafa Ben Jaballah, and Jonathan Petit. A simulator for cooperative and automated driving security. In Workshop on Automotive and Autonomous Vehicle Security (AutoSec), Ndss-Symposium, 2022

    2022

  18. [26]

    Opencda: an open cooperative driving automation framework integrated with co-simulation

    Runsheng Xu, Yi Guo, Xu Han, Xin Xia, Hao Xiang, and Jiaqi Ma. Opencda: an open cooperative driving automation framework integrated with co-simulation. In 2021 IEEE International Intelligent Transportation Systems Conference (ITSC), pages 1155–1162. IEEE, 2021

    2021

  19. [27]

    Simutack - an attack simulation framework for connected and autonomous vehicles

    Andreas Finkenzeller, Anshu Mathur, Jan Lauinger, Mohammad Hamad, and Sebastian Steinhorst. Simutack - an attack simulation framework for connected and autonomous vehicles. In The 2023 IEEE 97th Vehicular Technology Conference: VTC2023-Spring (VTC2023-Spring), pages 1–7, 7 2023

    2023

  20. [28]

    Modeling an its management solution for mixed highway traffic with eclipse mosaic

    Karl Schrab, Maximilian Neubauer, Robert Protzmann, Ilja Radusch, Stamatis Manganiaris, Panagiotis Lytrivis, and Angelos J Amditis. Modeling an its management solution for mixed highway traffic with eclipse mosaic. IEEE Transactions on Intelligent Transportation Systems, 24(6)...

    2022

  21. [29]

    PHABMACS: Physically Re- alistic Vehicle Simulation Tool for Prototyping Cooperative ADAS

    DCAITI (Daimler Center for Automotive Information Technology Innovations). PHABMACS: Physically Re- alistic Vehicle Simulation Tool for Prototyping Cooperative ADAS. https://www.dcaiti.tu-berlin.de/ research/simulation/phabmacs/?lang=en, 2025. Accessed: 2025-07-12

    2025

  22. [30]

    Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis

    Christoph Sommer, Reinhard German, and Falko Dressler. Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis. IEEE Transactions on Mobile Computing, 10(1):3–15, January 2011

    2011

  23. [31]

    Multi-technology cooperative driving: An analysis based on plexe

    Michele Segata, Renato Lo Cigno, Tobias Hardes, Julian Heinovski, Max Schettler, Bastian Bloessl, Christoph Sommer, and Falko Dressler. Multi-technology cooperative driving: An analysis based on plexe. IEEE Transac- tions on Mobile Computing, 22(8):4792–4806, 2022

    2022

  24. [32]

    Opendrive 2010 and beyond–status and future of the de facto standard for the description of road networks

    Marius Dupuis, Martin Strobl, and Hans Grezlikowski. Opendrive 2010 and beyond–status and future of the de facto standard for the description of road networks. InProc. of the Driving Simulation Conference Europe, pages 231–242, 2010

    2010

  25. [33]

    RoadRunner

    MathWorks. RoadRunner. MathWorks, 2025. Available at https://www.mathworks.com/products/ roadrunner.html

    2025

  26. [34]

    Instant veins virtual machine

    Veins Project. Instant veins virtual machine. https://veins.car2x.org/documentation/ instant-veins/. Accessed: 2025-05-09. 16

    2025

  27. [2025]

    Accessed: 2025-05-29

    2025

Pith tools

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