SLYY236A September   2024  – October 2024

 

  1.   1
  2.   At a glance
  3.   Introduction
  4.   Domain-based and software-defined vehicles
  5.   New technologies enabled by software-defined vehicles
  6.   Variations in software-defined vehicle and zone architecture approaches
  7.   Conclusion

Variations in software-defined vehicle and zone architecture approaches

Each automotive manufacturer has a unique approach to achieving the software-defined vehicle. The legacy of previous-generation vehicle platforms will force many OEMs to shift gradually to an electrical and electronic zone architecture that better suites their centralized software approach.

While the majority of OEMs are developing zone architectures, there are different approaches when deciding where the software to control vehicle functions resides, as shown in Figure 5.

There are three options when centralizing software control: central computer; shared between the central computer and zone control modules; or distribution into a few domain controllers and zone control modules. Some OEMs are centralizing high-performance computing domains such as ADAS and in-vehicle infotainment and adding additional application processing for other domains. Outside of the ADAS and in-vehicle infotainment domains, real-time control is implemented either in the zone control modules or edge ECUs.

The centralized computing approach may be the most attractive from an OEM perspective, as a single computer controls all vehicle functions. There may be additional challenges with real-time control loop latencies (active suspension, window anti-pinch) and functional safety if the communication link fails.

The distributed computing approach takes a more gradual step toward centralizing software, maintaining some application and real-time control software in the zone control modules or even in separate domain controllers. In all architectures, zone control module requirements will vary even within the same vehicle, depending on the OEM. One zone could handle some real-time control of body; heating, ventilation and air conditioning; and chassis functions, while another handles additional body, lighting and the vehicle control unit application software. Ultimately, OEMs will have to balance hardware and mechanical actuation control latency, in-vehicle network capabilities, functional safety, security, and how to structure software for the architecture that they choose and its specific zone control module requirements.

 Comparison of vehicle
                    architecture types. Figure 5 Comparison of vehicle architecture types.