The Road to Electronics Consolidation in the Vehicle

By Andrew Macleod

By Andrew Macleod, Mentor Graphics

red car wire harness

We increasingly hear about centralizing the processing power in cars down to two processors: one to handle all communications with the driver, and the other to process the autonomous-driving functions. This could also enable the so-called deep-learning for cars concept, where a few powerful processors analyze the huge amounts of data generated by the cameras and sensors in a car to ‘learn’ how to drive the car more safely and effectively, the other handing all network and data management. But from a vehicle architecture perspective, just how realistic is it to centralize around a handful of processors?

This question touches on several disparate points, such as electrical and electronic system architecture, sourcing strategy by car makers for SoCs and the vehicle increasingly being defined as a software platform more so than hardware. Architectures and SoC evolution are good topics to discuss when we look at ECU consolidation, but what about physical constraints that car makers need to deal with: weight, and space constraints for example. The trend towards ECU consolidation is definitely happening, but to standardize on 2 big processors for communication and autonomous functions may result in running significantly more cabling around the car, adding weight and cost.

Finding the Sweet Spot to a Multi-Dimensional Problem
Today’s automotive networks may look complex and inefficient, but they actually find the sweet spot between function, cost and vehicle weight. Ask any wiring harness manufacturer. First, there is the problem of physically fitting an expanded wiring harness into space constrained environment such as doors. Automakers can decide to add more ECUs and create greater distribution of network to reduce cabling size, weight and cost.

Another issue is whether to have an Ethernet backbone for data flowing through the vehicle. That certainly makes sense, but it will not replace CAN and LIN communications for things like door, mirror and seat control, the main body electronics functions that make up a significant part of the vehicle ECU network. That’s why new entrants to the auto industry with electric vehicles have, to date, designed distributed architectures, to manage vehicle weight which is particularly relevant when we consider new energy, and the direct impact on range.

It quickly becomes apparent that the problem is multi-dimensional: how to bring the latest automotive innovations to market faster, on budget, keep the vehicle weight to a minimum and leveraging decades of legacy software and network hardware. The 2 mega compute processors addresses only part of this and arguably creates all kinds of new problems.

Consolidation: Slowly but Surely
Every part of the vehicle is becoming electrified, and the road to consolidation may be appealing, and have cost benefits on-paper, but squeezing out those benefits means a complete re-write of today’s EE systems, something car makers don’t like.

Will the infotainment head unit and driver information system (cluster) converge? Absolutely and this makes sense. Will we see ECU consolidation driving vehicle networks from >100 processors in-car to just 2, 5 or even 10? Not anytime soon.
Consider the aspects of SoC design, and the challenges of running a vehicle from 2 main processors. Getting an automotive-grade SoC onto the road is not the same as getting it into a cellphone. The processors need to be zero defect for the life of the vehicle, have full functional safety compliance to ASIL-D level, be secure from external attacks and have secure partitioning around the vehicle. This is not a trivial task and there are only a handful of companies who can provide these processors.

Of course, with advanced process geometries, SoC vendors are designing fewer unique automotive microprocessor designs per technology node, due to design and manufacturing cost. So there is an argument that this will provide a catalyst for integration of function, and result in less unique, but more powerful processors with increasing functionality. But even if this trend proves true, the comfort and body electronics functions will remain distributed as long as we have copper wire and standard automotive communications networks.

Larger Paradigm Shift to System Design
The issue of consolidation is really a smaller part of the larger trend of the auto industry shifting from a manufacturing focus to a consumer-based focus, in response to drivers’ expectations for the latest and greatest technologies in their cars. This in turn is creating demand for shorter design cycles, software updates over the life of the car—for example, updating in vehicle infotainment systems to keep them relevant–and system engineering support to integrate this into the existing vehicle architecture.

