The software-defined vehicle architecture is poised to bring about a transformative shift in the automotive industry by facilitating a flexible and adaptable solution for the assimilation of cutting-edge technologies, features and services such as charging infrastructure, predictive maintenance, autonomous driving, connected vehicles, enhanced safety systems, as well as financial technology and blockchain. This necessitates a comprehensive reimagining of the vehicle's electric/electronic (E/E) architecture, especially the software but also for hardware. In addition to streamlining the vehicle development process, the new E/E architectures will also let original equipment manufacturers leverage data-driven services that cater to a user base more attuned to subscription-based features, thus creating new and appealing business opportunities. To learn more, we spoke to executives of Infineon Technologies AG.
Semiconductors play a central role in driving the automotive industry's megatrends, which include electrification, connectivity, autonomous driving and advanced security. They provide the foundation for smart traffic concepts and safe vehicles by powering various automotive technologies. Infineon Technologies offers a range of semiconductor solutions, leveraging its expertise in sensors, microcontrollers, connectivity, power semiconductors and security solutions.
The following is an edited transcript of the conversation.
S&P Global Mobility: We are seeing a gradual migration from distributed ECU E/E architecture to a centralized zonal one with a central computer to support a software-defined vehicle with more efficient hardware designs. How do you envisage the transformation of ECU consolidation?
The transformation will be gradual. We see OEMs migrating from distributed E/E architectures to zone-based E/E architectures. There are many flavors of zonal architectures in the market, and from today’s perspective is not clear which one will win.
Due to complexity, the most common approach is the centralization of body functions into zone controllers, while keeping vehicle motion and [advanced driver assistance systems (ADAS)] functions into separate domain controllers or into cross domain controllers.
The centralization of chassis and powertrain functions into zone controllers will most likely be addressed around the 2030 timeframe.
From your perspective, how are the respective roles of tier 1, tier 2 and OEM roles changing in terms of defining the vehicle’s architecture as well as the working relations?
We are seeing OEMs taking the lead in the development of future architectures taking over [software] and partially [hardware] development of key components like cross-domain controllers, central computers and zone controllers. OEMs are also taking over sourcing of key semiconductor components.
Classical tier 1s are transitioning slowly to being engaged in proof-of-concept work and manufacturing of modules (EMS).
Tier 2s (semiconductor manufacturers) are expanding their relationship with OEMs engaging sometimes in the co-definition of processors and [microcontroller units (MCUs)] together with OEMs.
Different domains will face different threats and opportunities, such as disappearing ECUs and/or increasingly smart actuators. What are the main opportunities/challenges for these domains: ADAS; infotainment; body; chassis; and powertrain?
Chassis and powertrain are the next wave of domains to be integrated, after the body. In the powertrain space, we see the appearance of new X-in-One systems where powertrain functions are consolidated.
The integration of chassis functions into such X-in-One systems or in zone controllers will be much slower. The main reason is the stringent safety requirements for braking and steering functions.
ADAS and infotainment we start to see the first [systems-on-chip (SoCs)] which can address both. Likely those domains will be integrated as the processing power will be available from a single SoC.
The body is a “joker” and can be integrated with any of the other domain controllers. Body functions were the first functions to be integrated into zone controllers. In the future, body domain controllers will not exist as stand-alone anymore, and their function will be covered fully by the zone controllers.
As this migration evolves, which ECUs do you see disappearing and being replaced by a zonal controller? How does that vary with its position in the car? Front, cabin, back, doors? Will the zonal controllers be based on the physical locations within the vehicle, front, rear and cabin? Or will their distribution be determined differently than location and if so, what?
We see body functions integrated into all types of zone controllers.
Front zones tend to integrate partially vehicle motion functions. Back and door zones generally focus on body functions.
The distribution of zone controllers will be based on physical location.
Will small ECU applications, such as seat control and wipers, survive this migration or will they be integrated into domain controllers as software applications?
Seat control and wipers will most likely be integrated into zone controllers.
As the E/E architecture becomes more centralized, what are the opportunities for the hardware and software in the architecture?
[Hardware] opportunities: To support the centralization of software components, new controller families with virtualization capabilities and extended connectivity will be needed. (Ethernet connectivity, routing of different communication protocols).
[Software] opportunities: The centralization of functions will require the virtualization of software components. With virtualization, the different SW components can be encapsulated and isolated from each other. We will see the growth of hypervisor and virtualization software. Communication stacks based on ethernet with time sensitive networking will be required to ensure critical timing requirements of real-time functions.
Will zone controllers act as their main function as a gateway between the central computer and actuators, or will local power distribution functionality be equally important? Will this be a common implementation, or will zone ECUs mainly act as I/O aggregators?
Depends on the OEM concept. We see that local gateway, power distribution and body functions are the three main functions of a zone controller.
Do you see MCUs being eliminated by SoCs in zone controllers or complete ECUs (if there is a power distribution function in the zone)?
MCUs will never be eliminated as even the software functions get centralized; there will still be the need for MCUs to control sensors and actuators locally.
Also, there are real-time and safety requirements that prevent certain applications from being centralized, e.g., braking control.
How much compute capability and memory densities will be required in zone controllers versus central computers?
The compute capability of zone controls depends heavily on OEM design. We see from 1k to 10k DMIPS and 4 MB to 24 MB as the possible range which would cover 99% of OEMs.
In central computers, the performance can scale up to multiple of 100k of DMIPs.
Are all OEMs moving in the same direction regarding the importance of over-the-air driving the vehicle’s E/E architecture? Does this mean all small ECUs and actuators will need to be reconfigurable via OTA or will OTA be limited to central computers and zonal controllers?
Yes, all OEMs are going in the direction of reworking their E/E architecture to enable OTA updates.
No, not all ECUs necessarily require an OTA update. The ECUs on which OEMs are setting the highest priority on enabling OTA are central computers and zone controllers.
