Your industrial AI pilot works. Why does the next plant still have to start over?

TL;DR

A successful industrial pilot often can’t scale because the knowledge behind it is tied to one plant’s equipment names, tags and custom integrations. In our webinar, Kudzai Manditereza and I traced a capper’s vibration measurement from an OPC UA tag to a reusable model in the HiveMQ Platform. Three things carry forward to the next site:

• Shared data access: An MQTT backbone publishes data once so any application can subscribe to it.
• A reusable equipment model: A Unified Namespace (UNS) gives the data shared meaning, and its calculations run on the broker.
• A repeatable mapping and validation process: Each site still connects its own sources and confirms its measurements. Everything else is reused.

The goal isn’t to eliminate site-specific engineering. It’s to stop repeating work that’s already been done.

Who this is for: Manufacturing IT/OT leaders and industrial data architects who have a working pilot and need to roll it out to more lines or plants without starting over.

The team has connected the equipment, built the application and validated the results. Everyone is happy with what they've achieved. The vibration monitoring pilot is working at one manufacturing plant. Great!

Then leadership asks a reasonable question: can we roll this out to our other plants? That's when things get complicated.

The next plant has different equipment identifiers, different source names and sometimes different systems altogether. The engineers who built the pilot know exactly which signals to use and what they mean, but much of that knowledge is specific to the first plant. So, instead of extending a working solution, the team starts rebuilding significant parts of it.

This was the problem we explored in our recent webinar, Escape pilot purgatory: how to define your Unified Namespace once and make every new plant routine, where I was joined by my colleague Kudzai Manditereza, Senior Industrial Solutions Advocate at HiveMQ.

Our goal was to answer a practical question: what parts of a successful industrial data project can you reuse, and what work still needs to happen at every new site? To answer it, we followed one example from a raw machine measurement through to a reusable data model in the HiveMQ Platform.

Figure 1: The pilot works at Site A. Site B has the same monitoring requirement, but its equipment and source names are its own and nothing is mapped yet.

Why a successful industrial pilot becomes difficult to scale

Imagine a packaging line with a capper, the machine that puts caps on bottles. The engineering team wants to monitor its vibration to understand the machine's condition.

The capper exposes vibration data through an OPC UA interface. The team knows which tag holds the measurement, what unit it's in and which readings to ignore during a changeover. They connect the source, build the monitoring logic and create an application that works.

For one pilot, a custom integration is a sensible choice. It's quick and the team understands it.

The problem emerges when a second application needs data from the same equipment. Say the plant wants energy monitoring. It connects to the same sources and works out the same local names again. Now there are two sets of mappings, and when a PLC is replaced or a tag is renamed, someone updates one application and can easily miss the other. Extend both applications to another plant and the work repeats again.

The challenge isn't that the technology doesn't work. It's that the knowledge and integration work behind each implementation aren't reusable.

And that's an important distinction. The goal isn't to eliminate site-specific engineering. It's to stop repeating work that has already been done and can be shared.

What carries forward to the next site

In the webinar, we organized the answer around three things a successful pilot can hand to the next line or plant: shared access to operational data, a reusable equipment model and a repeatable mapping and validation process. Each site still gets its own mappings and checks. What changes is how much it starts with.

Figure 2: Three things carry forward. The capper model (identity, measurements, context) sits on a shared model that spans both sites.

Start by separating data access from the applications that use it

In an application-centric architecture, each application establishes its own connection to the equipment or system providing the data.

With an MQTT data backbone, edge software connects to the PLCs and sensors at each site and publishes their data once. Applications subscribe to what they need. No application holds its own connection to the machine.

Figure 3: Applications subscribe to published data without connecting directly to every source.

For our capper, the vibration measurement is published once and reaches as many consumers as need it. Adding an application doesn't mean adding a connection. As Kudzai put it, the industry is used to request-response data collection, and that habit quietly rebuilds silos even inside modern IoT and MES tooling. Decoupling producers from consumers is the first step toward scaling across sites.

