Evaluation of CACC string stability using SUMO, Simulink, and OMNeT++

2.1 Control theory

Control theory [16] deals with the behavior of dynamical systems. The control objective is to realize a desired distance to the preceding vehicle. This desired distance may be an increasing function of vehicle velocity in order to take safety aspects into account. The result is commonly referred to as a "constant time-headway spacing policy". In order to realize the control objective, the control system acts on the desired acceleration of the vehicle by means of actively influencing the drive force, based on radar measurements and (in case of CACC) on data obtained through wireless communications. The controller's main task is to reject disturbances caused by velocity variations of the preceding vehicles. In our study, the disturbance is caused by the behavior of other traffic, such as sudden deceleration of preceding vehicles. An ideal feedback control system should be able to cancel out all errors, effectively mitigating the effects of any forces that might or might not arise during operation and producing a response in the system that perfectly matches the designer's wishes. In reality, this might be difficult to achieve when taking measurement errors in the sensors, delays in the controller, and imperfections in the control input into consideration. Though many solutions exist to implement a CACC controller, we will focus on a control structure that can be applied in an ad-hoc vehicle platoon scenario [9]. In this scenario, the concept of a platoon leader is not supported and all the vehicles in a platoon support the same type of one-vehicle-look-ahead CACC controller topology. The main reason of choosing this CACC controller structure is the fact that the one-vehicle-look-ahead topology is the simplest possible structure and therefore it has the highest probability of being deployed. Furthermore, a proof-of-concept implementation of this CACC controller structure has been developed within the Connect&Drive [17, 18] project and shows promising results.

2.2 String stability

The term "string stability" is often used interchangeably with "platoon stability" in this field, which means that any non-zero position, speed, and acceleration errors of an individual vehicle in a string do not amplify when they propagate upstream [4, 5]. According to [19], the vehicle speed should be taken as a basis for string stability, which is more relevant than distance error in view of traffic analysis. A simple scenario which can be used to explain string stability is illustrated in Figure 1a,b.

Figure 1a,b shows a string of vehicles, moving from left to right. For a clear illustration we show only four vehicles, but the concept also holds for strings of more vehicles. The leading vehicle is denoted as 1^st while the last vehicle is denoted as 4^th. In each of these figures, below the shown string of vehicles, a speed versus time coordinate graph for each vehicle is shown. As time goes by, the leading vehicle decelerates linearly and we can see different responses of the following vehicle in the platoon depending on whether the platoon is string stable or not.

In Figure 1a, the situation is shown where the platoon is string stable: the effect of the changing speed for the leading vehicle is not amplified through the following vehicles and the deceleration of following vehicles is smooth without any fluctuation of the speed. In Figure 1b, the platoon is considered not string stable (string unstable): the following vehicles decelerate even more than the leading vehicle. Though finally, the speeds of the following vehicles approach the leading vehicle's speed, the speed fluctuates significantly. These fluctuations are amplified from vehicle to vehicle in the upstream direction. Actually, during the period of fluctuation, the distance between neighboring vehicles also fluctuates. As a result, collisions between vehicles are more likely to happen. This example shows a decelerating lead vehicle, but the concept also holds for an accelerating lead vehicle.

String stability can be improved if the information of the preceding vehicle (e.g., acceleration and velocity) is used in the feedback loop of the Cruise Controller. This information can be collected by a low latency communication medium [9]. The most distinctive difference between ACC and CACC is that besides the preceding vehicle's speed and position used as inputs in ACC, the acceleration of the preceding vehicle transmitted through the wireless channel is also adopted as input in CACC, see Figure 2 and [9]. Therefore, CACC is treated as a solution to achieve a desired following distance with string stability. Alternatively, the preceding vehicle's acceleration can be estimated from the distance and relative velocity as measured by the radar. This leads, however, to additional phase delay in the estimated acceleration due to the estimation algorithm, which potentially causes string instability. For this reason, this method is not pursued here.

3.1 Simulink model

In the "Car" part of Figure 2, the module "(C)ACC Controller" together with the module "Vehicle" provides the prototype of the CACC and ACC controllers. At the beginning of each simulation step, the module "(C)ACC Controller" reads relative speed and distance to the preceding vehicle from the "Radar" module. The host vehicle's acceleration and speed are read from the module "sensor" as inputs. In addition, CACC would read the acceleration of the preceding vehicle from the "Wireless Medium" by Wi-Fi interface, which is not necessary for ACC. The desired time headway, desired distance at standstill, and cruise speed are pre-set before the simulation starts. The control objective is to realize a desired distance, taking into account a pre-defined maximum speed, referred to as the cruise speed. Note that the cruise speed is a maximum speed when the vehicle operates in (C)ACC mode. If there is no target (preceding) vehicle, the system switches to a cruise control mode, in which case the cruise speed becomes the target speed.

