Over the past few weeks, there has been extensive commentary on the Volkswagen and Rivian joint venture. Unfortunately, many of these discussions remain superficial, lacking a thorough “under the hood” analysis. Given the potential significant impact on the entire automotive ecosystem, a more detailed examination might reveal some very interesting additional aspects.

Personally I find the current discussions fall a bit short of my own expectations and curiosity. I have been following the zonal architecture discussions for a couple of years and am now keen to understand how these concepts are being implemented in detail, what legacy systems are being reused, and what is being discarded.

A more in-depth look would be beneficial, especially considering the increasing ambiguity in terminology, which leads to misunderstandings rather than fostering a mutual understanding for a broader audience. This audience includes not only engineers working on hardware and software but also stakeholders from various departments.

For instance, when OEMs began discussing developing operating systems in-house, there was initial confusion about whether they were now really creating alternatives to Linux or Real-Time Operating Systems. It later became clear that they were referring to the User Interface and User Experience—elements that do not equate to traditional embedded operating systems at all. For a while, people were not talking the same language any longer…

A similar issue now arises with the term ECU (Electronic Control Unit). With the advent of Zonal Architectures, there is talk of significantly reducing the number of ECUs, or even eliminating the majority of them. Rivian states that they succeeded to reduce the number of ECUs from 40-80 in legacy systems to just 7 in their latest generation vehicles. This represents a substantial change in many respects. The question is: what changes will happen to all those traditional ECUs? Will they disappear, or transform into something still “ECUish”?

Rivian appears to have developed all functions from scratch on zonal controllers, leveraging modern, powerful compute architectures rather than migrating existing (frequently Autosar-based) functions onto a multi-core microcontroller, separated by a hypervisor. This means there is no code reuse. Functions traditionally performed by multiple ECUs, such as wipers, seat adjustments, and window lifters, are now managed by a zonal controller, effectively eliminating the need for traditional ECUs and their individual software stacks.

To completely eliminate any electronics on printed circuit boards (PCBs) outside the 7-ECU zonal core, one could theoretically consider integrating power electronics into the zonal controller, connecting directly to the motor with usually 3 cables etc. However, this approach introduces more challenges such as EMI and also would not help to reduce the length of the wire harness. There must be something remaining from the historical ECU, something like a “Dumb ECU”, making a wiper for example an intelligent actuator by just receiving  simple commands via CAN bus or Ethernet like “SPEED 3”. It could mean that the whole control algorithms are running on the zonal controller leaving the peripheral device to be a power electronics interface. This approach would simplify the microcontroller needs at the peripheral device, potentially even replacing the microcontroller with a hardware state machine approach, as promoted by Analog Devices.

We now face the question of whether these simplified peripheral controllers still qualify as ECUs. If traditional measures (e.g., if it contains a PCB, power supply, controller, memory, …) still apply, then we haven’t truly removed all those ECUs. With high-speed signals from sensors like Radar and Cameras, intelligent interfaces to the zonal controller (e.g., 10G Ethernet) are required, suggesting a similar structure to ECUs. Rivian’s new inverter for the electric drive, discussed in their 2024 Investor Day presentation, interesting enough is not counted among the 7 ECUs, though it is a complex control device.

Speaking about ECUs, Volvos honesty in counting is notable. They initially hoped to reduce the number of ECUs but ended up with 150 in their current architecture SPA2, with a target to reduce to 100 in SPA3. This underscores the complexity and challenges in accurately counting ECUs. The number of ECUs alone does not tell the whole story.  As long as those ECUish devices come with a bill of material for electronic components, factors such as sourcing, pricing, assembly, integration, and life cycle management remain critical.

Nevertheless Rivian’s approach is a game changer. It suggests that traditional Tier 1 suppliers might no longer develop “complete ECUs.” Instead, they might provide hardware with minimal intelligence, executing simple commands—a task also suitable for contract manufacturers due to low margins and minimal integration expertise required.

Various zonal controller concepts have emerged over the past few years. Some OEMs consider intermediate steps, transitioning traditional ECUs onto hypervisors within powerful microcontrollers to reuse proven technologies and avoid extensive changes within a short time. Over several vehicle generations, this approach might lead to a pure zonal architecture like Rivian’s. The “famous” NXP diagram of transitioning towards the Software Defined Vehicle illustrates different paths chosen by OEMs.

Volkswagen’s decision to skip these intermediate steps and focus directly on a “fresh” zonal architecture, having Cariad focussing on application development, is remarkable. This approach represents a deep cut and might aim to avoid repeated challenges with change inherent in Volkswagen’s culture, leveraging Rivian’s established functions and signal interfacing. This represents a strategic “Make vs Buy” decision process – why do it internally when somebody else has already done it effectively..

Considering the impact of this transition, Volkswagen is not a start-up like Rivian, which sells around 50K cars per year. Volkswagen sells approximately 10M cars annually across more than 50 different models and their individual sub specifications. If the number of ECUs is reduced by a factor of 10, what does this mean for vendors and suppliers of electrical components and software stacks like AUTOSAR & Co? What if other OEMs like Toyota, Stellantis, and Hyundai/Kia replicate this approach?

My initial reaction to the Rivian/VW joint venture announcement was skepticism, fearing another expensive attempt to resolve Volkswagen’s software challenges. However, I am increasingly convinced that this could be one of the wisest decisions ever, provided the strategy can be adapted across all vehicle lines. I am curious to see how the overall architecture with all the ECUs and non-ECUs will look and how the ecosystem will be affected. Will VW trigger others to make a similar step?

I am eager to hear your thoughts on this. What do you see as the potential impacts and challenges? Please share your insights here on my original post on LinkedIn or you can directly get in touch me.