When Software Takes the Wheel: The Future of Automotive Architecture

Software dominates the vehicle platform

The software revolution in the automotive industry is well underway, with the number of software functions in vehicles constantly increasing. Historically, automotive electrical/electronic (E/E) systems and the corresponding architecture in vehicles were built on decentralized control units (ECUs), where each unit managed specific functions, tightly coupling hardware and software.

However, this landscape is rapidly evolving. The industry is shifting away from decentralized control units towards centralized systems where software takes on a more dominant role. Centralized virtual control units are expected to manage sensors and actuators, significantly reducing the number of microcontrollers in vehicles.

This transformation brings exciting opportunities but also unique challenges, particularly when considering compliance with the ISO 26262 functional safety standard. In this blog, we take a closer look at how this shift is impacting vehicle architecture and the implications for safety-critical systems.

New centralized E/E Architecture

New centralized systems in cars rely on integrated high-performance virtual control units (VCUs), which replace the traditional decentralized ECUs, each managing more or less individual functions. Shared calculation capability of the high-performance computer (HPC) enables the reduction of the large number of control units, making way for so-called zone control units (ZCUs). These ZCUs help simplify the vehicle network complexity in the car, further supporting the centralized architectures and enhancing the separation between software and hardware.

Zone control units bundle the functions in a localized sub-area of the vehicle (e.g. control functions or data management tasks) and are connected to the main control unit, the HPC, via Ethernet to ensure high-speed data transfer.

Software takes the wheel!

In previous aka traditional vehicle design, the focus was on so-called signal-oriented architecture, where each function (at the vehicle level) required an individually assigned ECU. In recent years however, this approach led to ‘wild growth’ of the ECUs per function, as cars began to offer more and more features and provide more advanced driver assistance systems (ADAS).

Modern centralized architectures move away from signal-oriented systems, adopting a service-oriented approach instead. The focus now is on the system and software functions, which ultimately shape the entire vehicle architecture, both in terms of software and hardware.

The scope of the architecture in software-defined vehicles comprises:

• Applications (classic apps, AUTOSAR apps, ADAS apps etc.)
• System functions (manage the in-vehicle software)
• Basic software (operation system & infrastructure for system functions)
• Framework (board support & startup to integrate different layers)

Strategic Shifts in Automotive Companies Amid Software Dominance

The new shift is also having an impact on how companies operate. Some OEMs have founded dedicated car software subsidiaries to develop their vehicle operating systems and other vehicle-specific solutions.

Alternatively, it also makes sense to outsource software-specific solutions to external providers, as it enables access to external expertise that drives the development of car operating systems, so to speak. In any case, transforming the entire company into a software-centric organization would be an ultimately difficult task for any OEM, particularly as the company’s own traditional culture would have to become more flexible while achieving set goals would take considerably more time.

How will the functional safety and quality requirements for vehicle software be met?

Shifting from organizational to technical aspects, there will still be system- or vehicle-level requirements. However, at the component level, the emphasis will increasingly be on software requirements. The required system functions, which in turn are mainly implemented through software, will dictate requirements, architecture, integration, and verification phases.

Dependent Failure Analysis (DFA)

The centralization of systems and hardware introduces a higher proportion of shared resources. This means that a special focus must be placed on the Dependent Failure Analysis (ISO 26262). In centralized architectures, shared resources such as the HPC or ZCU handle multiple functions. In such cases, it’s important to address common cause failures, where both, the monitoring and monitored functions, are subjected to the same event or cause. The required independence or freedom from interference shall be considered and achieved by the design of the architecture.