OPC UA vs MQTT: Which Should You Use for Industrial IoT?

The quick answer

OPC UA and MQTT are not direct equivalents

A simple comparison sometimes presents OPC UA as a heavy industrial protocol and MQTT as a lightweight cloud protocol. That is not entirely wrong, but it overlooks an important difference.

OPC UA defines much more than data transport. It includes:

• An industrial information model
• A browsable address space
• Standardised data types
• Read and write services
• Events
• Methods
• Subscriptions
• Application identity and security mechanisms

MQTT is primarily a messaging transport. It defines how clients connect to a broker, publish messages and subscribe to topics. It does not itself define what an industrial asset is, how a machine should be represented or what the data inside a message means. Those elements must be defined by the application, device manufacturer or an additional specification such as Sparkplug B.

This is why the question should not only be “Which protocol is better?” The more useful questions are where the data originates, where it must be consumed, how much context must travel with it, whether the receiving application must discover the data, whether communication is read-only or bidirectional, how many machines and consuming applications are involved, and whether communication crosses network boundaries.

OPC UA vs MQTT comparison

OPC UA is not limited to client/server communication. OPC UA PubSub supports publisher/subscriber architectures and can use MQTT as its underlying broker transport.

Where OPC UA is strongest

OPC UA is more than a method for transferring tag values. Its main strength is its ability to represent industrial information in a structured, discoverable and interoperable way.

An OPC UA server can expose an address space containing:

• Machines and equipment
• Components and subcomponents
• Variables and current values
• Data types
• Engineering units
• Relationships between objects
• Alarms and events
• Callable methods
• Metadata and descriptions

A compatible OPC UA client can browse this structure and understand what information the server makes available. This becomes valuable when several industrial systems must exchange information without relying entirely on vendor-specific tag mappings or undocumented register lists.

Typical OPC UA use cases include:

• PLC-to-SCADA communication
• Machine-to-MES integration
• Local machine interoperability
• Standardised access to production data
• Integration between equipment from different vendors
• Exposure of contextualised machine data to an edge gateway

OPC UA also defines extensive application-level security mechanisms, including application identities, certificates, signing, encryption, user authentication and access rights.

Where MQTT is strongest

MQTT focuses on moving messages efficiently between systems. A device or application connects to an MQTT broker and publishes a message to a topic. Other applications subscribe to the topics relevant to them.

The publisher does not need to know how many applications receive the data, where those applications are located, how the information will be visualised or processed, or whether additional consumers will be added later. Likewise, consuming applications do not require a direct connection to every PLC, machine or device.

This separation is valuable when:

• Many machines must send data to one central platform
• Several applications need the same information
• Machines are installed across many customer sites
• Communication crosses firewalls or organisational boundaries
• Devices use mobile or bandwidth-constrained networks
• Connections may temporarily be unavailable
• Machines should establish outbound connections without exposing inbound services

MQTT deliberately does not prescribe a particular industrial data model. The payload may contain JSON, text, binary values, Protocol Buffers, a manufacturer-specific format, Sparkplug B or OPC UA PubSub messages. This flexibility makes MQTT easy to adapt, but the publisher and subscriber must agree on the topic hierarchy, payload format and meaning of the data.

Can MQTT be bidirectional without Sparkplug B?

Yes. MQTT is inherently capable of bidirectional communication because an MQTT client can both publish and subscribe. Sparkplug B is not required.

A standard MQTT implementation can use separate topics for telemetry, commands and acknowledgements:

1. Device or gateway → Telemetry topic → DCC→
2. DCC → Command topic → Device or gateway → PLC register→
3. Device or gateway → Acknowledgement topic → DCC

A typical flow could be:

1. 1A device publishes telemetry to a data topic.
2. 2Inuatek DCC subscribes to the topic and receives the values.
3. 3The device subscribes to a separate command topic.
4. 4DCC publishes a requested command or value to that topic.
5. 5The device validates and processes the request.
6. 6The device publishes an acknowledgement or updated value back to DCC.

This can support acknowledging alarms, changing approved setpoints, writing PLC values, updating device configuration, resetting counters and triggering predefined machine or gateway functions.

Time-critical control, safety functions and machine protection should remain local. Cloud-based write-back is better suited to controlled, non-time-critical actions with clearly defined validation rules.

