SDV Series Episode 2: From Domains to Zones

bv Carrie Browen

In our first blog post, we explored what defines a software-defined vehicle (SDV) and why it marks a turning point for the automotive industry. Now, we’re diving deeper into the architecture that enables SDVs. As the automotive industry shifts from hardware-centric designs to software-first platforms, a fundamental transformation is reshaping the vehicle from the inside out. But what exactly is changing in the vehicle’s architecture, and why is this shift so pivotal for the future of mobility?

To understand the journey toward fully realizing the SDV, it is helpful to look at the evolution of vehicle architecture and software integration. Keysight shares the view held by other industry leaders and consultancies, such as PwC, that the SDV evolution can be represented in levels ranging from Level 0 to Level 5, similar to the SAE framework for autonomous driving. The following table outlines the key levels of SDV maturity — from mechanically controlled systems to fully integrated, cloud-native ecosystems — highlighting how each stage builds upon the last in terms of architecture, capabilities, and business potential.

Why the Software Stack Is the Game Changer

As the industry advances along the SDV maturity curve, with many companies currently progressing from Level 2 to Level 3, or from Level 3 to Level 4, and leading players already operating at Level 4 and beyond, it becomes increasingly clear that software is no longer just a supporting element. It has become the central driver of innovation, competitive differentiation, and long-term value creation.

At the lower maturity levels, software typically enhances isolated functions. However, as vehicles evolve, software becomes the foundation of the entire vehicle experience, encompassing everything from core functionality and safety systems to user interaction and service delivery. Over-the-air (OTA) updates and modular software stacks enable continuous innovation, allowing automakers to roll out new features and improvements long after the vehicle has left the factory floor.

At the upper levels of maturity, vehicles begin to resemble digital platforms. They support app ecosystems, enable third-party integrations, and deliver highly personalized services. With real-time data at their core, these vehicles unlock predictive maintenance, usage-based insurance, and dynamic performance optimization. This shift also opens the door to entirely new business models, from feature subscriptions to data-driven services, all made possible by a robust, scalable, and service-oriented software architecture. This SDV platform is also the enabler to advanced safety and security capabilities, as well as for AI-based intelligent mobility concepts such as autonomous driving, robotaxi, and tele-driving.

The Legacy: Domain-Oriented Architecture

For many years, vehicles have been built using a domain-based architecture, where each functional area, such as infotainment, powertrain, body control, or ADAS, is managed by its own set of Electronic Control Units (ECU). These ECUs (sometimes +80 per vehicle) are tightly coupled to specific hardware and software, forming isolated domains.

This architecture relies on:

  • Multiple ECU domains: Each domain contains several ECUs dedicated to specific functions
  • Heterogeneous BUS systems: Communication within and between domains is point-to-point
  • Cross-car wiring: Signals often need to travel across the entire vehicle, resulting in complex and heavy wiring harnesses (+50kg coper wires)

While this approach allowed for a clear separation of functions, it also introduced significant complexity and limitations:

  • A high number of ECUs per vehicle, often with overlapping functionality
  • Each ECU requires its own controller and dedicated firmware
  • Redundant hardware and wiring, increasing weight and cost
  • Limited flexibility for software updates and feature expansion
  • High integration and maintenance costs due to fragmented systems

While domain-oriented architecture served the industry well in the past, it creates functional silos, limits scalability, and poses challenges for the software-driven future of mobility.

The Shift: Zonal and Service-Oriented Architecture

In contrast, zonal architecture reorganizes the vehicle’s electronics based on physical zones (e.g., front-left, rear-right) rather than functional domains. Each zone is managed by a powerful zonal controller that aggregates data from nearby sensors and actuators. These controllers are connected to a centralized High-Performance Computer (HPC) via high-speed, low-latency communication across the vehicle, like automotive Ethernet.

Protocols like CAN and LIN have historically formed the core of in-vehicle communication systems. However, as automotive networks evolve toward domain and zonal architectures, the limitations of these legacy protocols become apparent. Nowadays for SDV, 10BASE-T1S addresses this gap by offering a lightweight, cost-efficient Ethernet solution optimized for low-speed, high-node count applications — enabling seamless integration across ECUs and sensor networks. Enabling multipoint communication and supporting both deterministic and non-deterministic functions.

This hardware transformation is tightly coupled with a shift in software architecture — from function-specific implementations to a Service-Oriented Architecture (SOA). In SOA, vehicle functions such as navigation, climate control, or lane keeping are delivered as modular, reusable services that can be independently developed, deployed, and updated.

Key Components:

  • High-performance computers: Centralized compute units for software execution and real-time decision-making
  • Automotive Ethernet: Multipoint, High-speed, low-latency communication backbone with one TCP-IP
  • Localized wiring: Sensors and actuators connect to the nearest zonal controller, reducing cross-car wiring
  • Service-oriented software: Decouples software from hardware, enabling dynamic feature deployment and cross-domain communication and data sharing via standardized APIs

This shift to a zonal, service-oriented architecture brings a host of transformative benefits. By consolidating functionality into fewer, more powerful computing units, automakers can significantly reduce the number of ECUs in a vehicle. This not only simplifies the overall system architecture but also lowers costs and minimizes potential points of failure. The shift away from complex, cross-car wiring toward localized connections within physical zones leads to lighter vehicles and more streamlined assembly processes.

Centralized computing, supported by zonal architectures, lays the foundation for a more dynamic software environment, enabling rapid feature deployment and streamlined updates. This architecture also enhances scalability, making it easier to adapt core systems across different vehicle models and configurations. With modular, service-based software, development cycles become faster introducing CI/CD/CT workflow and agile enabling collaborative development, supporting continuous innovation and seamless integration of third-party services. Perhaps most importantly, this approach enables dynamic OTA updates, ensuring that vehicles can continue to evolve and improve long after they leave the production line.

Together, these advancements lay the groundwork for the software-defined vehicle, a platform that is not only intelligent and adaptable but also designed for continuous evolution in a rapidly changing mobility landscape.

Looking Ahead

This architectural shift is not just a technical upgrade — it’s a strategic transformation. Automakers must now embrace a new mindset: HW/SW separation with using commoditized HW and components, building platforms that are modular and scalable, secure and cloud-connected, and designed for agility and rapid iteration.

It’s not just about adding more software; it’s about reimagining the vehicle as a dynamic, updatable platform. In the SDV era, the software stack becomes the engine of innovation, differentiation, and long-term value. The future belongs to those who build for continuous evolution, where software defines not just features, but the entire customer experience.

In the next blog article of our SDV Series, we’ll explore the business challenges that come with the SDV transition and how organizations can actively navigate and shape this transformation to stay ahead.

Posted in UncategorizedTagged