Historians, PLCs, OEM islands and ERP systems generate large amounts of data. The gap is that none of those systems share a common structure, so the data cannot be combined into something useful without bespoke point-to-point integration.
Publishing every system's data into a single, hierarchical namespace over MQTT with Sparkplug B, fed from OPC UA and the control layer, replaces brittle point-to-point links with one consistent, self-describing structure aligned to ISA-95.
OPC UA (IEC 62541), MQTT and Sparkplug B, and the ISA-95 (IEC 62264) equipment hierarchy turn an ad hoc integration into a repeatable architecture that survives equipment changes and vendor turnover.
Every modern manufacturing site has data. PLCs log thousands of tag values every second. Historians store months or years of process data. ERP systems hold production orders, material movements and cost allocations. Quality systems capture inspection results and batch records. OEM skids arrive with their own controllers, their own dashboards and sometimes their own databases.
And yet many operations teams still make decisions from shift handover notes, whiteboard tallies and memory. The data exists. The ability to use it, reliably and quickly, often does not. Metromotion Controls is a control systems integrator based in Mount Waverley that builds plant data and historian systems for manufacturers across Australia, and the gap we see most often is structure: the data is rarely organised, contextualised or made accessible in the right format to the right people at the right time.
This guide covers where the silos form, the architecture that breaks them down, the standards that make that architecture portable, a worked example of how the structure looks in practice, how to choose an approach, and the mistakes that quietly undermine a data programme.
Manufacturing data tends to accumulate in separate systems that were each designed to do a specific job, without a shared view of what is happening across the plant.
The result is that each system is accurate within its own domain but cannot answer cross-domain questions. Questions like: what was the true cost of the three unplanned stops on Line 2 last Tuesday? How much time was lost to changeovers versus breakdowns versus quality holds across the quarter? Those questions require data from multiple systems, and without integration they 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 alternative is to stop wiring systems directly to each other and instead 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.
In a UNS, every system publishes its data into one hierarchical namespace and any consumer subscribes to the part it needs. The historian, the OEE dashboard, the reporting tool and a future analytics package all read from the same structure rather than each building its own link to the source. The number of integrations collapses from a mesh of point-to-point links to a single connection per system into the namespace.
The transport that makes this practical is MQTT, a lightweight publish and subscribe protocol standardised by OASIS and widely used in industrial IIoT. MQTT decouples publishers from subscribers through a central broker: a PLC gateway publishes a temperature value to a topic, and the historian, an HMI and a dashboard all receive it without the publisher knowing or caring who is listening. Add a new consumer and nothing on the publishing side changes.
Plain MQTT alone is not enough, because it says nothing about how topics should be named, what the payload looks like or whether a device is still online. That is the gap Sparkplug B fills. Sparkplug B is an open specification, now standardised through the Eclipse Foundation, that defines how industrial devices use MQTT. It adds:
The state awareness is the part that matters for a single 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.
MQTT and Sparkplug B move and structure the data, but something has to read it out of the equipment first. That is usually OPC UA, the OPC Foundation's open 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. It is the common way modern PLCs, gateways and OEM skids expose their 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. OPC UA does the equipment modelling and secure transport from the device; Sparkplug B does the plant-wide distribution. The two are complementary rather than competing, and the PLC, SCADA and HMI layer is where the raw signals are first read and standardised before they ever reach the namespace. Standing up the broker, the edge nodes and the OPC UA connections cleanly is core industrial data and IIoT work.
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.
Anchoring a namespace to these standards matters for the same reason anchoring an OEE programme to ISO 22400 matters: it gives a site one agreed structure rather than a house interpretation that the next integrator or the next OEM cannot read.
The following is illustrative. The tag paths, values and structure are an example of how a namespace can be laid out for a single line, not a record of any specific Metromotion Controls project or client.
Consider a typical food and beverage site, "Plant A", with a packaging area containing 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 from 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_bpmA 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.
A Sparkplug B payload published to the filler topic carries more than a value. For example, a State metric publishes a value such as Execute with a datatype and a timestamp, and the filler's edge node publishes a birth certificate when it connects and a death certificate (via the broker's last will) if it drops off. A consumer reading Filler/State therefore knows the state is Execute, and from the timestamp and quality that the reading is live.
Two pieces of context turn this from raw values into usable data. First, 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. Second, the equipment-level GoodCount and RejectCount let an OEE calculation read counts directly rather than inferring them. Because the context lives in the namespace 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 separate 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 over OPC UA, derives a PackML-style state and a per-shift count by differencing the totaliser, and publishes Labeller/State and Labeller/GoodCount into the namespace 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.
Not every site needs a full unified namespace on day one. The sensible questions to work through before committing to an architecture:
As a rule of thumb: standardise the structure to ISA-95, read equipment over OPC UA where it is 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.
Historian/... and SCADA/... rebuilds the silos in a new place. Structure it by the ISA-95 equipment hierarchy so the topic describes the thing, not the source.Australian manufacturing sites tend to run mixed-vintage equipment: a recent line next to a plant that has been 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 data 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 can serve both the production view and the cleaning evidence a plant has to keep. For sites running condition-based maintenance, the same namespace feeds vibration, temperature and motor-current data into an IIoT condition monitoring programme without a separate parallel data path.
Two practical constraints shape Australian projects. First, OT security expectations are rising, and the Australian Cyber Security Centre publishes guidance relevant to the segmented networks a broker-based architecture depends on; the namespace and the OT networks that carry it should be designed together. Second, many sites cannot stop production for an integration, so the namespace is usually built incrementally, one line or area at a time, alongside live operation rather than in a single cutover.
Most Australian manufacturing sites are not short of data. They are short of data infrastructure that makes the data 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. Adding technology before that structure is in place rarely solves the underlying problem.
Tommy Kim writes for Metromotion Controls, a Melbourne control systems integrator delivering PLC, SCADA, controls integration and commissioning for food, beverage, dairy and FMCG manufacturers across Australia.
A unified namespace (UNS) is a single, structured, hierarchical view of all of a plant's current data, organised by where each value belongs in the physical and process hierarchy rather than by which system produced it. Every system publishes its data into the namespace and any consumer subscribes to the part it needs, so there is one agreed source of truth instead of dozens of point-to-point links. The structure is usually aligned to the ISA-95 (IEC 62264) equipment hierarchy of enterprise, site, area, line and cell.
No. They solve different problems and are often used together. OPC UA (IEC 62541) is an industrial interoperability standard with a rich information model that is strong at modelling equipment and exposing it from PLCs and gateways. MQTT is a lightweight publish and subscribe transport that decouples publishers from subscribers through a central broker. Sparkplug B is a specification that defines how to use MQTT for industrial data with state awareness and a defined payload. A common pattern reads structured data out of equipment over OPC UA and publishes it into a unified namespace over MQTT with Sparkplug B.
Sparkplug B is an open specification, now standardised through the Eclipse Foundation, that defines how industrial devices use MQTT. Plain MQTT says nothing about topic structure, payload format or whether a device is online. Sparkplug B adds a defined topic namespace, an efficient binary payload, birth and death certificates so consumers know when a device drops offline, and report-by-exception so only changed values are published. Those rules are what make a unified namespace reliable rather than a loose collection of topics.
A unified namespace holds the current state of the plant. A historian, or a time-series store, records how those values changed over time. In a UNS architecture the historian becomes one more subscriber: it listens to the namespace and records what it needs, rather than being polled directly by every reporting tool. Contextualisation, attaching each value to its equipment, product and order, is what turns raw history into data an analyst can use, and it is far easier when the context already lives in the namespace structure.
OEM skids often arrive with their own PLC, HMI and sometimes a local historian, exposing data through an OPC UA server, a handful of Modbus registers or nothing documented. Integration means mapping each island's native tags onto the plant's standard structure, ideally an ISA-95 aligned equipment model, and publishing that mapped data into the unified namespace. Where an island exposes only a totaliser or a running contact, an edge device or gateway reads it, normalises it and republishes it so the rest of the plant sees one consistent structure regardless of vendor.
Four matter most. ISA-95, published as IEC 62264, defines the enterprise-to-control equipment hierarchy and the integration models that give a namespace its structure. OPC UA, published as IEC 62541, provides the interoperable information model and secure transport for reading equipment data. MQTT is the OASIS-standardised publish and subscribe transport. Sparkplug B, standardised through the Eclipse Foundation, defines how to use MQTT for industrial data with state awareness. Together they turn a one-off integration into a portable architecture.
OEE, downtime, historian and production reporting systems built from reliable plant signals.
Connect OEM equipment, line controls, data systems and site standards into one operating environment.
Ignition Perspective, historian, reporting, SQL integration and production dashboards.
Line integration, OEE data and controls upgrades for high-volume manufacturing sites.
The ISA-95 levels, the SCADA-to-MES boundary, production tracking and genealogy, B2MML and ERP integration for food manufacturers.
Condition monitoring to ISO 17359 and ISO 13374, the P-F curve, MQTT and OPC UA data acquisition, and how condition data ties into OEE.
A practical guide to IIoT condition monitoring for Australian manufacturers, covering ISO 17359 and ISO 13374, the P-F curve, vibration, temperature and current sensing, MQTT and Sparkplug B, OPC UA, and how condition data ties into the historian and OEE.
Key point
Condition monitoring is a discipline with standards behind it
Published 9 May 2026
OEE is useful but routinely over-trusted. This guide covers what OEE leaves out by design, where it distorts on multi-SKU Australian food and beverage lines, why cross-line comparisons fail, and the one limitation that is actually fixable: the signal layer between the machine and the dashboard.
Key point
OEE measures how efficiently a line ran, not whether it made the right thing
Published 9 May 2026
A practical OT network security guide for Australian manufacturers: IEC 62443 zones and conduits, the Purdue model, segmentation, secure remote access, OT patch constraints, and the ACSC Essential Eight applied to plant networks.
Key point
OT networks need their own security model
Published 9 May 2026
Map out scope, delivery approach and what to have ready before the first conversation. Answer a few questions and Metromotion Controls returns a tailored scoping brief on screen.