But connectivity solves only part of the problem. An application can receive a value without understanding what that value represents.

A shared data foundation needs shared meaning

In our example, the capper's vibration measurement comes from an OPC UA source with the identifier CAP_501_VIB. That makes sense to the engineer who knows the machine. Another application needs more: which capper, on which line and site, measuring what, in which unit, and when?

A Unified Namespace (UNS) addresses this by giving operational information a shared, structured representation. In the demonstration, we placed the capper's data in a hierarchy you can read from the top: enterprise, site, production area, line and then the governed measurement, CapperVibration, with its tag name, timestamp and value.

Figure 4: The local identifier stays on the machine. It is mapped once into a governed namespace that vibration monitoring and energy monitoring can both use.

The local identifier didn't change. Nobody renamed the tag on the machine. The source data was mapped into a governed namespace that applications use consistently, and because the namespace is a logical structure, the data doesn't have to move to one physical place.

That distinction matters in brownfield plants. The most common pushback on UNS is the fear of rip and replace, and a UNS is the opposite: a layer above what already works. When a tag is renamed, the team updates the source mapping and nothing downstream changes.

Someone in the Q&A asked how a UNS differs from MQTT. My short answer:

“MQTT provides the transport. The Unified Namespace provides the shared meaning.”

MQTT lets anyone publish. The UNS is the agreement about how to use it: one shared hierarchy, data published in context, so a consumer finds information by where it belongs rather than by who produced it. To reuse data across applications and sites, you need both.

And as Kudzai added, a naming convention on its own isn't enough, because nothing guarantees every team conforms to it. Governing the namespace is what turns MQTT traffic into a trusted data layer.

MQTT's publish/subscribe model, hierarchical topics, and real-time data delivery make it particularly well suited to supporting a scalable Unified Namespace. To understand why these capabilities matter and how MQTT provides the foundation for a UNS, read our blog, Why MQTT is Critical for Building a Unified Namespace. And, standardizing data across sites involves more than agreeing on a naming convention. Read our blog, Most Manufacturing Data Isn't AI Ready, Fix the Data Foundation Not the Model, to explore why inconsistent units, structures, and context can prevent industrial AI from scaling reliably.

From one vibration measurement to reusable analysis

The most useful part of the webinar was seeing this work. Kudzai ran a live demonstration on a simulated packaging process.

HiveMQ Edge read the OPC UA tag, mapped it to MQTT and published it to the HiveMQ Broker. In the HiveMQ Platform, we promoted that topic into the governed namespace.

Then the demonstration went a step further. Kudzai built derived information from the raw vibration value: NormalVibration, a baseline from the median of recent readings; UpperBand, an upper reference for interpreting the vibration; and VibrationTrend, a calculated trend over incoming measurements.

Figure 5: What the demo established. Measured data (CapperVibration) feeds a derived analysis (CapperVibrationAnalysis), which feeds the monitoring application.

The accuracy of the formulas wasn't the point. The point was where they run. The calculations are defined in the platform but execute on the broker, where the data already flows. A single raw measurement became information a condition-monitoring application could act on, without an external analytics system in the loop.

And if that calculation logic has been validated for one capper, why start from an empty model for the next one?

What can actually be reused at the next line or plant

This is the step that makes the approach repeatable. Kudzai derived a data model from the capper's measurement structure and its calculations, created a second line in the namespace and instantiated the model there.

To bring the second capper online, the only input needed was its vibration source. The baseline, band and trend were calculated automatically because they were already part of the model.

It also standardizes how a condition is reported. Anyone who has lived through OEE knows what happens when every site calculates it slightly differently: the numbers stop being comparable.

Of course, there's a qualification.

Reusing a data model doesn't make a new plant operational by itself. The local equipment still needs to be connected. Its source measurements still need to be mapped. And someone who knows the equipment must confirm that those measurements represent what the model expects.

