Vehicle Communication Platform to Anything-VehicleCAPTAIN

Abstract

Vehicle-to-everything (V2X) is on the verge of being integrated as an integral part of modern vehicles. However, the battle for the final V2X radio technology is still not decided, and the available message standards are complex, hindering research and development. Hence, in our work, we provide a toolbox for early-stage development within V2X, called vehicle communication platform to anything (vehicleCAPTAIN). The vehicleCAPTAIN toolbox comprises (i) a set of software that mitigates the need to adapt for different V2X hardware vendors by decoupling and simplifying implementation, (ii) a set of libraries that supports encoding and decoding of messages, and (iii) a set of software bindings to enable development with ROS2. All software is provided as free and open source (FOSS). Within this work, we prove the functionality of the toolbox with classic end-to-end tests, as well as Qosium, a quality-of-service testing application. Finally, we highlight the applicability and benefits of the vehicleCAPTAIN toolbox for early-stage V2X research and development.

Acronyms

3GPP:

3rd Generation Partnership Project, is a union of seven mobile network standard development organizations.

ADD:

Automated Driving Demonstrator, is used short for vehicles that are used for automated driving demonstrations.

API:

Application Programming Interface, is a software interface to control another piece of hardware or software.

ASN1:

Abstract Syntax Notation One, is a syntax notation format.

CAM:

Cooperative Awareness Message, is a V2X message that allows an ITS-S to share information about itself.

CPM:

Collective Perception Message, is a V2X message that allows the exchange of sensor data, such as detected objects.

C-V2X:

Cellular V2X, is a V2X communication standard based on mobile networks.

DENM:

Decentralized Environmental Notification Message, is a V2X message that allows sharing of information, such as potholes, accidents, construction sites, etc.

DSRC:

Dedicated Short Range Communications, is protocol within WAVE.

ETSI:

European Telecommunications Standards Institute, is a European standardization institute.

FOSS:

Free and Open Source Software, is a term used for free software with publically available source code.

GNSS:

Global Navigation Satellite System, location discovery systems, such as GLONASS, GPS, etc.

HLA:

High-Level Architecture, is the high-level perspective of a complex system, typically in a diagram.

ITS:

Intelligent Transport Systems, the conglomeration of V2X capable actors.

IEEE:

Institute of Electrical and Electronics Engineers, is a standardization organization.

ITS-S:

ITS Station, a V2X actor.

ITSG5:

Intelligent Transport Systems G5; G5 stands for the frequency band (5.9GHz), is a V2X communication standard based on WIFI

IVIM:

In-Vehicle Information Message, is a V2X message that allows sharing of control information for driver and vehicle, such as speed limits, allowed automated driving levels, etc.

LTE:

Long Term Evolution, is a mobile network standard.

MQTT:

Message Queueing Telemetry Transport, is a middleware for data exchange.

OBU:

Onboard Unit, is a hardware component, within V2X, that is used in the vehicle for communication.

ROS2:

Robot Operating System 2, is a platform for rapid prototyping of robots.

RSSI:

Received Signal Strength Indicator, is an indicator for received signal strength.

RSU:

Roadside Unit, is a hardware component, within V2X, that is used by infrastructure for communication.

RTCMEM:

Radio Technical Commission for Maritime services Environmental Message, is a V2X message that allows sharing of GNSS correction data.

SAE:

Society of Automotive Engineers, is a standardization organization in the automotive domain.

UART:

Universal Asynchronous Receiver/Transmitter, is an interface for data exchange.

V2N:

Vehicle-to-Network, is the network-based communication between vehicles and everything else.

V2X:

Vehicle-to-Everything, is the wireless communication between vehicles and everything else.

WAVE:

Wireless Access in Vehicular Environments, is the wireless communication environment for 802.11p in the U.S.A.

ZMQ:

Zero Message Queue, is a middleware for data exchange.

WIFI:

Wireless Fidelity, is a communication standard for wireless networks.

1 Introduction