Bidirectional MQTT in Inuatek DCC

Inuatek DCC already supports controlled two-way communication through standard MQTT publish/subscribe logic for selected device integrations. This functionality does not depend on Sparkplug B.

The existing DCC two-way MQTT model can allow a user to set a value from a DCC dashboard. The request is published to a device-specific MQTT topic and is then handled by the connected device or gateway. Depending on the device and configuration, this may clear an alarm, change a setpoint, write a register or update an operating parameter.

The exact implementation depends on the capabilities of the device and the agreed MQTT topic and payload structure. Read more in the DCC two-way MQTT documentation.

What does Sparkplug B add to MQTT?

MQTT provides the transport mechanism, but it does not standardise the industrial meaning of topics and payloads. Two MQTT-enabled systems may use entirely different topic structures, payload formats, metric names, device hierarchies, state models, command conventions and online/offline indicators.

Sparkplug B adds a standardised industrial framework on top of MQTT. It defines conventions for:

• Topic namespaces
• Edge Node and Device identities
• Binary payloads based on Protocol Buffers
• Metrics and data types
• Metric aliases
• Sequence handling
• Birth messages
• Death messages
• Online and offline state
• Rebirth requests
• Node and Device commands

This makes it easier for compatible systems to understand which devices exist, which metrics they expose, whether a device is online and how values or commands can be sent back. Sparkplug B therefore adds industrial interoperability and lifecycle behaviour to MQTT. It does not make MQTT bidirectional; standard MQTT already supports that.

Does Sparkplug B replace OPC UA?

Not necessarily.

Sparkplug B makes MQTT more structured and interoperable, but it does not duplicate every aspect of OPC UA. OPC UA provides a browsable object-oriented address space, rich relationships between industrial objects, standardised services, methods and events, historical access models and a broad ecosystem of Companion Specifications. Sparkplug B provides a standard way to represent industrial metrics, device state and commands within an MQTT infrastructure.

The two can therefore complement each other. A gateway may collect process variables through OPC UA and then publish selected data through MQTT using Sparkplug B:

1. PLC or machine→
2. OPC UA→
3. Edge gateway→
4. MQTT with Sparkplug B→
5. Broker and cloud applications

Can OPC UA use MQTT?

Yes. This is another reason why a simple OPC UA versus MQTT comparison can be misleading.

OPC UA PubSub separates the OPC UA information and message model from the underlying transport. MQTT can be used as the broker-based transport carrying OPC UA PubSub messages, retaining OPC UA-defined information and message structures while using MQTT for brokered distribution.

Possible architectures include:

• OPC UA locally and custom MQTT to the cloud: PLC → OPC UA → Gateway → MQTT JSON → Cloud platform
• OPC UA locally and Sparkplug B to the cloud: PLC → OPC UA → Gateway → MQTT Sparkplug B → Cloud platform
• OPC UA PubSub over MQTT: OPC UA Publisher → MQTT broker → OPC UA Subscribers
• Direct MQTT from the controller: PLC or HMI → MQTT → Cloud platform

The appropriate architecture depends on:

• What the PLC, HMI or gateway supports
• Whether data must be browsable
• How much semantic information is required
• Whether several systems must consume the same data
• Whether communication must be bidirectional
• How much implementation freedom is acceptable

A common industrial OPC UA and MQTT architecture

A frequently used architecture is:

1. PLC or machine→
2. OPC UA→
3. Edge gateway→
4. MQTT broker→
5. Cloud platform

In this design:

• OPC UA provides structured access to machine data inside the local environment.
• The gateway collects and selects the relevant values.
• Data may be filtered, aggregated, translated or buffered at the edge.
• MQTT transports the selected information to the cloud.
• Cloud applications do not connect directly to the OPC UA server.
• Additional consumers can subscribe without creating more PLC connections.

This creates a useful separation between local machine communication, edge data processing, remote data transport, and cloud applications and dashboards.

Where a PLC or HMI already supports secure MQTT publishing, the intermediate gateway may not be necessary: PLC or HMI → MQTT → Inuatek DCC. DCC supports this approach by allowing an MQTT-enabled device to publish a simple JSON payload directly to the DCC broker using device-specific certificates.

Security: OPC UA vs MQTT

It is tempting to conclude that OPC UA is secure and MQTT is not. That is too simplistic.

