Changes in Vehicle Electrical Architecture: Centralized and Software-Defined


Cars as We Know Them

Cars as we know them today are digital machines with dozens of distributed computer systems running everything from infotainment and connectivity features to advanced safety, comfort, and convenience elements. A late model luxury vehicle may have up to 70 electronic control units (ECUs) that combine a processor, memory, and software. ECUs are designed to do one thing only for the life of the vehicle and are not built for functional change or enhancement. The only way to modify or update the code within an ECU is with a costly scan tool that is physically connected to the vehicles.  

Another key element of today’s vehicles is the Controller Area Network (CAN) bus. Considered the nervous system of a vehicle, the CAN bus is an underlying network architecture that connects and enables communication among the dozens of distributed ECUs.

Moving Toward a Centralized Architecture

While the distributed systems of vehicles have been practical and functional up until now, newer architectures, more data, and a movement toward centralized processing is challenging the limits of traditional automotive design. One such trend is the consolidation of domains into a centralized computer architecture. Instead of having several discrete ECUs, they are all housed in a centralized domain control. This model allows for greater software functionality, more code reuse, and easier remote management.

Tesla is a classic example of a software-defined car. Unlike any other vehicle on the market today, Tesla started from a clean sheet of paper. The goal was to design a car controlled by software and executed on a centralized compute platform. Tesla’s vehicles are considered software-defined cars because almost any new feature or modification to an existing feature can be made with software updates sent over the air. VSI believes Tesla is a proxy for future vehicle architectures, and many automotive OEMs have begun following suit, acknowledging it is time to give in to the contemporary architectures necessary to support future vehicles.

A key enabler to the software-defined car movement is the consolidation of domains into a centralized computer architecture. This supports a much better system for software management and computing efficiency. Furthermore, this architecture allows for feature enablement using Over-the-Air (OTA) distribution of new software code to the vehicle.  Tesla, for example, uses OTA exclusively for the management of features including the distribution of new functionalities as well as the improvement of existing ones.

The move toward software-defined vehicles is facilitated by processor companies that are making more powerful processors optimized to handle the computing requirements of a centralized approach. Additionally, the operating system companies can partition the platform whereby a central domain processing unit may have multiple virtual machines running independent of one another.

Challenges & Other Considerations

Aside from Tesla, the movement to centralized domain control has been slow, largely due to the “if it ain’t broke don’t fix it,” mentality. This is not surprising considering traditional architectures work very well. But we are at the limit of what those traditional architectures can support when it comes to lifecycle management.  Infotainment proved this and the OEMs finally gave in a bit. Now we have a greater movement toward intelligent feature enablement which is always changing and improving. The new architecture supports this, while the legacy does not.

There are many other hurdles to adopting a centralized approach. For one, there are software challenges that may be beyond the scope of many OEMs. However, the software expertise necessary to support the architecture is becoming better understood at the OEM level and even among tier one suppliers, and most major tier ones have introduced centralized domain architectures for ADAS and automated driving.

There are also a lot of software tools to manage the abstraction layers necessary to support central domain processing.  The abstraction layer enables an application interface from which applications can be managed. Even AUTOSAR has a specification to support the new architecture. Adaptive AUTOSAR allows an I/O interface to the most guarded of vehicle applications, most notably those associated with active safety and automated driving.

It is important to note that centralized domain control does not consolidate all processing into one box as you might think.  There will be distributed processing that optimizes the system and reduces the workload on the domain controller. There will need to be several accelerators pushed out to the edge to deal with so much data.  Sensors modules, braking control modules, body control modules, lighting modules, etc. There is a lot of expertise at the edge supporting the centralized domain architecture.

One consequence of this software-first movement is that the vehicle architecture will become a service-oriented architecture (SOA) based on generalized computing platforms. Developers will create new applications, artificial-intelligence elements, and operating systems. The differentiation will not be in the traditional vehicle hardware anymore but in the user-interface and experience elements powered by software and advanced electronics.


The movement toward software-defined cars has been under development for years, and nearly all OEMs are working on these newer architectures. You can credit Tesla for accelerating this and proving the architecture is viable.  So, can the OEMs pull it off? Only time will tell. There’s no way we can predict exactly how vehicles will transform over the coming years. But there is no doubt that software is playing a bigger role in cars of the future and will no doubt continue to do so.

ADAS Guide 2021 Banner