Automotive research started the standardization of the wireless standard 802.11 for vehicle-to-vehicle (V2V) communication in the early 2000s. Nowadays, the standard includes, among others, vehicle-to-infrastructure (V2I), and vehicle-to-network (V2N), the latter meaning communication via web-service backends. The family of vehicle communications with everything else is called vehicle-to-everything (V2X) communication. From the technology perspective, the 802.11p standard was released in 2010 by the Institute of Electrical and Electronics Engineers (IEEE) [1], which derives from the commonly known WiFi standard. Then, in 2017 the 3rd Generation Partnership Project (3GPP) [2] released the cellular V2X (C-V2X) standard based on the PC5 side channel in LTE. The IEEE and the 3GPP also announced predecessors 802.11bd and C-V2X (5G-based), respectively. Before the hardware crisis started in 2020, the soon available four technologies competed for a central standard. To date, the battle is still ongoing.

Communication for intelligent transport systems (ITS) also needed a software protocol. The Society of Automotive Engineers (SAE) and European Telecommunications Standards Institute (ETSI) started specification in parallel with their respective protocols, Wireless Access in Vehicular Environments (WAVE) and Intelligent Transport Systems G5 (ITS-G5). While the network protocol is not fully compatible, the messages found a common baseline. The ETSI consortia define the messages using parts of the messages defined in the Dedicated Short Range Communications (DSRC) protocol, which is part of WAVE. Nowadays, following the combined effort, all technologies mentioned above, i.e., 802.11p/bd and C-V2X (LTE/5G), are designed to use the message standards defined by ETSI, with messages such as cooperative awareness message (CAM) and decentralized environmental notification message (DENM).

V2X development now has an easy and complicated side. The easy side is that there is a common message protocol. The complicated side is the multitude of (soon) available hardware technologies. Before 2020, manufacturers of V2X solutions were providing mainly 802.11p systems but quickly adopting the released C-V2X (LTE) standard. Among others, Cohda,¹ Commsignia,² Yogoko,³ and Yunex⁴ are providing onboard units (OBUs) and roadside units (RSUs), each with its application programming interface (API). Adding multiple APIs now increases the effort in research and development for implementing application software if there is a need to stay independent of the underlying V2X technology. Each of the companies mentioned above aims to provide a single API. However, independent of the used technology, there is still the issue of adapting to multiple APIs and using other prototypes, such as V2N.

In our work, we aim to provide a solution for the interface problem. We created a platform that can host multiple V2X interfaces and route the messages from the interfaces to the user and from the user to the respective interfaces. This way, the user only has to implement one interface. The platform handles the actual hardware interfaces. In addition, we also provide a free and open source (FOSS) message library for the ETSI-defined messages to get started, as well as a ROS2 interface.

In the following Chap. 2, we provide more detail on the underlying issue of interfaces. In Chap. 3, we present the vehicle communication platform to anything (vehicleCAPTAIN) as the solution. The functionality of the vehicleCAPTAIN is then verified in Chap. 4. In Chap. 5, we discuss the applications and benefits of the vehicleCAPTAIN before concluding in Chap. 6.

2 Problem Statement

V2X has several communication standards. The most common are 802.11p and C-V2X (LTE), with their predecessors 802.11bd and C-V2X (5G). V2N extends this range with various web-based interfaces, with Ethernet, WiFi, 4G, and 5G as underlying technologies [3]. However, V2N needs a management system that relays messages to specific users, similar to the GeoNetworking protocol, with middleware, such as MQTT [4]. Going a step further, there are also mmWave protocols [5,6,7] currently under development that may be included in the V2X communication domain.

The complexity of this multi-interface structure should not hinder research and development of the application of V2X. Hence, there is a need for a platform that takes away the implementation effort for interfaces from the user. In other words, there is the need for a platform that is open enough to integrate new hardware interfaces with their respective APIs; have the option to configure the routing of messages, depending on the message type, payload, and connectivity; yet also provide one user interface for straightforward integration.

3 VehicleCAPTAIN—A V2X Platform for Research and Development

The vehicleCAPTAIN is a V2X toolbox designed for research and development and developed by Pilz et al. [8]. It is designed to lower the entry barrier for V2X development by providing various software repositories with sample code and libraries.

