From Local HMIs to a Central Broker - A Step-By-Step Guide with HiveMQ

In this article, we are building a data broker for our bakery Sweet Harmony Treats together with HiveMQ.

(Our topic. Our tone. Sponsored by HiveMQ *)

An often heard request from our readers (you 😀) is to translate some of our ideas into a tangible architecture, something you can follow and potentially implement. That’s exactly what we have planned for today together with HiveMQ, and hopefully more often in the future!

In the last year, we have published our second Industrial Data Platform Capability Map, a podcast with Kudzai Manditereza on the differences between OPC UA and MQTT, our recent article on the pitfalls around UNS and even our interview with HiveMQ Co-founder Dominik Obermaier.

Time to put all four together! And to do that: we’ll go back to Sweet Harmony Treats, our beloved industrial bakery which you might still know from previous data articles.

Meet Sweet Harmony Treats

Sweet Harmony Treats (SHT) started a century ago as a local bakery. Today, it’s a gigantic family-owned business producing cookies, confectionery, and (their specialty) waffles across multiple countries. Think golden, gooey, crispy waffles—the kind that makes you buy two packs even when you promised yourself just one.

Their production footprint reflects that growth: some facilities are over a hundred years old, smelling of nostalgia and buttered dough. Others were acquired from competitors, each bringing its own quirks, machines, and ways of working. It’s a patchwork that’s common in food manufacturing—and it creates real operational challenges.

Food and beverage companies don’t just make products; they operate under strict regulatory requirements. Traceability is everything. If a bad batch of ingredients gets through, or a quality concern emerges, you need to know exactly which products were affected, where they are, and how to recall them. Not being able to do that isn’t just bad for business—it can be catastrophic.

Which is why operational data matters so much in this industry.

Islands of Data

This brings us to Mark, a process engineer at SHT, and Emma, the lead maintenance engineer. Both are experienced. Both are brilliant at their jobs. Both are drowning in spreadsheets.

Why? Because most of SHT’s production equipment operates in isolation. Mixers, ovens, packaging lines—each has its own local HMI. Some speak OPC-DA. Other fancier ones OPC-UA or MQTT. And then there’s the legacy stuff that barely speaks at all.

The result? Mark can’t quickly compare energy consumption across product types. Emma can’t correlate maintenance events with process parameters. And neither can do it without manually exporting data from multiple systems, hoping the timestamps match up.

SHT’s leadership knew they needed a central data platform. Not someday. Now. Energy costs were climbing, sustainability targets were getting stricter, and their existing approach simply didn’t scale.

So they decided to do it right. SHT formed a small cross-functional team: a couple of people from plant operations (including Mark and Emma as subject matter experts), one from IT infrastructure, and one from OT systems.

Define the Standards Upfront

Before touching any hardware, they sat down with cybersecurity. Where would edge devices live in the Purdue model? What about the central broker? How would authentication work? What protocols were allowed?

They decided:

• Edge gateways at Level 2 (close to machines)

• Central broker in the DMZ (Level 3)

• MQTT as the primary transport protocol (but with bridges to OPC-UA and DA where needed)

• A central Data Broker structured on ISA-95 hierarchical asset model

That last point is critical. As we’ve written before, proper data management is key. And if you don’t define governance upfront (Who owns the namespace? Who approves new topics? How do we handle schema evolution?), you’ll end up with another data swamp.

Building the Namespace

Here is a quick overview of a part of the Namespace as it aligns with SHT’s production plant. We didn’t expand it completely, but this gives you a first idea.

Waffle Line 01
│
├─ Ingredient-Handling
│
├─ Batter-Mixing
│
├─ Proofing (yeasted waffles)
│
├─ Oven
│   ├─ Heating Zone 01
│   │   ├─ Temperature: Top (°C/F), Bottom (°C/F)
│   │   ├─ Gas burner: Valve position (%) 
│   │   ├─ Gas burner: Mass flow (Nm³/h), 
│   │   └─ Circulation Fan Speed (%)
│   ├─ Heating Zone 02
│   │   └─ …
│   ├─ Belt-Drive-Module
│   │   └─ …
│   ├─ Air-Circulation
│   │   └─ …
│   ├─ Humidity-Control
│   │   └─ …
│   └─ Oven Utility Metering
│       ├─ Electricity: Total oven (kW)
│       ├─ Electricity: Incoming mains current (A)
│       └─ Gas: Total oven (Nm³/h)
│
├─ Cooling
│
└─ Packaging

We use the equipment hierarchy from ISA-95 which helps us to build the above namespace. Now we do need to note a few “buts” here:

• This gives us a simple, easy to understand starting point

• But… ISA-95 is much more elaborate and complex than just an equipment hierarchy (it is actually object model which much more complex relationships)

• But… We also don’t depict anything related to the actual batch process here, as this is more the ISA-88 turf

However, for Emma and Mark, this is the perfect starting point for their data infrastructure!

The Architecture - From Edge to Enterprise

Here’s how we would implement a broker based architecture at Sweet Harmony Treats using HiveMQ:

1. HiveMQ Edge - connecting to legacy PLCs and collecting tags, enforcing consistent naming conventions, arranging the data in a UNS structure and bridging to a Site/Central broker.

2. HiveMQ Enterprise - Site/Central broker holding real time UNS structured data from across Sweet Harmony Treats equipment at massive scale.

3. HiveMQ Data Hub - Engine running on broker adds a UNS data validation layer to ensure data transmitted from all edges conforms to define schema.

4. HiveMQ Extension Ecosystem - persisting the sensor data on to a database