Here, "D_standstill" denotes the desired distance to the preceding vehicle at standstill; "h" denotes the desired time headway and "V(t)" is the current host vehicle velocity.

Based on these inputs, the CACC/ACC controller can calculate a reference acceleration "a ref". The "Vehicle" module takes this reference acceleration as input and mimics the response of a real vehicle, taking into account for instance the vehicle's inertia. The resulting (or real) acceleration that is the "Vehicle" module's output is referred to as "a real". This acceleration is used to model the behavior of the vehicle, and to calculate the vehicle's resulting speed "v" and position "s" at the next simulation time step. Module "Sensor" always outputs the current position and speed of a vehicle. Furthermore, "a real" is sent to module "Wireless Medium", to model its wireless transmission. Note that when due to impairments of the wireless communication medium a packet loss occurs and an updated acceleration value is lost, then the CACC controller uses a previously received and stored acceleration value. This holds in general, as evaluation of the controller happens at a higher rate than reception of input through the wireless medium.

3.2 SUMO model

Figure 3 shows a part of the generated road network and a platoon of 10 vehicles. We mark each vehicle with an ID, where the leading vehicle's ID is "veh0", that of the first following vehicle is "veh1" and the last vehicle's ID is "veh9". The leading vehicle moves from left to right (the downstream direction) and the other 9 vehicles equipped with ACC/CACC controllers follow the leading vehicle.

3.3 OMNeT++/MiXiM model

OMNeT++/MiXiM is used to simulate the wireless communication between vehicles in a platoon. Vehicles are simulated in the form of communication nodes, which have the same positions as the vehicles and are able to exchange information by periodically broadcasting short status messages called beacons. In this way, every vehicle (communication node) can get its preceding vehicle's acceleration.

The OMNeT++/MiXiM model applies a Cooperative Awareness mechanism using beaconing [20]. The beaconing procedure is using a simple timer, which means that a node transmits a beacon every τ seconds (i.e., at a rate of 1/τ Hz), with a small, randomly chosen variation or offset. By tuning the value of τ, the Beacon Sending Frequency (BSF) can be varied. The MAC and Physical modules used in the OMNeT++/MiXiM model are based on the IEEE 802.11p standard [1]. The model used in this research was realized by modifying the currently available IEEE 802.11 MiXiM example, i.e., Mac80211, such that it could operate as an 802.11p model. Changes relevant for this research primarily concern different modulation types and corresponding timing parameters (such as bitrate, slotTime σ and Inter-Frame Spacings) and MAC parameters such as contention window and enhanced distributed channel access (EDCA) functionality. In order to remain tractable the physical layer uses a stochastic error model (PLR is drawn from a uniform distribution). In these experiments we consider only a one-vehicle-lookahead controller topology and vehicles are following each other, establishing line-of-sight (LoS) communication paths between relevant communication peers. Within the range of distances (headways) used in the experiments (7.7-40 m), the PLR is not expected to vary significantly with distance for LoS communication. When studying scenarios with multiple-vehicle-lookahead, or non-communicating vehicles mixed with CACC-equipped vehicles, the wireless communication needs to be performed with a more detailed model in order to account for non-Line-of-Sight situations.

3.4 Complete simulation model

The complete experiment structure can be seen in Figure 4a, while the corresponding simulation model is shown in Figure 4b. As shown in Figure 4a, corresponding to Figure 2, "Cars" equipped with "Controllers" (CACC) communicate with each other through their "Wi-Fi" interfaces. In the simulation structure shown in Figure 4b, "Cars" are simulated by the SUMO model and "Controllers" are originally built in the form of a Simulink model. MiXiM simulates the wireless transmission.

In order to allow the Simulink model to be used by vehicles implemented in SUMO, it is first converted into a C++ shared library by using the Real-Time Workshop tool in Simulink so that it can be called in the source code of SUMO.

In this study, the method described in [21, 22] is used for bidirectional coupling between OMNeT++/MiXiM and SUMO, where the two simulators communicate with each other through a traffic control interface (TraCI) by transmitting TCP messages. Here OMNeT++/MiXiM acts as the TraCI client and SUMO acts as the TraCI server.

The functionality blocks used for the coupling between OMNeT++/MiXiM and SUMO are shown in Figure 5, and comprise:

