CENTRALIZING COMPUTE: HOW FAR CAN IT GO?

As consumers demand an increasing number of intelligent features in today’s vehicles, the approach of creating a dedicated electronic control unit for each feature is clearly unsustainable. It results in too much complexity and cost, uses too much power, adds too much weight and, most importantly, takes up too much physical space.

As a result, OEMs are up-integrating software-defined features into centralized compute wherever possible — which begs the question: How far could up-integration go, realistically? If we extrapolate this trend, will we ever see a vehicle with all compute functions handled within a single box?

While up-integration will continue, there are at least six key considerations that limit consolidation after a certain point. Vehicle designers must optimize their architectures so that they take these issues into account while maximizing the benefits of reducing the number of boxes required.

The optimal amount of up-integration will be different for every vehicle model. OEMs have different goals in terms of active safety capabilities, comfort and convenience functions, overall vehicle design and consumer price targets. As a result, every vehicle’s electrical/electronic architecture faces unique challenges related to packaging, power management, cost and other factors. Put another way, "optimization" will mean something different for every OEM and every platform.

Across all capability levels, however — from base models to premium options — designers must weigh certain common criteria when it comes to up-integrating functions into centralized compute.

 

The first consideration is the update timelines of different functions, which could be on very different schedules.

For example, an OEM might want to update a vehicle’s user experience software or advanced driver-assistance system (ADAS) on a regular basis. Developers could create new applications that provide a different experience for the consumer or improve existing software to make better driving decisions. They could push those updates to vehicles over the air as often as needed.

In contrast, there are plenty of software-defined functions that are unlikely to change much over five years or more. A prime example is the power and body controller, which manages interior and exterior lights, window controls and door locks, climate controls, warning lights and overall power distribution.

In Aptiv’s Smart Vehicle ArchitectureTM approach, those slowly changing or unchanging functions are handled by the central vehicle controller, or CVC. More frequently updated software resides in the open server platform, or OSP. This separation also allows for the possibility of upgrading the OSP hardware itself every couple of years as more-capable processors become available, providing a consumer experience closer to that offered by today’s smartphones.

In addition, the CVC is designed to boot up very quickly and use basic signaling to get essential systems running as soon as possible — opening the door, cranking the engine and activating the rear camera, for example — while the OSP can take longer to fully boot more-complex code and use Automotive Ethernet to communicate with other systems.

For details on those criteria, read our white paper.

 
OBC
EV CHARGING
WIND RIVER
4D RADAR
IONIQ 5 ROBOTAX
ADAS
ZONE CONTROLLER
SAT. ARCHI
CES 2024
SDV - CONTAINERS
ODDs
VA - 800V