Author: Konstantina Tsakiri
Edited by: Aikaterini Kokoliou
CARLA (Car Learning to Act)  is an open-source simulator for urban driving supporting multiple purposes of autonomous driving models, e.g., training, prototyping, and validation. Furthermore, the urban environment provided by CARLA includes a multitude of vehicle models, buildings, traffic lights, street signs, and also, urban layouts. All the aforementioned along with sensors have a specific role in the simulation and enable the enhancement of the existing system to provide more capabilities.
CARLA's highlighted features are listed below:
- Flexible API
- Server-(multi)client communication
- ROS bridge
- Maps generation
- Configurable sensor suite
Going deeper into the technical details, the simulator is designed as a server-client system and the composition of CARLA includes two modules:
- 1)Client-side: contains the Python client API for communicating with the CARLA server. This API, as a built-in feature, can control programmatically the vehicles, therefore the simulation can be customizable.
- 2)Server-side: includes all the assets for assembling the cities and behaviour of the agents in the scene.
Hence, the server is the simulator and the client-side communication can be controlled through the Python API as is depicted in Figure 1 below.
Figure 1: CARLA communication pipeline 
A main asset of CARLA is its configurable sensor suite. The vehicles rely on sensors i.e., cameras, IMU, LIDAR, GNSS etc., to dispense information, both in a real and in a simulated environment. Additionally, CARLA gives the possibility of creating custom vehicle models by adding any of the available sensors to a large selection of different vehicle types. Although multiple functionalities are already implemented in this vehicle simulator, such as navigation, measurement of physical properties, retrieving the geolocation etc., the functionality of a robust vehicle bus standard is not provided by default.
Utilising the flexible Python API, and in order to perform attack scenarios for the purposes of nIoVe project, CARLA is enhanced with Controller Area Network (CAN bus), a widely used protocol in automotive, for enabling and simulating the communication between the ECUs. With this improvement, an ECU can broadcast information e.g., steering, throttle, brake via the CAN bus.
In general, the CAN bus is operating like the nervous system in a human body which is responsible for intravehicular communication and the ECUs are like parts of the body. In automotive electronics, ECUs are embedded systems which control various of the electrical systems in a vehicle, such as doors, airbags, anti-lock braking system (ABS) and etc. Especially, the CAN bus system enables each ECU to communicate with all the other ECUs avoiding the complex dedicated wiring .
To achieve the CAN bus functionality inside CARLA, a virtual interface of type vcan is needed. With the following commands vcan0 is opened (vcan0 is an indicative name):
- $ modprobe vcan
- $ sudo ip link add dev vcan0 type vcan
- $ sudo ip link set up vcan0
By having vcan open, the libraries listed below should be included in the main python file of CARLA:
- import can
- import utils
- import cantools
Also, a CAN bus database (".dbc" file extension) is essential. It is comprised of all the CAN messages that are exchanged, explaining the data which are transmitted and the size of every information and it is similar to the one depicted in Figure 2.
Figure 2: CAN bus database
The message that was used for the needs of nIoVe is analyzed here. The message-id is 501 in decimal and 5 is the size of the message in pairs of hex numbers (5 hex digits is equal to 40 bits). In detail, above in the ".dbc" file, there are three (3) signals for throttle, brake, and steering. For instance, the explanation for the throttle is:
SG_ CTRL_THROTTLE : 0|8@0+ (0.01,0) [0|1] "%" TERMINAL
0|8: starting bit | length in bits
(0.01,0): (fixed step, offset)
[0|1]: [min physical value|max physical value]
Due to the required libraries in the python file mentioned before, the ".dbc" file is encoded and decoded, respectively. The initialisation of CAN bus is achieved through the two following commands:
db = cantools.database.load_file("file_name.dbc")
can_bus = can.interface.Bus("vcan0", bustype="socketcan")
The architecture of this tool along with the aforementioned enhancement allows the simulation of potential cyberattacks on the CAN bus. According to a survey on security attacks , there are a lot of potential attack scenarios to be tested on this protocol. Below is described a coveted one, the CAN Denial-of-Service (DoS) Attack.
A DoS attack is considered a cyberattack in which the attacker will attack a server and increase the rate of traffic in order to take down the server of the users. CAN protocol is a typical "victim" for malicious adversaries to cause major damage by exploiting flaws.
The selected method of achieving DoS attack on CAN bus is by flooding. More specifically, the CAN bus is flooded with messages with ID 0x000, by an attacker who has gained access to the bus and as a result, the correct communication between the vehicle modules is interrupted and the vehicle has unexpected behavior. In the CAN bus protocol, the message with the lowest ID number has the highest priority on the bus. So, the message with ID 0x000 has the highest priority over all the other messages in a CAN bus since there are no negative IDs. Such an ID will flood the CAN bus and prevent the correct transmission of the important messages that must be sent for the vehicle to move normally.
To implement this scenario, the throttle, brake, and steering control values are calculated from the built-in CARLA vehicle PID controller. Then, all these values are transferred through a CAN bus in one message, so that there is no latency in the transaction of this information.
The scenario is started as follows: CARLA simulation is running and the vehicle is moving on the map in autopilot mode. The throttle, brake, and steering commands are transferred through the CAN bus by a message with ID 0x1F5 (501 decimal). The ID of the message is chosen at random. The attack can be started at any time, by running a bash script that sends messages in the same CAN bus with ID 0x000 (0 decimal) continuously. The data value chosen is 0xFFFFFFFFFFFFFFFF, the maximum value for all the transmitted signals leading the car to unexpected behavior. Messages with this value were chosen because it is not common to encounter this when the vehicle moves normally into the map, giving a more visible effect when the attack happens. The CAN bus is flooded with these messages and the message with ID 0x1F5 which contains the vehicle control commands (throttle, brake, steering) cannot be sent correctly, and thus, important information is lost (Figure 3). As a result, the vehicle gets disoriented and crashes at the nearest obstacle (Figure 4).
Figure 3: Terminal window with the traffic in CAN bus. The bus is flooded with the messages of the DoS attack
Figure 4: Vehicle has crashed after the attack
To sum up, the addition of CAN bus functionality into CARLA may cause the interest of many parties for testing similar attacks in an Internet-of-Vehicles (IoV) ecosystem and generally, for autonomous driving research. Since, some of the attacks on CAN bus can lead to catastrophic consequences for both the vehicle and the human lives, more time should be devoted for further investigation.
 Minh Pham, Kaiqi Xiong. (2020). A Survey on Security Attacks and Defense Techniques for Connected and Autonomous Vehicle. Department of Computer Science and Engineering, University of South Florida Intelligent Computer Networking and Security Laboratory.