The components, shown in Fig. 1, are available as FOSS by Pilz et al. [8]. Essential details of the components are discussed in the following chapters. Section 3.1 introduces the routing platform and the core concept of how it eases development with V2X as a developing standard. Section 3.2 continues by introducing the C/C++ message library, followed by Sect. 3.3 introducing the ROS2 support.

Fig. 1

The vehicleCAPTAIN toolbox is split into four major groups. These four major groups currently result in seven public GitHub repositories

3.1 The Platform

The core elements of the vehicleCAPTAIN consist of a hardware configuration and the software routing core. The hardware configuration is independent of the software as long as the hardware can host the software and as long as the hardware configuration contains at least one transmission device with V2X capability. The software provides one interface to control one or more V2X interfaces simultaneously. The software simply needs an interface driver for the respective transmission device.

One can look at the HLA of the vehicleCAPTAIN, shown in Fig. 2, to understand how the platform works. The vehicleCAPTAIN provides a simple ZMQ interface for the user. Single V2X messages are exchanged as byte streams in both directions, receiving and sending. Starting with sending, the message is relayed to the Routing part. The Routing may be extended as required for research purposes. One may, for example, handle the GeoNetworking protocol here or prioritize specific messages. In the simplest case, the messages are relayed to the Communication Control. The Communication Control decides on the message type or other parameters via which interfaces to distribute the message. The message is then forwarded to the specific Interface implementations. Each Interface implementation then takes each message and transmits it by sending it via the respective hardware interface. Conversely, another vehicleCAPTAIN may receive a message via an Interface. The Interface implementation extends the incoming message with other received information, such as RSSI or geolocation. The Interface implementation holds this raw message in its incoming queue until the Communication Control collects it. The Communication Control collects and relays the messages to the Routing part. The Communication Control and the Routing part may also use the additional receiver information to adapt their behavior. In its simplest form, the message is relayed to the ZMQ interface for the user.

Fig. 2

The HLA of the vehicleCAPTAIN routing core. The left side shows V2X hardware interfaces. The bottom right has the user magic connected via ZMQ

All in all, the vehicleCAPTAIN routing core is a simple message-passing software. But depending on which and how many interfaces have to be tested, it eases implementation, as user code is separated from message relaying. One may test other messaging approaches, such as mmWave, UART communication, or Morse code. It simply depends on the implementation of the Interface implementation.

Last but not least, the vehicleCAPTAIN needs hardware. Currently supported is ITSG5 communication via the Unex SOM301-E and MQTT via Ethernet or plugged-in mobile network connections, such as 5G. The Virtual Vehicle Research GmbH can provide schematics or assembled hardware, as shown in Fig. 3. We currently use this setup with three modules. The Unex SOM301-E for ITSG5 communication, the Simcom sim8202g for 5G and V2N, and the Ublox F9P for highly accurate time-synchronization via 1pps.

Fig. 3

The vehicleCAPTAIN development kit in Quad Expander configuration, with a Raspberry Pi 4 as the computing platform (underneath the circuit board). The Quad Expander configuration can host up to four mPCI-E or M.2 modules. The configuration is from left to right (i) Ublox F9P with 1pps, (ii) empty, (iii) Unex SOM301-E, and (iv) Simcom sim8202g

3.2 Message Library

The ETSI provides the message exchange protocol for all V2X-related standards as Abstract Syntax Notation One (ASN1) in a public git repository [9]. Descriptions of each message element and the usage of each message are distributed across various public standardization documents. The ETSI repository contains scattered instructions on generating a C and C++ library from the specifications. However, it takes a few days of effort to set up everything.

A library can ease this entry barrier. Hence, Pilz et al. [8] made a generator script, which creates a ready-to-use library. The creation process is shown in Fig. 4. As one can see, everything is run in a Docker environment to provide a clean environment. A clean environment is needed for the ASN1 compiler to be installed correctly so that the generated library contains clean user paths, which are included as generated comments in the header. Within the setup environment, the script handles the generation. At startup, the script automatically loads the newest asn1 specification files for ETSI specifications, its dependencies, and additional defined experimental messages. After loading, the script provides a simple menu where the messages to generate can be selected. The options are (i) to generate specific messages, (ii) to only generate standardized messages, or (iii) to generate all messages which are available to the script. Each selection triggers the generation of multiple C-Header and C-Source files dumped in a folder of the respective message. One may already use this dump or the CMake option in the menu. The CMake option will rearrange the generated files to fit a library structure and automatically generate the required CMake files. The final library is ready to use in CMake projects. However, depending on the CMake version and CMake environment, it may be necessary to adapt the CMake syntax, as usual.

