Cutting Through the NoiseOPC UA, MQTT, UNS, IX³, and why none of them is the silver bullet
You are being told to standardize on one thing, and which thing it is changes depending on who is in the room.
This paper sets out what I would do instead, which is a layered and secure way to get plant data to the people who need it, and it holds up in a site you inherited as well as in one you are building from scratch.
Audience: OT/IT Digital Transformation Leaders, Cybersecurity Teams, and Executive Leadership.
Executive Summary
The conversation is louder than the outcomes.
Ask five people how to get your plant data into the hands of the business and you will get five confident answers: adopt a Unified Namespace, standardize on MQTT, deploy an IX³ platform, or move everything to OPC UA. None of those answers is wrong, but every one of them is incomplete, and I watch the same thing happen because of it. The project starts as a protocol decision, then it turns into a governance argument, then it stalls in security review, and in the end it fragments into site-by-site exceptions.
So why is the market confused, and why is it entirely reasonable that your team is confused too? Because these four things are not four competing answers to one question. They are partial answers to four different questions, and the industry keeps presenting them as if they were interchangeable. My conclusion is a simple one. MQTT, the Unified Namespace, OPC UA and IX³ each do real work, but they do different work, and digitalization succeeds when you layer them on purpose. That matters most where your data crosses a security boundary and where you are working with equipment you already own. OPC UA stays in the equation, because industrial systems need an agreed way to say what a number means, and that need does not go away when you delete the protocol.
I have kept this paper vendor-neutral, and it does not recommend a single product.
It does describe the architectural need for a secure data-access and enforcement layer between your plant and your business, one that governs what gets exposed, who is asking, what the policy allows, what gets recorded and how older protocols get carried across, because you will need that layer whichever vendor you end up choosing.
01 · The Problem
Why the conversation feels harder than it should.
You are asked to deliver reliability, efficiency, maintenance you can see coming, lower energy use, sustainability reporting, consistent measures across your sites and faster innovation. And you are asked to deliver all of it on top of decades of installed equipment, under modern cybersecurity expectations. At the same time, industrial data architecture is riding a marketing wave where a pattern or a protocol gets sold to you as a complete strategy. When every option is positioned as “the foundation,” you are the one left to reconcile the claims.
I do not think that confusion is an engineering failure. It is what happens when several separate concerns get collapsed into a single conversation. Moving data, agreeing what the data means, organizing it so people can find it, keeping a durable history, and governing who may see or change it are five different jobs. Most public discussions run them together, so a team tries to solve all five with one tool. That is why projects built on perfectly sound technology still fall apart on history and on being able to act on what they collected.
Brownfield makes it harder still. Even inside one company, no two of your sites are the same, because the naming differs, the network segmentation differs, the control philosophy differs, the security posture differs and the integration maturity differs. An architecture that ignores that becomes brittle the moment you take it to the second site.
02 · Definitions
The terms that get confused, and why none is the silver bullet.
The quickest way I know to turn the volume down is to separate these four by the job each one was built to do. Here is each of them at its best, and then the part it was never designed to cover.
MQTT is a lightweight way of moving messages around. Something publishes a message to a broker, anything that cares about that subject subscribes and receives it, and the two ends never have to know about each other. It is simple, efficient and cloud-friendly. MQTT is about moving data.
What it does not do: It does not describe what your data means, it does not keep your naming consistent, it does not decide what counts as “trusted,” and it does not replace a historian. You can encrypt the traffic and lock down the broker, but deciding who may read or write which object, and being able to prove afterwards who did, is still yours to design.
A Unified Namespace organizes the current state of your operation into one shared picture the whole company can see, and it is usually built on an MQTT broker with Sparkplug. It makes data easier to find and it cuts down the tangle of point-to-point connections, because consumers subscribe to agreed topics that stand for assets and events.
What it does not do: When I see a UNS project fail, the idea itself is not what failed. What failed is the assumption that organizing data is the same thing as governing it. A namespace organizes the shape of your data, and it does not on its own guarantee that two sites name things the same way, that schema changes are controlled, that writing back has a policy, that you can trace who did what, or that your history holds up. You have to design every one of those on purpose.
OPC UA is the industrial standard for saying what a piece of data means, and not only what it reads. It carries structured data types, descriptions, object models, secure sessions and standard ways to handle events and history. It belongs to no vendor, and it is the usual way to present plant data in a consistent, structured form.
What it does not do: People call OPC UA “too complex,” and it can be. But taking it out usually takes the shared vocabulary out with it, and you fall back on ad hoc naming and homemade payload conventions. That trade tends to come back later as analytics friction, inconsistent models and governance pain.
IX³ is a useful three-layer simplification into edge, platform and enterprise. It catches on because it is easy to say in a meeting and easy to draw on a whiteboard.
What it does not do: The risk is that the platform layer becomes a catch-all where transport, modeling, governance, storage and security are all assumed to be handled already. That assumption is where the confusion multiplies.
Read those four side by side and the title of this paper is already settled. None of them is the whole answer, because each one was built to solve a different part of the same problem.
03 · Competing Narratives
The strongest arguments on each side.
Public papers and vendor blogs take strong positions, because they are written to drive adoption rather than to describe an architecture. Here is the best argument I can make on each side, since that is the fastest way to see where an idea genuinely helps you and where it quietly breaks.
UNS caught on because it answers a real pain, which is the sprawl of point-to-point connections. A brokered publish-and-subscribe backbone separates the systems producing data from the systems consuming it, improves visibility and gets new use cases running faster. That makes it a practical way to organize data you want to reuse in many places.
UNS gets misread as the system that “holds everything.” The broker holds current state and the flow of events, and it does not hold long-term history. If you treat it as a historian, you create gaps in replay and in what you can show an auditor. If you treat topic naming as modeling, you end up with inconsistent context. And if you treat broker security as governance, you have skipped identity, policy enforcement and audit depth.
MQTT is excellent at distribution at scale, and Sparkplug helps systems understand each other by giving payloads a structure and adding rules about state. The limit is not in the transport. It is in the assumption that transport supplies meaning. If you have not agreed on structure upstream, MQTT becomes a very fast way to deliver inconsistent data.
OPC UA anchors industrial data to structured meaning through vendor-neutral models, secure sessions, events and, where somebody implements it, access to history. Take it out and the complexity does not disappear. It moves downstream into naming conventions, payload contracts and custom mapping code, and your team ends up rebuilding the same shared vocabulary informally, at greater expense and with less governance.
The newest narrative is AI-ready data.
The strongest argument I hear in the integration layer today is that plant data should arrive already in context, governed, and continuous enough for models and agents to use. I think that is a good argument. What it leaves out is how the data crosses the boundary between your plant and your business in the first place, meaning which side opens the connection, whose identity crosses with it and what gets written down. Read the note: AI-ready data still has to cross the boundary →
04 · The Foundation
Establishing the industrial data foundation.
A unified industrial data foundation is not a product and it is not a protocol. It is a way of building so that everyone who needs operational data gets it consistently and safely. It joins the places your data lives, which are your control systems, historians, edge devices and business systems, to the people waiting for it in operations, engineering, IT and cybersecurity, data science and executive leadership, and it does that through one governed interface instead of forty private ones.
Your business performs better when your data is connected, trusted, and actionable.
What you get from that is practical. Your architecture looks the same at every site, access to plant data is secure and governed, IT and OT stop arguing about who owns the path, and you have something you can build cloud and analytics work on without starting over.
05 · Layered Architecture
A layered architecture that matches reality.
So stop treating digitalization as a protocol decision, and treat it as a layered architecture that crosses your security boundaries. Once you look at it that way the confusion becomes obvious, because most conversations start in the middle, at transport, instead of at the top with the outcome you want and at the bottom with the constraints you actually have.
- 5.1Governance & StrategyOutcome-Driven Design
Digitalization starts with what you are trying to achieve and what stands in your way. What is the business outcome? What information do you need to get there? Where does that data live today? How fast does it have to move? Which security boundaries does it have to cross? Who decides who is allowed in, and who checks afterwards? Those questions shape the architecture far more than any protocol debate does.
- 5.2Modeling & NormalizationWhere OPC UA Leads
Data has to be usable and trusted, and that means putting it in context, making it consistent and giving it the same structure everywhere. OPC UA gives your plant sources one vendor-neutral, structured face. In a site you inherited it turns legacy and proprietary protocols into consistent models. In a new build it sets those models from the start, so growing does not pull your naming apart.
- 5.3Secure Access & Enforcement LayerThe OT/IT Bridge
Between your plant and your business you need a layer that decides how data gets exposed. That means controlled flow, segmentation that matches your security zones, strong proof of who is asking, permissions by role, encryption in transit, and audit logging detailed enough to be worth reading. It can tie into the directory your company already uses for logins, and it can feed your security monitoring. Older protocols get carried across here too, whether that is tunnelling OPC Classic, pulling several OPC UA servers together, or publishing OPC UA data sets into MQTT. I want to be clear that this layer does not replace protocols, because its job is to govern exposure and cut risk while still letting people in.
- 5.4Transport & DistributionWhere MQTT Excels
Once your data is structured and secured, MQTT distributes it at scale without tying systems to one another, so you get event-driven integration with far fewer point-to-point links. This is where most UNS implementations sit, with MQTT as the backbone and with topic conventions and Sparkplug giving the payloads a shape.
- 5.5Organization & VisibilityUNS as an Operating Pattern
Done well, UNS makes naming and models consistent, keeps your sites aligned and makes integration simpler for the applications on top. Done badly, it turns into a naming argument and a schema-drift problem. What decides which one you get is governance and modeling discipline, and not the broker.
- 5.6Persistence & HistoryHistorians Still Matter
A broker is not a historian. Industrial work needs long-term history, replay, correction, retention and audit support, so historians and time-series systems stay essential. Your architecture should say how live streams, alarms and events, and history relate to one another, and it should never assume that one of them replaces another.
Layer the jobs on purpose: agree what your data means, guard the boundary it crosses, then move it, then organize it, and keep history where history belongs.
06 · Two Playbooks, One Architecture
Brownfield vs greenfield.
The sites you inherited became multi-vendor by accident rather than by plan. They hold decades of capital, and the plant systems, the business systems and the security systems in them grew up in separate rooms. Networks are cut into security zones, and naming and data models differ from site to site. Winning here means working with what you already own instead of ripping it out.
Two playbooks, and one layered, governed architecture.
Your control systems and legacy sources connect through gateways and adapters, and the data gets turned into consistent structured models, commonly with OPC UA. A secure enforcement layer then governs how that data crosses between your plant and your business, MQTT distributes it, and UNS organizes the enterprise picture. Historians keep the time-series and event records, and your business systems and analytics subscribe to the governed data.
A new build lets you put structure in early. Devices may speak OPC UA out of the box, you set standard asset models on day one, you design your segmentation and your logins upfront, and you lay MQTT and UNS on top for distribution and visibility. Greenfield carries less debt because it settles what the data means before it starts moving it.
Water is where I see the brownfield constraint at its sharpest.
A federal alert on July 30 told water and wastewater utilities to take internet-exposed control equipment off public networks. That closes the way in, but it does not remove the reasons the way in existed, so it turns a brownfield data question into a question about which side opens the connection. Read the note: Water data after the disconnect →
07 · Treat Each Category Correctly
Real-time, alarms & events, history, and files.
Digitalization projects fail when every kind of data gets treated the same way. Your plant produces several different kinds, and each one comes with its own requirements.
Live state feeds your dashboards, your sense of what is happening right now, and the workflows that react to it. MQTT distributes it well, as long as the data was already structured and secured before it got there.
Alarms and events only mean something with their context attached, which is severity, timestamps, whether somebody acknowledged them, and where they came from. OPC UA has standard ways to carry all of that into enterprise event streams. The trick is keeping that structure intact when you bridge into MQTT topics and payloads.
History needs replay, retention and integrity. Historians stay central for keeping time-series records, and your UNS should point at them rather than try to be one. Decide how history gets reached, how corrections are handled, and how a consumer reconciles a live reading with a stored record.
Not everything in a plant is a tag, because reports, recipes, quality documents and configuration files all have to move as well. Those go through secure file services or controlled method calls, with governance and audit logging around them. Treating a file as “just another MQTT message” works for a notification, and it does not work for controlled transfer or for a record somebody will audit.
08 · Decision Framework
How to cut through the noise.
Get your team to agree on an order: the outcome first, then the information, then the constraints, then the layering, and only then the technology. The questions below matter more than the protocol debate does, so work through them before anyone opens a product page.
- 01What business outcome are you after, whether that is reliability, yield, energy, safety, compliance or simply reaching an answer faster?
- 02What information do you need to deliver it, meaning which signals, events, context, history and documents?
- 03Where does that data live today, in control systems, historians, edge gateways or business applications?
- 04How fast does it have to move, and what happens when the link drops?
- 05Which security boundaries does it have to cross, and what are your rules on remote access?
- 06Who decides who is allowed in, who approves a change, and who checks the records afterwards?
- 07How will you keep your sites consistent on naming, on models, on the measures you steer by, and on schema changes?
- 08What has to be kept, and where does it get kept?
- 09What is your position on writing back to the plant, meaning read-only for now, controlled writes later, and by which mechanism?
Here is the order I would work in on a site you already own.
Start with one bounded use case and map the flow end to end. Find the plant sources, the context you need, the security boundaries you will cross, and who is waiting at the far end. Give the data its structure and govern how it gets exposed first, then distribute it, then organize it, and then repeat the pattern site by site. A strong enforcement layer saves you redesign later, because it makes exposure and auditing work the same way everywhere.
OPC Classic is the worked example I meet most often.
The usual brownfield version of that sequence is an OPC Classic server running on DCOM, the older Windows plumbing that Microsoft's KB5004442 hardening has been squeezing since 2023. You can serve the same tag data as OPC UA, which brings certificate-based sessions and policy handling with it, and you can do that without replacing the server or touching the field equipment. Read the brief: Your OPC Classic server didn't break →
09 · Security & Governance
Security must be embedded, not appended.
Access to plant data is now a security and compliance question, and it is no longer only an integration question. Frameworks like ISA/IEC 62443 push you to secure industrial control systems as a whole, which covers zones, the conduits between them, policy, and the way your people actually work.
A practical architecture answers that by segmenting the network, controlling the conduits between segments, proving who is asking and what they may do, encrypting traffic, monitoring it and logging it. It also shrinks what an attacker can reach, because it stops applications from wiring straight into control systems wherever a governed broker or enforcement layer can safely stand in between.
I have written about the boundary itself in more depth.
Security at the boundary between your plant and your business comes down to one question, which is what can reach your control layer, and in which direction. Read the article: What can reach your control layer →
Get the layering right and your project stops stalling in security review, because the data your business acts on is data you can trust and account for.
10 · Why OPC UA Stays
OPC UA stays in the equation.
When somebody tries to eliminate OPC UA, the goal behind it is usually a good one, which is to cut complexity and get to the cloud faster. The problem is that OPC UA is not only a way of moving data. It is a way of describing what industrial data means. Take it out and you still need some way to express structure, events and controlled interaction across vendors, and that need does not disappear.
In practice, modern architectures bridge the two. OPC UA sits close to the machine network, where it captures structure and vendor-neutral meaning. Gateways or enforcement layers publish structured data sets into MQTT and Sparkplug for distribution at scale. UNS organizes the enterprise picture, historians retain the time-series records, and applications consume governed data. That is not redundancy. It is layering, and every piece is doing a job that none of the others does.
11 · Reference Data Flow
A textual blueprint.
I have kept this blueprint vendor-neutral and protocol-aware on purpose, so you can lift it straight into your own documentation and design reviews.
- 1Operational Sources
This layer holds your control systems, your shopfloor systems, your historians, your edge devices and whichever business systems belong in the picture.
- 2Connectivity & Normalization
Here you pair industrial connectivity with structured modeling, so the data comes out consistent rather than raw. This is often where OPC UA sits.
- 3Secure OT/IT Bridge
This is where policy decides what gets exposed, where logins tie to the directory you already run, where permissions by role apply, where traffic is encrypted and logged, where segmentation is respected, and where older protocols get carried across.
- 4Distribution Backbone
This layer moves the data at scale without tying systems to one another, and it is often MQTT with agreed payload conventions.
- 5Enterprise Organization
The UNS topic hierarchy and its conventions make things findable and keep your sites consistent with each other.
- 6Persistence
Historians, time-series stores and event stores hold the history, support replay and cover what you have to retain.
- 7Consumers
Your consumers are operations, engineering, IT and cybersecurity, data science, executive reporting, and whatever platforms you deliver on.
If you cannot say which layer provides which capability, whether that is security, history, context or distribution, you will find the design hard to scale.
12 · Implementation
Checklist and common failure modes.
Checklist
- Decide what outcome you want and how you will measure it before you pick any technology.
- Inventory your data sources, and work out where live data, events and history sit.
- Agree how you will name and model things across sites, even if you phase it in.
- Design your security zones and the conduits between them, and decide which boundaries get crossed.
- Put logins, permissions by role and audit logging at the layer between your plant and your business.
- Give the data its structure close to the source, and do not push raw tags into enterprise topics.
- Keep live brokered state separate from storage and from your historian’s responsibilities.
- Plan for schema changes, so you know what changes, who approves it, and how people hear about it.
- Start with one bounded use case, then scale it out with a pattern you can repeat.
Common failure modes
- The project starts with a broker and a topic tree before anyone has settled structure, governance and boundary enforcement.
- The team treats the UNS as a historian.
- Somebody assumes that encrypting the traffic is the same thing as governing it.
- The hard work of agreeing standards across sites gets skipped, so every site ends up with its own UNS and almost nothing gets reused.
Sources & Further Reading
Sources.
- HiveMQ, A Comparison of OPC UA and MQTT Sparkplug
- EMQX, A Comparison of IIoT Protocols: MQTT Sparkplug vs OPC UA
- Kai Waehner, Unified Namespace vs Data Product (IT/OT)
- FlowFuse, MQTT vs OPC UA: Why this question never has a straight answer
- i-flow, OPC UA vs MQTT feature comparison
- ISA, ISA/IEC 62443 Series of Standards overview
- Aker Solutions, Digital Solutions (ix3 / Integral platform)
- LNS Research, Industrial Transformation (IX) Reference Architecture
- LNS Research, What is an Industrial Transformation (IX) Platform?
Appendix A
Clarifying “IX³” vs “ix3.”
The term “IX³” shows up in industrial digital-transformation conversations as a simplified three-layer framing, which is edge, then platform, then enterprise. It is a concept rather than a protocol or a formal standard. Separately, “ix3” is also the name of a company associated with Aker Solutions that provides digital-twin offerings. The two are not related, and I mention it because the spellings are close enough to muddle your search results and your meetings.
Appendix C
Layered reference data-flow diagram.
In this diagram, normalization and governance come before distribution. Transport gives you scale, organization makes things findable, and persistence stays separate from whatever the broker is holding right now.
In Closing
The three things to take with you.
None of these tools is the whole answer, because each one was built to solve a different part of the same problem. Layer the jobs on purpose: agree what your data means, guard the boundary it crosses, then move it, then organize it, and keep history where history belongs. And get that layering right, because then your project stops stalling in security review and the data your business acts on is data you can trust and account for.
If you want one next step, take your current architecture diagram to your team and ask two questions. Which box decides what leaves the plant, and which box holds the history? If two fingers land on the same box, or if nobody can find one of them, you have just found the gap this paper is about, and you found it without buying anything.
And if you would rather describe the boundary you have today and hear what we would do with it, write to us at info@h2innovations.ca.