SOTA vs FOTA

Introduction

AosCore supports two distinct deployment mechanisms for delivering updates to Units in the field: SOTA (Software Over The Air) and FOTA (Firmware Over The Air). While both share the same orchestration state machine within the CM Update Manager, they differ fundamentally in what is being deployed, which components execute the update, and what impact the update has on the running system.

This page provides a detailed comparison of SOTA and FOTA to help OEMs understand when each mechanism applies, how to integrate with each, and what operational differences to expect.

When Each Applies

The distinction between SOTA and FOTA is determined by the type of Deployable Item being updated:

Deployable Item Type	Mechanism	Description
service	SOTA	OCI container images running application workloads
layer	SOTA	Shared OCI filesystem layers used by services
runtime	SOTA	Runtime environments for service execution
component	FOTA	System-level firmware (rootfs, bootloader, BSP)

A single desired-state message from AosCloud can contain both SOTA and FOTA items. The CM Update Manager processes them within the same update cycle, coordinating the appropriate executor for each type.

SOTA Triggers

SOTA updates are triggered when the desired state contains changes to:

• Services — new service versions to deploy, or services to remove
• Layers — new shared layers to install, or layers to remove
• Instances — changes to which services should run, how many, or with what configuration
• Unit configuration — changes to the Unit-level configuration version

FOTA Triggers

FOTA updates are triggered when the desired state contains changes to:

• Components — firmware images for system-level components (rootfs, bootloader, hardware-specific firmware)

Architecture Comparison

SOTA Execution Path

AosCloud → CM (Update Manager) → CM (Image Manager) → CM (SM Controller) → Service Manager (SM)

1. CM receives desired state with new service/layer versions
2. CM Image Manager downloads and verifies OCI images
3. CM SM Controller sends RunInstances to the Service Manager on each Node
4. SM stops old instances, starts new instances with updated images
5. SM reports per-instance status back to CM

FOTA Execution Path

AosCloud → CM (Update Manager) → CM (Image Manager) → External Update Manager (UM)

1. CM receives desired state with new component versions
2. CM Image Manager downloads and verifies firmware images
3. CM sends PrepareUpdate to the registered external Update Manager (UM) via gRPC
4. UM downloads component artifacts, validates, and prepares the update
5. CM sends StartUpdate — UM applies the firmware (may require reboot)
6. CM sends ApplyUpdate — UM commits the update permanently

Detailed Comparison

Aspect	SOTA (Software)	FOTA (Firmware)
What is deployed	Service images (OCI containers), layers, runtimes	System components (rootfs, bootloader, firmware blobs)
Executor	Service Manager (SM) on each Node	External Update Manager (UM) process
Communication protocol	servicemanager/v4 gRPC (RunInstances)	updatemanager/v2 gRPC (PrepareUpdate, StartUpdate, ApplyUpdate, RevertUpdate)
Image format	OCI image index with layers	Vendor-specific firmware format
Download responsibility	CM Image Manager downloads; SM may also download missing images	CM Image Manager downloads; UM receives artifacts via shared storage or HTTP
Impact on running system	Services are relaunched — no system reboot	Node may require reboot to apply firmware
Rollback mechanism	SM stops new instances, restarts previous versions	UM supports RevertUpdate before ApplyUpdate commits
Rollback window	Immediate — instances can be restarted at any time	Between StartUpdate and ApplyUpdate only
Scope	Individual services on specific Nodes	System-level components across the Node
Verification	Instance reaches running state	UM reports component state as INSTALLED
Failure detection	Instance fails to start or crashes	UM reports FAILED state with error
Priority handling	Instance priority determines scheduling order	UM priority determines update order across multiple UMs

SOTA in Detail

Deployable Item Types

SOTA handles three categories of Deployable Items:

Type	Code Enum	Purpose
Service	eService	Application container images
Layer	eLayer	Shared filesystem layers (base OS, libraries)
Runtime	eRuntime	Execution environments for services

Execution via Service Manager

The CM SM Controller communicates with the Service Manager using the RunInstances message:

Field	Purpose
services	Service images to make available (ID, provider, version, URL, SHA-256, size)
layers	OCI layers required by services (ID, digest, version, URL, SHA-256, size)
instances	Specific instances to run (identity, UID, priority, storage/state paths, network config)
force_restart	Whether to force-restart already-running instances

The SM responds with RunInstancesStatus containing per-instance state (run_state) and any errors.

SOTA Status Notifications

External systems subscribing to the Update Scheduler receive UpdateSOTAStatus messages:

Field	Content
state	Current update state (NO_UPDATE, DOWNLOADING, READY_TO_UPDATE, UPDATING)
unit_config	Target Unit configuration version
install_services	Services being installed (ID, version)
remove_services	Services being removed (ID, version)
install_layers	Layers being installed (ID, digest, version)
remove_layers	Layers being removed (ID, digest, version)
rebalance_request	Whether instance rebalancing is needed

SOTA Characteristics

• Non-disruptive: Services are stopped and restarted individually — the Node continues running
• Granular: Each service instance is independently managed
• Fast rollback: Previous service versions remain in the image store; rollback is a matter of restarting with the old image
• No reboot required: Service updates never require a Node reboot
• Placement-aware: Instances are scheduled to specific Nodes based on labels and priority

FOTA in Detail

Component Model

FOTA handles system-level components identified by component_id and component_type. These represent firmware elements that cannot be deployed as OCI containers:

