Is the Vehicle Now Defined by Software? Domain Architecture and the SDV Transformation

Electric Automobile Technologies
Creation: 14 October 2026

An architecture that reduces more than a hundred control units to a few zonal controllers means a car's identity is now built from code, not steel.

Share This Page

Yes: the behavior, features, and performance character of the modern automobile are now defined primarily by software. This transformation, known as the software-defined vehicle (SDV), moves the vehicle's electronic architecture from stacks of ECUs to domain and zonal controllers, separating hardware from software and reshaping everything from wiring weight to OTA updates.

Highlights

Today's vehicles 100 or more control units; new architectures aim to reduce this number by up to 20% .
Domain architecture organizes by function, zonal architecture by physical location.
In the zonal topology, CAN XL (up to 20 Mbps) and high-bandwidth backbones such as gigabit Ethernet are used.
OTA updates are a core SDV capability made possible by hardware-software decoupling.
The transition is gradual: the first area is the body domain; ADAS, powertrain, and chassis may remain in the existing structure for longer.

What Exactly Is a Software-Defined Vehicle?

The definition is clear: a software-defined vehicle is a vehicle whose functionality and behavior are determined primarily by software rather than hardware. In a traditional car, a feature was defined by a hardware component built specifically for that function; in an SDV, the same hardware can take on different functions through the software running on it. Even after the vehicle is sold, new features can be added, behavior can be calibrated, and errors can be fixed remotely.

Today's E/E architectures consist of 100 or more control units; next-generation structures deliver savings of up to 20% in the number of control units and up to 10% in materials and hardware.
Bosch Mobility, E/E architecture assessment

The figures in this sentence summarize the scale of the transformation. The problem is not only the number of control units: each ECU brings its own wiring, its own software stack, and its own validation burden. The SDV vision is to transform this scattered structure into a system in which software can manage everything in a single consistent layer. And this requires rethinking the electronic architecture from the ground up.

From ECUs to Domain Architecture: Grouping by Function

The era when every small function in a car had its own electronic control unit (ECU) made wiring harnesses unmanageable. Domain architecture was the first systematic answer to this: it organizes vehicle electronics into major functional areas such as ADAS, infotainment, powertrain, body electronics, chassis, and safety. Each domain typically has its own processor, software stack, communication interface, sensors, and actuators, and is managed by a domain controller.

This structure brought significant simplification compared to ECU chaos. However, as the SDV goal grew, the limits of domain architecture emerged. In particular, the sensor data generated by autonomous functions pushed the bandwidth of classic CAN networks to their limits. In addition, each domain carrying its own computing resources kept the wiring harness complex and made it harder for software to scale across the vehicle.

Zonal Architecture: Organization Shifting from Function to Location

Zonal architecture reverses the logic: it groups electronics not by function but by physical location in the vehicle. The vehicle is divided into zones such as front left, front right, rear left, rear right, and cabin; in each zone, a zonal controller gathers the sensors, actuators, and power distribution in that region and communicates with central high-performance processing platforms.

Feature	Domain architecture	Zonal architecture
Organizational principle	By function (powertrain, ADAS, body...)	By physical location (front left, rear right...)
Processing resources	Domain-specific processing	Consolidated central/distributed processing
Wiring	Complex, long wiring harness	Reduced wiring and weight
Number of ECUs	A large number of ECUs	Few zonal controllers + central computer
Software flexibility	Difficult to scale for SDVs	High software flexibility

The gains are tangible and measurable: wiring harness weight drops, point-to-point connections decrease, and the effort required for vehicle architecture and system validation is simplified. More importantly, sensor and actuator designs become independent of the central processing node; thus, hardware and software update cycles decouple, and a single sensor design can be used across multiple vehicle generations.

What Does a Zonal Controller Do? Task Distribution and Its Relationship with Hardware

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

The key to zonal architecture is the zonal controller, which is responsible for connecting numerous actuators and sensors to the central processing ECU. This controller is not merely a data collection box; it can run real-time control loops on its own, manage the devices in its zone, and send filtered, prioritized traffic to the backbone. According to an engineering assessment from TI, the zonal module's MCU must offer high real-time performance, large memory, virtualization support for different ASIL levels, high-speed communication to the backbone, and many low-cost edge interfaces such as CAN FD and LIN.

How is power distribution being decentralized?

