“Decentralized” vs “Centralized” Automotive Architectures – REWIRE Demo

by Athanasios Alexopoulos, KENOTOM

In the last decades, due to technological advancements in Artificial Intelligence (AI) and government regulations to improve road safety, the automotive industry is moving towards autonomous and connected vehicles that present increased needs for security and SW updates. Typical security methods such as encryption or authentication can overwhelmingly increase computational load as well as bus load of vehicle’s communication network, making it very difficult for current electrical and/or electronic (E/E) automotive architectures to keep up with industrial vision of the automotive future. A simplified timeline of the automotive industry E/E architecture trends is depicted in Figure 1. “Today” section represents distributed (decentralized) E/E automotive architectures currently adopted and widely used by automotive industry. “Tomorrow” section refers to the short-term goal of industry to eventually adopt domain centralized architectures, where larger portion of software (SW) functions are executed in less Electronic Control Units (ECUs). “Future” section describes the long-term direction of industrial trend in automotive architectures, where vehicle centralization gathers all SW functions in one central vehicle computer.

Figure 1: Moving towards centralized E/E Automotive architectures

 

Decentralized Automotive Architecture

“Distributed (decentralized)” automotive architectures (Figure 1) utilize individual ECUs for specific vehicle functions, providing flexibility and redundancy. It has been a reliable and well-established approach in the automotive industry. However, decentralized architectures present some important drawbacks, such as:
• Scalability challenges due to the increasing number of ECUs, often surpassing 100, resulting in complex wiring harnesses, significant development and maintenance cost and inefficient and expensive handling of SW/HW vehicle variants.
• Substantially increased source code, that can rise to million lines for all vehicle ECUs, leading to difficulties in management and maintenance.
• Redundant and inefficient communication between individual ECUs for numerous vehicle functions, negatively impacting performance, efficiency and responsiveness while increasing communication load.

 

Centralized Automotive Architecture

“Domain centralized” (Figure 1) automotive architectures group more vehicle functions or even entire vehicle domains (Powertrain, Chassis, etc.) into more powerful and less in number ECUs (Figure 1), while a fully “Vehicle Centralized” architecture (Figure 1, Figure 2) would only have a single central computing platform to handle the majority of vehicle’s functions, and multiple simplistic control units that would only serve as “smart-actuators” or gateway units. Overall, centralized architecture signifies an architectural shift that unlocks intelligent and connected mobility possibilities with enhanced efficiency and convenience, presenting various benefits:
• Enhanced scalability through the centralization of functions, allowing for: easier management of vehicle functions, easier software updates, while reducing complexity and maintenance costs.
• A smaller number of ECUs reduces needed network relations and improves communication efficiency.
• Provides a better suited platform for latest automotive trends, such as ADAS (Adanced Driver Assistance Systems), Over-The-Air (OTA) updates and vehicle connectivity.

Figure 2: Exemplary “Vehicle Centralized” E/E automotive architecture. The central computer undertakes most of computational and functional tasks, whereas zonal controllers act as simple “gateways” for signal distribution.

 

Security Challenges of Centralized E/E Automotive Architectures

Although the concept of centralized architecture is intriguing, security-related drawbacks emerge since a possible cyber-attack can affect a larger portion of the vehicle’s functionalities. In the decentralized architecture, functionalities are distributed around a large number of different ECUs, thus a possible security compromise of an ECU would only affect a specific vehicle functionality. In contrast, centralized architectures group many functionalities and computational tasks into less ECUs, therefore a security compromise may lead to loss of greater number of vehicle functionalities, thus significantly compromising overall vehicle operation.

 

REWIRE Countermeasures and Fail-Safe Mechanisms

REWIRE will face the security drawback described above by deploying specific fail-safe mechanisms. Firstly, REWIRE will ensure that ECUs safe SW state will be frequently stored, which will allow for a potential “Roll-Back” action whenever malicious intrusions are detected. With the latest safe SW state stored, a “function migration” mechanism will be explored, ensuring that whenever an ECU is compromised, secure migration of related functionalities to a neighboring, non-compromised ECU will be deployed, to ensure vehicle operation. In addition, REWIRE will provide secure delivery of software/firmware (SW/FW) OTA updates to the vehicle, that could patch a potential security vulnerability.

The vehicles of tomorrow have extended needs regarding computational resources, remote connectivity and security that highlight the limitations of current decentralized automotive E/E architectures. REWIRE Automotive Use Case will demonstrate REWIRE security framework on an exemplary “Centralized” automotive architecture, to showcase the basic characteristics and challenges, while also providing an automotive relevant platform for the application of REWIRE security mechanisms.

Leave a Reply