WHY A UNIFIED NAMESPACE
One simple question.
A clearer picture of your factory.
When machine data, production records, and reports live apart, answering a shift question can become a search through exports and spreadsheets. A Unified Namespace gives those systems a shared structure for exchanging data.
A shared place for machine data.
A Unified Namespace is a shared, structured layer of operational data. Machines publish signals under agreed names, and applications subscribe to what they need. In this implementation, an MQTT broker delivers the messages.
With a consistent source and stored history, a report can calculate how long CNC-01 ran last shift. That still depends on reliable signals, agreed state definitions, and a clear shift boundary.
The answer is spread across systems.
Imagine checking machine status, shift records, and production data in separate tools. This example shows the handoffs needed to assemble a utilisation report. The timings in the diagrams illustrate the story; they are not measured benchmarks.
The same question, with data already connected.
In this example, software collects machine states and stores the history as it arrives. A reporting application can use those records without a new round of manual exports. Response time depends on the deployment and query.
Start with the question your team needs answered.
The same data can support several uses. Each needs the right inputs and a definition agreed by the people who use the result.
"Which machines are running right now, and what's the overall shop floor utilisation?"
Combine current machine states with state history to show what is running and how much of the shift was spent active.
"Which machine has the worst reliability, and what are the top stoppage reasons?"
Review recorded stops and their reasons to decide where to investigate. Validate automatic classifications with operators and maintenance staff.
"Are we on target for today's production schedule? Where are the bottlenecks?"
Compare completed parts with the target for the period. This needs production counts and an agreed schedule or target.
"Where is the scrap coming from? Which machine-operator-program combination has the highest reject rate?"
Link reported scrap to the machine, program, and operator where those records are available. Add the quality context needed for the investigation.
"What's actually improved since we made that change last month?"
Compare consistent metrics across periods to evaluate a change. Keep definitions and data coverage comparable so the difference is meaningful.
Why the shared structure matters
More systems can mean more connections to maintain.
In a fully connected network, the possible pairwise links grow as n × (n − 1) ÷ 2. The counts below illustrate that model. Actual factories may connect only some pairs, or already use shared integration services.
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.
Three ideas make this possible.
The UNS combines an international standard for data addressing, a lightweight messaging protocol, and small independent functions that process data as it flows.
ISA-95 Topic Hierarchy
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.
MQTT Pub/Sub
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.
Serverless Functions
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.
Choose one question to answer first.
See how a signal becomes an answer, or plan a small pilot with the people who will use the result.