Exploring the vehicle architecture types

The different ways an E/E architecture can be built impact the vehicle attack surface, as well as the attack feasibility associated with certain attack paths. As we will see in Chapter 3, some E/E architectures are more vulnerable to cyberattacks than others.

Throughout the years, the E/E architecture has evolved from a highly distributed one with direct mapping between vehicle functions and ECUs to a more centralized architecture where vehicle functions are consolidated into a few yet computationally powerful domain controllers. Figure 1.20 shows the expected progress of E/E vehicle architectures. It starts with the highly distributed architecture, which consists of highly interconnected function-specific ECUs. The second evolution represents the domain-centralized architecture, which utilizes domain-specific ECUs that consolidate the features of multiple ECUs into fewer ones. The next generation is the zone architecture, which consists of vehicle computers or zone ECUs connected to the rest of the control units, sensors, and actuators:

Figure 1.20 – E/E architecture evolution

Let’s zoom in on the three main types of E/E vehicle architectures to better understand their differences and gain insights into some of their security weaknesses.

Note

OEMs take different approaches to how they advance their vehicle architectures, so it is possible to find vehicle architectures that are in a transitional stage between architecture classes presented here. At the time of writing this book, the story of the vehicle architecture evolution has not been finished yet, so a different architecture class may still emerge.

Highly distributed E/E architecture

This type of architecture clusters ECUs with similar functionality or inter-dependent functionalities in shared network segments using CAN, LIN, or FlexRay so that messages can be exchanged. You may find several ECUs in this architecture that perform message relay functionality in addition to their primary vehicle functions to allow messages to flow from one network segment to another – for example, CAN to CAN or CAN to LIN. Such ECUs can be considered as local gateways that allow you to add new ECUs to the vehicle architecture without the need for a complete redesign of the in-vehicle network. A side effect of this approach is that the proliferation of local gateways creates weaknesses in network isolation as these gateways are not designed to limit unwanted access to the newly added ECUs. To reduce the addition of dedicated network channels, the designers of this architecture may allow ECUs with a high degree of difference in security exposure to be grouped in the same sub-network. For example, you may find the infotainment ECU adjacent to the braking ECU, which should make you uneasy. Another common aspect of this architecture is that the OBD connector, which enables a diagnostic client to send and receive diagnostic commands to the vehicle, is directly connected to an internal vehicle network segment such as the powertrain or chassis domain:

Figure 1.21 – Highly distributed architecture

Discussion point 13

What could go wrong if infotainment ECUs are adjacent to safety-critical ECUs in a network segment? Why is the OBD connector a source of concern?

Domain-centralized E/E architecture

Challenges in terms of the cost and maintenance of highly distributed E/E architectures gave rise to the domain-centralized E/E architecture when security was not even a concern yet. The primary feature of this architectural variant is that you can group ECUs in well-defined vehicle domains and separate communication between the domains through dedicated gateways. The domains we introduced in the previous sections can be seen in Figure 1.22 connected through an Ethernet backbone to support high-bandwidth message transfer across the different domains:

Figure 1.22 – Domain partitioning in a centralized architecture

One of the main features of the centralized architecture is the availability of a central multi-network gateway with a high-speed networking backbone such as Ethernet, which is preferred due to the high volume of data transferred between domains as well as off-board systems. This gateway, which can serve as a vehicle’s central networking hub, is capable of enforcing network filtering rules that prevent one domain from interfering with others. A typical CGW contains multiple CAN/CAN-FD interfaces, along with multiple Ethernet interfaces with support for time-sensitive communication. The backbone enables features such as Diagnostics over IP (DoIP) to support high-bandwidth use cases such as parallel flashing and diagnostics of multiple ECUs.

Discussion point 14

What role does the CGW play in improving the E/E architecture’s security?

Domain control unit

A domain control unit (DCU) combines multiple small ECUs into a single ECU with a more powerful processor, larger memory, and more hardware peripherals and network interfaces. DCUs are a key enabling feature of software-defined vehicles, where vehicle features can be enabled or disabled through software updates without the need for a hardware upgrade. DCUs typically rely on high-performance MCUs and SoCs.

Due to a common computational platform being shared among different applications, these systems need to consider a larger threat space, which gives rise to concerns regarding spatial and temporal isolation:

Figure 1.23 – DCU architectural view