Fig. 4

The vcitslib creation process, within its Docker environment. On the left side is the setup of the environment. In the middle is the creation process of the files. On the right are the final files which are rearranged into a library

One must say that vendors of complete OBU and RSU hardware platforms already provide such libraries. However, they are not free and also not open source. The latter may be necessary for research of message standards. The script provided in the repository allows the addition of ASN1 specifications outside existing standards. The generated library then includes those new messages without any extra effort.

The vcitslib is a core component of the vehicleCAPTAIN toolbox and, therefore, already integrated into all necessary parts to allow rapid development. However, one may use a commercial ITS message library at any time. Within InSecTT, we use this library to exchange Collective Perception Messages (CPMs) in the airport use case. One robot can detect debris and share this information via V2X with other robots.

3.3 ROS2 Support

Research and development teams are often using ROS2 for rapid prototyping. ROS2 also provides much debugging functionality. Hence part of the vehicleCAPTAIN toolbox is the ROS2 interface. This interface can be used specifically for V2X messages.

Part of the ROS2 interface is the ROS2-type messages as a complement to the ETSI messages discussed in Sect. 3.2. The ROS2-type messages are generated from the ASN1 specifications. To achieve this, the ASN1 code generator [10], recommended by ETSI, is forked to include functionalities to generate ROS2 messages from ASN1 specifications. The parser adaptions are not yet perfect. Hence a few hotfixes are necessary for complex edge cases in the specification. However, the provided generator script can generate ROS2-type messages from provided ASN1 files and output a ready-to-use ROS2 message library as source code and an installable package.

The other part is the ROS2 V2X gateway, a translator between ETSI V2X messages and ROS2 V2X messages, shown as HLA in Fig. 5. The gateway is designed to use the vehicleCAPTAIN routing core to input and output ETSI V2X messages. Still, the internal abstractions allow straightforward changes with a different hardware and software environment for ETSI V2X message transmission. Furthermore, the gateway has handlers for every V2X message to account for the different requirements of the message itself. For example, the gateway may be used to buffer messages to account for 1–10 Hz sending, or it might be used to pre-filter specific message types for applicability. However, in the provided form, the handlers simply translate V2X messages between ETSI format and ROS2 format. Within the InSecTT use cases, the logic for handling V2X messages is implemented behind the gateway. The advantage is that one can use the input and output of the gateway on the ROS2 side to debug V2X messages beyond the capability provided by network analyzing tools, such as Wireshark. Additionally, the abstraction allows decoupling the message translation from the actual implementation, i.e., one can focus on the generation and interpretation of messages while not having to deal with the translation and verification of messages.

Fig. 5

The vehicleCAPTAIN gateway for ROS2 is a translator between asn1 encoded V2X messages and ROS2 encoded V2X messages. The gateway is compatible with the vehicleCAPTAIN routing core but can be easily adapted to support only a specific interface

4 Verification

The functionality of the vehicleCAPTAIN is regularly tested in the lab environment, and its performance was verified with the aid of Qosium,⁵ provided by the InSecTT partner Kaitotek. This book chapter will focus on the discussion of the validity of transmission. In parallel, the journal paper by Pilz et al. [11] has focused on highly time-accurate delay measurements and packet loss caused by the wireless connectivity, including the overhead of the vehicleCAPTAIN platform and thereby proving its overall functionality.

This book chapter will analyze the system and how the payload transmission can be proven. Section 4.1 will briefly discuss the input/output relation of the vehicleCAPTAIN before explaining the test setups. Section 4.2 will then show the found statistics before Sect. 4.3 reviews the outcome.

4.1 Test Methodology

