283 lines
16 KiB
Markdown
283 lines
16 KiB
Markdown
# 02. Choosing an OTA Update Strategy: Full Images, Packages, or Something Else?
|
|
|
|
The previous chapter introduced the central problem of OTA: replacing software while preserving a path to recovery.
|
|
|
|
The next question is:
|
|
|
|
> **What exactly are we trying to update?**
|
|
|
|
The entire system? One application? Configuration? Maps? A machine-learning model?
|
|
|
|
These targets have different lifecycles. Understanding those differences is more useful than starting with a list of tools.
|
|
|
|
This chapter is an introductory guide to the available approaches. The linked Architecture Decision Records (ADRs) explore the conditions under which each choice makes sense. Their examples provide starting points for further study, rather than a complete implementation recipe or a single architecture that every device should follow.
|
|
|
|
---
|
|
|
|
## 1. What Exactly Is Being Updated?
|
|
|
|
An embedded Linux device contains several layers:
|
|
|
|
```text
|
|
Bootloader and hardware support
|
|
Operating system and system libraries
|
|
Applications and services
|
|
Configuration and device identity
|
|
Persistent data and content
|
|
```
|
|
|
|
They do not necessarily change together. The operating system may change rarely, an application every month, and configuration whenever operational requirements change.
|
|
|
|
### 1.1. The Complete Software System
|
|
|
|
An update can represent a transition between complete software releases:
|
|
|
|
```text
|
|
System version N -> System version N + 1
|
|
```
|
|
|
|
The kernel, libraries, services, and applications are built and tested together. The device receives a predefined software version rather than assembling a release from independently changing components.
|
|
|
|
Here, “complete” refers to the software included in that release. Device-specific settings and user data still need their own treatment.
|
|
|
|
### 1.2. The System Platform
|
|
|
|
The operating system can also be maintained separately from applications.
|
|
|
|
Think of it as a platform providing the kernel, libraries, drivers, and core services that applications use. A platform update changes that foundation without necessarily releasing new versions of every application.
|
|
|
|
The platform may be delivered as an image or a versioned filesystem tree. Distribution packages are another possibility. The target being updated does not, by itself, determine the delivery format.
|
|
|
|
### 1.3. Applications
|
|
|
|
A device may contain a communication service, a web interface, diagnostics, and other applications with different release schedules.
|
|
|
|
Updating one independently can avoid a complete system release for a small change. But independence must exist in the software design: the application needs stable interfaces and a clearly supported platform.
|
|
|
|
Choosing to release an application independently comes before choosing whether to deliver it as a package, a bundle, or a container. [ADR-007](../adr/ADR-007-independent-application-updates.md) explores that boundary.
|
|
|
|
### 1.4. Data and Content
|
|
|
|
OTA can also deliver configuration, calibration data, certificates, maps, filtering rules, or machine-learning models.
|
|
|
|
These have compatibility requirements too. A model may need a particular runtime, and a configuration file may only be understood by certain application versions.
|
|
|
|
A small artifact can still have a large effect on the device. Its size does not determine the cost of failure.
|
|
|
|
---
|
|
|
|
## 2. Different Mechanisms Answer Different Questions
|
|
|
|
Full images, A/B layouts, containers, deltas, and signatures are often presented as competing strategies. They describe different parts of an update.
|
|
|
|
An **artifact** is the versioned item delivered to a device, such as an image or a package. **Activation** makes its new version operational. **Rollback** returns to a previous version when the new one cannot be used successfully.
|
|
|
|
| Question | Examples |
|
|
|---|---|
|
|
| What is the update unit? | A system image, application package, container image, filesystem tree, or data set |
|
|
| How is it transferred? | In full, compressed, or as a delta |
|
|
| Where is it prepared? | An inactive partition, a separate directory, or the running filesystem |
|
|
| How is it activated? | A service restart, a reboot, or a switch to a prepared version |
|
|
| How is it verified? | Integrity checks and verification of an authorized source |
|
|
| How is a failure handled? | A previous version, a recovery environment, or manual service |
|
|
|
|
An **A/B layout** keeps two system slots so a new version can be prepared while the current one remains available. A **binary delta** describes changes needed to reconstruct a new artifact from an existing one. Neither defines which software belongs in a release.
|
|
|
|
For example, an update can combine:
|
|
|
|
- a full system image as the release unit;
|
|
- an A/B layout for preparation and activation;
|
|
- delta delivery to reduce network traffic;
|
|
- signatures to establish authenticity.
|
|
|
|
These mechanisms complement one another. Selecting an image format alone does not finish the design of activation or recovery.
|
|
|
|
---
|
|
|
|
## 3. Full-System Image Updates
|
|
|
|
With this approach, the software included in a system release is distributed as a prebuilt image.
|
|
|
|
```text
|
|
Build and test a system release
|
|
|
|
|
v
|
|
Deliver image
|
|
|
|
|
v
|
|
Install and activate it
|
|
```
|
|
|
|
The central benefit is a known software state: the image installed on the device is the one validated before release. Dependencies within that image are settled during the build rather than resolved on the device.
|
|
|
|
Even a small change produces a new image release, and the resulting system still needs regression testing. Large images and hardware-specific variants can increase delivery and maintenance costs.
|
|
|
|
An image can also represent only the system platform in a design where applications are updated separately. In that case, its version identifies the platform, not every independently maintained component on the device.
|
|
|
|
[ADR-004: Full-System Image Updates](../adr/ADR-004-full-system-image-updates.md) examines the case where the software stack is maintained as one product, with reproducibility and system-level rollback taking priority over independent component releases.
|
|
|
|
---
|
|
|
|
## 4. Package-Based Updates
|
|
|
|
A package groups the files and metadata needed to install a software component. It usually identifies a version and may include dependency information and installation scripts.
|
|
|
|
Packages have many uses in Linux. The example developed in [ADR-005: Package-Based Updates](../adr/ADR-005-package-based-updates.md) focuses on independent application components running on a stable system platform:
|
|
|
|
```text
|
|
System platform version A
|
|
├── Communication package
|
|
├── User-interface package
|
|
└── Diagnostics package
|
|
```
|
|
|
|
The platform has its own lifecycle. Application packages are built and validated for that platform, with a corresponding package repository for each platform version.
|
|
|
|
In this model, compatibility is established through architecture and the release process. The device is not expected to discover a suitable application architecture by resolving arbitrary dependency combinations during installation.
|
|
|
|
A fix to diagnostics can therefore be released without replacing the whole system. The cost is maintaining component independence and the builds and repositories needed for supported platforms.
|
|
|
|
The package manager handles package delivery and installation. The OTA manager controls update policy, such as when installation is allowed and which operational conditions must be met. Retaining previous component versions supports downgrade; activation and the handling of application data remain part of the surrounding update design.
|
|
|
|
The ADR explains this division of responsibility and the conditions that make the approach useful.
|
|
|
|
---
|
|
|
|
## 5. Container-Based Updates
|
|
|
|
A container image delivers an application together with its required user-space environment, such as libraries and runtime components. The host supplies the kernel and a container runtime that starts and manages the container.
|
|
|
|
```text
|
|
Host platform
|
|
└── Container runtime
|
|
└── Application with its user-space dependencies
|
|
```
|
|
|
|
[ADR-006: Container-Based Updates](../adr/ADR-006-container-based-updates.md) considers an independently maintained subsystem, especially one supplied by another organization. Packaging its environment with the application reduces dependence on the customer's user-space libraries.
|
|
|
|
This can simplify delivery across compatible platforms. It also adds an environment to maintain and may make the integrator more dependent on the supplier for diagnostics, fixes, and information about the delivered software.
|
|
|
|
Containers do not create stable interfaces or correct tightly coupled components. Nor should container restart be confused with a general guarantee of stronger fault tolerance: containers still depend on the host kernel.
|
|
|
|
In the scenario discussed by the ADR, independent packages are worth considering first when one organization controls the software and components can use the shared platform. Container delivery needs a clear reason for bringing a separate user-space environment.
|
|
|
|
---
|
|
|
|
## 6. Versioned Filesystem Trees
|
|
|
|
A filesystem tree is the set of files and directories that makes up a software version. Instead of shipping a complete block image or modifying the running system package by package, an updater can prepare a new tree and select it for use.
|
|
|
|
```text
|
|
Current tree A remains available
|
|
|
|
|
v
|
|
Prepare new tree B
|
|
|
|
|
v
|
|
Activate prepared tree B
|
|
```
|
|
|
|
Some systems reuse unchanged content between versions. For example, OSTree provides versioned filesystem deployments and atomic upgrades: the managed software is switched as a prepared version rather than exposed as a partially installed set of files. Its [overview](https://ostreedev.github.io/ostree/introduction/) is a starting point for exploring this model.
|
|
|
|
This still requires a way to build releases, manage retained versions, and integrate activation with the platform. Data outside the versioned software tree needs separate handling.
|
|
|
|
[ADR-009: Versioned Filesystem Trees](../adr/ADR-009-versioned-filesystem-trees.md) explores when maintaining complete software states with content reuse justifies that additional machinery.
|
|
|
|
---
|
|
|
|
## 7. Binary Delta Delivery
|
|
|
|
A binary delta describes how to reconstruct a new artifact using a particular old artifact:
|
|
|
|
```text
|
|
Old artifact + Delta = New artifact
|
|
```
|
|
|
|
For example, a device may already hold most of the content of the next system image. Sending a delta can avoid transferring all of that content again.
|
|
|
|
The release unit is still the image. A delta changes how it reaches the device, not what the release contains or how its correctness is established.
|
|
|
|
The saving has a cost. The updater needs the expected source content, resources to reconstruct the result, and a supported path when that source is unavailable. Different starting versions may require different deltas.
|
|
|
|
[ADR-008: Binary Delta Delivery](../adr/ADR-008-binary-delta-delivery.md) considers this optimization when bandwidth or download time is important enough to justify the added work.
|
|
|
|
---
|
|
|
|
## 8. Updating Individual Files and Data
|
|
|
|
Some updates are best understood as replacing a versioned data artifact rather than installing software.
|
|
|
|
For example, a device may download a new map independently of the navigation application. The application must understand its format, and an interrupted download should not leave it using an incomplete map.
|
|
|
|
Useful questions include:
|
|
|
|
- Which application versions can use this data?
|
|
- How is the received artifact verified?
|
|
- When does the application start using it?
|
|
- What remains available if replacement fails?
|
|
|
|
The same questions apply to smaller files, but their answers differ. Configuration may need coordinated activation, while certificates may require a dedicated rotation process rather than an ordinary return to an older file.
|
|
|
|
The important distinction is between the delivered data and the software that consumes it. Their release schedules can differ, but their compatibility still matters.
|
|
|
|
---
|
|
|
|
## 9. Hybrid Strategies
|
|
|
|
A hybrid strategy assigns different update mechanisms to parts of a device with different needs.
|
|
|
|
For example:
|
|
|
|
```text
|
|
System platform -> system image
|
|
Applications -> independent packages
|
|
Maps -> separate data artifacts
|
|
Configuration -> versioned configuration updates
|
|
Certificates -> dedicated rotation mechanism
|
|
```
|
|
|
|
This example does not require every product to use all of these channels. Each additional channel needs a reason, such as a different release schedule or maintenance owner.
|
|
|
|
The combination also needs coordination. If a new map requires a newer application, separate downloads do not make the two versions compatible automatically.
|
|
|
|
[ADR-010: Hybrid Update Strategies](../adr/ADR-010-hybrid-update-strategies.md) explores how to choose useful boundaries without turning the device into an unrelated collection of update mechanisms.
|
|
|
|
---
|
|
|
|
## 10. Which Questions Lead to a Useful Choice?
|
|
|
|
There is no universal ranking of these approaches. A useful starting point is to describe the constraints in ordinary language:
|
|
|
|
| Question | Why it matters |
|
|
|---|---|
|
|
| Which parts change together? | Components released together may belong in one update unit. |
|
|
| Which parts need independent releases? | Separate lifecycles may justify application or data updates. |
|
|
| Who maintains each part? | An external supplier may need to deliver its own environment. |
|
|
| What happens if installation fails? | Recovery requirements influence preparation and activation. |
|
|
| How much storage and memory are available? | Keeping old and new versions or reconstructing artifacts consumes resources. |
|
|
| How expensive or slow is the connection? | Delivery optimizations may justify their maintenance cost. |
|
|
| Can the device reboot or restart a service? | Acceptable downtime influences activation. |
|
|
| How long must updates remain supportable? | Old versions, hardware variants, and tooling all create maintenance work. |
|
|
|
|
For a beginner, answering these questions is more valuable than choosing an OTA framework immediately. They give a vocabulary for understanding why different products use different designs.
|
|
|
|
---
|
|
|
|
## 11. Where to Explore Further
|
|
|
|
The ADRs develop the choices introduced here. They are conditional educational examples: each describes a situation, a decision, and the consequences someone would accept in that situation. Read the relevant ADR for the detailed reasoning behind this chapter's shorter explanation.
|
|
|
|
| Question to explore | Further reading |
|
|
|---|---|
|
|
| When should the software stack be released as one image? | [ADR-004: Full-System Image Updates](../adr/ADR-004-full-system-image-updates.md) |
|
|
| When do independent packages fit a stable platform? | [ADR-005: Package-Based Updates](../adr/ADR-005-package-based-updates.md) |
|
|
| When does a subsystem need its own delivered environment? | [ADR-006: Container-Based Updates](../adr/ADR-006-container-based-updates.md) |
|
|
| When should an application have a separate release lifecycle? | [ADR-007: Independent Application Updates](../adr/ADR-007-independent-application-updates.md) |
|
|
| When is reduced transfer size worth delta processing? | [ADR-008: Binary Delta Delivery](../adr/ADR-008-binary-delta-delivery.md) |
|
|
| When should software be managed as versioned filesystem trees? | [ADR-009: Versioned Filesystem Trees](../adr/ADR-009-versioned-filesystem-trees.md) |
|
|
| When should several update mechanisms be combined? | [ADR-010: Hybrid Update Strategies](../adr/ADR-010-hybrid-update-strategies.md) |
|
|
|
|
These questions are related rather than mutually exclusive. An independently released application can use packages, and a system image can use delta delivery within a hybrid design.
|
|
|
|
Start with what changes and why it needs to change independently. Then explore the mechanisms that fit those boundaries, and the activation and recovery behavior they require.
|