Skip to main content
Version: v1.1

Architecture Overview

Introduction

This page provides a detailed architectural view of AosCore — the software stack running on each AosEdge Unit. It describes the four main components, their internal submodules, how they communicate, and how they are distributed across Nodes within a Unit.

Use this page as a reference map when reading the detailed component pages that follow. Each component section below links to its dedicated documentation for deeper coverage.

System Architecture Diagram

The following diagram shows the complete AosCore architecture within a Unit, including both Main Node and Secondary Node deployments:

loading...

Legend:

  • Purple — Communication Manager (CM): cloud connectivity and orchestration
  • Green — Service Manager (SM): service lifecycle and execution
  • Yellow — Identity and Access Manager (IAM): security and identity
  • Red — Message Proxy (MP): inter-node communication

Component Distribution

AosCore components are distributed across Nodes based on their role within the Unit:

Node RoleComponentsPurpose
Main NodeCM, SM, IAMRuns the full stack including cloud connectivity
Secondary NodeSM, IAM, MPRuns services locally; MP bridges communication to the Main Node's CM

The Main Node is the single point of cloud connectivity for the entire Unit. Secondary Nodes communicate with the cloud indirectly through the Message Proxy, which routes messages to and from the Main Node's Communication Manager.

Communication Manager (CM)

The Communication Manager is the central orchestrator on the Main Node. It maintains the WebSocket connection to AosCloud, processes desired-state updates, and coordinates all other components.

Process: aos_communicationmanager

Subcomponents

ModuleResponsibility
communicationWebSocket-based JSON cloud protocol — connects to AosCloud, sends/receives messages, handles service discovery, reconnection, and message acknowledgment
smcontrollergRPC server that SM instances connect to — distributes service deployment commands, collects status, monitoring data, and logs from all Nodes
networkmanagerManages network resources for the Unit — DNS server, IP subnet allocation, network pool management for service containers
unitconfigHandles Unit-level configuration — loads and provides JSON configuration to other components
iamclientClient interface to IAM — obtains TLS certificates, system identity, and credential change notifications for cloud reconnection
databaseLocal SQLite storage with schema migration — persists CM operational state
configCM process configuration loading and validation

Key Interfaces

  • Cloud (outbound): WebSocket connection to AosCloud using a JSON protocol (protocol version 7). CM performs service discovery, then establishes a persistent WebSocket for bidirectional messaging.
  • SM (inbound gRPC): CM runs a gRPC server (SMService) that SM instances on all Nodes connect to. Through this interface, CM pushes instance updates and receives status, monitoring, alerts, and logs.
  • IAM (outbound gRPC): CM acts as a client to IAM for certificate provisioning, identity information, and credential lifecycle events.

Service Manager (SM)

The Service Manager handles the complete lifecycle of service instances on its Node — from image acquisition through container execution to monitoring and teardown.

Process: aos_servicemanager

Subcomponents

ModuleResponsibility
imagemanagerManages OCI service images — handles image download coordination, storage, and layer management
launcherStarts and stops service instances — supports multiple runtime types (container, native) through a pluggable runtime interface
resourcemanagerEnforces resource limits — CPU, memory, and storage quotas for service instances
networkmanagerConfigures per-service networking — CNI plugin execution, traffic monitoring, network namespace management
monitoringCollects Node-level resource metrics — CPU, RAM, disk usage for the Node and individual service instances
alertsGenerates alert events from journal entries — watches systemd journal for configured alert patterns
logproviderCollects and forwards service logs — system logs and per-instance logs on request
smclientgRPC client connecting to CM's smcontroller — registers the SM, receives commands, sends status and telemetry
iamclientClient interface to IAM — obtains service-level TLS credentials for the gRPC connection to CM
databaseLocal SQLite storage with schema migration — persists service state, image metadata

Key Interfaces

  • CM (outbound gRPC): SM connects to CM's smcontroller as a gRPC client. It registers itself (reporting Node ID, runtime capabilities, resource capacity), then receives instance update commands, and reports back status, monitoring data, alerts, and logs.
  • IAM (outbound gRPC): SM obtains TLS certificates from IAM for securing its gRPC connection to CM.

Identity and Access Manager (IAM)

The Identity and Access Manager handles all security-related concerns — certificate lifecycle, Node identity, provisioning, and access control.

