Every conversation about software-defined vehicles starts with silicon. How many TOPS, how many zones, which hypervisor. Those are real decisions and I do not want to dismiss them, but they are not what makes these programmes late.
What makes them late is that a modern vehicle programme has an OEM, two or three tier-one suppliers, a silicon vendor and an OS vendor, all of whom need to agree on interfaces that will be frozen years before the car ships and supported for fifteen years after. The compute is the easy part. I say this having spent five years on the supplier side of exactly this arrangement.
What actually changed in the architecture
The old E/E architecture was domain-based and, functionally, a distributed monolith: a hundred-plus ECUs, each with its own function, wired together on CAN buses, with signal-oriented communication. Adding a feature meant adding a box, and adding a box meant adding wiring harness, which is heavy, expensive and assembled by hand.
The new architecture is zonal. Compute consolidates into a small number of high-performance controllers; the boxes near the edges become zonal gateways whose job is power distribution and I/O aggregation for whatever is physically nearby. Automotive Ethernet carries the backbone. CAN survives at the leaves, because sensors and actuators do not need a gigabit.
The consequence people underestimate: communication moves from signal-oriented to service-oriented. Instead of broadcasting EngineSpeed onto a bus and hoping the right listeners exist, a component offers a service that others discover and call. SOME/IP is the common middleware for this; DDS shows up where the real-time and QoS requirements are stricter, often on the autonomy side.
That single change is what makes the vehicle "software-defined". A service can be replaced, versioned or moved to different hardware without rewiring the car. It also imports every hard problem of distributed systems into a safety-critical context — service discovery, versioning, partial failure, backpressure — which the industry is now learning the same way everyone else did.
The two-OS reality
There is no single vehicle OS and there is not going to be. What has stabilised is a split by criticality:
| Layer | Typical stack | Characteristics |
|---|---|---|
| Safety-critical control | Classic AUTOSAR on microcontrollers | Static configuration, deterministic, ASIL C/D |
| High-performance compute | Adaptive AUTOSAR, Linux, or both under a hypervisor | POSIX, dynamic services, updatable |
| Infotainment | Android Automotive OS, or Linux-based IVI | App ecosystem, consumer expectations |
Adaptive AUTOSAR exists to give the middle layer a service-oriented, POSIX-ish platform without abandoning the automotive toolchain. Whether teams adopt it wholesale or lift its concepts onto plain Linux depends mostly on how much of the supplier base has already tooled around it.
The hypervisor deserves specific attention, because it is where a lot of programmes quietly acquire risk. Running a safety partition and a general-purpose partition on one SoC is attractive on a bill of materials. It also means your freedom-from-interference argument — that the infotainment stack cannot starve the safety function of CPU, memory bandwidth or cache — has to be demonstrated, not asserted. That argument is expensive to make and even more expensive to make late.
Cybersecurity became a homologation gate
This is the change that reorganised how programmes are run, and it is often underweighted by people coming from consumer software.
Vehicle cybersecurity is no longer a quality attribute you improve. It is type-approval: without a certified cybersecurity management system and evidence for the specific vehicle type, you do not sell the car in the relevant markets. The same applies to software update management — the process by which you ship an OTA update is itself the thing being audited.
Practically, for an architect:
- Threat analysis and risk assessment is a maintained artefact for the lifetime of the programme, not a document produced once for an audit
- Every interface that crosses a trust boundary needs an explicit, justified decision
- Secure boot, key management and a hardware security module are architectural givens
- Your SBOM and vulnerability monitoring must survive the vehicle, not the project
The engineering practices are recognisable — this is a secure SDLC with better paperwork. What is unfamiliar is that the paperwork has legal force, and that "we will harden it in a later sprint" is not available as an option.
OTA is where the architecture pays out or does not
An OTA update to a car is not an app update. You are modifying a machine that may be parked on a hill, might be mid-charge, has a battery that could be at eight percent, and may be someone's only way to get to work in the morning.
The properties a credible implementation needs:
- A/B partitions with guaranteed rollback. Not a nice-to-have. The alternative is bricking cars in customer driveways.
- Preconditions enforced on-vehicle. Parked, in park, sufficient state of charge, handbrake engaged. The vehicle refuses; the cloud does not decide.
- Campaign management with cohorts and automatic halt. Ship to a thousand cars, watch health telemetry, stop on regression.
- Dependency awareness across ECUs. Updating one component often requires matched versions elsewhere. This is a dependency graph, and treating it as a list is how you produce an inconsistent vehicle.
- A signed, auditable record of what is on every vehicle. Which is also what your regulator asks for.
Point four is the one that surprises teams arriving from cloud. There is no "just roll forward" — a vehicle with mismatched component versions may be unsafe, so the update transaction spans multiple processors with different update mechanisms and different failure modes.
The data question
A connected vehicle can generate more telemetry than anyone can afford to move. The design work is deciding, per signal, where it is consumed:
- On-vehicle only — control loops, most sensor fusion
- On-vehicle inference, event to cloud — the majority of what fleet analytics actually needs
- Raw to cloud — training data, and only when triggered
COVESA's Vehicle Signal Specification has become genuinely useful here: a common vocabulary for vehicle signals means fleet applications are not rewritten per platform. It is the kind of unglamorous standard that saves more money than any architecture diagram.
Where I would push a programme
Three things I would fight for, based on watching which decisions aged well and which did not:
Freeze interfaces, not implementations. The service contract between the OEM and a supplier should be the deliverable. If the contract is precise, the supplier can change how they satisfy it and you can change supplier. If the contract is a document that says "as per specification 4711", you are married.
Build the update path before the feature. Programmes that treat OTA as infrastructure to be added later end up with a vehicle they cannot fix, which means every defect becomes a recall conversation.
Invest in the virtual vehicle. Hardware-in-the-loop is essential and always scarce. The teams that ship are the ones that can run most of their integration tests against a simulated vehicle on a build server, and treat physical rigs as the confirmation step rather than the development environment.
None of that is about TOPS. The vehicle is becoming a distributed system with a fifteen-year support obligation, four organisations holding pieces of it, and a regulator reading your commit history. The compute was never the hard part.