In domain architecture, power is distributed from central power distribution boxes containing fuses and relays. In the zonal structure, distribution becomes decentralized: a single power harness is run from the battery to the zone, and the zone module shares power among the modules in that region. Short power cables directly mean weight and cost savings. In addition, semiconductor-based smart fuses replace traditional fuses; high-side switches with I²t characteristics provide less fuse variability and more optimized cable cross-sections. A smart power distribution box consisting of an MCU, high-side switches, and transceivers becomes a unit configured via software: the same box can be used in every zone, adapted according to the load.

The decoupling of physical and logical I/O

A zonal module reduces wiring complexity by consolidating the logical input/output functions of multiple ECUs in one place, while the physical locations of sensors and actuators are preserved. A step further, end devices become "smart": local circuitry maintains state information and runs fault diagnostics. Simplified protocols like CAN FD Light can even eliminate the need for a separate MCU in some end nodes. This decoupling, where hardware stays fixed and the task is defined in software, is the engineering backbone of the SDV.

Data Bus in a Zonal Vehicle: Bandwidth, Timing and Cybersecurity

Sensor fusion and AI workloads make it mandatory to build the zonal topology on high-bandwidth backbones: PCIe, up to 20 Mbps CAN XL, reaching data rates of, while maintaining compatibility with existing CAN, and gigabit Ethernet. The real challenge goes beyond bandwidth: it lies in timing; short control messages, ADAS sensor data and infotainment traffic carry very different latency, jitter and synchronization requirements. As rough figures: millisecond-level latency targets apply for audio, and microsecond-level for powertrain and chassis control.

To carry these different traffic classes over a single network, Ethernet-based Time-Sensitive Networking (TSN) emerges as the solution. Standards such as time synchronization (IEEE 802.1AS), time-sensitive traffic shaping (802.1Qbv), express traffic (802.3br), frame pre-emption (802.1Qbu) and redundancy (802.1CB) provide deterministic latency guarantees for critical data. On the safety side, ISO 26262 support, redundant communication paths, safety partitioning and fault detection are decisive; on the cybersecurity side, the ISO/SAE 21434 standard, UNECE regulations and low-level encryption-authentication mechanisms like MACsec are key. Since zonal architecture centralizes networks, Ethernet-based attack methods also become applicable; the collapse of the input-processing separation concept in the event of a security breach is a risk that must be assessed individually.

How Does Hardware-Software Decoupling Make OTA Updates Possible?

The OTA update is the first feature that comes to mind in most SDV discussions, but it is not a capability on its own; it is a consequence of architecture. Seamless updates cannot be provided unless software is decoupled from specific chips through the hardware abstraction layer (HAL) and vehicle functions are divided into independent, reusable, loosely coupled services (service-oriented architecture, SOA). Decoupling also encompasses isolating software at different safety levels from one another.

The concrete meaning is this: with zone architecture, OTA/FOTA updates and a constant cloud connection, high-level software maintenance control passes to the manufacturer, while real-time control loops can be shifted to the zone modules. Fine adjustments, such as powering down unused modules in electric vehicles, also become easier in this structure. Ultimately, electric vehicle software is more than an update channel; it is the definition layer that determines the vehicle's features, safety systems and performance character. The car begins to resemble a distributed data center on wheels; the value chain rests on software, processing power and system architecture.

How Fast Will the Transition Be, and Is Zonal Architecture Alone Enough?

The transition will be gradual. The body domain, because it contains many distributed actuator and sensor ECUs, will be the first area to move to zone architecture; the migration of ADAS, powertrain and chassis control may take longer due to their safety-critical nature. The evolution seen in the MCAL, BSW and application layers since 2017 shows that this is not merely a technical project but an industry-wide change in mindset.

A balanced reading is also necessary. Zonal architecture physically reorganizes the vehicle; the logical and software side (SOA, HAL, cybersecurity) must be solved separately - merely rearranging the wiring does not make a car software-defined. Market size estimates also vary significantly depending on scope definitions; different figures for the E/E architecture market stem from differences in what is counted (only processing platforms, or all distributed electronics). It should also not be forgotten that the semiconductor and solution providers, as parties to this transition, naturally have a stake in it.

The result is a clear engineering balance: the software-defined vehicle is possible only through the simultaneous existence of a new hardware organization based on domain and zonal controllers, decoupled software layers, and a deterministic, safe data backbone. The OTA update is the most visible fruit of this integrated structure; the real revolution lies in the vehicle's hardware delegating its job description to software.