Open V2X.

The vehicle-side complement to V2X-Hub, maintained by the USDOT FHWA Saxton Transportation Operations Lab. Open-source platform for Cooperative Driving Automation (CDA) research, covering cooperative lane changes, platooning, intersection negotiation and SAE level 2-3 automation features that depend on V2X.

Part of a wider set. carma-streets handles signalised intersections from the road operator side; carma-messenger covers non-automated vehicles that still want to participate. Active development, daily commits, 400+ stars.

A V2X stack built on Vanetza and packaged for integration with the rest of the vehicle software. CAM, DENM, CPM and VAM each come with their own typed message interfaces (cube_ca_msgs, cube_den_msgs, cube_cp_msgs, cube_va_msgs); MAPEM and SPATEM are listed as upcoming. The compliance table in the README cites the exact EN/TS versions of each message and links the corresponding ASN.1 source. That pins a stack to a specific point in time.

Distributes over ROS 2 (Humble / Jazzy) and uses the etsi_its_messages package from ika-rwth-aachen for the ASN.1 typing. Conformance is checked explicitly against ETSI TR 103 099, unusual to see stated upfront and easy to forget once the codebase grows.

The Operational Data Environment maintained by the US Department of Transportation Joint Program Office. Ingests J2735 messages (BSM, TIM, SPaT, MAP), decodes them via ASN.1 and routes them onto Kafka topics, S3 buckets and the Situation Data Warehouse used by federal and state DOT analytics.

The closest thing the American side has to an official C-ITS infrastructure backbone. Where V2X-Hub is the RSU-side message handler, jpo-ode is the central-station data plane behind it. Active commits, weekly releases, large fork count from state DOTs running pilots.

Open Stack for Car (OScar) is a deliberately small ETSI C-ITS implementation from DriveX-devs, designed to run on low-end hardware. A Raspberry Pi plus a 5.9 GHz Wi-Fi module is enough to get a standards-compliant OBU/RSU for around €200 in parts.

Implements the CA Basic Service (ETSI EN 302 637-2 v1.4.1) including BTP and GeoNetworking, the VRU Basic Service (TS 103 300-3 v2.1.1), and security headers + certificate handling per TS 103 097 v2.1.1 at L0.

If you need to spin up dozens of physical field-test stations and Vanetza-on-x86 does not fit, OScar gets you the same baseline on cheaper, smaller hardware. The 2025 IEEE arXiv paper (2503.15461) lays out the design.

Open-source infrastructure-side V2X stack maintained by the US Department of Transportation FHWA Office of Operations. Designed for roadside units, it receives, processes and emits J2735 messages (SPaT, MAP, BSM, TIM, SRM, SSM, PSM) through a plugin architecture, with each message type handled by its own module.

Deployed in the USDOT Connected Vehicle Pilots (Tampa THEA, Wyoming DOT, NYC). The American counterpart to Vanetza on the infrastructure side, built on the IEEE 1609 and SAE J2735 stack. Active commits, daily push cadence.

The longest-running open implementation of the ETSI C-ITS protocol family. Originally a research codebase out of TU Dortmund, now maintained by Raphael Riebl and a small community. Used as the backbone of several simulator integrations, Artery in OMNeT++ among them.

It covers GeoNetworking, BTP, the message factories for CAM and DENM, IEEE 1609.2 security primitives, and a working DCC implementation. The newer CPM and VAM message sets are less complete, and still receive incremental contributions.

If you’re starting C-ITS work on Linux and want a stack you can step through with a debugger, this is the first stop.

A publicly reachable European V2X PKI testbed. It exposes an ECTL endpoint, the trust anchor, EA and AA certificates, and an AT-issuance flow over the ETSI TS 102 941 protocol. The endpoints answer without registration, so a stack can exercise certificate-chain handling against a live chain it did not fabricate.

The ECTL and TS 102 941 pages document what each endpoint returns, which makes them readable as worked examples of the trust-list and enrolment flows. A curve-support page lists the signature algorithms the deployment accepts.

