Electrical and electronic vehicle architecture trends: an exploration

Vehicle complexity is growing

Vehicles are becoming more complex everyday. Customers expect safe, autonomous, connected, electrified and shared vehicles and these features are achieved via software. Although there is a clear change in focus from hardware to software, the advent of software-defined vehicles will rely heavily on optimised Electrical / Electronic (E/E) vehicle architectures.

To make way for this changing paradigm, big hardware changes need to take place. In this post, we will study the trends and evolutions of E/E architecture and identify the ones that fit best with a software-defined approach.

From basic and discrete to complex and integrated

The first generations of E/E architecture didn’t have many Electronic Control Unit (ECUs) to handle. To put it simply, ECUs are embedded computing systems. Indeed, at that time, vehicles were Internal Combustion Engine (ICE) powered, had a radio-cassette system (with CD-reading capabilities for the lucky ones), powertrain and chassis-related ECUs. The number of ECUs was limited and they were all isolated from each other. Each ECU had one specific function; their features were simple and basic.

With new features and new safety constraints entering the picture, a lot of additional ECUs were required in vehicles. For example, to introduce Anti-lock Braking System (ABS), Electronic Stability Control (ESP), and Adaptive Cruise Control(ACC), etc. As more electronic systems were spread throughout the vehicle, the need for interfaces between specific ECUs began to emerge. At the same time, the infotainment requirements began to grow strongly. The system had to receive Global Navigation Satellite System (GNSS) data, display Advanced Driver-Assistance Systems (ADAS) functions, etc. This meant having inter-system communications and control.

As the ECUs started communicating with each other, specific networks were created inside the car so that specific sets of ECUs could communicate efficiently. These would lay the ground for what would later be called “vehicle domains”. For example, infotainment, powertrain, chassis, body, ADAS, etc.

Current architectures and use of central gateways

Today, vehicles use a central gateway that receives data from multiple ECUs in order to secure communication throughout the vehicle. Said data can then be intercepted or accessed by another ECU allowing for cross-functional operations, as long as you know what you’re looking for. Indeed, this approach relies on detailed specifications: one ECU needs to “fetch” the right information from another ECU correctly.

One of the flaws of this approach is that the vehicle still has to support multiple networks which handle multiple ECUs. That may not sound like a problem but just think of the wiring. At least 50kg of wires are required in a modern vehicle. If you put all of the wires in line together, it adds up to 4km in length! This takes a toll on both the vehicle’s cost and total vehicle weight. And with electric vehicles targeting lighter elements, it’s clear that the fewer wires, harnesses and connectors in a vehicle, the better. Not only will it save costs, it allows for fewer materials to be required – which is better for the environment too. 

A more modular approach that allows OEMs to use similar hardware for different functions will simplify the design process. It can also reduce the maintenance required and lower the Bill Of Materials (BOM). What would this approach look like? In the sections that follow, we will explore solutions that can help OEMs develop more optimised E/E architectures.

Intermediate evolutions using Domain Controllers (DC)

One solution consists of keeping the previously detailed central gateway but adding dedicated domain controllers to relieve the central gateway from specific functions, like handling the domain’s network, computations and adapting instructions to specific ECUs. 

This is a first step in simplifying the architecture, as it adds a layer of abstraction between the domain specific ECUs and the central gateway. This consolidation of domain functions can enable cost savings based on commonalised software and on leveraging this new abstraction layer.

This intermediate evolution is emerging in new vehicle models introduced this year. This step is a necessary transition in the right direction, but is not sufficient on its own to support software-defined vehicles.

As you can see in the graph above, there are still too many hardware layers between a sensor and the gateway. The more hardware layers, the more difficult the multi-system integration will be. On top of hardware integration, different software coming from different suppliers with different methods, skills, concepts (etc), will have to talk to each other. The target has to be to reduce to a maximum these layers and end-up with feature specific zones; hence the zonal architecture.

Setting the target: zonal architecture

If the target is to have a minimum number of layers, it implies that resources will be shared. Some resources will be accessible throughout the vehicle, others by zones with the least overhead possible. This means that the software will have to be scalable, dynamic, and available. While this sounds complex, cloud-native architecture has managed to do just that.

