Your EV is now a software platform

For most of automotive history, a car was finished the day it left the factory. The engine, the gearbox and the trim you drove off with were what you kept, give or take some wear. Wanting more meant buying a newer model.

That's changing. A modern vehicle keeps getting better after you buy it: new features and fixes arrive while it sits in your driveway. How come? The car is built around its software, and the industry has a name for it: the software-defined vehicle, or SDV.

I see it every few weeks in my Tesla. I park it one evening, and by morning, there's a release-notes screen waiting, sometimes for something I didn't know the car could do.

That's the easy half. What feels like magic from the driver's seat is serious engineering for the people writing the software. It is also a business shift: carmakers are no longer just selling a machine once, but maintaining a digital relationship with the customer for years. Let's look at both sides.

What "software-defined" actually means

In a software-defined vehicle, the features you experience are separated from the hardware that delivers them. The hardware sets the ceiling: a motor can only be so powerful, and a camera can only see so far. But what the car does with that hardware is increasingly written in code, and that code can be changed across the car's whole life.

Tesla made the idea ordinary by treating the entire car as a highly integrated, centrally managed software product. I've watched mine pick up features through an over-the-air (OTA) update without ever visiting a service centre. Recent updates are a useful reminder that the car is not frozen at purchase: release notes can bring anything from interface changes to safety-related instructions, new convenience features or small behaviour changes that make the car feel different the next morning.

It's no longer a one-brand story, though. Volkswagen built a dedicated software division to chase the same goal. Polestar and Rivian design their cars around over-the-air updates and connected services. Nearly every large manufacturer now has an SDV roadmap. The reason is simple: once a car can improve after it's sold, the relationship between maker and driver doesn’t end at the showroom door.

That is why SDVs matter to business people as much as to engineers. A software-defined car can open the door to paid upgrades, subscriptions, remote diagnostics, fleet services and longer customer relationships. But it also creates a new kind of risk: if the software experience feels unfair, unreliable or intrusive, the damage to trust is immediate.

The driver's view: a car that gets better after you buy it

From the driver's seat, the software shift mostly shows up as small surprises. The updates that stick with me are the ones I didn't ask for: a release quietly changed how the regenerative braking feels at low speed; another tightened the range estimate so it stopped lying to me on cold mornings. Small things, but the car keeps improving in directions I wouldn't have thought to want.

The same connection runs the other way since the car is reachable from my phone. I precondition the cabin before I leave the house, check the charge without walking outside, and lock or unlock it from wherever I happen to be.

The data flows both ways, too – when something's wrong, the service team can often read diagnostic data before the car is even in the workshop.

Then there's the part worth being honest about. If a feature is only software, the maker can switch it off or put a price on it. BMW tried this in 2022, charging $18 a month to activate heated seats already installed in the car. People hated it. You'd paid for the seats, the heating elements were right there under you, and now there was a meter running. The backlash was so strong that BMW cancelled the subscription the next year and later admitted heated seats were the wrong thing to start with. What I take from it is simple enough: we love waking up to a better car. We’re wary of waking up to a smaller one.

The developer's view: the car as a platform

Traditional cars ran on dozens of small electronic control units (ECUs), usually each a sealed black box from a different supplier. You can update parts of a car built that way, but not easily as one coherent platform. The SDV approach pulls more functions into a smaller number of powerful central computers, with smaller controllers reduced to simpler roles. That consolidation is the real groundwork. Once the car has a few capable computers instead of a maze of isolated ECUs, software can finally be written, tested, and replaced more like a whole system.

On top of that sits a platform, in the proper sense of the word. Depending on the vehicle, that foundation may include an infotainment operating system such as Android Automotive OS, real-time software such as QNX, middleware, hypervisors and a layer of vehicle APIs. Above it run services and apps, communicating with the car through defined interfaces rather than poking at the hardware directly. For a developer, this is a familiar shape: an operating system, a set of APIs, and a deployment target. In SDV, the target just happens to weigh two tonnes and travel at motorway speed.

That last point changes everything about how you work as a programmer. Shipping to a car is not shipping to a phone. A bad web release is rolled back in minutes; a bad vehicle release can strand someone in a car park or, worse, affect how the car behaves on the road. The build-test-deploy loop has to carry that weight at every step.

Why software-defined raises the stakes

Safely sending software to a car is a discipline in itself. You don't push to the whole fleet at once. You stage the rollout, watch a small group first, and keep a way back if something looks wrong, because a failed update can't leave a car bricked in someone's driveway. Tesla only installs while the vehicle is parked and won't let it drive mid-update, for exactly this reason. Rivian gives similar advice: during an update, the vehicle must be parked and is inoperable. The boring safeguards are the whole point.

Security raises the stakes further. A car that can receive software can, in principle, be reached by someone you didn't invite. Regulators saw this coming. Under UN Regulation No. 155, new vehicle types in many markets must have a managed cybersecurity system, and UN Regulation No. 156 sets rules for software updates themselves. For cybersecurity, ISO/SAE 21434 covers building security into a vehicle throughout its life rather than bolting it on. For software updates, ISO 24089 is the closer engineering reference. Simple to legislate, demanding to implement, which is usually where the interesting problems live.

And not every part of the car is equal. The screen that plays your music and the system that controls your brakes cannot share the same fate. Keeping infotainment and safety-critical functions properly separated, so a crash in one can never reach the other, is one of the quiet constraints that shape how these platforms are designed. It rarely makes the release notes, but it's doing a lot of the work.

Wrapping up

The software-defined vehicle is really one shift wearing two faces. From the driver's seat, it's a car that improves over time, occasionally asks you to pay for the privilege, and mostly just gets quietly better. From the developer's seat, it's a long-lived platform with an operating system, an API surface, and a deployment target that can never fail.

What ties the two together is durability. A car used to depreciate from the moment you drove it home. An SDV can, at least in principle, feel less obsolete as it ages, and sometimes even gain value through the features it receives later. Whether it lives up to that depends less on the metal and more on the teams shipping code to it. That's the part I find genuinely exciting to watch unfold.