Process: aos_iamanager

Subcomponents

ModuleResponsibility
identhandlerManages system identification — interfaces with hardware or software identity sources (VIS identifier plugins) to establish the Unit's identity
iamservergRPC server exposing IAM services — provides both public (certificate requests) and protected (provisioning, node management) APIs to other components
iamclientClient interface for IAM-to-IAM communication — used in multi-Node setups where secondary IAM instances communicate with the Main Node's IAM
currentnodeProvides current Node information — system info, Node ID, and Node type for the local Node
databaseLocal SQLite storage with schema migration — persists certificate metadata, Node registrations
configIAM process configuration loading and validation

Key Interfaces

  • Public API (inbound gRPC): Exposes certificate request and renewal services. CM and SM connect here to obtain and refresh their TLS credentials.
  • Protected API (inbound gRPC): Exposes provisioning operations, Node controller functions, and certificate management. Used during initial Unit provisioning and Node registration.
  • Node Controller: Manages the registration and lifecycle of Nodes within the Unit — tracks which Nodes are active and their certificate status.

Message Proxy (MP)

The Message Proxy enables multi-Node Units by bridging communication between Secondary Nodes and the Main Node's Communication Manager. It runs only on Secondary Nodes.

Process: aos_messageproxy

Subcomponents

ModuleResponsibility
cmclientClient interface to CM — connects to the Main Node's CM to relay messages on behalf of the Secondary Node's components
communicationManages the inter-node transport layer — supports multiple transport backends including Xen vchan (for Xen-based virtualization) and socket-based communication; handles secure channel establishment and message routing
filechunkerHandles large file transfers — splits files into chunks for reliable transfer across the inter-node transport
imageunpackerProcesses received service images — unpacks OCI image layers received from the Main Node for local SM consumption
logproviderForwards logs to CM — collects logs from the local Node and archives them for transmission to the Main Node
iamclientClient interface to IAM — obtains TLS credentials for securing inter-node communication
configMP process configuration loading and validation

Key Interfaces

  • CM (outbound, inter-node transport): MP connects to the Main Node's CM through the inter-node transport (vchan or socket). It relays desired-state commands to the local SM and forwards status/telemetry back to CM.
  • SM (local): MP provides the local SM with image data (unpacked layers) and forwards CM commands to it.
  • IAM (outbound gRPC): MP obtains certificates from the local IAM instance for securing its transport connections.

Inter-Component Communication Patterns

gRPC Communication

All local inter-component communication uses gRPC with Protocol Buffers, defined in the aos_core_api repository:

Proto PackageLatest VersionPurpose
servicemanagerv5SM ↔ CM interface — instance management, status reporting, monitoring
iamanagerv5/v6IAM public and protected APIs — certificates, provisioning, node management
communicationmanagerv3Update scheduler interface — external update manager integration

All gRPC connections are secured with mutual TLS (mTLS). Each component obtains its certificates from the local IAM instance.

Cloud Communication

The CM-to-cloud connection uses a WebSocket-based JSON protocol (not gRPC):

  1. Service Discovery: CM sends an HTTPS request to the configured service discovery URL to obtain the cloud WebSocket endpoint
  2. WebSocket Connection: CM establishes a persistent WebSocket connection to AosCloud
  3. JSON Messages: All cloud protocol messages are JSON-encoded with transaction IDs for request-response correlation and acknowledgment tracking
  4. Reconnection: CM implements exponential backoff reconnection with configurable timeouts

Inter-Node Communication

On multi-Node Units, the Message Proxy provides the transport between Nodes:

  • Transport backends: Xen vchan (for Xen hypervisor environments) or TCP sockets (for other configurations)
  • Secure channels: TLS-encrypted communication channels authenticated with IAM-issued certificates
  • Message routing: MP multiplexes multiple logical channels (CM channel, IAM channel) over a single transport connection

Build Configuration

Each component can be independently included or excluded from the build using CMake options:

-DWITH_CM=ON|OFF # Communication Manager
-DWITH_SM=ON|OFF # Service Manager
-DWITH_IAM=ON|OFF # Identity and Access Manager
-DWITH_MP=ON|OFF # Message Proxy

This allows building Node-specific images — for example, a Main Node image with CM+SM+IAM (no MP), or a Secondary Node image with SM+IAM+MP (no CM).