Its scope is that of a testbed. No code is published, the certificates carry no operational trust, and the deployment is absent from the European Certificate Trust List. The underlying contracts follow ETSI TS 103 097 v2.1.1.

Framework For Misbehaviour Detection in cooperative ITS, covering both ITS-G5 and C-V2X, built on top of Veins and OMNeT++. Used to evaluate plausibility checks, attacker models and reporting protocols, and to generate the VeReMi-Extension dataset that has become the benchmark for ML-based misbehaviour detection papers since 2020.

The companion VeReMi dataset is frozen but still cited as the original baseline. Together they form the substrate of most recent papers on V2X misbehaviour ML, whether the author is comparing GAN-based detectors or classical plausibility heuristics.

An open-source Rust implementation of the Security Credential Management System defined in IEEE 1609.2.1 (2022 revision). Covers three of the server-side authorities that drive the V2X credential lifecycle (Registration Authority, Enrollment Certificate Authority and Authorization Certificate Authority), with a C cryptographic core wired through Rust bindgen. Ships as a deployable backend with OpenAPI contracts and Kubernetes manifests.

Complements v2verifier on the client side. OpenSCMS issues and manages the certificates that a real vehicle would carry, v2verifier exercises them in the message exchange. Components still open (Policy Generator, Misbehavior Authority, Linkage Authorities, CRL Generator) leave the current version well short of an end-to-end SCMS. A reference for anyone comparing the North American SCMS model with the ETSI TS 102 941 credential-management flow.

The first open-source implementation of the IEEE 1609.2 standard for vehicle-to-vehicle security, covering signing, verification and certificate management as they happen on the vehicle itself. Released by the RIT Wireless Information Network Lab; comes with an SDR experimentation harness that lets you exercise the security layer over real radio.

Complements OpenSCMS on the server side. Where OpenSCMS issues and rotates the certificates, v2verifier exercises them in the message exchange. Serves as a reference and as a starting point for anyone studying the gap between standardised security and what runs on a constrained OBU.

An ITS-S-side PKI client in C++. It implements the enrolment and authorization flows of ETSI TS 102 941, the secured PDU formats of TS 103 097, and CCMS trust-list discovery, over IEEE 1609.2 underlying types.

It covers the station end of the credential exchange, where a vehicle or roadside unit obtains an enrolment credential and then rotates authorization tickets. Most open implementations in this catalogue sit on the CA side of that same exchange.

The documentation is thinner than the implementation, and the project has no release history yet.

The classic Lev Walkin compiler at vlm/asn1c is a historical reference but not what V2X codebases ship with. Two forks dominate in practice:

• velichkov/asn1c. Long-running fork with UPER aligned/unaligned fixes that Vanetza and several research stacks track.
• mouse07410/asn1c. Maintained, and ships the OER encoder/decoder fixes required for IEEE 1609.2 and ETSI TS 103 097 v2.1.1 security headers. Picked up by FilLabs’ fitsec2 and a growing share of new projects.

If you pull a fresh V2X codebase and the build instructions tell you to clone “asn1c”, check the URL. Odds are it points at one of these forks. Mixing them with upstream vlm/asn1c will not work for security-layer encoding.

A Python alternative for one-shot decoding scripts is asn1tools, but for embedded C/C++ targets the mouse07410 fork is the practical default in 2026.

Message definitions, conversion functions and RViz plugins for the full ETSI ITS catalogue, covering CAM, CPM, DENM, IVIM, MAPEM, MCM, SPATEM and VAM. All of it is generated automatically from the upstream ASN.1 at forge.etsi.org/rep/ITS/asn1, so a new minor release of any message propagates without hand-coding.

Maintained by the Institute for Automotive Engineering (ika) at RWTH Aachen University. Used as the message backbone by several downstream V2X projects, including cube-its. ROS 2 support (Humble / Jazzy / Kilted).

