Skip to main content
Version: v1.1

What is AosEdge

Introduction​

This page introduces AosEdge as a platform — what it is, what problems it solves, and how it fits into your product ecosystem. If you are evaluating AosEdge for integration or beginning an OEM deployment, start here to understand the platform's scope and architecture at a high level.

Platform Overview​

AosEdge is a multi-access edge computing orchestration platform. It provides the infrastructure for deploying, managing, and monitoring containerized services on connected Units — the physical hardware running at the edge of your network.

The platform consists of two main layers:

  • AosCloud — a centralized cloud backend that manages fleet-wide operations: service deployment, update campaigns, monitoring dashboards, and configuration management.
  • AosCore — the on-Unit software stack that executes cloud directives locally: downloading and running services, applying updates, enforcing security policies, and reporting telemetry back to the cloud.

This documentation set focuses on AosCore — the edge-side runtime that runs on your hardware.

What Problems AosEdge Solves​

OEM integrators building connected products face recurring challenges around software lifecycle management at the edge. AosEdge addresses these:

ChallengeHow AosEdge Addresses It
Deploying software to distributed hardwareOver-the-air updates (SOTA and FOTA) with rollback on failure
Running multiple workloads on constrained hardwareContainerized services with resource quotas and isolation
Keeping firmware and OS current across a fleetCentralized campaign planning with canary, rolling, and blue-green strategies
Monitoring remote Units without physical accessTelemetry collection (CPU, RAM, storage, network) with cloud-side dashboards and alerting
Securing edge devices against tamperingCertificate-based identity, hardware security module integration (PKCS#11), and access control
Managing heterogeneous multi-board systemsMulti-Node architecture with dynamic service placement across computing elements

How AosEdge Fits Into Your Ecosystem​

As an OEM, you provide the hardware (the Unit) and integrate AosCore into your system image. AosCloud is the management plane you interact with to operate your fleet.

┌─────────────────────────────────────────────────────────┐
│                       AosCloud                          │
│  (Fleet management, deployment campaigns, monitoring)   │
└────────────────────────────┬────────────────────────────┘
                             │ WebSocket / JSON
                             ▼
┌─────────────────────────────────────────────────────────┐
│                     Your Unit (Edge)                     │
│  ┌───────────────────────────────────────────────────┐  │
│  │                    AosCore                         │  │
│  │  ┌────┐  ┌────┐  ┌─────┐  ┌────┐                │  │
│  │  │ CM │  │ SM │  │ IAM │  │ MP │                 │  │
│  │  └────┘  └────┘  └─────┘  └────┘                │  │
│  └───────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────┐  │
│  │         Your OS / BSP / Hardware                   │  │
│  └───────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

AosCore runs as a set of userspace processes on your Linux-based system. It does not replace your OS or BSP — it sits on top of them and manages the application layer.

AosCore at a Glance​

AosCore is implemented in C++ and consists of four cooperating components:

ComponentRole
Communication Manager (CM)Connects to AosCloud, processes desired-state updates, orchestrates deployments, manages network configuration
Service Manager (SM)Manages service images (download, verify, install), launches containers, enforces resource limits, collects monitoring data
Identity and Access Manager (IAM)Handles certificates, node identity, provisioning enrollment, and access control
Message Proxy (MP)Routes messages between Nodes in multi-Node Units, distributes files, and forwards logs

These components communicate with each other over gRPC. AosCore communicates with AosCloud over a WebSocket-based JSON protocol.

For a deeper look at the component architecture, see Architecture Overview.

Key Capabilities​

Over-the-Air Updates​

AosEdge supports two update types:

  • SOTA (Software Over-The-Air) — deploys and updates containerized services and their dependencies (layers).
  • FOTA (Firmware Over-The-Air) — updates system-level components such as the OS, bootloader, or board firmware.

Updates are orchestrated from AosCloud using a desired-state model: the cloud declares what should be running, and AosCore converges the Unit to that state. If an update fails, AosCore automatically rolls back to the previous known-good state.

Containerized Service Execution​

Services run as OCI-compliant container images. AosCore supports multiple runtime types to accommodate different workload requirements — from fully isolated containers to lightweight rootfs-based execution. Each service instance has defined resource quotas (CPU, RAM, storage) enforced by the Service Manager.

Multi-Node Operation​

A single Unit can contain multiple Nodes — separate computing elements (boards, VMs, or partitions) that each run their own AosCore instance. The Communication Manager coordinates service placement across Nodes, and the Message Proxy handles inter-Node communication. This allows you to distribute workloads across heterogeneous hardware within a single managed Unit.

Security​

AosCore uses X.509 certificates for identity and mutual TLS for cloud communication. The Identity and Access Manager handles certificate lifecycle (provisioning, renewal, revocation) and integrates with hardware security modules via PKCS#11 for secure key storage. Each Node in a Unit maintains its own identity.

Monitoring and Observability​

The Service Manager collects per-instance and per-Node metrics (CPU, RAM, storage, network). These metrics flow through the Communication Manager to AosCloud, where they are available for dashboards and alerting. Resource threshold violations generate alerts locally before being reported to the cloud.

What You Need to Know​

To work with AosCore effectively, you should be familiar with:

  • Linux system administration — AosCore runs on Linux and interacts with systemd, networking, and storage subsystems.
  • Container concepts — services are packaged as OCI images and run in isolated namespaces.
  • Embedded systems constraints — Units typically have limited CPU, RAM, and storage compared to cloud servers.
  • PKI and certificates — AosCore uses mutual TLS and X.509 certificates extensively.

You do not need to understand AosCore's internal implementation to deploy and operate it. This documentation provides the operational knowledge needed for integration without requiring you to read source code.

Next Steps​

  • Architecture — explore the component architecture in detail