How to Achieve Global OEE with a Unified Namespace

Introduction: The Challenge of Measuring Global OEE

The Business Problem

Most large manufacturers already track OEE per plant. One common challenge is:

“Across all sites that run the same process, where is my biggest opportunity to gain capacity or reduce losses—today?”

To answer that, you need Global OEE, a consistent, comparable view of OEE across plants, lines, and geographies. That sounds like a reporting problem, but in reality, it is a data and architecture problem:

• Meaning drifts: “Availability”, “Performance”, and “Quality” are defined differently at each site.

• Structure drifts: Topic hierarchies and asset naming differ, so roll-ups and filters don’t match.

• Time drifts: Shifts, time zones, and aggregation windows create artificial gaps.

• Data drifts: Missing values and format quirks (e.g., percent vs. ratio) quietly corrupt the math.

At scale, these inconsistencies turn into hours of investigation and ranking debates instead of decisions and action.

Why Does This Hurt the Business

For a multi‑site operation, even a few percentage points of OEE difference equate to real capacity, cost, and delivery impact. Leadership needs:

• A single scoreboard they can trust.

• The ability to separate local noise from repeatable patterns.

• Confidence that when a new site or acquisition comes online, it shows up quickly and comparably.

Without that, every new plant or metric becomes a mini integration project, and the “scoreboard” is something people debate instead of act on.

The High‑Level Solution

Global OEE requires two things working together:

1. A Unified Namespace (UNS) that gives every site a shared structure and language for operational data.

2. A governed data intelligence layer that discovers, normalizes, and enforces that structure in real time as data changes.

This is exactly the gap the HiveMQ Platform plus HiveMQ Pulse is designed to fill.

Video Demo: Multi-Site Benchmarking with a Unified Namespace

If you prefer to see this in action first, watch the ProveIT demo of the exact scenario this blog covers:

The rest of this post unpacks that demo from a HiveMQ product and architecture point of view so you can reuse the pattern in your own environment.

From Edge Signals to Global OEE

To make Global OEE work in practice, the architecture must solve two problems:

1. Reliable, scalable OT data streaming across sites.

2. Consistent, governed data models that make KPIs comparable.

1. Streaming Backbone: HiveMQ Edge + Enterprise Broker

We use MQTT as the transport layer and HiveMQ as the backbone:

• HiveMQ Edge at each site connects to OT systems and local UNS structures, collecting MQTT topics from lines, assets, and sensors.

• HiveMQ Enterprise Broker clusters provide a reliable, secure, scalable transport between sites and HQ.

• MQTT bridges connect site brokers to the central HQ broker while handling reconnects, burst traffic, retained messages and queued sessions without breaking downstream pipelines.

This gives you:

• Stable, enterprise‑grade multi‑site MQTT transport.

• Decoupling between producers and consumers so new use cases can reuse the same streams.

2. Data Intelligence Layer: HiveMQ Pulse

On top of that backbone, HiveMQ Pulse turns raw MQTT topics into governed, comparable KPIs:

• Pulse Agents run close to the data, indexing live MQTT traffic and applying models and expressions at the source.

• The Pulse Server manages the shared namespace, policies and coordination across agents.

Simple representation of the data pipeline in the proposed architecture

In the ProveIT scenario, we used Pulse to:

• Discover existing Dallas topics and highlight mismatches.

• Build a browsable namespace & catalog for enterprises, sites, lines, and metrics.

• Normalize Dallas’s A/P/Q percent values into ratios and compute OEE via Pulse Expressions.

• Govern data in motion so deviations from the model surface immediately instead of corrupting KPIs.

Benchmarking Performance Across Multiple Sites

Starting Point: Enterprise B Already Live

Before the live challenge, Enterprise B was running a multi‑site OEE benchmark:

• Three bottling sites publishing metrics like:

  • EnterpriseB/Site1/metric/availability

  • EnterpriseB/Site1/metric/performance

  • EnterpriseB/Site1/metric/quality

  • EnterpriseB/Site1/metric/oee

