OScar - Open Stack for car

Maintainers and Contects:

Francesco RAVIGLIONE [francescorav.es483@gmail.com]
Carlos Mateo RISMA CARLETTI [carlosrisma@gmail.com]
Diego GASCO [diego.gasco99@gmail.com, diego.gasco@polito.it]
Giuseppe Perrone [giuseppe.perrone@polito.it]
Marco RAPELLI [rapelli.m@libero.it]
Claudio CASETTI [claudio.casetti@polito.it]

Other Contributors

Alessandro GENOVESE [alessandro.genovese@icloud.com]
Alessandro GIACCAGLINI
Mauro VITTORIO

This project is licensed under a GPL-2.0 License. Please see also the LICENSE file for more details.

How to cite OScar

M. Rapelli, F. Raviglione and C. Casetti, "OScar: An ETSI-Compliant C-ITS Stack for Field-Testing with Embedded Hardware Devices" in 2024 22nd Mediterranean Communication and Computer Networking Conference (MedComNet), June 2024. DOI: 10.1109/MedComNet62012.2024.10578207 URL BibTeX

Overview

The OScar - Open Stack for car framework is an ongoing C++ open implementation of the ETSI C-ITS stack for vehicular communications. OScar is designed to be an efficient, lightweight, single-executable, self-contained implementation of the ETSI C-ITS standards.

OScar is meant to be used on real hardware boards for vehicular communication and it was successfully tested on dedicated V2X boards running OpenWrt-V2X.

This project includes a full open source implementation of the ETSI CA Basic Service, with reference to the standard ETSI EN 302 637-2 V1.4.1, including the BTP and GeoNetworking layers. CAMs version 2 are currently being managed (there is currently no official support for the older CAMs version 1).

It includes an implementation of the ETSI VRU awareness Basic Service (VBS), with reference to the standard ETSI TS 103 300-3 V2.1.1. The implementation is complete except for the clustering feature.

It also includes the implementation of the ETSI Collective Perception Service (CPS), with reference to the standard ETSI TS 103 324 V2.1.1, allowing the transmission of CPMs version 2.

Finally, OScar includes a preliminary implementation of the ETSI Decentralized Environmental Notification Basic Service according to ETSI EN 302 637-3 V1.3.1. The transmission of DENM messages can be enabled with the --enable-DENMs-tx option and triggered via a dedicated JSON-over-TCP interface. This implementation is under development, and it currently supports the transmission of unsecured DENMs with circular destination areas. Reception is currently limited to logging (the insertion of events in the LDM is under development).

OScar thus supports the following message types:

Cooperative Awareness Messages (CAMs) according to ETSI EN 302 637-2 V1.4.1
Vulnerable road users Awareness Messages (VAMs) according to ETSI TS 103 300-3 V2.1.1
Collective Perception Messages (CPMs) according to ETSI TS 103 324 V2.1.1
Decentralized Environmental Notification Messages (DENMs) according to ETSI EN 302 637-3 V1.3.1.

Decentralized Congestion Control (DCC)

OScar implements Decentralized Congestion Control (DCC) across multiple protocol layers:

DCC_ACC — Access layer
DCC_NET — Network layer
DCC_CROSS — Cross-layer coordination

Both Reactive and Adaptive congestion control modalities are supported, in compliance with
ETSI TS 102 687 V1.2.1 (2018-04).

V2X Security

OScar currently implements security header and certificate formats according to ETSI TS 103 097 V2.1.1. This enables the transmission and reception of secured V2X messages, with L0 security.

The Enrollment Certificate (EC) and Authorization Tickets (AT) retrieval needs a working Internet connection (e.g., via cellular network when on a vehicle), and will be performed automatically the first time security is enabled. Both EC and AT will be then cached for subsequent uses, so that secured messages can be transmitted even when no connection to the Internet is available (until they expire and need to be requested again.

Security can be enabled with the --enable-security option, and configured by customizing the PKI_info.ini file (a sample INI file is provided in the main directory of this repository).

Next Developments

The support for other relevant message types is also planned for the near future:

Infrastructure to Vehicle Information Message (IVIM) according to ETSI TS 103 301 V1.3.1 , PD CEN ISO/TS 19321:2020 and BS EN ISO 14823:2017
MAP (topology) Extended Messages (MAPEM) and Signal Phase And Timing Extended Message (SPATEM) according to ETSI TS 103 301 V1.3.1
Electrical Vehicle Charging Spot Notification (EVCSNs) according to ETSI TS 101 556-1 V1.1.1
An ETSI-compliant proposal of a new type of message, i.e., Cooperative Enhancement Messages (CEMs) for the exchange of raw GNSS data, according to this paper and to the ms-van3t-CAM2CEM project

Important Notes

The OScar framework stems from other existing GitHub projects:

An open-source simulation and emulation framework for vehicular networks, VaN3Twin
The "Open Cooperative Awareness Basic Service", OCABS
An open vehicle Local Dynamic Map (LDM) implementation, i.e., the "Automotive Integrated Map", AIM

Important: OScar needs a source of navigation data either through gpsd or by connecting directly to a receiver via serial interface. Thus, a GNSS device must be available (either real, or emulated, for instance thanks to tools like gpsfake, the Cohda Wireless vsim or TRACEN-X).

The OScar main help, with all the possible options, can be displayed with ./OScar --help, after compiling the OScar binary.

Compiling OScar

OScar can be easily compiled on the same device in which it will be run using make.

Before building, make sure the following development packages are installed:

libgps-dev
libssl-dev
libnl-3-dev
libnl-genl-3-dev

On Debian/Ubuntu based systems you can install them with:

sudo apt-get install libgps-dev libssl-dev libnl-3-dev libnl-genl-3-dev

To download and build the latest version of OScar, first, clone this repository:

git clone https://github.com/DriveX-devs/OScar

Then, cd into the newly created directory:

cd OScar

Finally, build OScar:

make

The OScar binary file will be called OScar.

Then, make sure that a GNSS data provider is active and gpsd is running (you can use the gpsmon tool to check if GNSS PVT data is actively being received), with gpsmon -n <gpsd IP>:<gpsd port>.

Considering the transmission of CAMs, you can then launch OScar with (a stationID should be specified all the times with the -v option):

./OScar -C -v <unsigned 32-bit integer stationID> -D <IP or URL of the device where gpsd is being run - usually localhost/127.0.0.1> -P <port to use for the connection to gpsd> -L <log file name> -I <interface from which CAMs will be disseminated> -x -m

If you get a permission denied error (as OScar is internally using raw sockets), you can try launching again OScar with sudo or from the root user.

Cross-compiling OScar for OpenWrt

OScar is also designed to be easily cross-compiled for any embedded platform or router running OpenWrt.

Cross-compilation also leverages make. However, it requires a few additional steps, after cloning the repository.

First of all, an OpenWrt toolchain must be available in the device used for cross-compilation, with the PATH and STAGING_DIR environment variables being properly set. You can find additional information on how to set up the OpenWrt toolchain here. When performing the build procedure steps, select the libgps package with make menuconfig.

Then, open the OScar Makefile and update lines 8 and 10 (this needs to be done only once per development PC):

Line 8 (OPENWRT_LIBGPS_VER) should be updated with the libgps version which came with the OpenWrt toolchain installation (currently, it should be kept to 3.23, but it may change in the future)
Line 10 (OPENWRT_INCLUDE_DIR) should be updated to point to the directory where th

OScar

Install / Use

README