What is the Unified Namespace?
A single, structured, real-time data layer for your entire operation.
The Problem
Manufacturing data is trapped. Machine PLCs talk proprietary protocols. SCADA systems store data in siloed historians. MES platforms lock information behind vendor APIs. ERP systems hold planning data that never reaches the shop floor in real time.
The result: dozens of point-to-point integrations, each brittle, expensive to maintain, and impossible to scale.
PLC → SCADA → Historian PLC → MES → ERP PLC → Custom App Sensor → Another Custom App Sensor → Cloud Platform
Every new connection adds complexity. Every system has its own data model. Getting a simple answer — "what's the utilisation of machine cnc-01 over the last shift?" — requires pulling data from multiple systems and hoping the timestamps align.
The Solution: Unified Namespace
The Unified Namespace (UNS) replaces point-to-point integrations with a single, shared data layer. Every system — machines, sensors, applications, databases — publishes and subscribes to a common MQTT topic hierarchy.
Any system can publish data. Any system can subscribe. No point-to-point wiring. No vendor lock-in.
ISA-95 Topic Structure
The UNS organises data using the ISA-95 hierarchy — the international standard for manufacturing systems integration. Topics follow a structured path:
v1.0/{enterprise}/{site}/{area}/{machine}/{tag}
| Level | Description | Example |
|---|---|---|
| v1.0 | Namespace version | v1.0 |
| enterprise | Company or business unit | acme |
| site | Physical location / factory | factory1 |
| area | Production area or department | machining |
| machine | Individual machine or cell | cnc-01 |
| tag | Data point | status, program, tool |
Real Examples from This Project
v1.0/enterprise/site1/area1/cnc-01/status → machine state (ACTIVE, IDLE, ALARM...) v1.0/enterprise/site1/area1/cnc-01/program → current program, parts count, progress v1.0/enterprise/site1/area1/cnc-01/tool → active tool, tool life, offset v1.0/enterprise/site1/area2/cnc-03/status → different area, same structure
The hierarchy is self-describing. Any consumer can parse the topic path to understand where the data comes from without needing a separate mapping table.
Why MQTT?
MQTT is the messaging protocol that powers the UNS:
| Feature | Description |
|---|---|
| Lightweight | Runs on constrained devices and edge hardware |
| Pub/Sub | Decouples producers from consumers |
| Wildcards | Subscribe to v1.0/# to get everything, or filter by area |
| QoS levels | At-most-once, at-least-once, exactly-once delivery |
| Retained | New subscribers get the last known value immediately |
| TLS | Encrypted connections for secure data transport |
| Standard | Supported by every major PLC, gateway, and cloud platform |
The UNS Framework
This project follows the UNS Framework — an open standard for structuring manufacturing data in MQTT. The framework defines topic hierarchy based on ISA-95 levels, versioned namespaces, payload conventions, and best practices for topic naming and QoS selection.
What This Project Builds
Using the UNS as the foundation, this project adds a complete data processing pipeline:
| Stage | What Happens |
|---|---|
| Machines publish | Status, program, and tool data to MQTT topics |
| UNS captures | All data cached to Valkey with current/previous tracking |
| Functions process | State durations, stoppages, production runs logged to PostgreSQL |
| APIs serve | KPIs, reports, and queries computed on demand |
The result: a complete, working manufacturing data platform — built entirely from small, independent, version-controlled functions.