Over-the-Air Update Workflow on an Adaptive Platform (UCM Concepts)

The problem

Software-defined vehicles depend on safe and secure over-the-air updates, which are also expected under cybersecurity and software update regulations. An update must never leave a vehicle unable to drive, and must only install authentic software. AUTOSAR Adaptive describes this through Update and Configuration Management. This project builds a working update flow on Linux to study its states, safety conditions and failure handling.

Objectives

• Describe the update lifecycle: package, transfer, process, verify, activate, finish or roll back.
• Create signed software packages with a manifest and version metadata.
• Implement an update agent with A/B installation and an activation precondition check.
• Implement rollback on failed health checks after activation.
• Test failure cases and measure update and downtime durations.

What you need

Key concepts

Update and Configuration Management (UCM)

The Adaptive platform functional cluster that receives software packages, processes and verifies them, and activates new versions in coordination with state management.

A/B installation

Two slots hold the current and new versions. The new version is installed into the inactive slot, so the running software is untouched until activation and can be restored.

Activation precondition

A check that the vehicle is in a safe state for switching software, such as parked, ignition in a defined state and enough battery charge.

Code signing

The package hash is signed with the manufacturer's private key; the vehicle verifies it with the public key, so modified or foreign packages are rejected.

Step-by-step guide

1. 1

   Define update requirements

   Write requirements: only packages signed by the trusted key are installed; installation happens while the vehicle may drive; activation only when parked with sufficient battery state of charge; rollback if the new version fails health checks within a set time; no state in which neither version works. Reference the intent of ISO/SAE 21434 and software update regulations without quoting clauses. Define the measurable targets for download, install and downtime.

   Checkpoint: A numbered requirement list with security, safety and timing targets.

2. 2

   Model the update state machine

   In Stateflow, model the states Idle, Transferring, Processing, Verified, ReadyToActivate, Activating, Verifying, Finished and RolledBack, with inputs for package events, vehicle state and health checks. Simulate normal updates, bad signatures, interrupted transfers, activation requests while driving and failed health checks. Check that every path ends in Finished or RolledBack with a working version. Export the chart as a diagram for the report, since it becomes the reference for the agent's code.

   Checkpoint: Simulation results showing every scenario ends with a working version and no illegal transition.

3. 3

   Create the package format

   Define a package as an archive containing the application files and a manifest with name, version, target hardware, dependencies and a SHA-256 hash per file. Generate a manufacturer key pair with OpenSSL, sign the manifest, and keep the private key outside the target. Write a packaging script that builds, hashes and signs, so every test package is produced the same way.

   Checkpoint: A packaging script that produces a signed package, and a manual OpenSSL verification that passes.

4. 4

   Set up the target

   Inside a container or virtual machine, create two application slots, A and B, each holding a version of a stand-in ADAS application running as a systemd service. Store the active slot and a pending flag in a small state file written atomically with write-then-rename. Add a simulated vehicle-state service that reports parked, speed and battery charge, controllable from a test script.

   Checkpoint: The target runs version 1 from slot A and the vehicle-state service responds to test commands.

5. 5

   Implement transfer and processing

   Implement the update agent: download the package in chunks from a local HTTP server with resume support, store it in a staging area, verify the manifest signature and every file hash, check version is newer and target hardware matches, then install into the inactive slot. Keep the running version untouched throughout. Log every state transition with a timestamp. Make the agent refuse to continue if any check fails, and remove the staged files.

   Checkpoint: A valid package is transferred, verified and installed into slot B while version 1 keeps running.

6. 6

   Implement activation and rollback

   When an activation request arrives, check the preconditions from the vehicle-state service. If met, switch the active slot, restart the service and run health checks such as the service reaching Running and producing output within a timeout. If checks pass, mark the update Finished; if not, switch back to the previous slot and mark RolledBack. Persist decisions so a reboot mid-activation recovers correctly.

   Checkpoint: A good update activates and finishes; a deliberately broken version activates and rolls back automatically.

7. 7

   Test security failures

   Create attack test packages: a modified file with the original signature, a package signed with a different key, an older version with a valid signature (rollback attack) and a package for different hardware. Confirm each is rejected at the correct stage with a clear log entry and that the running version is unaffected. Record which requirement each test covers. Keep the attack packages in a separate folder with a note on how each was produced.

   Checkpoint: All four attack packages rejected, each mapped to its requirement.

8. 8

   Test interruption and power loss

   Interrupt transfers at random points and check resume. Kill the container or virtual machine at random moments during installation and during activation, 30 times each, then restart and check the system boots a working version and the agent resumes or cleans up. Request activation while the simulated vehicle is driving and confirm it is deferred. Record any case where the state file was inconsistent.

   Checkpoint: A table of interruption tests with outcomes, showing a working version after every restart.

9. 9

   Measure durations

   Measure transfer time for several package sizes, processing and verification time, installation time and the application downtime during activation. Downtime is what the driver sees, so report it separately. Compare A/B installation with an in-place approach on the same package to show the trade-off between storage use and downtime and risk. Repeat each measurement at least ten times and report median and worst values. Note the storage needed by each approach as well.

   Checkpoint: A timing table per phase and package size, with downtime highlighted for both approaches.

10. 10

    Report

    Document requirements, the state model, package format, agent design, test results and durations. Map each part to UCM concepts and state what a production system adds: secure boot, hardware key storage, campaign management, multi-ECU coordination and Uptane-style metadata. State limitations: a single simulated target and software-only keys. Add the scripts and the Stateflow model so the tests can be rerun by an examiner. Close with recommendations for a team taking the work further.

    Checkpoint: A report with traceability from requirements to tests and a clear statement of limits.

Testing & validation

• Signature, hash, version and hardware checks reject all attack packages.
• Working version present after every interruption and power-loss test.
• Activation deferred while the vehicle is not parked.
• Automatic rollback on failed health checks.
• Durations per phase and activation downtime.

Expected results

A working OTA update agent with signed packages, A/B installation, precondition-checked activation and automatic rollback, backed by security, interruption and timing test results.

Take it further

• Add delta updates and compare transfer size and processing time.
• Coordinate an update across two simulated ECUs that must change together.
• Store keys in a software TPM and verify the boot chain.
• Add a campaign server that targets vehicles by hardware variant.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.