IMPLEMENTATION DOCS / UNS FRAMEWORK
What is the Unified Namespace?
A single, structured, real-time data layer for your entire operation.
On this page 6 sections
The integration problem
Separate machine and business systems may use different identifiers, formats, and update cycles. The following example shows several paths a signal might take. Each connection needs a defined contract and an owner.
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.
A shared namespace
A Unified Namespace gives producers and consumers a common structure for exchanging operational data. In fn-uns, machines publish to MQTT topics and processing components read those messages or their cached values.
Agree topic names, payload meanings, timestamps, and access rules. Sharing a broker does not make those contracts automatic.
The sample topic structure
The fn-uns examples use the path below. The standard namespace definition also describes levels such as line and cell. Match your consumers to the actual topic layout you deploy.
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. A consumer using the agreed convention 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 | Check native support or an appropriate adapter for each device and application |
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
The reference implementation adds processing and reporting to the shared message structure:
| 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.