Evolving Automotive Architectures

Being in strategy consulting and product management, I often walk into discussions concerning what is happening in the automobiles space; these can be project discussions or random discussions that start at the coffee table. Most of these discussions are technical. They cover aspects such as how vehicles are becoming software-defined and how traditional OEMs (e.g., Volkswagen, BMW, and Mercedes) face challenges from creating a different E/E (electrical/electronic) architecture to embracing new approaches for software development.

And then some discussions are purely non-technical. Driven by technology-averse and less-aware people, these discussions revolve around thoughts such as - electric vehicles will perhaps take a long time to penetrate the market, autonomous driving vehicles are not for the Indian roads and others. A few revolve around the range of battery-powered electric vehicles and charging centers.

The above types of discussions are valid in their respect, as both highlight the changes or transformations expected in the automobiles space. However, the vantage points of these discussions differ; one speaks from the OEM's point of view, and the other from the customers'. Naturally, apprehensions and doubts drive the customers' point of view; this is typical of any new technology that replaces the current ones (e.g., when automobiles replaced horses as a mode of transportation or installations of elevators, etc.).

We discussed software-defined vehicles first in Apple's Autonomous Driving Vehicle Project Hits the Gas post. The hardware layer of a vehicle is fast becoming a commodity. The software layer, providing features such as infotainment, connectivity, active safety, autonomous driving, is becoming a buying factor and differentiator for customers. New features get added through OTA (over-the-air) updates, increasing or sustaining the value of the vehicles. Traditionally OEMs have been known for their hardware-first approach; however, these players are taking technology leaps to handle complex software development processes that support the aforementioned features. They have to set up robust and efficient back-end networks for OTA updates through secure channels using telematic solutions or technologies such as 5G. They also have the mandate to improve the range of electric vehicles by developing complex and effective battery management solutions and support applications such as robotaxis and ride-sharing. These developments and obligations will manifest changes in the software and electrical/electronic architectures as we advance into this decade.

OEMs should develop a robust, scalable, and flexible software and E/E architecture to deliver on the evolving requirements of the industry and customers.

Dynamics of Software and E/E Automotive Architectures

OEMs should develop a robust, scalable, and flexible software and E/E architecture to deliver on the evolving requirements of the industry and customers. The automotive software, electricals, and electronics market is expected to grow faster with new opportunities opening up along the value chain. As a result, significant changes are expected going forward.

Electrical/Electronics (E/E) Architectures

Traditionally, the automotive E/E architecture followed a distributed setup, with several ECUs (engine control units) playing a significant role. The distributed design has seen different generations of architectures, starting with generation one comprised of independent function-based ECUs. Generation two consisted of a group of ECUs dedicated to domains such as infotainment, chassis, or power train. However, there was limited communication among the domains for driving advanced functionalities such as adaptive cruise controls. The generation three architecture addressed this limitation. Generation three architecture uses a central gateway for collaboration between different domains of ECUs. This architecture is predominant currently. The inclusion of a central gateway is a departure from distributed design to a centralized one that foresees two different architecture generations for the future; essentially, generations four and five.

The fourth generation will have central domain controllers that would enable abilities to handle more intricate functions (e.g., active safety, user experience, and body control) and consolidate these functions for better cost optimizations. Centralizing the functions using domain controllers is the first step in evolving a vehicle to have advanced E/E architectures. For example, if one considers the active safety domain controller, it will receive inputs from sensors mounted around the vehicle and use them to create a sense of the surroundings. Based on this sense, the applications within the domain controller would decide for the actions to be taken - this could be to apply brakes or alert the driver. Domain controllers are an essential step towards creating a more software-defined vehicle. Domains controllers help in consolidating the functions that ECUs previously handled independently.

The fifth generation of architecture utilizes a combination of cross-domain controllers complemented by zone controllers. Zone controllers act as gateways in vehicles serving as hubs for power distributions and data connections. By handling the input-output (I/O) flows from sensors, actuators, and other peripherals, zone controllers provide an abstraction of the input-output from the compute, thus freeing up the domain controllers to focus on the applications that perform high-computing functions. As a result, domain controllers eventually achieve more consolidation. With the I/O abstraction from the compute function and existence of the high-speed network, it makes perfect sense to further consolidate the applications or software in the domain controllers onto cross-domain vehicle computers capable of dynamically sharing the workloads. This centralization and consolidation of the functions will help achieve cost and space optimizations, making it easier for OTA updates to unlock advanced functionalities in future timelines.

Software Architectures

The importance of software is continuously increasing for most players, as software is fast becoming the essential element for brand recognition. Software, as aforementioned, is becoming the factor for buying and product differentiation. Any software-related bugs or cybersecurity-related issues can cause vehicle recalls at the scale of millions. Thus, as the software complexity increases, OEMs are faced with the challenge of creating and adopting different and resilient software architectures. For most vehicle domains, horizontal stacks are expected to replace vertically integrated systems, reduce complexity and simplify the software update processes, and increase the reuse of the code modules. Horizontal stacking should also reduce the costs of software applications adaption.

Essentially, automotive software architectures will become a service-oriented architecture based on generalized computing platforms. Software developers should add new connectivity and AI solutions, operating systems, advanced analytics, and other relevant applications. Software is expected to move down the stack to be integrated communication with the sensors, actuators, and other hardware peripherals. This move should also drive further complexities and interdependencies in the form of data generation at a massive scale, requiring investments by the OEMs in data analytics and cybersecurity to remain competitive.

To develop the required new E/E and software architectures, OEMs will have to commit to significant investments, which could seem higher initially when compared to the investments on the current architectures. However, these investments would pay them off well by allowing greater reuse and reducing complexities, leading to greater market competitiveness and differentiation.