Stage 1: HiveMQ Edge – Collecting and Normalizing Data

The waffle line’s baking tunnel oven is a perfect microcosm of SHT’s challenge. It’s got:

• Temperature sensors in each heating zone (OPC UA)

• Gas flow meters on the burners (Modbus)

• A belt drive motor with vibration sensors (MQTT from an IIoT vendor)

• A state machine in the PLC tracking oven modes (OPC DA, because it’s an older controller)

Rather than writing custom integration code for each protocol, SHT deployed HiveMQ Edge—an open-source gateway designed exactly for this scenario.

For the OPC UA sensors, they used HiveMQ Edge’s protocol adapters to poll specific tags. But here’s the key: they didn’t just forward raw tag names like L15.B1.Zone01.TempTop.PV. Instead, they mapped them to a consistent, human-readable structure:

sweetharmony/site/plant1/waffle-line-01/oven/zone-01/temperature/top

By enforcing naming conventions at the edge, they ensured every data point had context before it even left the production floor.

For the legacy Modbus and OPC DA systems, HiveMQ Edge bridged those protocols into MQTT. The result? A single, unified data stream published to MQTT topics—regardless of the original source.

Collecting tags from the Baking Tunnel Oven using the protocol adapter

Mapping the plc tags to MQTT topics with consistent naming

Arranging that data with a UNS data structure prefix

Bridging the HiveMQ edge “UNS” to HiveMQ enterprise broker

Stage 2: HiveMQ Enterprise Broker – The Central Nervous System

All that edge data now flows to a central HiveMQ Enterprise broker sitting in SHT’s DMZ. This isn’t just a message router—it’s the backbone of their real-time data architecture.

The broker handles:

• Real-time pub/sub for thousands of data points (current values only—remember, this is an event stream, not a historian)

• TLS-encrypted connections from all edge nodes

• Quality of Service (QoS) guarantees to ensure critical messages aren’t lost during network hiccups

What does this enable? Other systems can now subscribe to exactly the data they need:

• The historian subscribes to /sweetharmony/+/+/+/oven/# to store all oven telemetry

• Mark’s dashboard subscribes to energy-related topics

• Emma’s maintenance system subscribes to vibration and temperature anomalies

Because it’s pub/sub, adding a new consumer doesn’t require changing anything upstream. No point-to-point integrations. No fragile ETL pipelines. Just clean, decoupled data flow.

Connection to UNS shows the structured Oven sensor data

Stage 3: HiveMQ Data Hub – Governance at Scale

Here’s where things get interesting.

As SHT scaled from one line to twelve, they needed to ensure data quality didn’t degrade. What if an edge node starts publishing malformed JSON? What if someone creates a new topic that doesn’t follow the namespace standard?

This is where HiveMQ Data Hub comes in. It’s an engine running on the broker that validates all incoming data against predefined schemas.

For example, SHT defined a schema for temperature sensors:

{
  “location”: “string”,
  “sensor_id”: “string”,
  “value”: “number”,
  “unit”: “celsius”,
  “timestamp”: “ISO8601”
}

Any message that doesn’t conform? Rejected. Logged. Routed to a dead-letter queue for investigation.

This is governance in action. It’s not a policy document gathering dust—it’s an automated quality gate that prevents bad data from polluting the platform.

And because schemas are versioned and managed centrally, SHT can evolve their data model over time without breaking existing consumers.

Defining a schema for all UNS sensor data

Enforcing a policy against the schema

Stage 4: HiveMQ Extensions – Persisting the Data

Real-time data is great. But Mark and Emma also need history. Trend analysis. Batch comparisons. That requires storage.

SHT uses the HiveMQ TimescaleDB extension to automatically persist sensor data into a time-series database. TimescaleDB is optimized for this: it compresses old data, handles massive write throughput, and supports SQL queries (which their analysts already know).

The extension subscribes to relevant MQTT topics and writes them to TimescaleDB—no custom code required. Retention policies ensure they’re not storing decades of sub-second data unnecessarily.

And finally: Governing the entire landscape

HiveMQ Pulse is a distributed data intelligence platform that turns fragmented, inconsistent operational data into structured, governed data for real-time decisions, analytics, and AI.

It uses a centralized Semantic Graph and distributed agents to catalog data, validate structure, compute KPIs, and apply governance at the source.

Pulse helps teams structure and govern their MQTT data - forming the foundation for a Unified Namespace, even across diverse edge and broker environments.

Pulse Capabilities:

1. Semantic Graph & UNS Governance
   Define and enforce the structure of MQTT topics, payloads, and metadata through a centralized Semantic Graph — applied consistently across edge and broker agents. Pulse provides the enforcement backbone for Unified Namespace strategies by ensuring site-to-site consistency, eliminating schema drift, and reducing fragile scripting.

2. MQTT Discovery & Runtime Validation
   Agents observe active topics and payloads, identify data not yet modeled, and validate live messages against expected formats, surfacing deviations for resolution.

3. Asset Mapping & KPI Computation (Edge‑only)
   Map non‑MQTT sources (e.g., OPC UA) into governed MQTT payloads and compute derived values such as KPIs, rollups, and expressions using local history.

Building the namespace in HiveMQ Pulse

Adding an OEE calculated tag in HiveMQ Pulse

Defining the calculation expression in HiveMQ Pulse for OEE

Full infrastructure overview in HiveMQ Pulse

Discovery of ungoverned traffic in HiveMQ Pulse

Solving payload issues in HiveMQ Pulse

A big thank you to HiveMQ for contributing to this article!

Extra resources you might find useful:

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well.