Building Secure And Compliant Applications For Connected Vehicles

In today’s connected environment, people expect a seamless experience using all of their devices, including vehicles. As a result, vehicles are becoming increasingly connected to the rest of the world. Modern vehicles are being shipped with a state-of-the-art infotainment unit (Bluetooth, NFC, and WiFi), a telematics unit (mobile internet and GPS), and many other electronic sensors (Camera, LiDAR, and Radar) to assist the driver and make decisions autonomously. In Figure 1, we show a connected vehicle with advanced driver assistance system (ADAS) functionalities.

Figure 1: The various components of a connected vehicle.

Many new devices and technologies pose serious security threats, and researchers have already shown a number of attacks that perform life-threatening activities by remotely accessing vehicles. Modern vehicles use around 100 Electronic Control Units (ECU) to control different functionalities of the vehicle. Often, the networks of these ECUs are also connected to the infotainment or the telematics unit to which other devices (phone, camera, and public WiFi hotspot) are also connected. As a result, we need to make sure that all the individual components of a vehicle (ECU, Infotainment, Telematics, ADAS, Instrument Clusters) are secure and that there is a holistic approach to secure their integration.

A Software Architecture for Connected Vehicles

Vehicles today use a distributed architecture and various vehicle components have different kinds of hardware and software. These can be separate units sold by third-party vendors with dedicated CPUs, GPUs, and operating systems. For example, the infotainment system may have the Windows, Android, QNX, or AGL (Automotive Grade Linux) operating systems depending on the OEM (Toyota, Honda, Ford, or GM).

It is likely that future connected vehicles will be equipped with Drive-by-Wire technology and a number of other computing platforms. We can assume that many individual ECUs will be replaced by System on Chips (SoCs) that consolidate ECU functions (virtual ECU or vECU). Safety-critical vehicle functionalities will be controlled by a control computer. A powerful computing unit will be used by other components, such as ADAS and Infotainment. While each of these components will share the underlying computation unit, they will be operated by separate operating systems running on top of a type-1 real-time hypervisor. This architecture (Figure 2) reduces the connections needed between multiple components.

Figure 2: A software Architecture for Connected Vehicles.

As we can see from Figure 2, we need to develop different types of applications for different connected vehicle components. For example, to implement a certain powertrain function, we need to write an ECU application which may execute inside a real ECU or a virtual ECU. Similarly, we need to develop applications for the control computer, Infotainment, Telematics, Digital Instrument Cluster, and ADAS.

Automotive Standards and Regulations

The complexity of the connected car application development increases immensely with the myriad of standards and regulations that dictate the industry. Some are listed below, but we can expect new standards or regulations as the industry becomes more mature.

1. AUTOSAR (AUTomotive Open System ARchitecture)
2. ISO 26262: Road vehicles — Functional safety
3. ISO 21434: Road vehicles — Cybersecurity engineering (WIP)
4. SAE J 3101: Requirements for Hardware-Protected Security for Ground Vehicle Applications
5. SAE J 3061: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
6. Automotive SPICE Process Assessment / Reference Model
7. General Data Protection Regulation (GDPR)
8. EU ePrivacy Regulation (upcoming)

Developing Applications For Connected Cars That Are Both Secure And Compliant

Now the question is, how can we develop secure and compliant applications for different components of connected vehicles? The answer is simpler than you might think. We have to build a safety and security management program that is intertwined with the application development lifecycle. We also have to track all of those safety and security requirements throughout the lifecycle and ensure that enough artifacts are generated in each phase to prove compliance.

Figure 3: Platform to manage safety, security, and compliance requirements.

In order to ensure trustworthy components in an industry that competes with large volumes and low margins, there has to be an automated way to ensure compliance throughout the Systems Development Lifecycle. Building safety and security in from the beginning is a priority because it avoids the costly rework of components later on. Moreover, we need a platform that guides us through these processes and helps us manage safety, security, and compliance requirements.