WEDA Architecture
WEDA separates centralized orchestration from device-side execution. WEDA Core manages fleet-wide configuration, workloads, and APIs. WEDA Node applies those configurations, runs workloads locally, and reports device status and telemetry back to WEDA Core.
Keep one sentence in mind while reading the rest of this page: WEDA Core coordinates; WEDA Node executes.
Architecture at a Glance
The diagram above shows the two layers and the traffic between them.
WEDA Core is the cloud-side coordination and management layer. It holds the intended configuration for every registered device, exposes REST APIs for the platform's capabilities, and orchestrates deployments across the devices you target.
WEDA Node is the device-side execution layer. It runs on the edge device, carries out what WEDA Core defines, and processes data locally.
The two layers exchange four things: configuration, management operations, device state, and telemetry. Edge applications run on WEDA Node as containers, and they reach peripheral hardware through WEDA SubNode and Device Library.
How WEDA Core and WEDA Node Work Together
The relationship follows a repeating cycle.
- Identification and connection. WEDA Node identifies the device and establishes its connection to WEDA Core.
- Intended state on the cloud side. WEDA Core holds the configuration, workloads, and management operations targeted at that device.
- Execution on the device side. WEDA Node applies the configuration, runs the assigned containers and workloads, and handles local data.
- Reporting back. WEDA Node returns its current state, the result of each operation, and telemetry to WEDA Core.
The cycle rests on the Device Shadow, which stores an intended state and a reported state for each device. See Device Shadow for how the two reconcile.
Offline behavior. WEDA Node continues running its local work while disconnected from WEDA Core. Changes that require cloud coordination are queued and synchronized after the connection returns.
Components by Layer
WEDA Core (Cloud Layer)
WEDA Core provides centralized management, REST APIs, configuration storage, deployment orchestration, and fleet visibility. Each capability below is a group of related APIs rather than a separate product.
| Capability | Primary Responsibility |
|---|---|
| Identity and Access | Organizations, users, roles, and machine-to-machine credentials |
| Device Management | Device registration, configuration, and lifecycle state |
| Data Engine | DataStreams as the unified data layer, with Analyzers and Data Stream Bridge built on top of them |
| Alerting and Notifications | Alert Policies on DataStream values, alert event history, and delivery channels |
| AI Model Management | Model registration, versioning, and deployment to devices |
| Container Management | Container registry, stack definitions, and deployment workflows |
| Remote Access Tunnel | On-demand sessions to TCP services reachable from a device, without inbound firewall rules |
| Reports | Scheduled collection of Tenant-level usage metrics, and downloadable summaries |
WEDA Node (Edge Layer)
WEDA Node runs on the edge device as its execution layer. It takes responsibility for:
- Device communication and state synchronization with WEDA Core
- Local data collection and buffering, so measurements survive a short disconnection
- Container and workload execution on the device
- AI model deployment, including delivery of model files to the containers that run inference
- Remote management, covering diagnostics and the device end of a tunnel session
- Device Shadow state, which lets the device keep acting on its last known configuration
Edge Development Resources
| Resource | What it is | When you use it |
|---|---|---|
| WEDA SubNode | Open-source edge SDK that runs as a container managed by WEDA Node | You connect custom sensors or sub-systems over protocols such as Modbus, HTTP, MQTT, or SNMP |
| Device Library | Open-source Python and C# library over Advantech hardware interfaces | Your application reads sensors or controls I/O on Advantech hardware |
| Ready-to-Dev Containers | Development containers with toolchains and hardware-specific dependencies already prepared | You build an AI application for a specific edge platform |
| Third-party edge applications | Containers supplied by another vendor or by your own teams | You run additional workloads on the same device, alongside WEDA platform services |
Where Developers Extend WEDA
WEDA covers device connectivity, state synchronization, container orchestration, and lifecycle management. That leaves two surfaces where you write code: one in the cloud, one on the device.
Cloud-Side Applications and Integrations
The WEDA Core REST APIs are the integration surface for anything running off the device. Common uses are:
- Management interfaces that let operators monitor and control devices
- Data visualization dashboards over DataStream values and their history
- System integrations that connect WEDA to existing enterprise systems
- Domain-specific workflows that encode how a particular operation runs
MUI Boilerplate is an open-source React and MUI frontend template with WEDA authentication already wired in, which gives this kind of application a starting point.
Edge-Side Applications and Device Integrations
On the device, you extend WEDA in four ways.
- Package a custom application as a container and deploy it to WEDA Node through Container Management.
- Use WEDA SubNode to integrate peripheral devices and sensors, so their data reaches WEDA Core through WEDA Node.
- Use Device Library to access Advantech hardware capabilities from Python or C#.
- Start from a Ready-to-Dev Container when the application targets specific edge hardware.
Model training stays in your own toolchain. You build models with the tools you prefer, then use WEDA for model registration, versioning, and deployment to the edge.
Design Characteristics
Centralized coordination with local execution. WEDA Core holds the intended state for the fleet and WEDA Node carries it out on the device. Each responsibility sits in one place, so a change is defined once and applied where it takes effect.
API-first extensibility. WEDA Core exposes its capabilities as REST APIs, so the WEDA Console, your own applications, and third-party integrations use the same interface.
Offline continuity. WEDA Node keeps executing its local work when it cannot reach WEDA Core. Pending cloud-side changes apply once the connection returns.
Modular components. You adopt the components a deployment needs. A device can run WEDA Node on its own, add WEDA SubNode for peripheral integration, or use the full set.