From a software perspective, a domain controller is expected to execute an application subsystem that runs within a POSIX-based operating system alongside a high safety integrity-compliant MCU within a real-time operating system. One common implementation of this architecture uses an AUTOSAR adaptive instance, alongside one or more AUTOSAR classic instances, as shown in Figure 1.24. Assumptions about the security of real-time instances must be reconsidered in this type of architecture because of a common hardware platform being shared:

Figure 1.24 – Multiple software platforms in a single DCU

Discussion point 15

Do you think that a DCU is more vulnerable to attacks compared to the ECUs that run AUTOSAR classic only?

Central compute cluster

This high-performance vehicle computer is built upon heterogeneous execution domains, integrating CPUs, GPUs, and real-time cores to support computationally intensive applications, such as autonomous driving, infotainment, and the cockpit, all within a common hardware platform. An example of a central compute cluster is NVIDIA’s autonomous driving platform, as shown here:

Figure 1.25 – Software partitioning of the NVIDIA vehicle computer (credit Nvidia)

This type of architecture supports multiple instances of AUTOSAR classic for the real-time safety applications that are executed on the real-time cores. A separate CPU cluster is hosted through a hypervisor that supports one or more POSIX-compliant operating systems. Typically, a safety-certified operating system such as BlackBerry’s QNX manages autonomous driving applications, while Linux and Android operating systems are used to offer cockpit and infotainment services. These systems offer a rich set of peripherals and network interfaces to enable applications for computer vision, object detection, sensor fusion, and many cloud-supported services, such as mapping and software updates.

Discussion point 16

Can you think of the security weaknesses of this type of architecture? What happens when applications of varying security levels are hosted within a single computer?

Zone architecture

The zone controller is an essential element of this design as it connects a large number of actuators and sensors to a CGW and vehicle computer. Zones are distributed based on the location in the vehicle (for example, the front driver location can be a zone and the rear right passenger location can be another zone). A zone supports various functions, and local computing handles each of these functions to the best extent possible. Typically, a central computing cluster (introduced in the previous subsection) is linked to the sensors and devices through networked zone gateways. A backbone network connects the zones to the central computing cluster:

Figure 1.26 – Top-level view of the zone architecture

The domain-centralized E/E vehicle architecture can scale well if the sensors and actuator placement remain very close to the ECUs. However, as new vehicle functions are added, vehicle architects must duplicate sensors and add more cabling and interfaces, which becomes very costly.

This resulted in the advent of the zone architecture, which aims to distribute power and data effectively across the vehicle while reducing the wiring cost, vehicle weight, and manufacturing complexity. This approach classifies ECUs by their physical location inside the vehicle, leveraging a CGW to manage communication. Rather than duplicating sensors, the CGW can transport sensor data across zones, reducing overall costs. Furthermore, the physical proximity of sensors to the zone controllers reduces cabling, which saves space and reduces vehicle weight, while also improving data processing speeds and power distribution around the vehicle. This makes the networked-zone approach desirable as it provides better scalability and flexibility, as well as improved reliability and functionality.

Discussion point 17

Are there downsides from a security standpoint of having so much data processed by the CGW? How about the single central vehicle computer – could it present security risks?

Commercial truck architecture types

Before concluding our discussion on E/E architectures, we need to touch upon a special vehicle category that is quite important for security. Commercial trucks may not get the glamour that passenger vehicles get, but when security is considered, the consequence of a breach in a commercial truck weighing up to 40 tons can have far more catastrophic effects than a passenger vehicle. The E/E architecture of commercial trucks trends in a similar fashion to passenger vehicles, with the main difference being the existence of one or more trailers that have electromechanical systems, such as trailer braking and trailer lamps. Due to the longer development cycles for commercial trucks, their architectures typically include more legacy components, making it harder to adopt security features. Another differentiating aspect of commercial trucks is the reliance on the J1939 protocol for in-vehicle communication. Moreover, the usage of SAE J2497 is common for communicating with the trailers through power-line communications (PLC), creating a unique attack surface. When it comes to ECU types, while the domains are largely the same, the types of actuators differ due to the larger vehicle size. For example, the braking system relies on pneumatic pressure rather than brake fluid pressure. Throughout the remaining chapters of this book, we will point out special threats and considerations that apply to commercial trucks when appropriate.