Updating a phone is one endpoint with spare flash and mains power. Updating a vehicle is fifty to a hundred and fifty endpoints, most of them small microcontrollers on CAN or LIN with no room for a second image, reached through a gateway, on a battery that must still start the car afterwards. The single-device update problem is solved. The campaign problem is not.
A campaign has to accommodate all three at once. Designing for the easiest class and retrofitting the others is the common and expensive mistake.
| Class | What it runs | How it updates |
|---|---|---|
| High-performance compute | Linux or Adaptive AUTOSAR on a domain or zonal controller | A/B partitions, atomic switch, rollback — closest to conventional device update |
| Classic ECU on CAN | Classic AUTOSAR or bare-metal on a microcontroller, 256 kB to 4 MB flash | Flash bootloader entered over UDS; erase-then-write, usually with no room for a second image |
| LIN node | Small actuator or sensor node behind a CAN master, often 20 kbit/s | Reprogrammed through its master where supported at all; frequently excluded from campaigns entirely |
The gateway is the only node with enough memory to stage images, which makes it the campaign engine whether or not it was specified as one.
A campaign is only “over the air” for the first hop. Inside the vehicle the image is forwarded from the gateway down through a tree of buses, and the bus a node sits on decides how — and how fast — it can be reprogrammed. Designing the campaign for the Ethernet-class nodes and discovering the FlexRay and LIN nodes late is the expensive mistake.
| Bus | Typical rate | Where it sits | How an image reaches a node | What constrains it |
|---|---|---|---|---|
| Automotive Ethernet | 100 Mbit–1 Gbit/s (100/1000BASE-T1) | Backbone: gateway to domain and zonal controllers | DoIP (ISO 13400) straight to high-compute nodes; large images travel here | Only high-end nodes are wired to it; not every ECU can be reached directly |
| CAN FD | 1–5 Mbit/s data phase | Powertrain, body and comfort domains | UDS over ISO-TP (ISO 15765-2) into a flash bootloader | Still far slower than Ethernet, and most classic ECUs have no second bank |
| Classic CAN | 500 kbit/s | Legacy ECUs and diagnostics | UDS over ISO-TP, erase-then-write | Bandwidth sets the campaign in hours; framing and flow-control overhead is large |
| FlexRay | 10 Mbit/s, time-triggered | Chassis, braking, steering — safety-critical control | UDS in a reserved slot; the flash is scheduled around the static communication cycle | The deterministic schedule must be preserved; reprogramming windows are tight and planned |
| LIN | ~20 kbit/s | Actuators and sensors behind a master ECU | Reprogrammed through its CAN or CAN FD master node, where supported at all | Too slow for OTA at fleet scale; frequently deferred to a service visit |
FlexRay is where OTA most often breaks down: the nodes are safety-critical, the bus is time-triggered, and the reprogramming slot has to be engineered into the schedule rather than assumed. It is the opposite of a best-effort download.
Images signed, versions registered, and the dependency matrix established across the affected set. A release is a combination of versions, not a file.
Delta packages against each vehicle's known base, delivered over cellular with resumable transfer and integrity checked on arrival.
The gateway holds the images and verifies what it can, but is not trusted to be the only thing that verifies.
Ignition, motion, gear, battery charge, fault state and driver consent. A campaign that cannot meet its preconditions waits rather than proceeds.
Each ECU entered into its flash bootloader over UDS, erased and written, with the bootloader itself untouched. Signature verified by the target before the application is marked valid.
Version readback across the whole set, checked against the matrix. Activation only when every member is where it should be.
Either the set is complete, or the affected members are written back to their previous images and the vehicle is left in a combination that was tested.
Software versions per vehicle retained for type approval and for the next delta to have a known base.
A phone is one endpoint with spare flash and mains power. A vehicle is fifty to a hundred and fifty endpoints, most of them small microcontrollers on CAN or LIN with no room for a second image, reached through a gateway, on a battery that has to start the car afterwards. The single-device problem is solved; the campaign problem is where the difficulty is.
The update is destructive — erase then write — so safety comes from the flash bootloader, which is locked, never erased, and always able to re-request an image. If power is lost mid-write the ECU has no valid application but can still be recovered over the bus, which is the difference between a retry and a workshop visit.
Bus bandwidth sets it. Classic CAN at 500 kbit/s delivers considerably less than its headline once diagnostic framing and flow control are counted, so a megabyte-class ECU takes minutes and a thirty-ECU campaign can take hours. CAN FD helps without eliminating the constraint, which is why delta updates matter.
Sometimes, through their CAN master where the design supports it. At typical LIN rates, reprogramming is slow enough that many programmes exclude LIN nodes from campaigns and handle them at service instead. That is a decision to take deliberately at architecture rather than discover during a rollout.
The campaign is a transaction across a version combination, not a queue of independent updates. If a member fails, the affected members are written back to their previous images so the vehicle is left in a combination that was actually tested. Without A/B that means reflashing, so the bus time is budgeted twice.
Because if only the gateway verifies, a compromised gateway can write anything it likes to every ECU behind it. Verification at the target makes the gateway untrusted infrastructure rather than a single point of total compromise.
In adopting markets, yes. UNECE R156 requires a software update management system for type approval and R155 a cybersecurity management system, with ISO/SAE 21434 as the engineering practice underneath. Update capability moved from a product feature to a homologation obligation.
Over UDS, like any other ECU, but the transfer has to fit the time-triggered schedule. FlexRay reserves communication slots in a static cycle, so the reprogramming traffic is planned into a slot rather than sent best-effort, and the node’s deterministic behaviour has to be preserved throughout. Because FlexRay carries chassis and braking functions, the preconditions around flashing it are stricter than for a comfort ECU, not looser.
Automotive Ethernet (100/1000BASE-T1) is the backbone between the gateway and the domain or zonal controllers, and DoIP (ISO 13400) carries UDS over it. Large images move here quickly, which is why high-compute nodes update in a fraction of the time a classic CAN ECU does. The image is then forwarded down from the controllers onto CAN FD, CAN, FlexRay and LIN, so a campaign mixes a fast backbone with slow leaves in the same transaction.
Zonal architecture and the backbone.
KNOWLEDGEWhy update cannot be retrofitted.
TECHNOLOGYThe verified chain and rollback.
PRODUCTFleet provisioning and staged delivery.
INDUSTRYWhat the vehicle does to electronics.
TECHNOLOGYPreconditions as a safety argument.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.