If one has two vehicleCAPTAINs, one sender and one receiver, the messages’ payload on both ends must be the same, as discussed in Sect. 3.1. This basic functionality can prove that the system is working correctly. Three separate tests verify the platform: (i) the input/output verification with simple senders and receivers, (ii) the input/output verification with the ROS2 gateway, and (iii) the packet loss test with Qosium.

In the first two cases, the two vehicleCAPTAINs stand side-by-side in our lab, as shown in Fig. 6. In those two cases, the aim is zero packet loss, as the goal is to verify the correctness of the transmission.

Fig. 6

Two vehicleCAPTAIN development kits stand on each other for continuous integration tests

The first case is simple input/output testing. A small set of ten asn1 encoded bitstreams, including CAM and DENM data, is sent out via vehicleCAPTAIN A with a set frequency. The data is then received with vehicleCAPTAIN B and compared for similarity.

The second test is similar. Here we use the ROS2 gateway to verify that the transmission and encoder are working correctly. Hence, the ROS2 gateway generates CAM data with our automated driving demonstrators (ADDs) simulation environment and sends them via vehicleCAPTAIN A. The data is then received with vehicleCAPTAIN B, respectively the second gateway, and we compare the received and sent messages.

In the third case, the vehicleCAPTAINs are mounted into two street legal ADDs of the Virtual Vehicle Research GmbH. As discussed above, the goal is to test the transmission delay and packet loss, which we published in detail in [11]. The principle is similar to the first test. Qosium probes are installed on the vehicleCAPTAIN computing hardware and check the incoming and outgoing ZMQ TCP/IP packets. Because of ZMQ, the payload of the TCP/IP packets for V2X messages are the same when sending and receiving, even though they are repacked in between for V2X message transmission. The ADDs drive around a building block of $100 ~m\ \times \ 250~m$ with specific distances. This way, one can verify the delay and the packet loss in a field scenario.

4.2 Results

The results are provided in three tables. Table 1 shows the simple sending and receiving results. The packet loss is minimal and most likely caused by another Yunex RSU in the same room sending messages. However, one can see that the packets are transmitted correctly, as at least one correct message of each type was received correctly.

The results shown in Table 2 show that also the ROS2 gateway is working correctly, as the messages sent out equal the messages coming in on the other end.

Finally, shown in Table 3 is an excerpt of the measurements conducted with Qosium. Here one can see a different metric for counting packets. Qosium averages the quality of service results over a definable period, in our case, 1000ms. Hence Table 3 shows the sum of averaging periods with the direct result of overall packet loss.

Table 1 Simple sender receiver tests

Table 2 ROS2 gateway sender receiver tests

Table 3 Qosium packet loss test. Averaging interval (T) $=$ 1000 ms. CAM frequency $=$ 10 Hz

4.3 Discussion

The results presented in Sect. 4.2 prove the fundamental purpose of the platform to be able to relay messages reliably. Results shown in Tables 1 and 2 show that each generated message can be received at least once. Table 3 then includes packet loss results from test drives where the line of sight between sender and receiver was obstructed. The packet loss in those scenarios is as expected. The output of the vehicleCAPTAIN platform is also continuously tested with the aid of Wireshark as a reference decoder. Known issues are tracked within the respective GitHub repositories [8].

Overall, one must also verify the other components, such as the C/C++ encoder called vcitslib and the ROS2 message library. The conducted sending and receiving tests implicitly prove their functionality, as messages can be encoded and decoded. However, we currently only test messages we implement in use cases. In other words, both libraries are constantly under development because the V2X message standard is extremely nested and complex and, therefore, not yet implemented and tested in every aspect.

5 Key Performance Indicators

As discussed, the vehicleCAPTAIN toolbox consists of four major elements: (i) the platform itself, providing V2X transmission hardware and a software routing core, (ii) the ITS message libraries, currently supporting C and C++ development, (iii) the ROS2 support, which consists of a ROS2 type ITS message library and a supporting message translation gateway, as well as (iv) the additional tools, which currently support the generation of ITS messages for ROS2.