At the beginning of each timestep, OMNeT++ would send buffered commands to SUMO by using the TraCIScenarioManager (steps 1 and 2 in Figure 5). SUMO uses this information as described in the previous subsection. Once the received information is used, SUMO sends a trace to MiXiM (step 3 in Figure 5), which includes the traffic information such as position, speed and acceleration of vehicles. In MiXiM, the communication nodes are moved discretely according to the positions received from the SUMO trace. This movement of the communication nodes is implemented by the MiXiM mobility module TraCIMobility (step 4 in Figure 5). Then the communicating nodes' state of each vehicle is modified, followed by the procedure of transmitting a beacon (step 5 in Figure 5). Note that the received information is buffered before the start of next simulation timestep.

For ACC simulation, we just need the SUMO model and the shared library converted from the Simulink model, as no communication is involved. More details on the implemented and used integrated simulation environment can be found in [23].

4.1 Experiment setup

The topology that is used in all our experiments is illustrated in Figure 3. A platoon of ten vehicles is placed on a straight single lane road 5,000 m long. We use a pre-defined time headway of 0.7 s. The distance at standstill is set to 7.7 m and vehicle length is 4.46 m. Varying D_standstill is not of interest to the dynamic platoon behavior because it has no effect on the dynamic behavior, D_standstill could be seen as a "virtual extension" of the vehicle. It is a margin a vehicle uses around its preceding vehicle. The distance between vehicles will change with different D_standstill setting, which may impact communication. However, variations in the range [5, 10] m are not of that much influence.

The upper limit of the vehicle's acceleration is specified to be 2 m/s² and the minimal acceleration is specified to be -9 m/s², i.e., the deceleration does not go below -9 m/s². These parameters apply to all experiments in our study except for those where we investigate the influence of different time headway values. In order to guarantee a high statistical accuracy of the obtained results, multiple runs have been performed and 90% confidence intervals have been calculated. For all performed experiments, the largest calculated confidence interval is ± 3.1052% of the shown calculated mean values.

In order to validate the controller model and traffic model, we simulate the performance of ACC (without communication), and CACC with perfect communication, where for CACC each vehicle can always get its preceding vehicle's acceleration within SUMO without loss and delay. The results (not shown here) are very similar to the results obtained in [9] and it is concluded in [23] that the original Simulink model and the combined SUMO-Simulink model are satisfactorily equivalent. In these baseline experiments, CACC outperforms ACC on string stability. Details of this experiment and its corresponding results and analysis can be found in [23]. This article covers a comparison between the string stability of an ACC system and of a CACC system which uses a non-perfect communication medium.

4.2 Simulation results and analysis

For the first scenario, due to space limitations, we only show a subset of the results obtained during this research activity. The other simulation results of vehicles with respect to both velocity and acceleration, and two-sided 90% confidence intervals for all the simulation results can be found in [23].

4.2.1 Deceleration

The curves from bottom up at the 9,000^th time step of Figure 6 indicate packet loss ratio in descending order. It can be seen from Figure 6 that for a constant value of beacon sending frequency (10 Hz) and time headway (0.7 s), as the packet loss ratio increases, the velocity fluctuations of veh9 are increasing, which means that the disturbance of the leading vehicle is amplified more through the platoon upstream. In other words, the platoon is more string unstable. Moreover, the undershoot of the velocity is also getting larger as the packet loss ratio increases according to Figure 6. Figure 7 shows the acceleration corresponding to Figure 6; higher PLR results in delayed but larger response.

The undershoot of velocity for the last vehicle is shown in Figure 8. The undershoot is shown for different combinations of selected beacon sending frequencies and packet loss ratios.

From Figure 8 it follows that, with a selected value of beacon sending frequency and time headway (0.7 s), the undershoot of velocity for the last vehicle increases as the packet loss ratio increases, which means that the platoon becomes more string unstable. It can also be observed that for a selected value of packet loss ratio, the string stability becomes worse as the beacon sending frequency decreases. A vehicle always uses the acceleration value which is most recently received from its preceding vehicle as the input of the CACC controller. Therefore, a higher beacon sending frequency for the preceding vehicle results in a higher possibility of receiving fresh information under a constant packet loss ratio. Besides, lower packet loss ratio can also result in a higher possibility of receiving fresh information under a constant beacon sending frequency. For a BSF of 25 Hz packet loss has little effect because vehicles can still easily receive sufficiently fresh information. It should be noted, however, that at 25 Hz the wireless channel capacity will become a limiting factor when considering larger numbers of vehicles [10], so a low PLR is not always achievable.

