Why Most Plants Collect Data but Can't Use It

Every modern manufacturing site has data. PLCs log thousands of tag values a second, historians hold years of process history, ERP carries orders and costs, quality systems hold inspection results, and OEM skids arrive with controllers and databases of their own. Yet many operations teams still make decisions from shift handover notes and whiteboard tallies, because those systems share no common structure and combining their data takes bespoke work each time. Metromotion Controls builds plant data and historian systems for manufacturers across Australia, and the gap we see most often is structure rather than volume: the data exists but is not organised, contextualised or reachable by the people who need it.

This guide covers where the silos form, the architecture that breaks them down, the standards that make that architecture portable, and a worked example of the structure in practice.

Where the silos form

Manufacturing data accumulates in systems that were each designed to do one job, without a shared view of the plant.

• The historian records time-series values from PLCs and instruments. It is excellent at storing what happened and poor at explaining why, or what the production impact was.
• The ERP system holds production orders, material consumption and cost data at shift-level or day-level granularity. It cannot see what the plant floor is doing in real time.
• Maintenance records sit in a CMMS or spreadsheets, linked to assets by description rather than to the events that caused failures, which makes cross-system root cause analysis difficult.
• OEM equipment islands are the silos people forget. A filler, a palletiser or a CIP skid often ships with its own PLC, HMI and local data store, exposing values through an OPC UA server, a few Modbus registers, or nothing documented at all.

Each system is accurate within its own domain but cannot answer cross-domain questions: the true cost of three unplanned stops on Line 2 last Tuesday, or time lost to changeovers versus breakdowns versus quality holds across a quarter. Without integration, those questions get answered with estimates.

The traditional fix makes the problem worse. Each new requirement gets its own point-to-point link: the historian polls the PLC, the OEE dashboard polls the historian, the reporting tool polls ERP, a new analytics package polls all three. With ten systems the number of possible point-to-point connections grows toward fifty, and every one is a bespoke integration that breaks when a tag is renamed or a server is replaced. The architecture problem is the wiring pattern, not the number of systems.

The unified namespace: one structured source of truth

The alternative is to stop wiring systems directly to each other and give the plant a single place where all current data lives, structured by where it belongs in the physical and process hierarchy. This is the unified namespace, commonly abbreviated UNS. Every system publishes its data into one hierarchical namespace and any consumer subscribes to the part it needs, so the integration count collapses from a mesh of point-to-point links to one connection per system.

The transport that makes this practical is MQTT, a lightweight publish and subscribe protocol standardised by OASIS. MQTT decouples publishers from subscribers through a central broker: a PLC gateway publishes a temperature to a topic, and the historian, an HMI and a dashboard all receive it without the publisher knowing who is listening. Add a new consumer and nothing on the publishing side changes.

Plain MQTT says nothing about how topics are named, what the payload looks like or whether a device is still online. Sparkplug B, an open specification standardised through the Eclipse Foundation, fills that gap. It adds:

• A defined topic namespace, so every device publishes to a predictable, structured path.
• An efficient binary payload carrying metrics, datatypes, timestamps and aliases compactly.
• Birth and death certificates, so a subscriber knows immediately when a device comes online or drops offline, rather than reading stale values as if they were live.
• Report by exception, so only changed values are published, keeping bandwidth and broker load low.

The state awareness is the part that matters for a source of truth. Without it, a dashboard cannot tell the difference between a value that is genuinely steady and a gateway that died an hour ago. With Sparkplug B, a missing device announces itself and the namespace stays honest.

Reading the equipment: OPC UA and the control layer

Something has to read the data out of the equipment first. That is usually OPC UA, the OPC Foundation's interoperability standard, published as IEC 62541. OPC UA carries a rich, self-describing information model, so a value arrives with its datatype, units and place in an equipment model rather than as a bare number, and it is the common way modern PLCs, gateways and OEM skids expose data securely across an OT network.

