For decades, a car's electrical architecture was mostly a wiring diagram. Add a feature, add a box: a new electronic control unit, a new harness, another line on the bus. SDV architecture breaks that habit. In a software-defined vehicle, features are no longer bolted to dedicated hardware, so the architecture has to be designed around software that keeps changing for years after the car leaves the factory.
SDV architecture is the way a software-defined vehicle organizes its compute, networking, and software so that features are defined in software and decoupled from the hardware that runs them. Instead of one control unit per function, a few high-performance computers host many functions, a high-speed network carries data between them, and a software platform lets those functions be validated, configured, and updated over the air. The hardware becomes a stable base; the value moves into software that ships and improves continuously.
This guide covers the structural side of SDVs: the layers, the common patterns, and the engineering-data problem the new architecture creates. For the wider picture of what an SDV is and why programs stall, start with our software-defined vehicles guide and the software-defined vehicle execution gap.
Traditional vehicles grew one electronic control unit at a time. Each function got its own box, its own supplier, and its own slice of the network. That worked while functions were independent and mostly mechanical. It stops working when a hundred functions interact in software and every new feature adds another node to an already tangled harness.
Software-defined vehicle architecture answers this by consolidating compute. Rather than scattering intelligence across dozens of small controllers, it concentrates it into a handful of powerful computers, then treats the rest of the car as sensors, actuators, and zones that feed them. Fewer, more capable computers mean shorter wiring, more headroom for new software, and one place to update behavior instead of many.
It helps to read an SDV as four stacked layers. Each one decouples something that used to be fused.
Compute. High-performance computers replace the sprawl of single-purpose control units. A function no longer needs its own hardware; it runs as software on shared compute, alongside others.
Network. A high-speed backbone, usually automotive Ethernet, carries data between computers and zones. Communication moves toward a service-oriented model, where functions publish and subscribe to data rather than being hard-wired point to point.
Software platform. An operating system, middleware, and a hardware abstraction layer sit between the applications and the silicon. This is what lets the same application run across hardware revisions and model years, and what makes an over-the-air update safe to ship.
Applications. Vehicle functions live here as software, configured per variant and market, updated across the vehicle's life. Differentiation happens in this layer, not in the sheet metal below it.
Most programs sit somewhere on the path from distributed to zonal. The three patterns below mark the route, and most real vehicles are a mix.
| Pattern | How compute is organized | The trade-off |
|---|---|---|
| Distributed (classic) | One control unit per function, wired point to point | Simple per function, unmanageable across hundreds of them |
| Domain | Functions grouped by domain (powertrain, chassis, ADAS, infotainment) into domain controllers | Fewer boxes and clearer ownership, but the software is still bound to its domain |
| Zonal plus central compute | Controllers placed by physical zone, wired to a few central high-performance computers | Shortest harness and true software-hardware decoupling, but the whole product depends on getting the data model right |
The direction of travel is clear: toward zonal wiring and centralized compute, because that is what makes software-hardware decoupling and over-the-air updates practical. The cost is that the architecture stops being something you can read off a diagram and becomes something you have to manage as data.
Beneath the layer diagram, the network is where much of the real engineering happens. The backbone is automotive Ethernet, often with time-sensitive networking (TSN) to guarantee that critical messages arrive on time, while service-oriented protocols such as SOME/IP let functions discover and subscribe to each other's data instead of being wired point to point. Classic buses do not disappear: CAN FD and LIN still connect sensors and actuators at the edges, now aggregated through zone controllers rather than run all the way back to a central box. The result is a mixed network where a single function's data may cross Ethernet, a service interface, and a legacy bus before it is complete.
Centralizing compute also concentrates risk, so safety and security move to the front of the architecture. When several functions of different criticality share one computer, the platform has to guarantee freedom from interference, usually through a hypervisor or a partitioned operating system that isolates a safety-critical function from a lower-criticality one. Functional safety under ISO 26262 and cybersecurity under ISO/SAE 21434 stop being late-stage checks and become architectural constraints: every over-the-air update has to be delivered securely and stay traceable to the requirement and hazard analysis behind it. That traceability only holds if the requirements, functions, software, and tests behind a safety case are connected rather than scattered, which is the same thread this guide keeps returning to. We cover the compliance side in our guide to ISO 26262 and ASPICE compliance.
When you decouple software from hardware, you also decouple a function from any single box you could point at. A feature now spans a requirement, a piece of software, a set of signals, one or more computers, a physical zone, and a stack of variants. No one artifact tells the whole story, and the tools that hold each piece were never designed to talk to each other.
That is where SDV programs quietly lose control. A change to one function ripples across domains that no single engineer owns, and tracing a requirement through software and signals to the hardware that runs it becomes a manual hunt across disconnected systems. This is the same drift we describe in model-based systems engineering: the architecture model is right the day it is drawn and wrong the moment the software moves on. A good SDV architecture on paper is worth little if the data behind it cannot be kept coherent.
The fix is not another tool that holds a copy of the architecture. It is a connected model that links the artifacts the architecture spreads across, so a function can be traced end to end no matter how many systems it touches. That means requirements, functions, software versions, ECUs, signal and bus communication, parts, and tests resolved into one navigable structure rather than a pile of exports.
This is what SPREAD's platform is built to do. It connects the systems that already hold your product data, PLM, ALM, signal databases, and the ECU and network descriptions, then maps them onto a prebuilt Product Ontology: years of refinement on how requirements, parts, functions, software versions, tests, and traces relate, with your variants and programs extending it. Filled with your data, that ontology becomes a Product Knowledge Graph, one model a person or an AI agent can question and trace back to the source. The SPREAD data documentation lists exactly the SDV-relevant inputs it maps, from ECUs and bus communication to functions, requirements, and diagnostics, and connectors map each system in place, so teams keep working in the tools they already use.
With the architecture on one model, engineers can navigate connected functions, components, and software in Product Explorer and see the impact of a change before it ships. The economics follow: on the platform page, a European Automotive Group reports that errors caught at architecture review cost around 1,000 times less than the same errors found in the field, worth more than 20 million euros a year on the software-defined vehicle cost curve, and a global Tier 1 supplier runs one data model across six OEM customers. That is what a coherent SDV architecture buys you: not a prettier diagram, but the ability to change software fast without losing the thread to the hardware underneath.
FREE REPORTThe Engineering Intelligence Index 2025How engineering teams are coping with software-defined complexity, and where the leaders pull ahead. Survey data and benchmarks.Get the report →SDV architecture is the way a software-defined vehicle organizes its compute, networking, and software so that features are defined in software and decoupled from the hardware that runs them. Instead of one electronic control unit per function, a few high-performance computers host many functions, a high-speed network carries data between them, and a software platform lets those functions be configured per variant and updated over the air across the vehicle's life.
Domain architecture groups functions by their domain, such as powertrain, chassis, ADAS, or infotainment, into a controller per domain. Zonal architecture places controllers by physical location in the vehicle and wires them to a few central high-performance computers, so software is no longer bound to a domain and the harness gets much shorter. Domain designs reduce the number of boxes; zonal plus central compute goes further and truly decouples software from hardware, which is what makes broad over-the-air updates practical.
Centralizing compute lets many functions run as software on a few powerful computers instead of on dozens of single-purpose control units. That shortens the wiring harness, leaves headroom for new features, and creates one place to update behavior rather than many. Most importantly, it decouples software from the hardware, so functions can be improved and shipped over the air without touching the physical car.
You keep traceability by connecting the systems that hold the architecture, rather than storing another copy of it. When requirements, functions, software versions, ECUs, signals, parts, and tests are resolved into one connected model, a function can be traced end to end and the impact of any change can be seen across domains before it ships. Without that connected model, a function is scattered across disconnected tools and traceability has to be rebuilt by hand every time.
A software-defined vehicle is only as strong as the model behind its architecture. Get the data coherent, and the architecture stops being a diagram you defend and becomes a product you can keep changing.
Want to see your SDV architecture on one connected model? Get started with SPREAD.