SDV 101: what actually makes a car software-defined

The phrase everyone uses and nobody defines

“Software-defined vehicle” (SDV) gets used for everything from a big touchscreen to full autonomy. The useful definition is narrower: a vehicle whose features are primarily delivered, differentiated, and updated through software — on hardware designed to be a stable, general-purpose platform.

The reference point is what happened to phones. A 2006 phone was a fixed-function device: the features it shipped with were the features it died with. The smartphone inverted that — stable hardware platform, an OS with APIs, features arriving as software for years after purchase. SDV is the same inversion applied to a much harder target: a safety-critical, decade-lived, real-time machine.

This post is the foundation for my virtual-car series: what’s changing in the car’s architecture, why, and how you can put your hands on it today for free.

Where cars are coming from: 100 computers in a trench coat

A modern conventional car contains dozens to over a hundred ECUs (electronic control units) — small embedded computers, each typically owned by a different supplier, each doing one job: one for the wipers’ logic, one for each door, one for the engine, one for the airbags. They talk over buses — CAN mostly, LIN for cheap peripherals, FlexRay and automotive Ethernet for faster domains — using signal databases as the contract (the .dbc files you meet in the virtual-car post).

This architecture wasn’t a mistake; it optimized for supplier modularity and per-unit cost. But it makes software change brutally expensive:

• A feature that touches five ECUs touches five suppliers’ codebases, five release cycles, five validation campaigns.
• Software is welded to hardware: you can’t update the logic without re-qualifying the box it runs on.
• The wiring harness that connects everything is among the heaviest, most labor-intensive parts of the car.

Where cars are going: consolidation

The E/E (electrical/electronic) architecture is consolidating in a well-documented progression:

The endpoint matters for software people: in a zonal architecture, zone controllers handle local I/O by physical location (front-left corner of the car), while the actual vehicle logic runs as software workloads on one or a few central high-performance computers — increasingly with hypervisors, containers, and a service-oriented middleware. At that point, a vehicle feature is a deployable software artifact, and the game changes to the one software engineers already know: APIs, CI/CD, over-the-air updates, observability.

The decoupling stack

For features to outlive hardware generations, software has to stop caring which sensor variant or which supplier’s ECU it runs against. That’s an abstraction problem, and the industry’s answer looks familiar:

Layer	Automotive instance	Analogy
Apps / features	Cabin comfort, ADAS behaviors, companion apps	Mobile apps
Vehicle API	COVESA VSS — a standard tree of vehicle signals (Vehicle.Speed, Vehicle.Cabin.Seat.Row1.Pos1.Occupant)	POSIX / Android SDK
Middleware / OS	AUTOSAR Adaptive, Android Automotive OS, vehicle runtimes (e.g. Eclipse KUKSA)	The OS
Signals & buses	CAN frames, SOME/IP services — the .dbc/ARXML world	Device drivers
Hardware	Zonal ECUs, HPCs, sensors, actuators	The chipset

The load-bearing row is the vehicle API. When an application reads Vehicle.Speed from a standardized signal tree instead of decoding bits at offset 8 of CAN frame 0x123, that application survives a sensor swap, a supplier change, and a platform generation. It can even run against a simulated vehicle — which is exactly what makes the virtual-car workflow in the rest of this series possible.

Try it today, in a browser: digital.auto

You don’t need an OEM job to touch this stack. digital.auto — an open industry initiative — ships a free playground where you prototype vehicle features against the VSS API in the browser: pick signals from the standard tree, write the feature logic in Python, run it against a simulated vehicle with a dashboard, and iterate in minutes.

The canonical starter exercise is a child-presence reminder: subscribe to seat-occupancy and ignition signals, detect “child still on the rear seat after the driver leaves”, trigger a warning. It’s a real UN-regulation-adjacent feature (child presence detection is entering Euro NCAP roadmaps), and in the playground it’s an afternoon of work — the entire feature is ~50 lines against the vehicle API, no CAN knowledge required.

That’s the SDV pitch in miniature: the feature logic was never the hard part; the access layer was. Standardize the access layer and feature development becomes fast, testable, and portable — the properties the rest of this series builds on with virtual ECUs, a real Android cockpit, and physics simulation.

What SDV is not

Worth stating, because the term gets stretched:

• Not autonomy. An SDV can be Level 0. Autonomy is one (demanding) workload; SDV is the platform underneath any workload.
• Not just infotainment. A big screen on a distributed E/E architecture is a conventional car with good marketing.
• Not “no more hardware constraints.” Safety-rated real-time control still exists; ASIL-rated functions still need certified paths. SDV moves the boundary between frozen and flexible — it doesn’t abolish it.

The honest one-line summary: SDV is the industrialization of change. Conventional vehicles optimized for shipping a fixed product; software-defined vehicles optimize for shipping changes to a product already on the road. Everything else — zonal architecture, vehicle APIs, virtual validation — is machinery in service of that one capability. How that machinery changes day-to-day engineering work is the subject of the next post: shift left, shift north.