Each of the components lowers the entry barrier for V2X development. The components are not designed to provide a complete and ready implementation but to provide a basis for research and development. The toolboxes for ready-to-use OBUs, as discussed in Chap. 1, may be enough. But as soon as specific requirements have to be fulfilled, the vehicleCAPTAIN toolbox can help. Requirements could be the parallel support of different V2X radio standards, testing new and yet unsupported message types, or using ROS2 components.

5.1 Use Cases Within InSecTT

The vehicleCAPTAIN demonstrates its capability in two demonstrators. One demonstrator shows V2X management from the infrastructure side with a complex simulation and an actual intersection in Istanbul, Turkey. Here the vehicleCAPTAIN is used for the communication of various V2X status messages.

The other demonstrator showcases the sharing of perception information between robots and vehicles. This demonstration uses the vcits library to generate an encoder for pre-standardized CPMs. All of the systems in the demonstrator run ROS. Hence additionally, the ROS2 interface is used for the translation of messages.

5.2 Use Cases Within the Virtual Vehicle Research GmbH

The use cases are plentiful, as designed by the approach of V2X. To get a better understanding, this section provides an overview of scenarios in which the vehicleCAPTAIN toolbox is already of high value for the Virtual Vehicle Research GmbH.

The vcitslib is the most used component of the vehicleCAPTAIN toolbox. We use this library across various projects and in multiple scenarios. We use it extensively to share positional information for sensor fusion, i.e., Cooperative Awareness Messages (CAMs) for ego information and CPMs for second-person information. We also use other messages, such as Decentralized Environmental Notification Messages (DENMs) to react at active tramway crossings, In-Vehicle Notification Messages (IVIMs) to react on speed limit changes, automated driving levels, and open bus lanes, as well as Radio Technical Commission for Maritime Services Environmental Messages (RTCMEMs), to receive GNSS correction data.

The vehicleCAPTAIN hardware and routing core are highly valuable because of their versatility. At first, used the Unex SOM301-E for ITSG5 communication, which could have also been done with a complete OBU from another vendor. However, soon we needed highly accurate time synchronization for testing and verification. The vehicleCAPTAIN hardware allowed us to adapt quickly by including 1pps synchronization via a Ublox F9P. The next challenge was to provide better connectivity over farther distances in city environments. The simple solution was the integration of a 5G module and the implementation of V2N. As we are using the vehicleCAPTAIN toolbox, it was as simple as integrating a new interface into the vehicleCAPTAIN routing core. This way, we did not have to change any other parts, and all other use cases were immediately able to use the same way of communication.

The vehicleCAPTAIN routing core and its connectivity are used for major projects. Additionally, as mentioned in Sect. 3.3, we see high potential in using ROS2 in our use cases. ROS2 allows the reusing of components, allowing rapid prototyping and focusing on separate integration elements. In other words, at the Virtual Vehicle Research GmbH, we have street-legal ADDs running Autoware based on ROS2. The ROS2 gateway allows for a simple vehicle extension with V2X capability.

6 Conclusion

In this book chapter, we discussed the vehicleCAPTAIN toolbox. The toolbox is designed (i) to ease entry into the V2X development domain, (ii) to provide a platform for cross-development with existing and upcoming V2X interfaces, and (iii) to provide development interfaces for rapid prototyping with ROS2.

We found the toolbox to fulfill all these needs by (i) the discussion verifying its design and by providing FOSS releases for its components, (ii) the verification of sending capability and performance in lab and field environments of the vehicleCAPTAIN development kit and routing core, and (iii) the discussion of use cases already implemented within and beyond InSecTT.

Development is currently focusing on releasing additional papers proving the capability of the vehicleCAPTAIN toolbox and providing quickstart tutorials for every component. Aside from those crucial steps, future development will focus on upgrading the provided V2X interfaces with the latest releases and integrating upcoming technologies.

Finally, we encourage V2X researchers and developers to use the vehicleCAPTAIN toolbox for inspiration and implementation, as it combines the know-how necessary for basic V2X implementations.

Glossary

vehicleCAPTAIN The vehicle communication platform to anything is a toolbox designed for easy entry into the V2X domain. It was created within the Ph.D. works of Christoph Pilz, at the Virtual Vehicle Research GmbH, in cooperation with Graz University of Technology.