Who this is for: IT and production teams connecting machines, shop-floor applications and business platforms.
OPC UA and MQTT can have different roles within the same architecture. The useful question is not which is universally better, but how to move information that receiving systems can interpret while allowing operations to continue through connection failures.
Before choosing, list the required information, its available sources and its destination applications. A temperature reading, an end-of-cycle event and an operational command have different consequences. Treating them as one generic connection hides decisions that need to be made before implementation.
Moving a value and explaining what it means
OPC UA includes information access and modelling facilities for objects, relationships and properties. It supports client-server interactions and PubSub. MQTT provides publish-and-subscribe messaging, while the applications define the contents of those messages.
For a buyer, this leads to a practical question: who makes sure every application interprets the information consistently? A number alone does not identify the machine, measurement unit, time or reading status. Assign responsibility for these details regardless of the selected protocol. Include a representative message and its interpretation in the interface documentation so that the receiving team can check the same assumptions.
References: OPC Foundation — OPC Unified Architecture · OASIS — MQTT Version 5.0
When to assess them separately or together
Start with interfaces that actually exist. For a machine with an OPC UA server, check the exposed information, access permissions and licensing. Where several applications need events over MQTT, identify who manages the broker, which subscribers are permitted and how messages will be structured.
An integration can read from OPC UA and distribute selected information over MQTT. That introduces a transformation that must be documented and maintained; it does not automatically make applications interoperable. Ask for the complete path from the original signal to the field displayed or stored by the final application, with ownership of each handover.
Scroll horizontally to see every column.
| Situation | Initial check | Decision to document |
|---|---|---|
| Existing OPC UA interface | Exposed data and permitted access | Information model and required update intervals |
| Distribution to several applications | Broker and subscriber management | Topic and message structure |
| Connection across different environments | Required gateways and transformations | Owner of each integration stage |
Specify what happens when the connection fails
Describe the expected behaviour when the machine, connection or receiving application becomes unavailable. Some uses only need the latest reading; others require a sequence of events to be recovered. Specify local retention, how unavailability is reported and what happens when the connection returns.
MQTT quality-of-service levels concern message delivery. They do not by themselves guarantee that a business application records a production update or carries out an action only once. Acceptance checks should also cover how the application handles retransmitted and duplicate information. A transport acknowledgement and a completed business operation are different things to verify.
References: OASIS — MQTT Version 5.0
Request a representative trial before expanding
Select one machine and a small set of information covering periodic readings, state changes and an error condition. Compare the original information with the received result, including units and timestamps. Repeat after disconnecting the link, and check that an operator can distinguish a current reading from one that is no longer valid.
The proposal should identify responsibility for identities, permissions and connection maintenance. Check connection limits, licence renewals, supplier availability and handover documentation. An open protocol can reduce certain dependencies, but configuring, maintaining and changing the integration still requires resources. Include those activities in the comparison rather than assessing only the initial connector price.
Information to gather before selecting an interface
- Machine manufacturers, models and documented interfaces.
- Required information, its meaning, units and destinations.
- Update intervals and acceptable delays for each use.
- Clear separation between reading, events and commands.
- Expected behaviour during outages and reconnection.
- Owners for networks, credentials, brokers and receiving applications.
Common questions
Does MQTT always replace OPC UA?
No. The choice depends on the information available and the applications involved. An architecture can use both with clearly assigned roles. Assess the complete data journey rather than relying on the presence of a connector carrying the protocol’s name.
Is a gateway enough to integrate a machine?
A gateway may address one technical step. Data meaning, permissions, outage handling and acceptance checks still need to be defined. Information about the manufacturer’s interfaces and operational constraints is also needed before the scope of the integration can be confirmed.
Sources and further reading
Apply this to your project.
Send us the machines involved and the information you need to make available. We can assess an integration that fits your existing systems.
Discuss your industrial software