Secure OTA update path for vehicle ECUs

Problem context

An OTA programme touches the OEM backend, the vehicle telematics unit, the in-vehicle gateway, and every flash-able ECU. Integrity, authenticity, freshness, rollback, and recording all have to hold simultaneously — and the SUMS process layer has to leave a trail that survives type-approval review under UNECE R156 (and AIS 190 in its enforcement window).

Engineering approach

1. Define the OTA control plane: campaign authoring, package signing, delivery tracking, RXSWIN management, and audit logging.
2. Specify package format and signing flow — typically dual signatures (development + release) over a manifest plus per-component image hashes.
3. Design in-vehicle distribution: telematics download, gateway brokering, ECU staging, atomic activation, A/B partitions or a recovery image for rollback.
4. Implement ECU-side acceptance: secure-boot-anchored verification of incoming images, integrity checks before commit, and downgrade prevention.
5. Cover failure modes — interrupted downloads, partial flashes, mid-flight ignition cycles — with recovery procedures and customer-facing messaging.
6. Document the SUMS evidence: campaign records, signed manifests, RXSWIN updates, and the rollback / recovery argument.

Outputs / evidence

• OTA control-plane architecture with PKI roles and keys
• Update-package format specification and signing pipeline
• In-vehicle distribution and staging design
• Secure-flashing requirements per ECU class
• Recovery / rollback design and HARA-aligned safety argument
• SUMS process-evidence package (campaign log, RXSWIN map, audit trail)

Standards touched

• UNECE R156 (SUMS)
• UNECE R155 (intersection — OTA channel hardening)
• ISO 24089 (Software update engineering)
• AIS 190 (where applicable to Indian programmes)