OPC UA defines a comprehensive application security model that can include:

• Application certificates
• Authentication
• Message signing
• Encryption
• User identities
• Roles and access rights
• Certificate trust management

A secure MQTT architecture may include:

• TLS encryption
• Client certificates
• Unique device identities
• Username and password authentication where appropriate
• Broker access-control lists
• Topic-specific publish and subscribe permissions
• Certificate lifecycle management
• Network segmentation
• Logging and monitoring

Sparkplug B does not replace these security mechanisms. It relies on the underlying MQTT infrastructure and its access-control configuration. The useful question is not which protocol contains more security features, but whether the complete architecture has been designed, configured and maintained securely.

How Inuatek DCC fits into OPC UA and MQTT architectures

Inuatek DCC focuses on scalable collection, processing, visualisation and use of industrial data in the cloud.

DCC can receive MQTT data from:

• PLCs with built-in MQTT support
• HMIs and industrial controllers
• Industrial IoT gateways
• Devices collecting data locally through OPC UA
• Devices collecting data through Modbus or Siemens S7
• Mobile and telematics devices
• Selected vendor-specific MQTT integrations

This means that DCC does not require an OEM to replace OPC UA. OPC UA can remain the local protocol used to communicate with the machine, while MQTT provides the secure and scalable connection between the machine, gateway and DCC.

For example:

1. PLC→
2. OPC UA→
3. SIA Connect or Teltonika gateway→
4. MQTT→
5. DCC

Once the data reaches DCC, it can be used for:

• Machine dashboards
• Fleet overview dashboards
• Alarm notifications
• Historical analysis
• Reports
• Data refinement
• External application integrations
• Controlled write-back for supported device integrations

Current Sparkplug B support in DCC

Inuatek DCC currently supports the Sparkplug B payload format used by the IXON integration. IXON uses MQTT and Sparkplug B conventions to publish machine data, and DCC uses this structure to understand and process the received data.

This should not be interpreted as a complete generic Sparkplug B Host Application implementation. The current IXON-oriented implementation primarily supports the data format needed to receive and interpret the IXON telemetry. DCC does not currently provide a standard generic Sparkplug B device type covering the full Sparkplug B suite, including every lifecycle, discovery, state-management and command requirement.

Generic Sparkplug B as a possible DCC extension

A generic Sparkplug B device profile could be a logical future extension of the DCC MQTT architecture. Depending on the intended scope, such an implementation could include:

• Automatic discovery from NBIRTH and DBIRTH messages
• Processing of NDATA and DDATA telemetry
• Handling of NDEATH and DDEATH states
• Metric aliases
• Sequence validation
• Rebirth requests
• Properties and metadata
• Templates and advanced data types
• Primary Host state behaviour
• NCMD and DCMD command handling
• Controlled bidirectional write-back

DCC already has two relevant building blocks: the ability to decode the Sparkplug B payload structure used by IXON and an existing framework for controlled two-way communication through standard MQTT publish/subscribe logic. A future generic implementation could build on these capabilities while adding the required Sparkplug lifecycle, discovery and command conventions.

This would require development and validation against the required Sparkplug scope. Generic Sparkplug B is not currently offered as a standard DCC device type, but Inuatek is open to discussing an implementation with OEMs, gateway providers or system integrators that have a concrete use case.

Generic bidirectional MQTT as another option

Sparkplug B is not the only path to generic two-way MQTT communication. For applications that do not require the complete Sparkplug model, Inuatek could also develop a simpler generic bidirectional MQTT device profile.

Such a profile could use an agreed topic structure such as:

devices/{device-id}/telemetry
devices/{device-id}/commands
devices/{device-id}/acknowledgements

The payload could be JSON or another mutually agreed format. Such an implementation could support:

• Telemetry from the device to DCC
• Commands from DCC to the device
• Acknowledgements from the device
• Validation of writable values
• Device-specific access control
• Dashboard-based write-back
• Audit logging

This approach may be appropriate where the device already supports configurable MQTT topics, JSON is preferred over a binary payload, automatic Sparkplug discovery is not required, only a limited number of writable values are needed, and the OEM controls both the device configuration and the cloud model.

This is not currently a universal plug-and-play DCC feature, but it is technically feasible and can be evaluated as a scoped integration.

Which protocol should you choose?

Frequently asked questions