The transition toward centralized E/E Architecture in SDVs is a major step for OEMs.

Software determines a steadily growing share of the value of a modern vehicle. Partnerships between software giants such as Google and NVIDIA and established OEMs are accelerating a transformation that, until recently, moved slowly. The destination is not in dispute: centralized electrical/electronic (E/E) architectures built around high-performance computers. The effort required to reach it is.

The feature that forces the architecture

The ability to receive new functions over the air after purchase, close security gaps and adjust calibrations without a workshop visit has become a central competitive differentiator. What has been standard in consumer electronics for over a decade requires a fundamental redesign of the E/E architecture in vehicle development – because the goal is nothing less than being able to update or replace every software component in the vehicle remotely.

Historically grown networks of more than a hundred distributed electronic control units (ECUs), connected over CAN, LIN and further communication buses, were never designed for that. Every signal has a fixed home, every communication matrix is negotiated up front, and every update touches a software stack somebody else owns.

Regulation is pushing in the same direction. The EU Cyber Resilience Act, the GDPR, and UN/ECE Regulations R155 (Cyber Security Management System) and R156 (Software Update Management System) all raise the transformation pressure on exactly this part of the vehicle.

The question every E/E program is asking

Transitioning Toward Centralized EE Architecture in SDVs

So the question is no longer “should we centralize”. Most organizations already know the answer is yes. The industry’s concept-level response is equally well known: concentrate compute on a small number of high-performance computers (HPCs), encapsulate functional clusters in domain-specific zones, replace the multitude of parallel communication buses with an Ethernet backbone, and abstract software from hardware so platform concepts scale and components can be reused.

Those architectural paradigms are not the hard part. The real question is:

How do you move to a centralized E/E architecture in SDVs without discarding the E/E estate you already have – and without bolting safety and security on at the end?

Because in practice, transformation almost never happens on a greenfield. Existing control units with long lifecycles, established communication protocols, and regulatory requirements for functional safety (ISO 26262) and cybersecurity (UN/ECE R155/R156) shape the solution space. In parallel, powerful open-source frameworks such as ROS 2, Google AAOS SDV and Eclipse S-CORE are emerging as credible competition to proprietary middleware stacks – while introducing new demands on governance and certification.

What follows is one coherent way to address all of this: a zonal E/E architecture with a centralized HPC, described at the level of the decisions that actually determine whether the concept survives contact with a series program.

Zonal architecture: a structuring principle, not just a topology

The move to a centralized E/E architecture needs a structuring principle that governs the physical topology as well as the allocation and distribution of software. A zonal architecture provides an established one. Instead of spreading compute across individual, highly specialized control units, tasks are bundled into meaningful zones – defined by physical proximity in the vehicle or by networking requirements – and the substantial compute workloads, particularly for functions with high performance demands, are consolidated on central HPCs.

A typical realization looks like this:

• Core Zone. One to n HPCs at the center, handling centralized control and data aggregation functions.
• Connectivity Zone. Communication components such as the telematics control unit (TCU) and intelligent antenna systems, providing 4G/5G, GNSS, WLAN and Bluetooth connectivity.
• IO Zone. Dedicated Zonal Control Units (ZCUs) abstract the sensor and actuator interfaces and decouple the physical periphery from the HPC core. This is also where signal-oriented bus systems such as CAN, LIN and FlexRay are abstracted away, so that the HPCs and their services communicate entirely service-oriented over modern IP-based protocols.
• Propulsion Zone. Powertrain and steering functionality with elevated functional safety requirements.
• DMZ. A de-militarized zone that isolates the services exposed to the internet from the rest of the vehicle network – a common and, in this architecture, load-bearing cybersecurity pattern.

The zonal controllers and HPCs communicate over an Ethernet backbone, which should be laid out redundantly for resilience. Beyond the obvious advantages of IP-based communication – service-oriented protocols with proper discovery and management functions, sophisticated quality-of-service handling, dedicated routing for load distribution, and considerably expanded cybersecurity options such as VLANs and network segmentation – the physical payoff is significant: only two Ethernet cables need to be routed through the entire vehicle, saving substantial space and weight.

