The software-defined vehicle is becoming one of the most important architectural shifts in the automotive industry, changing how vehicles are designed, developed, updated and monetised across their lifecycle.
The move toward SDVs is about more than adding new software features to a vehicle. It requires a fundamental rethink of the vehicle's electrical and electronic architecture, from legacy distributed ECUs to more centralised, scalable and software-led platforms.
The market data supports the urgency. McKinsey's 2026 automotive software and electronics outlook states that the global automotive software and electronics market could grow at a 4.5 percent CAGR and reach $519 billion by 2035. McKinsey also notes that the automotive software and electronics market is transitioning toward zonal and central computing architectures that enable more scalable SDVs, over-the-air updates, enhanced connectivity and generative AI integration.
This shift is already underway. According to IoT Analytics' Software-defined Vehicles Adoption Report 2026 analysis, 45 percent of surveyed automotive OEMs and suppliers rank the transition to SDVs as their number one strategic priority. The same research found that more than 90 percent of automotive OEMs are committed to zonal architecture, with 80 percent already migrating and a further 11 percent confirming firm plans to do so.
So, what is the difference between domain and zonal architecture, and why is the industry moving so quickly toward zonal compute?
What is domain architecture?
Domain architecture is a vehicle E/E architecture that organises electronic control units around functional areas, or "domains". Typical domains include:
- ADAS and autonomous driving
- Infotainment and connectivity
- Body and comfort
- Powertrain
- Chassis and vehicle dynamics
In a traditional distributed architecture, vehicles can contain dozens or even more than 100 ECUs, each responsible for a narrow function. This creates complexity across wiring, software integration, diagnostics, validation and lifecycle management.
Domain architecture reduces this fragmentation by consolidating related functions into more powerful domain controllers. Instead of every function having its own ECU, a domain controller manages multiple functions within the same area of vehicle operation.
For OEMs, this is an important step toward the software-defined vehicle because it helps reduce ECU sprawl, simplifies development and creates a clearer separation between software and hardware. However, domain architecture still groups functions by what they do, rather than where they are located physically in the vehicle.
That distinction is where zonal architecture becomes important.
What is zonal architecture?
Zonal architecture organises vehicle electronics around physical zones of the vehicle, rather than functional domains. A zone controller may manage sensors, actuators, power distribution and data communication for a physical area such as the front-left, front-right, rear-left or rear-right of the vehicle.
In a zonal model, local devices connect to the nearest zone controller, which then communicates with a central compute platform or high-performance computer. This allows the vehicle to reduce long wiring runs, simplify harness design and create a more scalable foundation for software updates.
NXP's automotive zone controller platform describes a zonal development ecosystem for OEM proof-of-concept work, designed to prototype vehicle-level zonal architecture with an Ethernet backbone and support features including PDU gateway, PDU tunnel, DDS application, TSN features and performance benchmarking.
Automotive IQ has also covered this transition in How Software-Defined Vehicles are Redefining Architecture and Transforming Field Service Actions, which explains how centralised high-performance computers and zonal gateways can help support a more software-led vehicle platform.
Domain vs zonal architecture: the key difference
The simplest way to understand the difference is this:
Domain architecture organises by function. Zonal architecture organises by physical location.
In a domain-based vehicle, braking, steering, ADAS, infotainment and body functions may sit within separate functional domains. In a zonal vehicle, sensors and actuators in one area of the vehicle connect to a local zone controller, regardless of which function they support.
This matters because software-defined vehicles require high bandwidth, reduced complexity and a more consistent platform for updates. As vehicles add more sensors, displays, ADAS features, connectivity services and electrified systems, the old distributed ECU model becomes harder to scale.
A 2026 academic survey describes the industry's evolution as a move from distributed ECU systems to domain-based, zonal and centralised computing platforms, supported by technologies including service-oriented software architectures, middleware, automation pipelines, AI mechanisms and cloud infrastructure.
Table: Domain vs zonal architecture
| Area | Domain architecture | Zonal architecture | Why it matters for SDVs |
|---|---|---|---|
| Organising principle | Groups electronics by function, such as ADAS, body, powertrain or infotainment | Groups electronics by physical vehicle zone, such as front-left, front-right or rear | Zonal architecture better supports scalable vehicle platforms and simplified physical layouts |
| Controller structure | Uses domain control units for specific functional areas | Uses zone controllers connected to central or high-performance compute | Enables more centralised processing and software-defined feature delivery |
| Wiring approach | Wiring may still run across the vehicle to connect function-specific systems | Local devices connect to the nearest zone controller | Can reduce wiring complexity, harness length and weight |
| Software scalability | Improves on distributed ECU models but can still retain functional silos | Creates a more consistent foundation for software layers and OTA updates | Helps OEMs separate software development from hardware complexity |
| Diagnostics and service | Faults may be traced through function-specific domains | Faults can be isolated more easily by physical zone | Supports remote diagnostics, predictive maintenance and more efficient field service |
| Best fit | Transitional architecture for consolidating ECUs by function | Long-term SDV architecture for centralised compute and software-led platforms | Zonal architecture is increasingly seen as the backbone of the SDV |
Why OEMs are moving toward zonal architecture
1. Reduced wiring complexity and vehicle weight
One of the most frequently cited benefits of zonal architecture is the reduction of wiring harness complexity. In a distributed architecture, wires may need to run across the vehicle to connect ECUs, sensors and actuators. This adds weight, cost and manufacturing complexity.
Zonal architecture shortens the distance between devices and their nearest controller. This can help reduce harness length, improve packaging and support greater manufacturing efficiency.
This is especially important as electrification accelerates. The International Energy Agency's Global EV Outlook 2026 reported that electric car sales exceeded 20 million globally in 2025, representing one in four new cars sold worldwide. As EV volumes rise, reducing vehicle weight and improving efficiency become even more important for range, cost and performance.
2. Better foundation for OTA updates
The value of an SDV depends on its ability to improve after production. Over-the-air updates, new feature deployments, security patches, diagnostics and performance improvements all require a more software-native architecture.
A zonal architecture, combined with central compute and middleware, creates a more consistent software platform across the vehicle. This can make it easier for OEMs to update functions, manage variants and deliver improvements without relying on physical service interventions.
IoT Analytics found that vehicle-to-cloud integration is one of the four key dimensions of the SDV transition, with OTA updates identified as the top cloud integration role by 73 percent of OEMs and 71 percent of suppliers in its 2026 SDV adoption analysis.
3. Greater scalability across vehicle platforms
A key challenge for traditional OEMs is vehicle complexity. Different platforms, trims, markets and supplier systems can create a large number of software and hardware variants.
Zonal architecture can help create a more standardised hardware layout. OEMs can design a repeatable compute and zone-controller structure, then differentiate vehicles through software, features and services.
This is central to the SDV business case. If automakers want to launch new connected services, subscription features, AI-enabled functions and software-defined user experiences, they need a vehicle architecture that can scale across product lines.
4. Improved diagnostics and field service
Zonal architectures can also improve diagnostics by making it easier to identify issues within a physical zone of the vehicle. Rather than tracing a fault across a complex network of separate ECUs and wiring paths, service teams may be able to isolate problems more efficiently through zone-level diagnostics.
This also links to the long-term shift in field service. In an SDV environment, many issues may be resolved through software updates, remote diagnostics or predictive maintenance.
5. Support for AI-enabled vehicle functions
AI is becoming more important across ADAS, infotainment, predictive maintenance, cybersecurity, range estimation and personalisation. McKinsey's 2026 outlook states that operating systems and middleware could grow at a 16.2 percent CAGR from 2025 to 2035, while autonomous driving and ADAS software could grow at nearly 20% CAGR over the same period, reaching around $50 billion by 2035.
This matters because AI-enabled functions require faster data movement, greater compute capacity and more flexible architectures. Zonal and centralised platforms can help support this by consolidating processing power and reducing fragmented software dependencies.
The challenges of moving to zonal architecture
Despite the benefits, the transition from domain to zonal architecture is not simple.
OEMs must rethink software development processes, supplier relationships, validation methods, cybersecurity strategies and in-vehicle networking. A zonal vehicle may be simpler from a wiring perspective, but it can be more complex from a systems engineering perspective.
Key challenges include:
- Managing safety-critical functions across central and zone controllers
- Ensuring redundancy for braking, steering and ADAS systems
- Validating software across multiple hardware and software variants
- Building secure OTA update pipelines
- Integrating legacy supplier components into new E/E architectures
- Developing internal software expertise
- Balancing centralised compute with real-time processing at the edge
Cybersecurity is also a major consideration. As vehicles become more connected, updateable and software-led, the attack surface expands. OEMs must ensure that vehicle-to-cloud integration, OTA updates, APIs and in-vehicle networks are secure by design.
What this means for OEMs and suppliers
For OEMs, the move from domain to zonal architecture is not just a technical decision. It is a strategic decision about future competitiveness.
A successful SDV platform could help automakers reduce complexity, shorten development cycles, improve customer experience and create new revenue opportunities through software-defined features. However, the transition also demands major investment in software engineering, systems integration, cybersecurity and validation.
For suppliers, the shift is equally significant. Traditional component suppliers must adapt to an environment where value is increasingly created through software, compute platforms, middleware, sensors, zone controllers and system-level integration.
McKinsey notes that tier-one suppliers will need to align with OEMs' evolving requirements by helping shape zonal and central architectures, while investing in software development, generative AI integration and system-level expertise.
Conclusion: Zonal architecture is becoming the backbone of the software-defined vehicle
The transition from domain to zonal architecture marks one of the most important engineering shifts behind the software-defined vehicle.
Domain architecture has helped OEMs move away from highly fragmented ECU networks, but zonal architecture takes the next step by simplifying the physical vehicle architecture and enabling a more centralised, scalable software platform.
As SDVs become a strategic priority for OEMs and suppliers, zonal architecture will play a central role in reducing wiring complexity, supporting OTA updates, improving diagnostics, enabling AI-powered features and creating more flexible vehicle platforms.
For automakers, the question is no longer whether software will define the future of the vehicle. The question is whether their architecture can support it.