Full IEEE 802.11 a/g/p transceiver implemented in GNU Radio, the reference for V2X work that touches the physical layer. Coverage tests, signal capture from real RSUs, jamming and interference studies, ITS-G5 prototyping on commodity SDR hardware.

Originally a tutorial implementation by Bastian Bloessl; now the canonical SDR-side stack for ITS-G5 and DSRC in academic literature. Pairs naturally with USRP B210 or N210. The starting point if your interest in V2X goes below the MAC layer.

Marben Products has been shipping ASN.1 tooling since the 1990s. Their automotive decoder targets the ETSI C-ITS message set specifically, covering CAM, DENM, CPM, MAPEM, SPATEM, IVIM, plus the security headers from TS 103 097.

It buys vendor support contracts, certified encoders and decoders that a legal team is happier signing off on, and a stable API that does not drift between PR merges. It costs money, the source is closed, and integrating it into open research code is awkward.

Even if you stick to open-source forks, the conformance a paid vendor certifies is what pilots and OEMs often validate against.

An alternative to asn1c for V2X codecs. Implements ASN.1 BER/DER/PER/UPER/OER in no_std Rust, with first-class library modules for IEEE 1609.2 security headers and certificates and for ETSI TS 103 097. Both standards are easy to mis-implement; doing them in safe Rust eliminates a class of memory-corruption bugs that have surfaced in C codecs over the years.

Pairs with librasn/compiler, which generates Rust types from raw ASN.1 sources. It earns its place when iterating on the unreleased fields of ETSI Release 2 messages or J2735 dictionary updates without waiting for vendor toolchain releases.

A server-side decoder for ETSI V2X messages. Paste a hex string, pick a type (CAM, DENM, CPM, VAM, MAPEM, SPATEM, SREM, SSEM, IVIM) and it returns a decoded JSON tree with the ETSI sentinel and unavailable markers expanded into readable values.

It decodes without verifying. Signatures are not checked and any well-formed UPER is accepted, with no validation against a trust chain, so it answers what a frame says, leaving trustworthiness to a real stack.

The REST endpoint at /api/v1/decode takes ?hex=...&type=cam and responds with JSON, which makes it scriptable from CI without compiling a local codec.

The reference open-source implementation of SOME/IP (Scalable service-Oriented middlewarE over IP), the service discovery and serialisation layer that AUTOSAR Adaptive Platform vehicles use for in-vehicle communication. Maintained by COVESA (the consortium formerly known as GENIVI).

The V2X angle is easy to miss. Once a vehicle gateway receives a DENM or BSM, what it speaks into the rest of the car is SOME/IP. A working understanding of vsomeip is what bridges a clean C-ITS stack on one side and the ECU domain on the other. Pairs with jamores/eth-ws-someip for Wireshark-side dissection.

Since Wireshark 4.x the C-ITS dissectors are in the mainline build, covering GeoNetworking, BTP, CAM, DENM, MAPEM, SPATEM, IVIM, SREM/SSEM. Drop a pcap with raw 802.11p or Ethernet-encapsulated ITS traffic and you get the full tree.

The dissectors are read-only. They decode without verifying signatures. For signature-validating analysis you still need a stack-level tool. But for “what did the OBU actually send” debugging, Wireshark out of the box is plenty.

TS 103 097 v2.1.1 security headers may show as “Reserved” fields on older Wireshark builds. The 4.4+ branch decodes them properly.

C-Roads is the joint initiative of EU member-state road authorities to harmonise day-1 and day-1.5 C-ITS services. This is where the profiles live, the agreed subsets of ETSI standards that pilots and deployments commit to. They fix which optional fields are present, which DENM cause codes are used for what, and which CPM object types.

Read the platform profile documents before integrating with any roadside infrastructure in Europe. The standards leave choices open; the C-Roads profile closes them. Tests against a real RSU will fail if your stack ignores this layer.

The deployment maps show which corridors are live, which is what you need when planning field-test routes.

