Blog postSELFY project CCAM

In recent years, highway capacity has become a limiting factor for efficient ground transportation. Traffic jams caused by an overwhelming number of vehicles on the roads increase fuel consumption and decrease travel safety and comfort.   

A natural and direct solution is to reduce to a minimum the distance at which vehicles drive behind each other and to maintain a constant velocity for most vehicles. However, the inherently slow human reaction time (about 250 milliseconds) makes it unfeasible (and unsafe) to reduce intervehicle distances significantly. To this end, vehicle automation technology has been employed by OEMs to automate cooperative driving.  

Adaptive Cruise Control (ACC) is a relatively mature technology that uses onboard sensors (e.g., lidars, radars, camaras, and velocity/acceleration sensors) and computers to perceive the environment around vehicles and automatically adjust their acceleration to maintain a prescribed distance among them and enforce platooning formations.  

However, ACC is designed primarily as a comfort and safety system and not to increase highway capacity. That is, its purpose is to make driving more comfortable and to keep safe (relatively large) distances between vehicles.  

In terms of safety, ACC is a preventive technology whose philosophy is to move vehicles far enough apart to avoid collisions. A fundamental question arises here: can we build on the ACC technology to devise a new cooperative driving scheme that maintains safety but reduces intervehicle distance to increase highway capacity?  

Cooperative Adaptive Cruise Control (CACC), the successor of the ACC, has emerged as a cooperative driving technology that enables groups of vehicles to drive autonomously in tightly-coupled platoons (i.e., it allows relatively short intervehicle distances). CACC’s key feature is the use of Vehicle-to-Vehicle (V2V) wireless communications to exchange kinematic data among vehicles, see Figure 1. That is, instead of only relying on onboard sensor data (as ACC does), CACC exploits received data from adjacent vehicles to anticipate braking and accelerating. As a result, for instance, instead of driving 1 second away from the preceding vehicle (as in ACC), CACC enables driving within 0.2 seconds (so 80% closer). 

Figure 1: Vehicle platoon using different data to drive autonomously.

Figure 1: Vehicle platoon using different data to drive autonomously.

However, the use of communication networks brings security concerns as it exposes network access points that adversaries can exploit to eavesdrop data and inject integrity cyberattacks (see Figure 2), resulting in new safety and security challenges that were not encountered in traditional vehicular systems.  

Given these connectivity-induced vulnerabilities, can we trust the data received from adjacent vehicles and road-side units? Is CACC even safe to deploy?

Figure 2: Compromised autonomous vehicle platoon.

Figure 2: Compromised autonomous vehicle platoon.

Our research at the Dynamics and Control (D&C) group, Eindhoven University of Technology, focuses on developing technology that allows quantifying the potential impact of cyberattacks on platooning behavior. We develop algorithmic tools to characterize the impact of particular compromised vehicle elements (e.g., sensors, actuators, networks, and software) and provide guidelines to allocate security resources to minimize the impact of attacks. 

There are various CACC schemes available in the literature, and different versions of it lead to different impact of attacks. The latter arises from structural differences in the control algorithms and the use of different subsets of sensors, actuators, and inter-vehicle transmitted information.  

Take for example the video below where we simulate the behavior of two platoons, each driven by a different CACC scheme (the schemes of Ploeg and Lefeber). For the first sixty simulation seconds, the two platoons drive identically (d1 and d2 denote the inter-vehicle distances). At second sixty, we induce a false-data injection attack to the sensors of the red vehicle. It is clear that both platoons behave very differently after the attack has started, the scheme of Ploeg is robust against the attack and the one of Lefeber is less so (which even leads to a collision). Then a natural question is: can we quantify a priori the effect of using different CACC schemes?  

To quantify the potential impact of false-data injection attacks, we make use of the size of the adversarial reachable set. The adversarial reachable set characterizes the set of all vehicle states (e.g., inter-vehicle distances, velocities, and accelerations) that can be induced by the attack.  

An example of an adversarial reachable (ellipsoidal) set is depicted in Figure 3. This set obtained for the two CACC schemes considered in the animation. On the x-axis, we show the vehicle velocity vi and on the y-axis the inter-vehicle distance zi. The green area represents states where no collision or speeding occurs. In this plot, bigger (smaller) ellipsoids mean that the attack can induce more (less) states into the platoon

Under the framework of the SELFY project we would like to improve current CACC schemes to make them more resilient to cyberattacks and improve road safety, while minimizing traffic congestion 

So, a CACC scheme with smaller ellipsoids would be, in general, more secure, and vice versa. As we also observed in the simulation, there is a significant difference in the level of security that the two schemes can guarantee (as the size between the two ellipsoids is significantly different). 

Figure 3: Adversarial reachable set for an attack on the acceleration sensor.

Figure 3: Adversarial reachable set for an attack on the acceleration sensor.

As an intuitive next step, we are looking for optimal CACC schemes that maximize the resilience against false-data injections. Resilience in the sense of minimizing the volume of adversarial reachable sets and pushing them towards safe regions (e.g., the green area in Figure 3) — as in this case the attack does not cause unsafe scenarios.  

If you are interested in our work, please keep following our future updates within the SELFY project!