Self Updates

1: Self Update Tutorial
2: RAUC Integration
3: API Reference

In general, the self-update mechanism for operating system level updates is done with two separate partitions. While one partition is the actively booted partition and in use, the other partition can be updated by writing a partition image to it, as it is unused or inactive.

Once the download and writing is done, a reboot is triggered and the boot loader will now switch to the newly updated partition.

If the booting of the updated partition fails, the self update mechanism can revert back to the previous partition or boot to a rescue partition.

Leda Self Update

As updating the running operating system cannot be done at runtime, the approach requires additional disk space, a second partition and also requires the device to be rebooted for the updates to take effect.

In a vehicle, the self-updater cannot decide on its own when to do a reboot, as the vehicle must be in a safe condition (eg parked, state of charge etc.). Hence, the trigger for performaing the switch to another slot and a subsequent reboot is handed over to a higher level component, such as the vehicle update manager, which may in turn rely on driver feedback or other conditions.

Implementation with RAUC Update Service

RAUC is a lightweight update client that runs on your embedded device and reliably controls the procedure of updating your device with a new firmware revision.

For general usage of the RAUC tool, please see the RAUC User manual

Reference configuration

The project contains an example reference implementation and configuration using RAUC, which allows the evaluation of the concepts, mechanisms and involved software components in an emulated, virtual environment.

The Leda quickstart image contains the following disk partitions:

a small rescue partition
a full SDV installation with a container runtime, pre-loaded SDV container images and deployment specifications and additional developer tools such as nerdctl and kantui.
a minimal SDV installation with a container runtime, but no additional examples or developer tools. This partition is used to demonstrate the self-update functionality.
additional boot and data partitions for keeping system state information

Note: All three rootfs partitions (rootfs) initially contain the same identical copies of the base operating system. Both SDV Root partitions will use the same shared data partition for the container persistent state.

1 - Self Update Tutorial

This chapter describes the steps necessary to perform a local (without cloud) self update of the operating system.

Self Update Architecture

Self-Update using RAUC Update Bundles

On host: Update bundle sdv-rauc-bundle-qemux86-64.raucb is in current folder

Note: In the development environment, the update RAUC Update Bundle is located in the BitBake machine-specific output folder Example location is tmp/deploy/images/qemux86-64
On host: Start a dummy web server for serving the update file
```
python3 -m http.server --bind 192.168.7.1
```

On host: open two new terminals - one for monitoring and one for triggering the self-update

Terminal 1: To view the progress, watch the MQTT topics selfupdate/desiredstate and selfupdate/desiredstatefeedback:
```
mosquitto_sub -h 192.168.7.2 -p 1883 -t "selfupdate/#"
```

Terminal 2: Trigger the actual self update process by publishing an MQTT message to selfupdate/desiredstate:

mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate" -f start-update-example.json
mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate/command" -f download-command.json
mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate/command" -f update-command.json
mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate/command" -f activate-command.json
mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate/command" -f cleanup-command.json

Files:

start-update-example.json

download-command.json

update-command.json

activate-command.json

cleanup-command.json

Switch to a terminal in the guest
On guest: After the self update process completed, check the status:
```
rauc status --detailed
```

Self-Update Trigger Message

start-update-example.json file:

{
    "activityId": "random-uuid-as-string",
    "timestamp": 123456789,
    "payload": {
        "domains": [
            {
                "id": "self-update",
                "components": [
                    {
                        "id": "os-image",
                        "version": "${VERSION_ID}",
                        "config": [
                            {
                                "key": "image",
                                "value": "http://leda-bundle-server/sdv-rauc-bundle-minimal-qemux86-64.raucb"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}

Example Message Flows

Current State

Initial response message on startup from self update agent in topic selfupdate/currentstate, or upon request by sending message to selfupdate/currentstate/get

 {
       "activityId": "1234567890",
       "timestamp": 1687510087
 }

Response by Self Update Agent on topic selfupdate/currentstate

 {
       "activityId": "1234567890",
       "timestamp": 1687787461,
       "payload": {
             "softwareNodes": [
             {
                   "id": "self-update-agent",
                   "version": "build-152",
                   "name": "OTA NG Self Update Agent",
                   "type": "APPLICATION"
             },
             {
                   "id": "self-update:leda-deviceimage",
                   "version": "v0.0.10-194-g3d48cb8",
                   "name": "Official Leda device image",
                   "type": "IMAGE"
             }
             ],
             "hardwareNodes": [],
             "associations": [
             {
                   "sourceId": "self-update-agent",
                   "targetId": "self-update:leda-deviceimage"
             }
             ]
       }
 }