Key Concepts and Terminology

Introduction

This page defines the core terminology used throughout the AosCore documentation. Understanding these terms is essential before reading the architecture, deployment, or operational sections. If you encounter an unfamiliar term elsewhere in the documentation, refer back here.

AosEdge uses specific terminology that may differ from general industry conventions or from terms used in earlier versions of the system. A terminology translation table at the end of this page maps deprecated terms to their correct replacements.

Core Concepts

Unit

A Unit is the complete AosEdge system at the edge — the physical or virtual entity that runs AosCore and connects to AosCloud. A Unit is the top-level management boundary: it has a unique identity, receives desired-state updates from the cloud, and reports its status back.

A Unit contains one or more Nodes. In the simplest case, a Unit is a single board running all four AosCore components. In more complex deployments, a Unit spans multiple boards or VMs coordinated together.

In the codebase, the Unit concept appears as system_id and unit_model in the IAM SystemInfo message, and as UnitConfig / UnitStatus structures that describe the Unit's configuration and runtime state.

Node

A Node is a computing element within a Unit. Each Node runs its own instance of the Service Manager (SM) and Identity and Access Manager (IAM), and is identified by a unique node_id and node_type.

Nodes represent the actual hardware or virtual machines that execute services. A multi-Node Unit might have a high-performance Node for compute-intensive services and a low-power Node for always-on monitoring. The Communication Manager (CM) runs on one designated Node and coordinates all others.

In the codebase, Nodes are represented by the NodeInfo message (containing node_id, node_type, CPU info, RAM, partitions) and managed through the IAMPublicNodesService gRPC interface.

Service

A Service is a containerized application managed by AosCore. Services are packaged as OCI-compatible images, downloaded from the cloud, and launched on Nodes by the Service Manager.

Each Service is identified by a service_id and versioned. A Service can have multiple running Instances — individual executions of the same Service image, each identified by an InstanceIdent (combining service_id, subject_id, and instance number).

Services are the primary workload that AosEdge manages. They can be user-facing applications, system utilities, or infrastructure components deployed by the OEM.

Deployable Item

A Deployable Item is any artifact that can be deployed to a Node as part of an update. The system supports several types of Deployable Items:

Type	Description
service	A containerized service image (OCI format)
component	A firmware or system component managed by an Update Manager
layer	A shared filesystem layer used by one or more services
runtime	A runtime environment (e.g., container runtime)

Deployable Items are tracked by the Image Manager within SM and have a lifecycle that includes downloading, verification, storage, and eventual removal when no longer referenced.

In the codebase, Deployable Items are represented by the UpdateItemInfo and UpdateItemStatus structures, with types defined in the UpdateItemType enum.

Deployment Bundle

A Deployment Bundle is a collection of Deployable Items sent together as a single coordinated update. When AosCloud determines that a Unit needs new software, it sends a desired-state message containing all the Deployable Items and Instance configurations that should be running.

The Communication Manager receives the Deployment Bundle, coordinates the download and verification of each item, and orchestrates the deployment across all Nodes in the Unit. If any part of the bundle fails, the system can roll back the entire update.

Deployment Bundles can contain a mix of SOTA (Software Over The Air) items like services and layers, and FOTA (Firmware Over The Air) items like system components.

Verification

Verification is the process of confirming the correctness and integrity of deployed items. In AosCore, verification occurs at multiple levels:

• Image verification — cryptographic signature checks on downloaded OCI images and layers to confirm they originate from a trusted source and have not been tampered with.
• Component verification — integrity checks on firmware components before and after installation.
• Certificate verification — checking the certificate chain to confirm identity and trust relationships.

The codebase uses Verify methods throughout the crypto subsystem (signature verification, certificate chain verification) and in the image pipeline (SHA-256 digest checks on downloaded content).

Instance

An Instance is a single running execution of a Service on a specific Node. Multiple Instances of the same Service can run simultaneously, potentially on different Nodes.

Each Instance is uniquely identified by an InstanceIdent containing:

• service_id (or item_id in v2) — which Service this is an instance of
• subject_id — the subject (tenant/owner) this instance belongs to
• instance — a numeric index distinguishing multiple instances of the same service for the same subject

Instances have their own storage paths, network parameters, resource quotas, and monitoring data.

Desired State

The Desired State is the target configuration that AosCloud sends to a Unit, describing what services, layers, components, and configurations should be active. AosCore continuously reconciles the actual state of the Unit toward this desired state.

The desired state includes:

• Which Deployable Items should be present (services, layers, components)
• Which Instances should be running and on which Nodes
• The Unit configuration and per-Node configurations
• Certificate and subject information

The Communication Manager receives desired-state messages from the cloud and coordinates SM and IAM to achieve the target state.

Component (Firmware)

A Component is a firmware or system-level artifact managed by an Update Manager (UM). Unlike services (which are managed by SM), components represent lower-level system elements such as bootloaders, OS images, or board support packages.

Each Node can have one or more Update Managers registered with CM. When a FOTA update arrives, CM sends PrepareUpdate / StartUpdate / ApplyUpdate commands to the relevant UM, which handles the actual installation. Components are identified by component_id and component_type.

Subject

A Subject represents a tenant or owner identity within the system. Services and Instances are associated with subjects, enabling multi-tenancy where different organizations can deploy and manage their own services on shared infrastructure.

Terminology Translation

The following table maps deprecated or informal terms to the correct terminology used in this documentation. If you encounter these terms in older documents, code comments, or external references, use the correct term instead.

Deprecated / Informal Term	Correct Term	Notes
Device	Unit	"Device" is ambiguous — it could mean the hardware, a peripheral, or the system. "Unit" specifically means the complete AosEdge edge system.
Update Item	Deployable Item	Reflects that items are deployed (not just updated) and covers initial installation as well as updates.
Update Bundle	Deployment Bundle	Consistent with "Deployable Item" naming; emphasizes the deployment action over the update mechanism.
Validation	Verification	"Verification" is the correct term for confirming correctness of signatures, certificates, and deployed artifacts. "Validation" is reserved for schema/format checking of inputs.
Board	Node	A Node is the logical computing element; it may correspond to a physical board but could also be a VM or partition.
Module	Component (context-dependent)	In the context of AosCore architecture, use the specific component name (CM, SM, IAM, MP). In the context of firmware updates, use "Component".

note

The codebase still uses UpdateItem in type names and variable names (e.g., UpdateItemType, UpdateItemInfo). This is a known legacy naming convention in the code. The documentation uses "Deployable Item" as the customer-facing term.

Concept Relationships

The following hierarchy shows how the core concepts relate to each other:

Unit (the complete edge system)
├── Node 1 (computing element — runs SM + IAM)
│   ├── Service A, Instance 1
│   ├── Service A, Instance 2
│   └── Service B, Instance 1
├── Node 2 (another computing element)
│   └── Service C, Instance 1
└── Unit Configuration
    ├── Node 1 Configuration
    └── Node 2 Configuration

Deployment Bundle (sent from cloud)
├── Deployable Item: Service A v2.0 (OCI image)
├── Deployable Item: Layer "base-runtime" v1.3
└── Deployable Item: Component "bootloader" v4.1 (firmware)

Related Pages

• Unit and Node Model — detailed explanation of the Unit/Node hierarchy and multi-Node operation

• Architecture — how CM, SM, IAM, and MP implement these concepts
• Service Lifecycle — how Services and Instances are deployed and managed

• Deployment Flows — how Deployment Bundles are processed