Three-layer namespace
MaestroHub runs at every layer: an edge per line, a hub per site and an enterprise hub for the group. Each layer adds its part of the namespace (line, then site and area, then enterprise) and buffers what it sends upward.
- Scenario
- 5 of 5
- Shape
- Tier 1 per line · Tier 2 per plant · Tier 3 for the group
- Applies to
- 3.0
Choose it when you want cross-plant KPIs on one namespace while every line and every site keeps working on its own.
- MaestroHub
- Reads machines
- Data
- Buffered on disk
- Management
- Your tooling
What you install
| Level | Component | How it runs | Recommended hardware |
|---|---|---|---|
| L4 | Enterprise hub, Tier 3 | Helm chart with production values on three nodes | 3 nodes, each 16 vCPU, 24 GB RAM, 500 GB SSD |
| L3.5 | Site hub, Tier 2, one per plant | The single-node chart on K3s | 16 vCPU, 24 GB RAM, 500 GB SSD |
| L3 | Edge, Tier 1, one per line | One binary as a native service | 8 vCPU, 16 GB RAM, 200 GB SSD |
| L5 | Fleet Manager (optional) | Its own binary or Helm chart | A small server or container host |
Edges publish to their site hub over MQTT. Site hubs forward to the enterprise hub over NATS or Kafka. Every hop is opened by the lower layer, and every write that fails waits in a Store & Forward buffer on the sender.
When something fails
| What fails | What happens |
|---|---|
| The WAN between a site and the group | The site keeps working and buffers its feed. Cross-plant KPIs lag until the backlog is delivered. |
| A site hub | Its edges keep their lines running and buffer toward it. Tier 2 has one node; use Tier 3 at sites that cannot wait. |
Limits. Three layers to operate and upgrade; keep their versions in step. Agree the topic contract between the layers (who owns which part of the namespace) before the first site goes live.
Previous: Independent plants · Next: Deployment scenarios · How to read the drawings: Deployment scenarios