Vehicle-to-Anything (V2X) communication is expected to make trafic more eficient and safe by creating an essential infrastructure for Cooperative Intelligent Transport Systems (C-ITS). Cooperative platooning is a C-ITS application controlling a group of vehicles and maintaining small intervehicle distances even at high speeds. The small distance between the vehicles requires an extended vision for the adaptive cruise control (ACC) algorithms, which can be provided through advanced V2X communication, such as creating an extension of ACC called cooperative ACC (CACC). The Quality of Service (QoS) parameters of the V2X communication influences the reliability of the CACC algorithms. In this paper, we modeled and examined the efects of QoS parameters on the platooning control algorithms using Veins/Plexe as the base simulation framework.
Vehicle-to-Anything communication is direct and fast (very low-latency), but not
expected to provide high throughput. V2X communication protocols are designed
for fully distributed networks that are able to operate without any centralized or
cellular-like control and management systems [
The platooning term refers to a set of vehicles, where the corresponding vehicles
drive in one line, following each other. We assume that the control of the first
car in the group (the platoon leader) is solved either with a professional driver
or with a fully autonomous car. The steering of every other, so-called following
vehicle, is considered to be handled in terms of this paper. The cooperative term
refers to platooning applications, where the algorithm of the lateral acceleration can
also take motion state information of the non-adjacent vehicles into account. The
platoon uses V2X communication features to gain information about non-adjacent
vehicles. Having information about non-adjacent vehicles is a must because it
is a mathematically proven fact that the linear response algorithms which try to
maintain a fixed intervehicle gap require such information to ensure the string
stability property [
The main topic of this article is the inspection of CACC algorithms for platooning
in circumstances where the communication link has varying QoS parameters. To
reach this goal, we extended the existing framework of Veins/Plexe [
The PHY and MAC layers of existing, available V2X communication techniques
are based on the IEEE 802.11p [1] or the LTE-V2X [2] standards. The cooperative
platooning application requires regular updates about the motion states of the
platoon member vehicles and some additional messages to maintain the platoon
members, roles, and maneuvers [
EU and US standardization provide two similar message types to implement the
periodic update (“heartbeat”) feature. These two message types are Cooperative
Awareness Messages (CAM) [
The other type of messages handle management tasks for platoons. These
messages are responsible for maintaining the platoon member vehicles, the leader
of the platoon, the maneuvers made by the platoon, for example, merging two
platoons, changing the lines, or splitting. Currently, these types of messages and
solutions based on them are under standardization and evaluation [
The platooning application was described first in the 1960s [
A control algorithm for vehicle platooning is expected to produce the desired acceleration or deceleration value as output to determine the lateral dynamics of the controlled vehicle. The steering of the controlled vehicle is considered to be solved. The control of the platoon leader is handled by a fully autonomous vehicle or a human driver.
Existing control algorithms can be categorized by the inputs of they are relying on. If the control algorithm has only information about the adjacent vehicles, then the solution is ACC. At the same time, the algorithm also uses information about non-adjacent vehicles, and then it is a CACC. CACC algorithms can have the string stability property – unlike the ACC –, making the technique able to be a secure basis for platooning control.
Simulational examination of the platooning application is a reasonable method
because it can provide realistic data much cost-eficiently than using field tests.
Several articles are examining the quality of service (QoS) requirements of the
platooning application from various approaches via simulation. The Plexe article [
3.1. Plexe
As part of our work, we selected a simulation framework that is able to simulate the
platooning trafic with support for parametrized lateral control algorithms. The
framework had to support V2X communication, as well. The Plexe framework
was chosen, which is an extension of the Veins simulation framework [
This framework simulates network trafic through various terrestrial
situations with various parameters given. Plexe uses the communication
implemented in the Veins framework and extends it with additional functionalities.
Plexe implements a higher layer unicast protocol and basic beaconing
protocols with corresponding message definitions to support signaling messages
of the cooperative platooning applications. Plexe also defines a superclass
for platooning applications, which can pass wirelessly received data to the
controllers and also logs the motion data.
• The Veins open source vehicular network simulation framework [
To examine QoS requirements of cooperative platooning control algorithms, we selected the Average Packet Loss, Latency, and Jitter as the most important communication QoS parameters.
The average packet loss is interpreted here as a certain percent of the signaling packets of the cooperative algorithm that does not arrive at the receiver. The loss of each packet is independent and follows a Bernoulli distribution, where the probability – and the mean – value of the packet loss is the configurable packet loss parameter. The L represents the event of packet loss.
L ∼ B ( ) Latency represents the amount of time, which corresponds to the time diference between sending a signaling packet and receiving it.
The latency is caused by processing delays, communicational delays, and many other reasons.
latency = receive − send The jitter parameter in our analysis follows a normal distribution, with an adjustable dispersion parameter and 0 as the mean parameter. This definition of the latency would allow the simulator to send a packet before the generation of the packet, which would not be realistic, nor implementable, so this efect is filtered. The latency and the jitter parameters together form a normal distribution where the mean – – is the configured latency parameter and the dispersion – – is the configured jitter parameter.
Latency with Jitter = (, ) if > 0
otherwise ︃{
0
To perform the desired analysis, we had to extend the Plexe framework with the support of an explicit declaration of communication QoS parameters. For batch execution, the values of the QoS parameters must be given in the configuration ifle of OMNeT++. Therefore we introduced proper TraCI messages at the Veins side to enable the configuration as an adjustable parameter. The above mentioned three explicit QoS parameters were implemented as receiver functions. The latency and the jitter were implemented as OMNeT++ self messages parameterized with a certain latency. A new application class was introduced at the Veins side called QoSApp containing two instances from helper objects: one of them implements the draw of the probabilistic packet loss using the selected Bernoulli distribution, the other implements the draw of the latency values using the normal distribution. The QoSApp class is responsible for the implementation of the packet loss as well. It stores the message frame of the delayed message and sends a self message to schedule the delivery of the packets. As the self message arrives at the QoSApp, it makes the corresponding message available for the cooperative platooning application.
There are multiple approaches to ACC/CACC algorithms with diferent design visions and objectives. We examined four diferent algorithms that were already implemented in Plexe. We did not change the built-in parameters of the algorithms to stay consistent with the original framework.
• Plexe ACC. This algorithm only considers the motion state of the preceding vehicle. Therefore, this algorithm can not ensure string stability with a low headway time gap. The safety of the platoon can only be ensured if quite long distances – time gaps – are maintained between the vehicles. The ACC algorithm relies on the distance between the preceding and the ego vehicle and the speed of the ego and the preceding vehicle. • Plexe CACC. The CACC algorithm uses V2X communication to gather information from the preceding and the leader vehicle. This algorithm counts with the information obtained from the leader and preceding vehicle. It uses the acceleration, speed, and distance values as well. • Plexe PLOEG. The PLOEG algorithm uses information only from the preceding vehicle transmitted via V2X communication in the Plexe implementation. This approach can be realistic because the acceleration is the second derivate of the distance. If the acceleration sensing is based on distance sensing, the accumulated errors can lead to unreliable results. This problem can be solved by using communication to share the measurements of the sensors in the preceding vehicle. • Plexe CONSENSUS. The Consensus algorithm can count on every member of the platoon. This algorithm has an adjacency matrix filled with properly chosen coeficients. The Plexe implementation of the Consensus algorithm only uses the leader and the preceding vehicle data obtained from V2X communication.
Plexe implements the two most important safety-relevant scenarios in terms of the platooning application. In both of them, the first car is driven by the simulator on a flat and straight highway with diferent characteristics of speed.
The Braking scenario is responsible for testing emergencies where the platoon has to stop in a very short distance. The leader vehicle brakes hard, and the follower vehicles have to stop without colliding the other cars.
In the Sinusoidal scenario, the speed of the leader vehicle follows a sinus curve. This scenario is responsible for testing whether the algorithms can ensure safe operation in situations where they face an excitation with a constant frequency. The desired answer of the algorithm is a decaying behavior where the algorithm smoothens the speed oscillation of the leader car. It is easy to consider that an ascending answer would lead to collisions. This ability is called string stability.
The introduced QoS parameters, the two crucial scenarios, and the applied algorithms were defined as adjustable variables in the OMNeT++ configuration file. The QoS implementation introduced significant random factors in the simulation runs – without the QoS implementation, and the simulation runs did not show an indeterministic behavior.
In order to get statistically relevant results, it was necessary to execute each simulations multiple times. The OMNeT++ framework executed each combination of the available variables, where the available free factors were the following: • the examined algorithm. The simulation ran on four diferent ACC/CACC algorithms, where the first algorithm was represented twice because it ran with two diferent configuration parameters; • the packet loss rate, parametrized from 0 percent until 70 percent with 10 percent steps; • the standard deviation of the jitter could be 0 or 500 milliseconds; • the delay parameter could be 0 and 1 second; • the two key scenarios; • finally, an additional helper parameter was introduced to execute the test cases multiple times.
Each scenario covered a 60 seconds long situation on a straight highway. The platoon contained eight vehicles, a leader and seven follower vehicles, as it is visible in Fig 1. The platoon used a dedicated lane; the surrounding trafic was not a disturbing factor. Each simulation run took approximately 10 seconds for the framework to simulate. During our analysis, we executed thousands of diferent simulations and produced more gigabytes of data to be processed.
A novel tool was developed with the capability to handle the multiple simulation runs. The analysis tool was developed to process and visualize the most critical measured Key Performance Indicators (KPIs) of the examined algorithms. The logging of the measured data in the simulation framework was performed on the Veins side, where each platoon participants sent their movement data to play the communication parts of the overall simulation. In the platooning application the following KPIs were logged and analyzed: • the distance between the platoon members, where the logged parameter is the distance between the adjacent vehicles; • speed of the platoon member vehicles; • the acceleration of the platoon member vehicles.
The logging is implemented with standard OMNeT++ methods on the communication simulation side, with a defined frequency, along with the beaconing messages.
The distance between the platoon member vehicles is the most important evaluation criterion because it shows if the vehicles collide, which is not acceptable due to the strict safety requirements of the platooning application. The speed and the acceleration data shows whether the algorithms can perform according to the design principles also in suboptimal communicational situations or not. The tool, in its current form, calculates the minimum, maximum, deviation, and mean values of the measured data.
The main goal of the analysis was to point on the most sensible QoS parameter of the examined algorithm and also to specify the algorithm’s numerical limits. It is important to note that the algorithms were used with the coeficients/parameters defined in the article where they were used. This means that not all of the algorithms try to keep the same time gap or distances, so a direct comparison is not applicable. During the evaluation, we used the developed analysis tool to evaluate the simulation results.
The experience of the analysis is that most of the algorithms are sensitive for the latency, especially when having a braking scenario. Most of the algorithms could handle the Sinusoidal scenario, but some of them could only handle it because they had a relatively wide safety gap. If having a Sinusoidal gain, the correct answer from the algorithms is a decaying behavior, which we could see from some of the algorithms. In the Braking scenario, however, some of the algorithms did not respond hard enough to stop without colliding. This behavior is potentially caused by choosing too small coeficients, which creates a smooth response in most of the time, but when having a hard brake situation, this approach does not perform well. The algorithms have diferent identified weaknesses and strengths: • ACC: The performance of the ACC depended strongly on the chosen time gap between the vehicles. If the time gap was great enough, the algorithm could avoid the collision in any case, as one can see in Fig 2, which means that this algorithm can be a fallback solution. However, the lack of string stability property does not make it able to be a full solution, as one can see in Fig 4. • CACC: The CACC handled the Sinusoidal scenario relatively well – which is visible on Fig 6 –, but it is visible that with higher coeficients the algorithm could result in a better performance when braking hard as one can see on Fig 2. The algorithm collides if having too high latency or jitter values. • PLOEG: The PLOEG algorithm was susceptible to the latency property, which is proven by Fig 3 and Fig 6. • CONSENSUS: The consensus algorithm was sensitive for the latency property but relatively resistive for the jitter. This is visible on Fig 3 and Fig 6.
The experience of the performed analysis is that most of the examined CACC algorithms are sensitive for the latency, especially when having a braking scenario. Most of the algorithms could handle efects in the Sinusoidal scenario, but some of them could only manage it because they had a relatively wide safety gap. If having a Sinusoidal gain, the correct answer from the algorithms is a decaying behavior, which we could see from some of the algorithms. In the Braking scenario, however, some of the algorithms did not respond hard enough to stop without colliding. This behavior is potentially caused by choosing too small coeficients, which creates a smooth response most of the time, but when having a hard brake situation, this approach does not perform well. As an experience, future algorithms could recognize some critical situations like hard braking, and they could handle these situations with diferent control sequences.
As a part of our future work, we plan to extend the set of examined CACC
algorithms, and also to explore the circumstances where the obtained minimal QoS
parameters are present due to the dense trafic. We want to implement control
algorithms and new maneuvers as well based on the Artery framework [
J2735_201603.