The Common Certificate Policy Operator, hosted by the JRC (Joint Research Centre) at cpoc.jrc.ec.europa.eu. This is the operational endpoint of the European C-ITS Trust Model, where Root CAs join, where the European Certificate Trust List (ECTL) is signed and published, and where TLM certificates rotate.

The site holds three kinds of thing.

• Normative docs under /documents/, holding the CPOC Protocol (current Release 3.2, April 2026), the C-ITS Security Policy, the C-ITS Certificate Policy, the L0/L1/L2 CPOC-WEB Logbooks, the Annex I documents listing approved Station and Crypto-module Protection Profiles. This is the law for any pilot that wants its Root CA on the European trust list.
• Live binary endpoints under /data/certificates/, with ectl/{N}/{HID8}.oer for the current ECTL, tlm/{N}/{HID8}.oer for TLM and TLM link certificates. The {N} is the trust-list schema version (5 = v2.1.1, 7 = v2.2.1 at time of writing). HID8 is the ETSI HashedId8 of the cert. All COER-encoded per IEEE 1609.2.
• Operational forms under /documents/operational/, from CPA TOR procedures, S/MIME certs used to sign requests, the EU CCMS request-form ZIP. The plumbing for joining.

ECTLs rotate quarterly (Mar / Jun / Sep / Dec). The L0 ECTL is several times larger than L2 because it lists every L0 pilot Root CA; L2 is production-grade so it’s tighter.

If you are building a V2X stack and need to validate against the real trust list, this is the source. Many implementations only validate against locally-bundled certs and break the day they try to handle a production message. cpoc.jrc.ec.europa.eu is the cure.

The starting point for the standards themselves. ETSI publishes every TS/EN/TR cited in the C-ITS ecosystem here, in PDF, freely downloadable.

The numbers that keep coming up are TS 103 900 (CAM v2), TS 103 831 (DENM v3), TS 103 324 (CPM), TS 103 300-3 (VAM), TS 103 301 (facilities layer dictionary), TS 102 941 (PKI / trust model), TS 103 097 (security headers + cert format), TS 103 759 (misbehaviour reporting), EN 302 663 (access layer, ITS-G5).

Bookmark the committee page and search by document number. The portal-side filtering is mediocre, but every link gets you to a stable PDF.

The standard answer when someone asks “how do I simulate a thousand cars exchanging CAMs”. Artery wires Vanetza into OMNeT++ as the C-ITS stack and connects to SUMO for vehicle mobility. The same code paths you would run on a real OBU produce telemetry inside the simulator.

Even without running simulations, the Artery configuration files are a reference for default parameters (DCC, CAM trigger conditions, antenna models) when bringing up a real stack.

A multi-scale, multi-domain co-simulation framework for cooperative and connected mobility scenarios. Originally developed at Fraunhofer FOKUS as VSimRTI; relicensed and rehosted at the Eclipse Foundation, where it now sits alongside SUMO and other automotive simulators.

MOSAIC federates traffic simulation (SUMO), network simulation (ns-3 or OMNeT++), application logic and visualisation into a single time-synchronised run. Version 25.1 added a full-stack ns-3 LTE C-V2X integration. Where Artery is the academic-favourite OMNeT++ stack, MOSAIC leans industrial, with Eclipse-branded governance, a Java application layer and scriptable scenarios.

Continuation of SimuLTE for full 5G NR user-plane simulation in OMNeT++. Covers gNB scheduling, NR numerologies, beam management and, the part that matters here, NR sidelink Mode 2 for C-V2X. The reference in papers that need 5G C-V2X simulation outside of ns-3.

Compatible with the INET framework and slots into existing Artery / Veins setups for sidelink-aware scenarios. Released under LGPL by the Computer Networking Group at the University of Pisa, the same lab that has maintained SimuLTE since 2014.

The historical reference for VANET simulation. Couples OMNeT++ (network) with SUMO (traffic) and provides the IEEE 802.11p / WAVE PHY model that the academic literature has been benchmarking against since 2011. Conceptual predecessor to Artery and the basis of Plexe.