Indeed, cloud-native applications can dynamically allocate resources, be fully containerised (simplifying dependency management and security) and fully automated. This results in increased resilience as an application can return automatically to the previously stable state. Additionally, they allow for an efficient, continuous integration and continuous delivery (CI/CD) process that moves code efficiently from building to production.

In order to fathom where the zonal approach is coming from, it’s important to understand the cloud-native approach. 

In the past years, containers and microservices have completely reshaped the way companies develop and deploy services. Containerised services guarantee isolated applications and allow for agnostic services to be run reliably regardless of the environment, as dependencies are included. Compared to virtual machines (VMs), containers require less resources and are more easily deployed using orchestrators.

In an automotive world in which safety and security are mandatory requirements, easy to deploy isolated services fit perfectly. The graph below shows a very simplified view of what a cloud-native architecture looks like. For simplification purposes, we didn’t illustrate hypervisors and orchestrators.

The distributed approach

With complex computing functions and containerised services in mind, the next E/E architecture evolution has to be compatible with a central server. Although this in-vehicle server is often referred to in the automotive industry as “an HPC” (high performance computing) server, it’s  way less powerful than cloud-based HPC and is also very different from a technical standpoint. In order not to confuse our readers, we will refer to it as “vehicle server”.

The vehicle server will benefit from the abstraction layers that were defined with domain-controller-based E/E architectures and will tend to replace these, as it runs their software functions. This transition will occur progressively during a certain period of time: probably at least 2-3 vehicle generations.

The phase during which the vehicle server coexists with domain controllers is often referred to as a distributed zonal architecture. As the domain controller functions move to the server, the domain controller’s hardware will disappear, generating cost savings in materials like wiring.

The consolidated approach

The next and final phase is referred to as the consolidated zonal architecture approach. When complete, no physical domain controllers are needed, as these functions are completely handled by the vehicle server.

One of the key advantages of this approach is that most, if not all, software functions are handled by the server. This means that OEMs will benefit from a reduced number of hardware configurations. On top of that, the same software can be used throughout an OEM’s product range as all the vehicle models can rely on the same software packages for a similar function.

With this in mind, engineering teams can focus on optimised software development cycles, and the software in serial life can benefit from the latest security updates and features. No need to keep a dedicated development team in place to maintain the previous vehicle model’s software. Not only will this benefit from development investments’ point of view, but the software itself should improve in quality – for new vehicles and those which are already on the market.

The final hardware optimisation: one ring to rule them all

We mentioned wiring a lot in this piece, but how exactly would this central computer be physically connected to the rest of the ECUs? A lot of solutions exist, but whether it’s a mesh, star or tree approach, they all require a lot of wires. How can we optimise this even further?

ECUs, sensors and edge devices are all physically spread throughout the vehicle by zones and we want to make sure the server can connect with the least amount of wiring to the zonal gateways.

A mesh approach (having most zones interconnected) allows for redundancy and guarantees physical connections but leads to high wiring costs. On the other side of the spectrum, a ring approach limits the interconnections to the minimum possible. Hence, it has the lowest wiring cost. The ring approach also enables the vehicle server to communicate with all of the zones, even though it doesn’t have a direct physical connection with them.

The sweet spot will probably be ring-based but with very specific additional connections to safety-critical zones for added redundancy. Moreover, in order to guarantee enough bandwidth for all of the data, we expect the whole network to be Ethernet-based.

Conclusion

Vehicle E/E architecture has become too complex due to a legacy approach that doesn’t scale and doesn’t play well with the constant addition of features and updates. In order to help the industry move towards software-defined vehicles, the E/E architecture has to evolve and allow for abstraction layers to be handled from the software side.

In this chicken and egg type of problem, the best way to move forward is to apply the transition on both the hardware and the software. The first issue that OEMs and Tier-1s will encounter is inter-system compatibility, as most of these companies use proprietary in-house developed software. The best solution to defeat this issue is open-source software. With transparency, collaboration and peer reviews, the right software can be maintained, updated, and spread. This approach can generate considerable value for the companies developing, supporting and building on top of said software. Overtime, it has the potential to become an industry standard. 

Contact Us

Curious about Automotive at Canonical? Check out our webpage!

Want to learn more about software-defined vehicles? Download our guide!