Domain-based and software-defined vehicles

Today’s domain-based architectures are inefficient at providing scalable software that automakers can maintain easily through over-the-air updates. Domain architectures segment the control of vehicle functions into domains such as in-vehicle infotainment and advanced driver assistance systems (ADAS), as shown in Figure 1.

Dividing control of vehicle functions complicates software development for features that may require communication and control across multiple domains. Updating software for these systems is challenging, as they are designed and manufactured by different Tier-1 suppliers that all use various processors and microcontrollers from different semiconductor suppliers. The software for controlling vehicle functions is also closely coupled to the hardware. OEMs will install electronic control units (ECUs) to perform specific functions (seat adjustments, parking assistance), with application-specific firmware running on each ECU microcontroller. These ECUs will also vary across vehicle models and trims, leading to higher manufacturing and design costs. Thus, managing software across all vehicle models, trims and individual ECUs is a significant effort, requiring that OEMs work with multiple Tier-1 and potentially even semiconductor suppliers to implement new software updates.

In contrast, software-defined vehicles employing a zone architecture simplify over-the-air updates by centralizing software, enabling the flexibility to add new features through software by decoupling the vehicle hardware from higher-layer application software and offering more cost-effective scalability across vehicle models and trims.

Figure 2 shows an example of a zone architecture that centralizes software in the central computing system and implements zone control modules to aggregate data, actuate loads, and distribute power locally. For more information about zone architectures, see “How a Zone Architecture Paves the Way to a Fully Software -Defined Vehicle.”

The main advantage of centralized software in software-defined vehicles is the reduction in ECUs that host application software, simplifying over-the-air updates by reducing the number of processors and microcontrollers requiring firmware changes. Adding new features and applications requires updating only the central computer or zone control module software, as the downstream sensors and remaining ECUs controlling the mechanical actuation (headlights, door modules, audio amplifiers) are abstracted from the application software. Therefore, the ECUs performing mechanical actuation and sensors at the edge of the vehicle network require less complex firmware and may completely shift real-time control to the central computer in the future.

Furthermore, it is possible to repurpose sensors and actuators originally designed for specific applications to create new features. An example is adding new applications for the in-cabin radar sensor, initially designed for occupancy monitoring, to provide intruder or theft detection and seat belt reminder functions. Essentially, OEMs have more flexibility to implement new features with hardware and sensors that already exist within the vehicle.

Lastly, software can scale across all vehicle platforms, as shown in Figure 3, further reducing development costs. An economy-level vehicle can implement the same software as a luxury brand for functions such as remote keyless entry, window lifts and rearview cameras.

Luxury models can offer premium features through software on top of baseline features. Although hardware changes may still be required, the overall approach is modular and scalable across vehicles. Adding or removing processors and microcontrollers can scale computing power up or down in the central computer or zone control modules.