• rootfs — the root filesystem of a Node
• bootloader — boot firmware
• BSP components — board support package elements
• Hardware-specific firmware — device firmware, FPGA bitstreams, etc.

External Update Manager Protocol

The CM communicates with external Update Managers through the UMService gRPC interface (updatemanager/v2). The UM registers with CM via a bidirectional streaming RPC:

UM → CM: RegisterUM(stream UpdateStatus) returns (stream CMMessages)

CM sends commands to the UM, and the UM reports status back:

CM Command	Purpose	Expected UM Response
PrepareUpdate	Download, verify, and prepare component images	Report PREPARED state
StartUpdate	Apply the update (system must remain revertible)	Report UPDATED state
ApplyUpdate	Commit the update permanently (no rollback after this)	Report IDLE state
RevertUpdate	Roll back to the previous version	Report IDLE state

PrepareUpdate Details

The PrepareUpdate message contains a list of components to update:

Field	Purpose
component_id	Unique identifier for the component
component_type	Type classification of the component
version	Target version string
annotations	Vendor-specific metadata
url	Download URL for the firmware image
sha256	Integrity digest for Verification
size	Expected file size in bytes

FOTA Status Notifications

External systems subscribing to the Update Scheduler receive UpdateFOTAStatus messages:

Field	Content
state	Current update state (NO_UPDATE, DOWNLOADING, READY_TO_UPDATE, UPDATING)
components	Components being updated (ID, type, version)

UM Update States

Each Update Manager reports its state through UpdateStatus:

State	Meaning
IDLE	No update in progress; ready for new commands
PREPARED	Components downloaded and verified; ready to apply
UPDATED	Update applied successfully; awaiting commit or revert
FAILED	Update failed; error details provided

Per-component status is also reported:

Component State	Meaning
INSTALLED	Component successfully updated to target version
INSTALLING	Update in progress
ERROR	Component update failed

FOTA Characteristics

• Potentially disruptive: Firmware updates may require Node reboot
• System-wide scope: Affects the entire Node, not individual services
• Explicit commit model: Updates are not permanent until ApplyUpdate — providing a safe rollback window
• Priority-ordered: When multiple UMs are registered, they are processed in priority order (lower priority value = higher precedence)
• Reboot handling: Update modules within the UM determine whether a reboot is needed after each operation (Update, Apply, Revert)
• External process: The UM runs as a separate process from CM, communicating via gRPC

Rollback Differences

SOTA Rollback

SOTA rollback is handled implicitly through the desired-state model:

1. If a service instance fails to start, the error is reported to AosCloud
2. AosCloud can send a new desired state with the previous service version
3. CM processes the new desired state, instructing SM to run the old version
4. Previous images remain in the local store, so no re-download is needed

There is no explicit "revert" command for SOTA — the system simply converges to whatever desired state AosCloud sends.

FOTA Rollback

FOTA rollback is explicit and time-bounded:

1. After StartUpdate, the firmware is applied but not committed
2. The system verifies that the new firmware is functional
3. If Verification succeeds, CM sends ApplyUpdate — the update is permanent
4. If Verification fails (UM reports FAILED), CM sends RevertUpdate
5. The UM rolls back to the previous firmware version
6. After ApplyUpdate, no rollback is possible — the previous version is discarded

This two-phase commit model ensures that firmware updates can always be reverted if the system becomes non-functional after the update.

Reboot Behavior

Scenario	SOTA	FOTA
Normal update	No reboot	Reboot may be required
Rollback	No reboot	Reboot may be required
Multiple components	N/A	Reboots are ordered by module priority to minimize total reboots

For FOTA, the Update Manager's update modules individually determine whether a reboot is needed. Modules are called in priority order so that a single reboot can satisfy multiple components (e.g., a rootfs update and a bootloader update may both need a system reboot, but only one reboot is performed).

Mixed Updates

A single desired-state message can trigger both SOTA and FOTA updates simultaneously. The CM Update Manager handles this within a single update cycle:

1. Download phase — all images (both service and firmware) are downloaded
2. Install phase — Node states and Unit configuration are applied
3. Launch phase — SM receives RunInstances for services AND CM sends PrepareUpdate/StartUpdate to UMs for firmware
4. WaitingActive phase — CM waits for both SM instance status and UM component status
5. Finalize phase — all items (services and components) are committed together

This ensures atomic updates where both software and firmware changes are applied as a single coordinated operation.

Update Scheduler API

External systems interact with SOTA and FOTA through separate RPCs on the UpdateSchedulerService:

RPC	Triggers	Notifications
StartSOTAUpdate	Software update using last received desired state	UpdateSOTAStatus with service/layer details
StartFOTAUpdate	Firmware update using last received desired state	UpdateFOTAStatus with component details
SubscribeNotifications	N/A — subscribes to both	Both UpdateSOTAStatus and UpdateFOTAStatus

These RPCs allow OEM systems (such as HMI applications or fleet management tools) to control update timing — for example, deferring updates until the vehicle is parked or the user approves.

Related Pages

• Deployment Flows — section overview with deployment architecture summary
• Update Flow Overview — end-to-end sequence from cloud trigger through all phases to completion
• Update Handler State Machine — complete FOTA Update Manager state machine with module interfaces and reboot handling

• Rollback and Recovery — detailed rollback mechanisms for both SOTA and FOTA failures

• Update Manager (CM module) — internal architecture of the CM Update Manager that orchestrates both SOTA and FOTA
• Service Manager — SM component that executes SOTA deployments on each Node
• Key Concepts — definitions of Deployable Item, Verification, and other core terms