A typical pattern reads structured data out of equipment over OPC UA at the edge, maps it onto the plant's standard structure, and publishes it into the unified namespace over MQTT with Sparkplug B. The two protocols are complementary: OPC UA does the equipment modelling and secure transport from the device, Sparkplug B does the plant-wide distribution. The PLC, SCADA and HMI layer is where the raw signals are first read and standardised, and standing up the broker, edge nodes and OPC UA connections cleanly is core industrial data and IIoT work.

The standards that make it portable

A unified namespace is only worth building if it survives equipment changes and vendor turnover. Four standards turn a one-off integration into a repeatable architecture.

• ISA-95, published as IEC 62264, defines the functional hierarchy from enterprise systems down to control, and the equipment hierarchy of enterprise, site, area, line and cell. It is the backbone of a sensible namespace structure, and it is what makes MES and SCADA integration on food plants tractable rather than bespoke.
• OPC UA, published as IEC 62541, provides the self-describing information model and secure transport for reading equipment data.
• MQTT, standardised by OASIS, is the lightweight publish and subscribe transport the namespace runs on.
• Sparkplug B, standardised through the Eclipse Foundation, defines the topic structure, payload, state awareness and report-by-exception behaviour that make industrial MQTT reliable.

Anchoring the namespace to these standards gives a site one agreed structure rather than a house interpretation the next integrator or the next OEM cannot read.

Worked example: a unified namespace for one packaging line

The tag paths and structure below are illustrative, not a record of any Metromotion Controls project or client.

Consider a food and beverage site, "Plant A", whose packaging area contains two lines. Line 2 has a filler, a capper, a labeller and a palletiser, each from a different OEM. Aligning the namespace to the ISA-95 equipment hierarchy gives a structure where every topic reads left to right as enterprise, site, area, line, then equipment and metric:

PlantA/Sydney/Packaging/Line2/Filler/State
PlantA/Sydney/Packaging/Line2/Filler/Speed_bpm
PlantA/Sydney/Packaging/Line2/Filler/GoodCount
PlantA/Sydney/Packaging/Line2/Filler/RejectCount
PlantA/Sydney/Packaging/Line2/Capper/State
PlantA/Sydney/Packaging/Line2/Labeller/State
PlantA/Sydney/Packaging/Line2/Palletiser/State
PlantA/Sydney/Packaging/Line2/Line/CurrentOrder
PlantA/Sydney/Packaging/Line2/Line/CurrentSKU
PlantA/Sydney/Packaging/Line2/Line/TargetRate_bpm

A consumer that only cares about line throughput subscribes to PlantA/Sydney/Packaging/Line2/#. A site dashboard subscribes to PlantA/Sydney/#. The historian subscribes to everything it needs to retain. Nobody connects to the filler's PLC directly. Each metric arrives as a Sparkplug B payload with a datatype and timestamp, and each edge node publishes a birth certificate when it connects and a death certificate if it drops off, so a consumer reading Filler/State knows both the state and that the reading is live.

Two pieces of context turn the values into usable data. The Line/CurrentOrder and Line/CurrentSKU metrics, published from the MES or order system into the same namespace, let any consumer join a process value to the product being made when it was recorded. The equipment-level GoodCount and RejectCount let an OEE calculation read counts directly rather than inferring them. Because the context lives alongside the process data, the historian records contextualised history automatically: a query for rejects on Line 2 while running SKU 4471 last Tuesday is answerable without joining four systems after the fact.

This is also where OEM islands get absorbed. Suppose the labeller exposes only an OPC UA Running boolean and a lifetime totaliser. An edge node reads both, derives a PackML-style state and a per-shift count by differencing the totaliser, and publishes Labeller/State and Labeller/GoodCount in the same structure as every other machine. The rest of the plant sees one consistent line, not four incompatible vendor formats. That mapping work is the heart of multi-OEM systems integration.

How to choose an approach

Not every site needs a full unified namespace on day one. Work through these questions before committing to an architecture.

