Software-defined vehicle (SDV)

A software-defined vehicle (SDV) is a vehicle whose functions, features and customer value are primarily delivered through software rather than fixed at the factory by hardware. In an SDV, capabilities can be added, improved or removed after the vehicle is sold, typically through over-the-air updates. The hardware is designed with headroom and abstraction layers so that the software running on it can change over the vehicle’s lifetime.

The term describes a shift in engineering approach, not a single technology. Traditional vehicles distribute functions across dozens of fixed-purpose electronic control units (ECUs), each developed and frozen with its hardware. SDVs consolidate computing into a small number of powerful computers running a vehicle OS, separate software from hardware through middleware, and treat the vehicle as a platform that evolves after production.

What it is — and what it is not

“Software-defined” has become one of the most overstretched labels in the automotive industry, applied to everything from a new infotainment screen to a genuinely re-architected platform. That makes a working test useful. A vehicle is software-defined to the degree that its behavior can change materially after sale without touching hardware: new functions can be deployed to existing cars, safety-relevant systems can be corrected in the field, and the software organization ships on its own cadence rather than the model-year cycle.

By that test, a modern car is not an SDV merely because it contains a great deal of software — every car built in the last two decades does. Nor is a connected app store or a subscription menu sufficient. The distinguishing property is architectural: computing consolidated enough, and abstracted enough, that software becomes the primary axis of product development. Conversely, a vehicle does not need to be electric to be software-defined, although in practice most clean-sheet SDV platforms are EVs, because clean-sheet electrical architectures and clean-sheet propulsion tend to arrive together.

Tesla set the reference point. From 2012 onward it normalized full-vehicle over-the-air updates — including performance, driver assistance and safety-relevant changes — and demonstrated that a car’s capability at year five can exceed its capability at delivery. Much of the industry’s SDV investment since is an attempt to reach that operating model from a legacy starting position.

The technology stack

The SDV stack is easiest to read bottom-up. At the base sits the E/E architecture: the physical layout of computers, networks and power. The industry is moving from distributed ECUs through domain consolidation toward zonal architectures, where zone controllers handle local I/O and a few high-performance computers provide central compute. Fewer, more capable computers are what make lifetime software evolution economical.

Above the hardware run the operating systems — typically a mix of Linux, QNX and real-time kernels, separated by hypervisors where different safety levels share a chip. Middleware provides the abstraction layer: service-oriented communication, hardware abstraction and common services that let applications be written without knowledge of the specific ECU or sensor variant beneath them. The OEM’s vehicle OS bundles these layers with APIs, developer tooling and a cloud backend into one platform spanning its model lines. The OTA pipeline closes the loop, carrying new software to the fleet and telemetry back from it.

No layer of this stack is settled. Standards bodies, open-source projects such as Eclipse SDV, industry alliances such as COVESA, commercial suppliers and OEM-internal platform teams all compete for the same architectural slots.

The business model shift

The commercial logic of the SDV is that a vehicle stops being a product whose value peaks at the point of sale and becomes a platform with revenue potential across its lifetime. Features can ship as software: functions installed in hardware but activated on demand, one-time purchases, and subscriptions for connected services or advanced driver assistance. Fleet-wide software also changes the cost side — a defect fixed by an update campaign costs a fraction of a physical recall, and one software platform amortized across many model lines replaces per-model electronics development.

The revenue side has proven harder than early projections assumed. Buyers have resisted paying subscriptions for capabilities they perceive as part of the car, and several OEMs have publicly repositioned or withdrawn paid features after customer pushback. The more durable near-term gains have come from the cost side: faster defect resolution, reduced warranty and recall expense, and shared platforms.

The organizational shift

The hardest part of the SDV transition has been organizational, not technical. Traditional OEMs are structured around mechanical integration: functions specified by the OEM, implemented by tier-1 suppliers as black-box ECUs, and integrated late. An SDV requires the opposite — a large in-house software organization, continuous integration and deployment, and platform decisions made centrally rather than per component.

The difficulty is well documented. Volkswagen’s software subsidiary CARIAD became the sector’s most visible cautionary tale, with widely reported delays that pushed back flagship vehicle programs and triggered repeated restructurings. Across the industry, OEMs have cycled through strategies: building in-house, partnering with technology companies, buying access to a software-native company’s stack, or narrowing ambition to the layers where they believe differentiation lives. None of these has yet emerged as the settled model.

Regulation

Regulation now assumes vehicles whose software changes in the field. UNECE R156 requires manufacturers to operate a certified software update management system and to assess whether each update affects the vehicle’s type approval; it applies alongside UNECE R155 on cybersecurity management. Together they make the update pipeline itself a regulated system, not just a convenience feature. Data legislation adds a further dimension: rules such as the EU Data Act shape who may access the data a software-defined fleet generates, which bears directly on the business models built on that data.

State of play and what to watch

As of 2026, the direction is no longer contested — every major OEM has a centralized-architecture and vehicle-platform program — but execution is uneven. Software-native manufacturers ship fleet-wide updates routinely; several legacy OEMs now do so for their newest platforms while older architectures in the same showroom cannot. Chinese OEMs have compressed development cycles in ways that pressure incumbent timelines.

The open questions define the sector’s news flow: whether OEMs can sustain the cost of in-house platforms or consolidate around shared and open-source layers; whether feature-on-demand revenue materializes at scale; how quickly zonal architectures reach volume production; and whether regulators’ update and cybersecurity regimes keep pace with fleets whose behavior changes weekly. Those threads run through most entries in this wiki.