You still need local validation.

The platform can catch structural symptoms, such as a tag that stops arriving. A value that matches the expected data type can still be the wrong measurement. That's where engineering judgment belongs.

In the webinar, we showed reuse of the model on a second line, not a production rollout across two factories. The objective is repeatability, not pretending every site is identical.

Governance is what keeps the shared model useful

As the number of sites grows, the questions get harder. Who owns the definitions? Who decides when a model changes? Who validates that data from a new site matches the agreed meaning?

Two responsibilities show up on every rollout, often split across IT and OT. A model owner keeps the shared definitions and their versions consistent and manages changes deliberately. A site engineer owns the local source mappings and confirms that live values make sense on the real machine.

Sometimes they sit in the same team. Sometimes they don't. Either way, both are necessary.

Figure 6: A repeatable process for the next site. Agree the definitions once; every new site repeats from step 2.

The HiveMQ Platform supports the model owner with visibility into governed and ungoverned traffic, and into data that deviates from its definition. Checking that data conforms to a structure is still different from verifying the condition of a machine. Technology enforces consistency. It doesn't replace someone who knows the plant.

Extend reusable data models to new industrial use cases

So far, we've taken vibration monitoring from one capper to another. Reuse doesn't have to stop with the same application.

Suppose the next team wants energy monitoring. They start with the equipment identity, the existing measurements and the agreed context that are already in the namespace. They still need to add electrical measurements and the calculations that matter for energy consumption. What they don't need to do is rediscover the equipment or go back to the OPC UA server.

Figure 7: Energy monitoring reuses the equipment structure and adds only the measurements and calculations it needs.

A shared data foundation should make both the next site and the next use case easier to introduce. Each application contributes what's specific to its purpose and inherits the rest. Instead of treating every new requirement as a separate integration exercise, teams build on a foundation that compounds.

Where to start if your pilot is ready to scale

If you already have a successful industrial data pilot, I wouldn't start by trying to define a complete enterprise-wide namespace in one exercise.

I'd start with the implementation that already works. Look at the data it uses, the context it depends on and the calculations that make it useful. Then compare that with the next line or site.

A few practical questions can help:

1. Which equipment and measurement definitions can be shared?
2. Which calculations should produce consistent results across deployments?
3. What source connections and mappings will still be specific to each site?
4. Who will validate the local measurements and own changes to the shared model?

Figure 8: Shared definitions and reusable calculations span sites. Local connections, mappings and validation stay with each one.

This is where the HiveMQ Platform can help, by bringing MQTT data streaming, governed contextualization, reusable models and derived calculations into one operational data foundation. Monitoring data health, investigating deviations and responding to them is the next half of the story, and the subject of a future session.

Conclusion: Make every industrial pilot easier to replicate

The lesson from our webinar isn't that manufacturers need to abandon their existing applications or start their data architectures again.

It's that a successful pilot should leave behind more than a working application. It should also leave behind reusable definitions, validated calculations and a clearer way of connecting the next piece of equipment.

The first pilot will always involve learning. But once that work has been done, the next team should be able to benefit from it.

A successful pilot proves that a use case works. A reusable data foundation makes it routine to repeat.

That's how manufacturers move beyond isolated successes and make their industrial data investments more valuable over time.

Watch the webinar: Escape pilot purgatory: how to define your Unified Namespace once and make every new plant routine, featuring Shashank Sharma and Kudzai Manditereza.

If you're planning to extend an existing pilot to another line or plant, connect with the HiveMQ team to discuss which parts of your current implementation can be reused and what will need local adaptation.

Scaling an AI pilot also depends on the readiness of the wider industrial data foundation, from connectivity and contextualization to analysis and governed action. Benchmark your architecture against industry peers, understand your AI maturity, and get a personalised roadmap to accelerate your AI initiatives with HiveMQ AI Maturity Assessment.

Frequently Asked Questions (FAQs)