• What questions must the data answer, and for whom? Operations need what is running, what stopped and why, and output against target; engineering needs asset performance and failure patterns. The questions determine which sources matter and how the namespace is structured.
• How many systems and OEM islands need connecting? With three tightly coupled systems, a couple of point-to-point links may be defensible. Past five or six, a broker-based namespace pays for itself by collapsing the integration count.
• Do you need current state, history, or both? A UNS holds current state. If the questions are about trends and root cause over time, a historian must subscribe to the namespace. Most sites need both.
• Can the OT network carry it safely? A broker concentrates traffic and trust, so the network has to be segmented and the broker secured. Plan this with the OT networks work rather than bolting it on later.
• Will the structure survive an equipment swap? If the namespace is aligned to the ISA-95 hierarchy, replacing an OEM skid means remapping one edge node, not rewriting every downstream consumer.

As a working rule: structure to ISA-95, read equipment over OPC UA where available, distribute over MQTT with Sparkplug B, and treat the historian as a subscriber rather than the hub. That pattern scales from one line to a site.

Common mistakes

• Buying a dashboard before fixing the structure. A reporting tool layered onto unconnected silos becomes another silo. The structure comes first; the dashboard is a consumer of it.
• Using plain MQTT without Sparkplug B. Topics drift into inconsistent names, payloads vary by publisher, and there is no way to tell a live value from a dead gateway.
• Organising the namespace by system instead of by hierarchy. A namespace structured as Historian/... and SCADA/... rebuilds the silos in a new place. Structure it so the topic describes the thing, not the source.
• Treating OEM islands as too hard. A skid that exposes only a totaliser and a running contact can still be mapped and republished by an edge node. Left alone, it undermines any line-level view.
• Ignoring contextualisation. Process values without their order, SKU and equipment context are just numbers. Publishing context into the same namespace is what makes history analysable later.
• Leaving the broker and network as an afterthought. Concentrating data through a broker without segmentation, authentication and monitoring creates a single point of both failure and exposure.

The Australian context

Australian manufacturing sites tend to run mixed-vintage equipment: a recent line next to a plant extended in stages over twenty years, with PLCs and OEM skids from several eras and vendors. That mix is exactly the environment a unified namespace suits, because it absorbs old and new equipment behind one consistent structure rather than forcing a rip-and-replace.

Hygienic food, beverage and dairy plants add a further reason to contextualise well. CIP and sanitation cycles consume large amounts of equipment time and also have to be recorded for food safety, so a CIP event captured once in the namespace serves both the production view and the cleaning evidence the plant has to keep. The same namespace can feed vibration, temperature and motor-current data into an IIoT condition monitoring programme without a parallel data path.

Two practical constraints shape local projects. OT security expectations are rising, and the Australian Cyber Security Centre publishes guidance relevant to the segmented networks a broker-based architecture depends on, so the namespace and the OT networks that carry it should be designed together. And because most sites cannot stop production for an integration, the namespace is usually built incrementally, one line or area at a time, alongside live operation.

What this means

Most Australian manufacturing sites are not short of data; they are short of data infrastructure that makes it usable. Breaking down the silos is an architecture decision before it is a tooling decision: stop wiring systems point to point, give the plant one structured namespace aligned to ISA-95, read equipment over OPC UA, distribute over MQTT with Sparkplug B, and let the historian and every dashboard subscribe to the same source of truth. Done that way, integrating the next OEM island or answering the next cross-system question is a small extension rather than another bespoke project.

References

• ISA-95 / IEC 62264, Enterprise-control system integration (functional and equipment hierarchy): https://www.iso.org/standard/57308.html
• OPC Foundation, OPC Unified Architecture technology overview: https://opcfoundation.org/about/opc-technologies/opc-ua/
• MQTT, official protocol site (OASIS-standardised publish/subscribe transport): https://mqtt.org/
• Sparkplug, the Eclipse Foundation specification for MQTT industrial interoperability: https://sparkplug.eclipse.org/specification/