Every manufacturing operation faces the same problem. Someone asks a straightforward question about the shop floor — and answering it requires pulling data from multiple disconnected systems, exporting to spreadsheets, and hoping the timestamps align. By the time you have an answer, it's already stale.
To answer one question about machine utilisation, you traverse five systems, perform three manual exports, and spend hours in a spreadsheet. Here's the actual journey. Watch it to the end, it'll annoy you.
Every system stores its own data in its own format. Connecting any two systems requires a custom integration. The number of possible connections grows with the square of the number of systems — and every one is a bridge that breaks when either end changes.
Each connection is custom-built, manually maintained, and breaks when either system updates. The cost isn't just the initial build — it's the ongoing maintenance, the data inconsistencies, and the questions that never get asked because everyone knows the answer would take too long.
That's the Unified Namespace. Instead of connecting every system to every other system, every system connects to one MQTT broker. Machines publish their state. Applications subscribe to what they need. The broker handles delivery. Adding a new system means one new connection — not N.
The same question — "what was the utilisation of CNC-01 last shift?" — becomes a single API call that returns in under a second. Not because the question got simpler, but because the architecture stopped making it hard.
The machine publishes its state every 3 seconds. Functions process the data automatically. The answer is always ready — computed from real-time data, not assembled from stale exports.
The UNS combines an international standard for data addressing, a lightweight messaging protocol, and small independent functions that process data as it flows.
Every data point gets a canonical address following the ISA-95 international standard. The path is self-describing — any consumer can parse it to understand where data comes from without mapping tables.
Machines publish. Applications subscribe. The broker handles delivery. Producers don't need to know who's listening. Consumers don't need to know who's publishing. Adding a new system means one new connection to the broker — not N connections to every other system.
Each piece of processing logic is a small, independent function —
Go or Node.js. State tracking, stoppage classification, production
logging, KPI computation. They read from a shared cache, write to
PostgreSQL, and compose through infrastructure rather than through
each other. Deploy with
git push.
Utilisation was just the start. The same architecture — machines publishing to MQTT, functions processing data, APIs serving results — answers every question your factory asks.
Every machine publishes its state every 3 seconds. The UNS cache holds the current value for every topic. A single API call returns live status for every machine — ACTIVE, IDLE, ALARM, OFF — with utilisation computed from state duration history. No SCADA screen required. No manual aggregation. Real-time, always.
Every state transition is logged with precise timestamps. The stoppage function auto-classifies downtime reasons. MTBF and MTTR are computed per machine. Stoppage pareto charts rank reasons by total duration. Maintenance can see exactly where to focus — not from gut feeling, but from data that updates continuously.
The productivity function tracks parts completed per program, throughput per hour, and target attainment. Compare actual output against planned schedules in real time — not at the end of the shift when it's too late to adjust. Identify which machines are falling behind before they impact delivery.
Operator input captures scrap counts linked to specific machines, programs, and operators. Quality data flows through the same UNS pipeline as production data — so you can correlate rejects with machine state, tool life, and program parameters. Traceability from raw material to finished part, all in one query.
Every state change, every stoppage, every production run is recorded with timestamps and durations in PostgreSQL. Compare any time period against any other. See whether utilisation improved, whether MTBF increased, whether the top stoppage reason changed. Evidence-based kaizen — not anecdotes in a meeting room.
Read the open standard, explore the reference implementation with real serverless functions, or dive into the documentation. Everything is open source, self-hosted, and ready to deploy.