Key takeaways
- OPC UA provides meaning (information model), services and security; MQTT only carries messages and your contract defines the meaning.
- OPC UA is strong for browsing, writing and calling methods; MQTT is strong for distributing data to many consumers.
- OPC UA PubSub is also defined and can run over MQTT; still, a common pattern in practice is to read with OPC UA and distribute with MQTT.
- The decision comes from questions about who writes, how many consumers there are, what the network is like and where meaning is carried.
The question “OPC UA or MQTT?” is usually framed wrongly: the two do not compete in the same layer. OPC UA provides an information model that describes machines and data, plus services to access it; MQTT is a transport that distributes messages through a broker. In most production architectures you see OPC UA on the machine side and MQTT on the side where data is distributed.
Not the same layer
OPC UA describes what a machine or process is: objects, variables, units, methods and how they relate. A client can browse the server’s address space to discover what is offered. See the OPC UA architecture article for detail.
MQTT lets a message be published to a topic and delivered to subscribers. It does not define what is in the message, what unit it is in or what a topic name represents. This simplicity makes MQTT light and widespread; it leaves carrying meaning to you (the data contract).
Where OPC UA is strong
- Access close to the machine. Discovering tags by browsing, working with structured objects, reaching devices of the same kind in the same way through standard types and companion specifications.
- Writes and commands. Authorised writes and method calls are the natural route when a control or recipe operation is needed.
- Built-in security. Signing, encryption, application certificates and user authentication are part of the specification.
- Quality and time. Every value comes with a status code and timestamps.
The price is more configuration and a client-server connection: each consumer opens its own session to the server, and many consumers put load on the server.
Where MQTT is strong
- Distribution (fan-out). Delivering the same data to many consumers without the publisher knowing them.
- Loose coupling. Adding a new consumer does not change the publisher.
- Narrow-band and unreliable networks. The light header and QoS levels are designed for constrained links.
- Distribution to central or cloud systems. The broker is a natural midpoint between plant and centre.
The price is that meaning has to come from outside and that the broker becomes a critical component. See MQTT in production for detailed design principles.
Using them together: two patterns
Pattern 1: read with OPC UA, distribute with MQTT. Machine and PLC data is read with OPC UA; an integration layer tidies unit, name and timestamp and publishes it to a plant-wide MQTT namespace. A consumer then receives the data without knowing machine protocols. The naming side of this approach is covered in the Unified Namespace article.
Pattern 2: OPC UA PubSub. Besides the client/server model, OPC UA also defines a publish/subscribe model and supports MQTT as a transport option. The aim is to combine the OPC UA information model with MQTT’s distribution advantage. Device and software support depends on the product; confirm the profile your products support before relying on it.
Even though the second pattern is possible, the first is common in practice: machines speak OPC UA, central systems prefer MQTT or a similar structure, and an integration layer performs the conversion in between.
Five questions to decide
- Who will write? If control parameters or recipes are to be written, OPC UA’s authorised writes and methods fit better.
- How many consumers are there, and how many will there be? Many, changing consumers favour the MQTT side.
- What is the network like? A narrow or intermittent link to the centre calls for a light flow that can be buffered.
- Where will meaning be carried? If you want companion specifications and an information model, choose OPC UA; if you are ready to write your own JSON contract, MQTT may be enough.
- What should happen in an outage? If loss is unacceptable, decide up front which layer buffers and how repeated processing is made safe (Store & Forward).
The integration planner gathers these questions into a brief tailored to the source and destination systems you choose.
Frequently asked questions
Does OPC UA replace MQTT, or the other way round?
No; they solve different problems and are used together in most projects. OPC UA is the common choice for access close to the machine and for the information model, MQTT for data distribution.
How do I carry OPC UA data over MQTT?
There are two routes: an integration layer reads from OPC UA and publishes to MQTT with your own JSON schema, or you use the MQTT transport of OPC UA PubSub. The first is more common and lets you define the schema; the second depends on device and software support.
Which one is more secure?
Both can be configured securely. OPC UA security is part of the specification (certificates, signing, encryption); in MQTT security comes from TLS, authentication and broker authorisation. The real difference is getting the configuration right; see the article on secure data flows.