I attended the ProveIt! Conference in Dallas and joined a session by HiveMQ. At first, it seemed like a standard presentation about “MQTT architecture”.
It was not.
It was one of the most practical sessions I attended. Not because it introduced a new protocol. Not because it promised a breakthrough. But because it focused on a problem most industrial companies quietly struggle with. Multi-site OEE alignment.
Leadership wants one enterprise number. Engineers answer carefully, “It depends.”
The session did not blame either side. It explained why this gap exists and how it can be reduced.
Most importantly, it shifted the conversation from “How do we move more data?” to “How do we make sure the same KPI means the same thing everywhere?”
That is where the real value was.
The Real Problem. Same KPI Name, Different Reality
I have seen this pattern for years. A company runs multiple plants. The lines look similar. The product families are similar. Everyone claims they track OEE.
Then you put all the numbers on one enterprise dashboard. Immediately, the debates start.
Not because people are lying. Because definitions drift. Math drifts. Context drifts.
Typical gaps that quietly break benchmarking:
- One site calculates Availability per shift. Another uses a rolling 24-hour window.
- One site publishes Performance as 92. Another publishes 0.92.
- One site includes planned downtime in the formula. Another excludes it.
- One team rounds at the PLC. Another rounds in the dashboard.
- Topic naming looks “standard” at first. Then acquisitions and local tweaks slowly change the structure.
At small scale, this gets patched with tribal knowledge and spreadsheets. At enterprise scale, it turns into what I call analytics court. Smart people arguing about formulas instead of improving throughput.
One line from the session captured it well. Visibility alone is not enough. Data has to be comparable.
What HiveMQ Showed. Governance on Top of MQTT
The architecture presented by HiveMQ was straightforward.
- Machines and OT systems publish data locally.
- A site-level MQTT broker handles local traffic.
- A subset of topics is bridged upstream to an enterprise broker.
- A governance layer sits on top to standardize and prevent drift.
The key was not the transport. Streaming is not the hard part anymore. Trust is.
They positioned their governance capabilities, including HiveMQ Pulse, as the layer that brings structure to a Unified Namespace instead of letting it turn into a junk drawer.
The capabilities discussed included:
- Automatic discovery of existing MQTT topics.
- Cataloging the namespace so people can see what actually exists.
- Normalizing naming, units, and structures.
- Defining canonical KPI contracts.
- Enforcing rules so the model does not slowly drift over time.
A lot of teams say they have a Unified Namespace. What they often mean is, “We publish MQTT topics.” A governed UNS is different. It is a managed contract with guardrails.
Onboarding an Acquired Plant in Minutes
The live demo scenario was simple and realistic.
An enterprise already had a central OEE dashboard working for a few plants. Then a new plant, recently acquired, needed to appear on that dashboard quickly. Leadership wanted numbers they could trust. Not next quarter. Now.
In the demo, they showed roughly this flow:
- Discover hundreds of existing MQTT topics from the new plant.
- Bring those topics under a governed namespace model.
- Create a canonical structure for Availability, Performance, Quality, and OEE.
- Define OEE as Availability × Performance × Quality.
- Normalize inconsistent formats, for example converting percent values to ratios.
- Republish normalized topics so the enterprise dashboard could consume the same contract it already expected.
The headline claim was around 30 minutes for the normalization work itself, and roughly a man-day including full setup.
My honest take. The exact timing will vary. But the direction is correct. If onboarding a new site takes months, it is rarely a broker problem. It is almost always a governance problem.
A practical test is simple.
“Can I onboard a new site without changing my dashboard logic?”
If the answer is no, you do not have a scalable contract. You have a one-off integration that happens to work today.
Security and Regulated Environments
There was also discussion around cybersecurity and data sovereignty. The message was that the broker can be self-managed, and governance components can support deployments where cloud is not mandatory. They described models where metadata can be managed without pushing full operational data streams upstream.
That matters in regulated manufacturing environments. Especially when operational data boundaries are tightly controlled.
Governance is not just about math. It is also about who is allowed to publish what, in which structure, under which rules.
Final Thoughts
Here is the part that will not get applause in every room.
If you want cross-site benchmarking, governance is not a phase two activity. It is the price of admission.
Without it:
- KPI drift becomes normal.
- Topic structures sprawl.
- Every new site requires custom dashboard logic.
- Trust in the numbers erodes quietly.
- And eventually, adoption dies.
Then someone says, “OEE is a bad KPI.” No. The implementation was bad.
Governance sounds boring. It is. It is also the difference between a cool ProveIt! demo and a model you can actually run your business on.
This post reflects my personal opinions from sessions I attended at the ProveIt! Conference 2026.
I am not affiliated with the companies mentioned, and this content is not sponsored. Company names and trademarks belong to their respective owners.
Company referenced: hivemq.com
Leave a Comment