Software-defined vehicles and cybersecurity

Everything in the previous four topics is software running on something. This topic is about that something — how it got consolidated, how it is changed after the vehicle has left the factory, and what has to be true for that capability not to be a liability.

What actually changed

A conventional vehicle accumulated electronic control units one function at a time. Add electric windows, add a controller. Add stability control, add another. Premium vehicles reached a hundred or more, each a small dedicated computer doing one fixed job, from a different supplier, with its own toolchain, its own update procedure, and behaviour settled at the factory.

A software-defined vehicle consolidates onto a few capable computers and moves the behaviour into software running on them. The difference that matters to the owner is that the behaviour is no longer settled — it can be changed after the car has been sold.

Domain and zonal

Two ways of consolidating, and they are often confused.

Domain grouping is by function. One controller for powertrain, one for chassis, one for body, one for infotainment. Fewer computers, certainly — but a function’s components are physically spread through the vehicle, so the long wiring runs survive almost unchanged.

Zonal grouping is by location. One controller in each region of the vehicle — front left, rear right — serving whatever happens to be near it, regardless of function. A door switch now runs half a metre to its zone controller rather than three metres to the body computer. A small number of high-speed links carry the aggregated traffic between zones and the central compute.

The saving is the harness, and it is substantial. It is one of the heaviest and most expensive assemblies in the vehicle, it is largely hand-built, and it is awkward to install. Shortening the runs attacks all three at once.

What the network looks like

Automotive Ethernet forms the backbone, because a camera feed is measured in hundreds of megabits and CAN offers a couple at best.

But CAN and LIN do not disappear. There is no benefit in running Ethernet to a door lock actuator, so the short low-rate hops inside a zone stay exactly as they were. The result is layered rather than replaced — Ethernet between zones, CAN and LIN within them.

Updating a vehicle that is not in a workshop

An over-the-air update has a hard constraint that a workshop update does not — it can be interrupted at any moment by a flat battery, a lost connection, or someone simply driving away.

The standard structure is A/B partitions:

1. The signed package downloads in the background, while the vehicle is in ordinary use.
2. It is written to the inactive partition. The active one keeps running throughout, and a failed write damages nothing.
3. The written image is verified — signature, and completeness.
4. Only then is the switch made, as a single atomic step, while the vehicle is stationary and with the driver’s consent.
5. A health check follows, and a failure to come up cleanly returns automatically to the previous partition.

Rollback is not optional. Verification proves an image is authentic and intact; it cannot prove the software is correct. A fleet-wide defect with no route back becomes a physical recall, which is the exact cost the capability existed to avoid.

Rollouts are staged for the same reason. A pilot group, then progressively larger waves, with a halt point after each. The escaped defect then meets a few thousand vehicles instead of a few million, and telemetry has a chance to reveal it while stopping is still possible.

The other side of the same capability

A vehicle that can be updated remotely is, by construction, a vehicle that can be reached remotely.

Secure boot is the foundation. From an immutable root of trust in hardware, each stage verifies the signature of the next before handing control to it. An attacker who succeeds in writing code to storage still gains nothing, because it will never be executed — the defence is at the point of execution, not the point of storage.

Around it:

Measure	Against
Signed updates, verified on the vehicle	A tampered or substituted package
Network segmentation and a gateway	Reaching the drive systems from infotainment
Intrusion detection on the buses	Injected or replayed messages
Hardware security module	Extraction of keys from the device

ISO/SAE 21434, and why it is about the organisation

The obvious way to write a cybersecurity standard is to list required technical measures. The standard deliberately does not, because such a list would be obsolete in a few years and would encourage compliance with the list instead of security.

Instead it requires cybersecurity to be managed as a process across the whole lifecycle:

• Threat analysis and risk assessment — identify what an attacker would want, what it is worth, and what is proportionate.
• Defined responsibility through the supply chain — every component has an owner for its security, written down, including the supplier’s supplier.
• Development practices that follow from the assessment rather than from a checklist.
• Monitoring after sale — vulnerabilities disclosed years later must reach someone whose job it is to respond.
• Incident response, defined in advance.

UN R155 turns this into a type-approval condition in many markets: a manufacturer must hold a certified cybersecurity management system to sell vehicles at all. UN R156 does the equivalent for software update management, and ISO 24089 sets out the engineering practice behind it.

What to take away

• The software-defined vehicle consolidates a hundred fixed-function controllers onto a few capable computers, so behaviour stops being settled at the factory.
• Domain groups by function and saves computers. Zonal groups by location and saves harness, which is the larger prize.
• Ethernet forms the backbone because perception data demands it. CAN and LIN keep the short hops inside a zone.
• A/B partitions make an interrupted update harmless, and the changeover is one atomic step.
• Rollback and staged waves exist because verification proves authenticity, never correctness.
• Secure boot defends at the point of execution, so code written to storage is worthless without a valid signature.
• The real attack path runs sideways from the connected parts, which makes segmentation more valuable than algorithm strength.
• ISO/SAE 21434 governs the organisation and the lifecycle, not a list of technical measures, and UN R155 makes that a condition of sale.

That closes the ADAS and connected vehicle module. Next comes the diagnostics module, which starts where every fault investigation on a modern vehicle starts - with OBD trouble codes and readiness monitors. If any of the above rested on foundations that felt thin, LIN, FlexRay, Ethernet and ECU architecture covers the networks underneath, and ADAS sensing and perception is where the picture all of this acts on comes from.