4.2.2 Varying time headway

Figure 9 shows the velocity of the last vehicle for varied time headway settings for the BSF of 15 Hz and 20% PLR. Note that the curves from left to right at a velocity of 18 m/s of Figure 9 show the headway in ascending order. It can be seen from Figure 9 that with our selected beacon sending frequency and packet loss ratio, as time headway increases, the platoon becomes more string stable, i.e., the velocity of the last vehicle decreases with less fluctuations, findings also reported in [9, 18]. Figure 10 shows the acceleration of veh9 in response to the sudden deceleration of the lead vehicle. It clearly shows that, with shorter time headway, reaction of veh9 is sooner but more aggressive than with larger time headways, even to such a degree that deceleration resembles an emergency stop.

Furthermore, with larger time headways, the relative distance between vehicles is larger. when a disturbance occurs on a leading vehicle, the following vehicles do not react as aggressively as when small time headways are used. Though large time headways may be beneficial for string stability, they are detrimental to road throughput and capacity. Therefore, it is important though challenging to find the smallest time headway to guarantee string stability, while maximizing the road capacity, especially in the face of traffic and network dynamics.

4.2.3 Acceleration

For the second scenario, we again observe the velocity of the last vehicle. The results of the simulation are plotted in similar fashion as the first scenario.

Note that the curves from top down at the 9,100^th time step of Figure 11 indicate packet loss ratio in descending order. For PLR = 0%, there is hardly any overshoot. The associated acceleration is shown in Figure 12 and shows that higher PLR results in larger acceleration.

Different from Figures 8 and 13 depicts the overshoot of the velocity associated with the last vehicle. From Figures 11 and 13 it can be seen that for a given value of beacon sending frequency and time headway, the CACC controller's performance on string stability is decreasing with a higher packet loss ratio. Accordingly, for a given value of packet loss ratio and time headway, the string stability gets worse with a lower beacon sending frequency. The acceleration of veh9, plotted in Figure 12, shows that with a higher PLR reaction is later and more aggressive.

4.2.4 Varying time headway

Note that the curves from left to right at a velocity of 22 m/s of Figure 14 indicate time headway in ascending order for a BSF of 15 Hz and 20% PLR. From Figure 14, the same conclusions can be derived as the ones derived from Figure 9 in the deceleration scenario. In particular, it can be observed that string stability is improving when the time headway is increased. Figure 15 shows the corresponding acceleration curves. It becomes clear that, even in an acceleration scenario, string instability may result in sudden deceleration of vehicles, clearly visible for TH = 0.5 s

4.3 ACC versus CACC

The third and fourth experiment scenarios are used to compare the ACC and CACC string stability performance. In particular, the third experiment scenario is similar to the first experiment scenario, where the lead vehicle suddenly decelerates. The undershoot of velocity for the last vehicle is shown for different combinations of selected beacon sending frequencies and packet loss ratios, see Figure 16. The fourth experiment is similar to the second scenario, where the lead vehicle suddenly accelerates. The overshoot of velocity for the last vehicle is shown for different combinations of selected beacon sending frequencies and packet loss ratios, see Figure 17. Note that in both experiments the string stability performance of the ACC system is not affected by the beacon sending frequencies and packet loss ratios, since ACC does not use beaconing, but radar measurements for the calculation of, e.g., time headway and acceleration, as modeled in the "Radar" block in Figure 2.

In both Figures 16 and 17, it can be observed that from the point of string stability performance, CACC strongly outperforms ACC. In particular, for a beaconing packet loss ratio of 0% the CACC string stability overshoot and undershoot are more than 10 times smaller than those measured on the ACC system. Even for a beaconing packet loss ratio of 50% the CACC string stability overshoot and undershoot are more than 5 times smaller than those measured on the ACC system.

High packet loss ratio or low beacon sending frequency can result in a low refresh rate of inputs at the controller. Though differences between, e.g., 0 and 50% PLR are large, the resulting CACC still outperforms ACC, reinforcing the conclusion of [9] that the CACC feed forward controller enables smaller time headways than the ACC feedback controller, while still maintaining string stability.

This research evaluated PLR and BSF. The delay of the communicated information is minimal, as 10 vehicles do not load the wireless channel to such an extent that contention delay increases significantly. It should be noted that in an 802.11p system high PLR is usually accompanied by increased delay due to its carrier sense multiple access with collision avoidance (CSMA/CA) medium access mechanism [24].