• A Grafana dashboard at HQ showing side‑by‑side OEE, Availability, Performance, and Quality.

• The HiveMQ platform handling distributed MQTT transport between site and HQ brokers.

Leadership already had a trusted baseline: Site 2 at 92%, Site 1 at 85%, Site 3 at 78%—and a clear view of where to focus improvement.

The Live Challenge: “Just put Dallas on the scoreboard”

The ProveIT scenario introduced a classic transformation problem:

A new acquisition, Enterprise A / Dallas, is added to the footprint. Management demands:“Just put Dallas on the same scoreboard—quickly—and only show numbers we can actually compare.”

Dallas looked like many real acquisitions:

• The namespace structure didn’t match Enterprise B’s topic model.

• OEE was not published directly; only A/P/Q were available as percentages.

Stakeholders had conflicting constraints: OT doesn’t want production touched, IT wants governance, analytics wants one formula, and management wants speed.

This table highlights the OEE data structure in our two different enterprises. While Enterprise B has a consistent way to structure its OEE data, Enterprise A has a different way to organize this data. This causes an immediate challenge.

In many organizations, that request becomes a 3–6 month integration project with custom scripts and manual documentation. Our goal at ProveIT was to prove a different outcome.

The Pulse‑Driven Onboarding Workflow

Using HiveMQ Pulse, we turned Dallas onboarding into a live alignment workflow, not a project:

1. Discover Dallas topics

   • Use Pulse discovery to scan live MQTT traffic from the Dallas site and surface format and structure mismatches.

2. Align to the canonical UNS model

• In the Pulse Namespace, model Dallas under the same structure as Enterprise B, creating normalized metric nodes such as:

  • EnterpriseA/Dallas/metric/availability

  • EnterpriseA/Dallas/metric/performance

  • EnterpriseA/Dallas/metric/quality

  • EnterpriseA/Dallas/metric/oee

• Map discovered Dallas topics to these nodes.

  • Convert percent → ratio for A/P/Q.

  • Compute OEE = a × p × q from the normalized metrics.

• Publish the resulting normalized metrics back into the UNS via MQTT, so they look identical to Enterprise B’s topics from the HQ perspective.

3. Validate instantly in the dashboard

• Because dashboards point at canonical metric topics, Dallas simply appears in the existing multi‑site OEE view.

• OEE values update in real time as A/P/Q change and behave like any other site.

Who Wins – and How HiveMQ + Pulse Creates Value

From a business perspective, the win is that each critical persona gets what they care about:

• OT Engineers

  • Keep production stable – no risky renames or PLC changes just for KPIs.

  • Changes stay in the Pulse model, not the control logic.

• IT Architects

  • Enforce a consistent namespace model across sites.

  • Centralized governance on topic structures, data types, and policies.

  • Fewer one‑off integrations and long‑term maintenance traps.

• Analytics / BI teams

  • Stable metric paths and normalized values across all sites.

  • One OEE definition: dashboards don’t need constant rewiring.

• Management

  • Speed and comparability – new plants show up on the scoreboard quickly.

  • Confidence that OEE numbers mean the same thing everywhere, so decisions are based on reality, not debates.

Conclusion: From Local Metrics to Global Operational Intelligence

Global OEE is not just a better dashboard. It is a capability: the ability to add new sites, lines, and acquisitions to a shared operational model quickly, safely, and repeatedly.

The ProveIT scenario shows that:

• A Unified Namespace over MQTT gives you a scalable way to organize multi‑site OT data.

• HiveMQ’s streaming platform ensures messages move reliably across that footprint.

• HiveMQ Pulse turns that backbone into a governed UNS, where data is:

  • Discovered and cataloged.

  • Normalized and computed at the edge.

  • Governed so drift is surfaced and corrected.

Global OEE becomes not a one‑off project, but a repeatable pattern your organization can apply whenever the network, footprint, or product mix changes.

To see how manufacturers build a scalable data backbone for global operational intelligence, explore the HiveMQ Platform and how it enables real-time industrial data streaming and Unified Namespace architectures.