For communication between the physical and virtual network participants, DDS (Data Distribution Service) or SOME/IP can be used. DDS is data-centric and follows a modern publish-subscribe model: communication partners do not need to know each other, and data flows are governed through topics and configurable quality-of-service parameters. That makes DDS more tolerant of topological change than SOME/IP. New network participants – and crucially, these can be virtual ones in the form of software containers or virtual machines – can largely be added or removed without manual rework of the network addressing.

Diagnostic communication, both in-vehicle and towards the cloud, runs service-based via SOVD through a SOVD gateway, enabling remote diagnostics over modern protocols such as HTTP on the basis of a standardized API.

Inside the HPC: hypervisor-based partitioning

The centralized E/E architecture on the HPC follows a virtualization approach, chosen for maximum scalability and functional breadth. A type-1 hypervisor partitions the available hardware resources into isolated virtual machines (VMs). These VMs can run different operating systems and, more importantly, carry different ASIL classifications, because the hypervisor guarantees Freedom from Interference (FFI).

In a typical allocation, one safety-relevant VM handles control tasks on the basis of AUTOSAR Adaptive or an open-source middleware, while another optionally provides an Android Automotive OS (AAOS) runtime for infotainment and GUI-centric services. The DMZ is realized as its own VM, fully isolated from the vehicle-side network. Access to the extranet (internet) and the intranet (vehicle LAN) is granted through precisely definable, service-level firewall rules. Additional mechanisms such as NAT, which conceals the local IP addresses, or reverse proxies, which conceal the local service names, can be implemented at the same point.

The architecture scales in two directions at once: with the hardware of the HPC platform (number of CPU and GPU cores, RAM) and with the allocation of virtual machines, and therefore of functions. A particularly powerful HPC can be replaced by several less powerful ones simply by distributing the VMs across them, if that is preferable for cost or packaging reasons. The concept is largely hardware-agnostic, which is what makes a consistent software platform across different vehicle and control unit variants realistic.

The hypervisor enforces isolation at the level of memory and time-slice management and prevents a fault or a security incident in one VM from propagating to another – a precondition for ISO 26262-compliant development.

The legacy question: ZCUs as protocol bridges

The zonal architecture is technologically convincing for many use cases. In development practice, though, one question arises immediately, and hardly any vehicle project can avoid it: what happens to the existing E/E heritage?

Communication buses such as CAN, LIN and CAN FD are deeply embedded in nearly all current vehicle projects. Control units with fixed communication matrices, long certification cycles and supplier-owned software stacks cannot be replaced at short notice. For the overwhelming majority of vehicle projects, a complete redevelopment remains the exception.

In the architecture described here, the ZCUs in the IO Zones take on a bridging role and act as intelligent protocol translators. Existing control units continue to communicate over their native buses – CAN, LIN, FlexRay or others – while the ZCU republishes that data service-based over DDS on the Ethernet backbone. From the HPC’s perspective, all signals appear as one uniform, IP-addressable data stream; the heterogeneity of the periphery stays invisible inside the HPC core.
That is what makes the transition incremental rather than disruptive. Legacy control units can be retained inside a running series development process and replaced step by step with HPC-native functions, as lifecycles or functional extensions require – or permit – it.

There is a second benefit, and in a platform program it may be the larger one: variant management. ZCUs can be configured relatively freely in terms of the number and type of supported communication interfaces, without requiring changes to the HPC software stack. Different vehicle derivatives with differing sensor and actuator equipment can therefore be covered by a single platform architecture, which reduces development and validation effort considerably.

Safety and security, designed in rather than retrofitted

The zonal architecture plays to its strengths not only in topology, but in how safety and security requirements can be anchored architecturally instead of being inserted into existing structures after the fact.

Functional safety

HPCs of modern SDV platforms provide dedicated safety cores that execute safety-relevant monitoring functions in parallel to the main CPU. Combined with the hypervisor approach, this yields a clean separation: safety-relevant control functions run on the safety cores or in a dedicated VM that is isolated in both time and memory, while non-safety-critical functions run in separate partitions. This partitioning prevents faults in non-safety-relevant VMs from radiating into safety-critical functions – the central principle of Freedom from Interference under ISO 26262.

