Architecture

Introduction

This section describes the internal architecture of AosCore — the software stack running on each AosEdge Unit. AosCore is composed of four main components that run as separate processes and communicate over gRPC. Together they handle cloud connectivity, service management, security, and multi-node coordination.

If you are new to AosEdge, read the System Overview first to understand the Unit and Node model before diving into component details here.

The Four-Component Model

AosCore follows a modular architecture where each component has a well-defined responsibility boundary:

Component	Process	Primary Responsibility
Communication Manager (CM)	aos_communicationmanager	Cloud connectivity, desired-state processing, update orchestration, network management
Service Manager (SM)	aos_servicemanager	Service image lifecycle, container launching, resource enforcement, monitoring
Identity and Access Manager (IAM)	aos_iamanager	Certificate management, provisioning, node identity, access control
Message Proxy (MP)	aos_messageproxy	Inter-node message routing, file distribution, log forwarding

Each component is independently buildable (controlled by CMake options WITH_CM, WITH_SM, WITH_IAM, WITH_MP) and can be deployed selectively depending on the Node's role within the Unit.

Component Interactions

The components interact through gRPC interfaces defined in the AosCore API repository:

• CM ↔ IAM — CM obtains the Unit's system identity and user credentials from IAM. IAM notifies CM when credentials change, triggering cloud reconnection.
• CM ↔ SM — CM instructs SM to deploy, update, or remove services based on the desired state received from the cloud. SM reports service status back to CM.
• CM ↔ MP — On multi-node Units, CM communicates with remote Nodes through MP, which routes messages across the inter-node transport.
• SM ↔ IAM — SM requests service-level certificates and permission checks from IAM.
• MP ↔ CM/SM — MP forwards cloud messages and distributes image files to SM instances on secondary Nodes.

Inter-Component Communication

All inter-component communication uses gRPC with Protocol Buffers. The proto definitions are versioned in aos_core_api/proto/ and organized by component:

• communicationmanager/ — update scheduler interface (CM exposes to external update managers)
• servicemanager/ — service management interface (CM uses to control SM)
• iamanager/ — identity and certificate services (protected and public APIs)

Cloud communication uses a WebSocket-based JSON protocol — not gRPC — connecting CM to the AosCloud backend.

Shared Infrastructure

Beyond the four main components, AosCore includes a shared library layer (common/) providing:

• Cloud protocol handling — WebSocket JSON message serialization and deserialization
• Downloader — resumable HTTP downloads with integrity verification
• OCI image specification — parsing and validation of OCI container image manifests and layers
• Network utilities — shared networking primitives
• Logging — structured logging infrastructure
• Database migration — schema versioning for component-local SQLite databases

In This Section

• Architecture Overview — detailed component diagram and interaction patterns

• Communication Manager — cloud connectivity, update orchestration, network management

• Service Manager — service image lifecycle, launching, resource management

• Identity and Access Manager — certificates, provisioning, node identity

• Message Proxy — inter-node message routing and file distribution

• Common Infrastructure — shared libraries and utilities

Related Pages

• System Overview — introduction to AosCore and the Unit/Node model
• Service Lifecycle — how services are deployed and managed end-to-end

• Deployment Flows — SOTA/FOTA update processes

• Security Model — certificate architecture and access control