Platform Architecture
How EmberNet is put together, from the equipment on the floor up to the console.
The layers
┌─────────────────────────────────────────────┐
│ EmberCORE │
│ Console, API, collectors, alerts, tenants │
├─────────────────────────────────────────────┤
│ Fabric │
│ Flux (L4+ overlay, primary) · ArcNet (L3)│
├─────────────────────────────────────────────┤
│ Edge Runtime Layer │
│ Edge clusters, App Store apps, Cinder │
├─────────────────────────────────────────────┤
│ Industrial Device Layer │
│ OPC UA · Modbus · S7 · EtherNet/IP · SNMP │
└─────────────────────────────────────────────┘
EmberCORE
EmberCORE is the console and the API behind it. It keeps the record of every organization, its users and roles, its sites and devices, and its apps. It runs the industrial collectors and SNMP polling, evaluates alerts, and delivers them by bell, email, phone push, and webhook. Every view in the console is built on the same API.
Edge runtime
Edge nodes run as clusters that schedule platform services and App Store apps, restart what fails, and keep a site's workloads running on its own hardware. Clusters are single-node for small sites, and multi-node where workloads need to survive losing a machine.
Nodes can run EmberRTOS, Fireball's own immutable Linux distribution, with a read-only root filesystem and atomic, snapshot-backed updates. The immutability is the point. An edge node sitting in a plant for three years with nobody logging into it should be in a known state, and a failed update should roll back rather than leave a half-configured host that nobody can diagnose remotely.
Volumes on edge clusters are provided by Cinder, which keeps replicas on other nodes where the cluster has more than one.
Data path
- Collectors in EmberCORE read devices in the protocols they already speak, over Flux when the device has a Flux service. They are read only and touch nothing they were not configured to read.
- Edge apps such as HotLoop, Ignition Edge, and Node-RED process data next to the equipment, and keep working on site.
- Messaging runs through AnvilMQ, the platform's MQTT broker, with each organization confined to its own topics.
- Time-series storage keeps the history.
Storage tiers
| Tier | Location | Retention | What it's for |
|---|---|---|---|
| Hot | Edge node | 7 days | Live dashboards, alerting |
| Warm | Edge cluster | 30 days | Historical analysis, trending |
| Cold | Cloud storage | 365 days | Compliance, long-term analytics |
These are the defaults. Hot retention is the tier that scales with deployment size; see System Requirements. Changing them is covered in Configuration Reference.
Networking
The fabric uses two layers for two different jobs.
Flux is the primary path and the application overlay at layer 4 and above. Access is granted between cryptographic identities rather than between addresses, it rides outbound TCP/443 so it survives restrictive networks, and it carries the cluster API and remote app interfaces back to your browser.
ArcNet is the encrypted layer 3 tunnel underneath it, giving nodes plain IP reachability to each other. It is faster in principle, but it needs UDP that the network has to permit, so it is ranked below Flux, and at most sites it is carried over Flux rather than running beside it.
The ordering is the point. Flux is the transport that survives an industrial network, so it is the one the platform relies on; ArcNet is the optimization you get when the network cooperates.
Both share the same properties:
- No exposed ports. Nodes dial out; nothing dials in.
- Mutually authenticated. Both ends prove who they are.
- Identity-based. Routing follows identity, not IP, so there is no flat network to scan.
- Automatic. Nodes join on enrollment and reconnect through outages and address changes on their own.
Protocols
EmberCORE's collectors read OPC UA, Modbus TCP and RTU over TCP, S7comm, EtherNet/IP, MTConnect, FINS, MELSEC/SLMP, BACnet/IP, DNP3, and 3D printer APIs, and read PROFINET, EtherCAT, HART, CANopen, and FANUC equipment through the controllers and gateways in front of them. Network equipment is polled over SNMP v2c and v3. See Device Connectivity.
EmberBurn republishes tag data across a further set, including Sparkplug B and Kafka.
Deployment models
| Model | How nodes join | Typical customer |
|---|---|---|
| Fireball-managed | Nodes join a cluster Fireball manages | Standard deployments |
| External | The customer's own cluster connects over ArcNet and is imported | Enterprises running their own infrastructure |
The external model is covered in External Tenants.
Availability
- Failover. On a multi-node cluster, workloads reschedule onto healthy nodes.
- Replication. On a multi-node cluster, Cinder keeps volume replicas on different nodes. Volumes created from EmberCORE default to three replicas, which is why three nodes is the recommended minimum.
- Working through outages. Apps on edge nodes keep running when the site loses its connection, and apps built for it, such as Ignition Edge with store and forward, catch up when the link returns.
- Alerts on the platform itself. A cluster that stops answering, or storage that is degraded or faulted, raises an alert instead of going quiet.
Next steps
- Multi-Tenancy: how tenant isolation works
- System Requirements: hardware and OS prerequisites
- Zero-Trust Networking: the security model in depth