Cybersecurity

The DMZ hosted in the central HPC takes a key role in the vehicle’s security concept. As an independent, isolated VM it forms the single controlled transition point for inbound data connections. Firewall, intrusion prevention and deep packet inspection (IPS/DPI) functions are operated inside it. This architectural principle mirrors the regulatory requirements of UN/ECE R155 (Cyber Security Management System, CSMS) and R156 (Software Update Management System, SUMS) – not as a compliance add-on, but as the structure the regulation implicitly asks for.

Open source in the SDV stack: what is actually ready

The trend points clearly toward open-source software. The SDV ecosystem of the Eclipse Foundation alone already comprises more than 40 projects, from an ASIL-D certified RTOS to S-CORE, a direct competitor to AUTOSAR Adaptive. The middleware layer is one of the most consequential places to make that call, and three candidates dominate the conversation:

• ROS 2 / Apex.OS. Originally from robotics, ROS 2 has established itself as a flexible middleware base in the vehicle domain as well. Apex.AI developed Apex.OS as a production-ready variant whose core runtime, Apex.Grace, is certified by TÜV Nord according to ISO 26262 as a Safety Element out of Context (SEooC) up to ASIL-D. Deterministic execution, zero-copy communication and an integrated UDS diagnostic layer are its main advantages. Toyota (Arene platform), ZF and Volvo Group are among the confirmed users.
• Eclipse S-CORE. The Safe Open Vehicle Core project addresses safety-relevant open-source middleware for ADAS, body and chassis functions. It is carried by more than 50 contributors, including BMW, Mercedes-Benz, Volkswagen, Bosch, ZF, Qualcomm, Qorix and FEV.io. Release 0.6 (February 2026) delivered a first reference implementation. Alongside the software components, S-CORE is building a fully ISO 26262-compliant development process for open-source software. Users can either certify their own S-CORE-based functions up to ASIL-B on the basis of the certifiable OSS artifacts, or purchase a certified stack from commercial providers.
• Google AAOS SDV. Google is extending Android Automotive OS to non-safety-critical vehicle functions, with open-sourcing announced for the course of 2026. Safety-critical functions such as braking and steering are currently out of scope, which makes AAOS SDV complementary to safety stacks rather than competing with them – although that may change. Renault will deliver the first series vehicle on this basis with the Trafic E-Tech (start of production at the end of 2026).

The strategic value of open source goes beyond functionality. Dependency on individual software vendors is structurally reduced by community-carried stacks. License and maintenance costs, which can be considerable for proprietary middleware platforms, can be expected to be lower given the higher level of competition. And open source code secures the long-term extensibility of the platform – independently of vendor strategies or the product lifecycles of individual suppliers.

None of that is free. Using open-source software in series development requires active governance: a strategy for handling update increments, a willingness to participate in the developer community to ensure continued development in the directions you depend on, and a deliberate integration strategy for OSS components within your own software ecosystem.

What stays with your team

Summary: Centralized EE Architecture in SDVs

The centralized E/E architecture transformation in the SDV context can be addressed systematically with a zonal approach: type-1 hypervisor-based VM isolation on the HPC for safety and security, a dedicated DMZ VM as the single point of exposure to the internet, DDS as a flexible publish-subscribe protocol, and ZCUs for protocol encapsulation and legacy integration. Open-source middleware frameworks open up new opportunities – and new obligations – in the way automotive software stacks are built and maintained.

This insight is based on the technical article “Navigation der Transformation hin zu zentralisierten E/E-Architekturen in SDVs” by Dr.-Ing. Christopher Kugler (Lead Solution Manager SDV, FEV.io GmbH), Dr. Dirk Macke (Chief Software Architect, FEV.io GmbH) and Dr.-Ing. Thomas Huelshorst (GVP Intelligent Mobility & Software, FEV Group GmbH), published in ATZextra.

Let’s talk

Interested in what a centralized, zonal E/E architecture would mean for your program – legacy integration, safety and security concept, or open-source strategy? Reach out to Christopher Kugler, Lead Solution Manager for Software-Defined Systems (FEV.io), at solutions@FEV.io