The processor is just one part of this larger challenge. As we said, the wider question is how to make this not only secure, but also have zero defect for the life of the car, while still getting to market faster and staying within budget. It is this shift from component design to vehicle electrical design that is the real challenge that car OEM’s face, requiring system design expertise to implement a new architecture within these constraints. Some premium OEM’s are developing custom electrical architectures dependent of the model and the options selected by the buyer. Other automakers find that a more distributed architecture reduces cost in different ways: such as eliminating extra wiring and complexity.

The question of reducing the number of ECU’s in a car is still a valid one from a megatrend perspective, but it doesn’t capture the reality of EE car design today and the myriad of challenges that car makers face. Sweeping up all the ECUs into handful of powerful processors sounds like a great idea for a prototype architecture, but making it work is a different question, as OEM’s well understand. This is why the current hot topic of deep learning for cars as the catalyst for ECU consolidation is a great subject to talk about, but first there are a few engineering design constraints that need to be considered. It will be an interesting road to get there, but we aren’t there just yet.


5 thoughts about “The Road to Electronics Consolidation in the Vehicle
  • When you say “zero defect for the life of the vehicle”, how long would you expect “life of the vehicle” to be?

    There are cars from over 100 years ago still on the road; modern electronics, in my opinion, are the limiting factor on vehicle longevity these days.

    For example, I owned a 1982 Triumph TR7 which had carburettors, non-electronic distributor, cable operated speedo etc. When I sold it on in 2000 it still worked rather well whereas by 2011 my 2003 Renault Laguna, with ECU, multiple control systems, and various other electronics was dead through ECU failure, with replacement cost and coding being prohibitively expensive.

    In addition to that, the increase in electronic systems increases costs of repair since only specialists can afford to invest in the technology required to diagnose faults in the system and, even then, (certainly in the Renault Laguna’s case) the diagnostics results are often nonsense and bear little resemblance to the actual fault. These depend on the diagnostic systems themselves being perfect and that’s far from guaranteed.

    In the future if, for example, the hell that appears to be likely if “self-drive cars” ever get the go-ahead, aren’t we going to need the sort of redundancy and voting systems that are used in aeroplanes to provide reasonable safety? In many cases those systems are developed by multiple software teams given a common requirement and hardware architecture to try to minimise the risk of all the systems including the same ‘faulty’ software, i.e. software that has code derived from an invalid interpretation of the requirements.

    Minimizing the number of physical processors is an interesting concept, but it would tend to suggest more complicated processors are required and, clearly, the more complicated the device the more the risk of inherent design flaws.

    You may disagree….

  • Hey John, all great comments and valid points; vehicle life is generally specified by the OEM, and is at the component level, eg microcontroller will have x years of zero defect operation with the flash memory cell at x degC with y write/erase cycles; I think the industry is moving towards new implementation methods for maintenance, eg Tesla rolling out over the air software updates which is estimated to be able to ultimately fix 75% of recall or maintenance issues without needing to visit the dealer. Eventually. Also we have an ISO standard (26262) for functionally safe electronics systems in cars, to address exactly what you talked about, with redundancy at the hardware and software levels, and we have strict qualification and design rules for automotive grade processors to facilitate zero defect performance with increasing complexity. This means these processors are structurally different than consumer or industrial grade chips. You raise great and valid points, and the industry is absolutely moving in the direction you suggest to address these at the speed of new innovations. And the ’82 TR7 is a fabulous car, and OEMs today now put logistical processes in place to preserve classic car status, with certain models electronic systems having decades of assured maintenance and upgrade. Thanks for the insightful comments.

  • I enjoy simply seeing the term “ECU” on a tech site! I’ve worked in vehicle electronics for years and do to a recent employment change (Tesla) I found myself having to dive a bit deeper into automotive electrical systems and learn how to trouble-shoot Controller Area Network systems. I find myself stuck between new cars and old cars in terms of trust. I just love a simply put together vehicle, without ECU’s. On the other hand ‘Boy do I love a Tesla’.

  • Brilliant blog!
    I guess for now I’ll settle for book-marking and adding your RSS feed to my Google account. I look forward to new updates and will share this blog with my Facebook group.
    Talk soon!

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at