Ask five applications at a power plant for the status of one feedwater pump, and you'll often get five different answers arriving through five different paths — a SCADA poll, a historian query, a spreadsheet export. A unified namespace fixes that by giving every piece of data one address, published once and subscribed to by anything that needs it. See how iFactory builds this on MQTT and OPC UA through a Book a Demo.
One Topic Address. Every System Subscribed. No More Point-To-Point Polling.
iFactory implements unified namespace architecture using MQTT and OPC UA, so every reading published from your plant floor arrives once at a single topic address and reaches every subscribed application instantly — dashboards, historians, analytics models, and CMMS alike.
Publish Once, Subscribe Anywhere — Why Unified Namespace Replaces Point-To-Point Polling
In a traditional plant data architecture, every application that needs a piece of data — a dashboard, a historian, an analytics model, a report generator — builds its own connection back to the source system and polls for the value it needs on its own schedule. As the number of applications grows, the number of point-to-point connections grows even faster, and every one of those polling connections adds load to the source system it's querying. A unified namespace inverts this model entirely. Instead of every application polling every source, each source publishes its data once to a defined topic address on a message broker, and any application that needs that data simply subscribes to the topic. The data arrives the instant it changes, without the subscriber ever having to ask for it. This also changes who bears the integration burden: in the polling model, every new consumer of data has to understand the source system's own query interface, authentication scheme, and data structure, while in the publish-subscribe model a new consumer only needs to know the topic address and the shared payload format, regardless of which underlying system originally produced the data.
Every application polls the source directly on its own schedule, duplicating requests and load.
The source publishes once. Every application subscribes to the same topic and receives updates instantly.
Two Protocols, Two Different Jobs Inside The Same Namespace
MQTT and OPC UA are often discussed as competing protocols, but in a well-designed unified namespace they typically work together, each covering the part of the architecture it is best suited for. Understanding where each one fits prevents the common mistake of trying to force one protocol to do a job the other handles better. Teams new to this architecture sometimes try to run OPC UA all the way out to every subscribing application, which reintroduces much of the connection overhead the unified namespace was meant to eliminate in the first place, or they try to use MQTT to pull data directly from a PLC without an intermediate OPC UA layer, which forfeits the rich data typing and security model that OPC UA already provides at the source.
MQTT — The Namespace Backbone
MQTT is a lightweight publish-subscribe protocol built for exactly the topic-based namespace model described above. It defines the topic hierarchy, handles the broker that routes messages between publishers and subscribers, and is efficient enough to run over constrained networks including cellular and satellite links common at remote sites.
OPC UA — The Source Connection
OPC UA is the protocol most SCADA, DCS, and PLC platforms already expose natively, with rich data typing, security certificates, and a standardized information model. It is typically used to connect the unified namespace to the actual control system source, translating OPC UA tags into MQTT topics that the rest of the namespace subscribes to.
Sparkplug B — The Missing Convention
Raw MQTT does not define a payload format or a session state model on its own, which is where the Sparkplug B specification fills the gap by defining a standard topic namespace structure, a compact binary payload format, and birth and death certificates that tell subscribers whether a device is currently online.
Stop Polling. Start Publishing.
iFactory builds your unified namespace on MQTT and OPC UA so every application in the plant subscribes to one shared topic address instead of polling the source directly.
Structuring Topics On The ISA-95 Model So Every Address Is Predictable
A unified namespace only stays usable if its topic hierarchy follows a consistent, predictable structure that mirrors how the plant is physically organized. Most successful implementations base their topic structure on the ISA-95 equipment hierarchy, which defines a natural nesting from enterprise down to individual equipment. A well-formed topic address reads almost like a physical address for a piece of data, making it possible for any engineer to guess the correct topic for a new data point without having to look it up.
A topic address built on this model for a feedwater pump might read as Enterprise/PlantA/BoilerArea/Unit2/FeedwaterPump1/Vibration, giving any subscriber both the exact data point and its full physical context in a single readable string, without needing a separate lookup table to figure out which equipment the reading belongs to. This same structure also makes it straightforward to subscribe to an entire branch of the hierarchy at once — a dashboard interested in every reading from Unit 2 can subscribe to Enterprise/PlantA/BoilerArea/Unit2/# using MQTT's wildcard syntax and automatically receive every tag published anywhere beneath that branch, including new equipment added later, without needing to update the subscription each time.
Choosing And Sizing The MQTT Broker That Sits At The Center Of The Namespace
The broker is the single most important architectural decision in a unified namespace deployment, since every publisher and every subscriber depends on it being available, fast, and secure. The comparison below covers the deployment models most plants choose between.
| Deployment Model | Latency | Best Fit |
|---|---|---|
| On-Premise Edge Broker | Sub-millisecond to plant applications | Plants requiring local control room responsiveness even during a network outage |
| Cloud-Hosted Broker | Tens to hundreds of milliseconds | Enterprise-wide dashboards spanning multiple sites and remote analytics |
| Hybrid Edge-To-Cloud | Local sub-millisecond, cloud bridged | Plants needing both real-time local response and centralized multi-site visibility |
Most power generation facilities land on the hybrid model, running an edge broker on-site for control-room-critical subscribers and bridging a filtered subset of topics to a cloud broker for enterprise reporting and cross-site analytics. The edge broker keeps operating independently even if the connection to the cloud is temporarily lost, which matters for plants where control room dashboards and local alarm systems cannot tolerate any dependency on internet connectivity, while the cloud bridge still gives corporate teams the fleet-wide visibility they need without requiring every enterprise application to reach back into the plant network directly.
What Changes When Data Stops Being Polled And Starts Being Published
The shift from polling to publish-subscribe produces measurable reductions in both network load and the time it takes new applications to come online, since a new subscriber only needs to know the topic address rather than negotiate a new connection to the original source system. These reductions compound over time as more applications join the namespace, because each additional subscriber adds essentially no incremental load to the source systems themselves — the broker absorbs the fan-out, not the SCADA or DCS platform that originally produced the data.
Publishing Data Outward Doesn't Mean Opening The Control Network
Because a unified namespace touches every SCADA and DCS system in the plant, it draws close scrutiny from OT security teams, and rightly so. A properly designed namespace keeps the same segmentation boundaries the plant's cybersecurity policy already requires, rather than creating a new path around them.
Read-Only At The Source
The OPC UA connection feeding the namespace reads tag values from the control system; it never writes setpoints or commands back, keeping the namespace fully outside the control loop itself.
Broker At The OT-IT Boundary
The broker is typically deployed at the demilitarized zone between the control network and the enterprise network, consistent with the same segmentation model used for any other OT-to-IT data flow.
Authenticated Publishers And Subscribers
Every publisher and subscriber connects to the broker using TLS encryption and certificate or credential-based authentication, so only authorized applications can publish to or read from any given topic.
Topic-Level Access Control
Access control lists on the broker restrict which topics each authenticated client can publish to or subscribe from, so a dashboard application can be limited to read-only access on relevant topics rather than the entire namespace.
A Practical Rollout Path, Not A Plant-Wide Rip And Replace
Plants that succeed with unified namespace adoption almost always start with a single area or unit rather than attempting to publish every tag across the entire facility on day one. This lets the topic hierarchy, payload conventions, and broker configuration get tested and refined on a smaller scope before being extended plant-wide, where mistakes become far more expensive to correct.
Where Unified Namespace Projects Tend To Go Wrong
The unified namespace pattern is conceptually simple, which is exactly why it's easy to underestimate the discipline it requires to implement well. Most of the problems plants run into trace back to a handful of avoidable mistakes made early in the rollout.
Publishing Before The Hierarchy Is Final
Once dozens of subscribing applications are built against a topic structure, renaming or reorganizing that structure means updating every subscriber, which is far more disruptive than spending an extra week finalizing the hierarchy design before the first tag is ever published.
No Convention For Payload Format
Without a shared standard like Sparkplug B, different teams end up publishing payloads in inconsistent formats, forcing every subscriber to write its own parsing logic for each publisher rather than relying on one predictable structure across the entire namespace.
Treating The Broker As A Single Point Of Failure
Because every subscriber depends on the broker, a namespace built on a single unclustered broker instance with no failover plan turns a broker outage into a plant-wide data blackout, which is why production deployments typically run clustered or high-availability broker configurations.
Publishing Too Much, Too Often
Publishing every tag at maximum scan rate regardless of whether it changes floods the namespace with redundant messages; report-by-exception publishing, where a value is only republished after it changes meaningfully, keeps the namespace efficient without sacrificing responsiveness.
We had six different applications each polling our DCS historian on their own schedule, and during peak reporting periods the historian query queue would back up badly enough that even our own operators noticed slow trend loading. After moving to a unified namespace built on MQTT with OPC UA feeding the source data, every one of those six applications now subscribes to the same topic set instead of hammering the historian with separate queries. Query load on the historian itself dropped dramatically, and new dashboards our engineering team builds now come online in a day instead of a week.
Frequently Asked Questions
Q: Do we need to replace our existing SCADA or DCS system to implement a unified namespace?
No. A unified namespace sits above your existing SCADA and DCS systems rather than replacing them. iFactory connects to these systems through their native OPC UA interfaces, translating the tags they already expose into MQTT topics published to the namespace. Your control engineers keep using the same SCADA and DCS interfaces they already know for real-time control, while the unified namespace becomes the shared data layer that every other application in the plant subscribes to. Reach out through Support Contact to review your specific SCADA and DCS versions.
Q: What happens to applications that were already polling our historian directly — do they need to be rebuilt?
Most existing applications can be migrated to subscribe from the unified namespace rather than being rebuilt from scratch, since the underlying data they need is still available, just delivered through a different mechanism. In practice, plants typically run both models in parallel during a transition period, gradually moving applications over to subscription-based access as time allows, rather than requiring a single cutover date where everything must change at once. A Book a Demo session can walk through what this migration path looks like for your specific application list.
Q: Is MQTT secure enough for data coming from a power plant control network?
MQTT supports TLS encryption for data in transit and username, password, or certificate-based authentication for both publishers and subscribers connecting to the broker, which is the same security model widely used in industrial IoT deployments across other critical infrastructure sectors. The broker itself is typically deployed on the OT-to-IT boundary rather than inside the control network itself, and the OPC UA connection feeding the namespace remains read-only from the control system's perspective, so the namespace never gains write access back into SCADA or DCS control logic.
Q: How do we decide on the topic hierarchy structure before we start publishing data?
The topic hierarchy should be designed before any data is published, because retrofitting a hierarchy after hundreds of topics already exist is far more disruptive than getting it right at the outset. Most plants base their structure on the ISA-95 equipment hierarchy already used in their asset management systems, which means the naming convention work often overlaps with an existing CMMS asset register rather than starting from a blank page. iFactory's implementation process includes a topic hierarchy design phase specifically to avoid this rework later.
Q: Can the unified namespace scale across multiple plants in our fleet, not just one site?
Yes, this is one of the primary advantages of the topic-based model over point-to-point integration. Because the topic hierarchy includes a site-level identifier by design, a single enterprise-wide broker or a bridged network of site-level brokers can host data from every plant in the fleet under one consistent namespace, letting a fleet-level dashboard subscribe to the same equipment-level topic across every site without needing a separate integration for each plant. This also means a best-practice dashboard or analytics model built for one site can typically be reused at another site in the fleet with little to no modification, since both sites publish under the same hierarchy conventions. Discuss fleet-wide namespace design with a Book a Demo.
Give Every Piece Of Plant Data One Address And One Path.
iFactory builds the unified namespace, topic hierarchy, and broker architecture your plant needs to stop polling and start publishing.