Maintained by Christoph Sommer’s group at the University of Paderborn. Still receives commits, and serves as the substrate in newer V2X experiments where the focus is on radio, channel modelling or mobility below the ETSI facilities layer.

The reference real-world dataset for cooperative perception in V2X research. Captured by the Institute for AI Industry Research (AIR) at Tsinghua University across roadside infrastructure and vehicle deployments. Three subsets cover V2V, V2I and fused cooperative scenarios, totalling around 464,000 annotated 3D objects across 10 classes.

Apache-licensed, used as the benchmark in dozens of cooperative perception papers since CVPR 2022. The follow-up DAIR-RCooper (2024) focuses on roadside-to-roadside cooperation specifically and is the closest published equivalent to the SPaT/MAP layer of cooperative perception research.

Real-world V2X dataset from TU München’s Providentia++ project. Five roadside lidars and four onboard sensors, around 30,000 annotated 3D boxes with track IDs across both sides plus precise GPS/IMU. Complementary geographically and methodologically to V2AIX from RWTH Aachen, with the same engineering ethos (instrumented public road segments, labels usable for cooperative perception) in a different city.

The dev-kit (parsers, visualisers, evaluation scripts) is the maintained part on GitHub; the dataset itself is downloaded via the project page after a short request form.

Recorded across 30 hours of measurement drives and stationary roadside infrastructure around Aachen and Düsseldorf, it holds 263,467 CAMs, 18,192 SPATEMs, 2,315 MAPEMs and 1,338 DENMs from 2,388 distinct ITS stations. According to the authors, the first multi-modal public dataset of ETSI ITS V2X messages captured in real public road traffic.

Distributed under a non-commercial academic license that covers research and teaching only, with no redistribution of the raw data and citation of the paper required. The dataset host at v2aix.ika.rwth-aachen.de serves an incomplete TLS chain, so the paper page is the reliable entry. Maintained by the Institute for Automotive Engineering (ika) at RWTH Aachen. The processing tooling is the same etsi_its_messages package already listed here.

The cellular-V2X consortium. While ETSI and C-Roads set the European ITS-G5 (802.11p / OCB) line, 5GAA pushes the C-V2X side, with PC5 sidelink for direct vehicle-to-vehicle and Uu for vehicle-to-cloud through the mobile network.

Their whitepapers are the readable surface of the spec, covering cross-RAT MCO, NR sidelink mode 2, V2N predictive QoS, vulnerable road user protection over PC5. They sit between academic writing and vendor marketing, with enough technical substance to be worth reading before forming opinions on the ITS-G5-vs-C-V2X debate.

The library lives at 5gaa.org/publications/. Open access, no login.

The reference write-up of the Security Credential Management System designed by CAMP and the USDOT for North American V2X. Documents the multi-organization separation between Registration Authority and Pseudonym CA, and the butterfly key expansion that lets one client request unlink large batches of certificates. It closes with the deployment lessons from a PoC at ~17M vehicles per year.

Implementing or reviewing the American side of V2X PKI without reading this paper is impossible. The earlier Whyte 2013 VNC paper is the shorter, first-version predecessor.

The Car 2 Car Communication Consortium’s position on misbehaviour detection and reporting in C-ITS deployments. Reads as the operational counterpart to ETSI TS 103 759. It leaves the message formats to the standard and discusses what an OEM is supposed to do once its fleet starts seeing misbehaving stations on the road.

It grounds security discussions in the European deployment context, where the gap between standardised mechanisms and real-world responsibilities is wide enough that consortium documents end up filling it.

The paper that put VANET security on the map. Maxim Raya and Jean-Pierre Hubaux, at EPFL in 2007, were the first to lay out the threat model for vehicular networks in full: sybil attacks, message replay, position spoofing. They also proposed the architecture of changing pseudonyms backed by a vehicular PKI, which the field has been refining ever since.

Almost every subsequent paper on V2X security cites this one as the starting point. Reading it explains why ETSI TS 102 941 and the IEEE 1609.2 SCMS look the way they do. The vocabulary was set here.