top of page


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

Understand the differences, overlaps and why the best industrial architecture often uses both

OPC-UAvsMQTT.png

 

OPC UA and MQTT are often presented as competing industrial communication protocols.

​

That comparison can be useful, but it is also incomplete.

​

OPC UA is an industrial interoperability standard with a rich information model, standardised services and mechanisms for reading, writing and interacting with industrial systems.

​

MQTT is a lightweight publish/subscribe messaging protocol designed to move data efficiently between distributed systems through a broker.

​

They operate at partly different layers and solve partly different problems.

​

For many Industrial IoT projects, the best answer is therefore not OPC UA or MQTT, but:

​

OPC UA for structured local machine integration and MQTT for scalable communication between machines,

gateways, cloud platforms and applications.

​

​

The quick answer

Choose OPC UA when you need:

 

  • A browsable and structured industrial information model

  • Standardised data types, metadata and relationships

  • Direct read and write access to machine data

  • Events, methods or more complex object structures

  • Interoperability between PLCs, SCADA, MES and industrial software

  • Support for industry-specific OPC UA Companion Specifications

 

Choose MQTT when you need:

  • Efficient communication across sites or over the internet

  • A brokered publish/subscribe architecture

  • Many machines publishing to one or more applications

  • Edge-to-cloud telemetry and remote monitoring

  • Separation between data producers and consumers

  • Outbound-only communication from machines or gateways

  • Efficient operation over bandwidth-constrained or intermittent connections

 

Use both when you need:

  • OPC UA to collect structured data locally

  • MQTT to transport selected data to cloud and enterprise applications

  • A gateway that separates the local OT environment from external systems

  • Local industrial interoperability combined with scalable fleet connectivity

​​

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 does the data originate?

  • Where must it be consumed?

  • How much context must travel with it?

  • Must the receiving application discover the data automatically?

  • Is communication read-only or bidirectional?

  • How many machines and consuming applications are involved?

  • Does communication remain inside the plant, or cross network and organisational boundaries?

​​

OPC UA vs MQTT comparison

Area
OPC UA
MQTT
Primary purpose
Industrial interoperability, information modelling and system interaction
Efficient message transport between distributed systems
Common architecture
Client/server, with PubSub also available
Brokered publish/subscribe
Data model
Built-in address space, data types, relationships and semantics
Topic structure and payload format are defined by the implementation
Discovery
Clients can browse the server and discover available information
Subscribers normally need prior knowledge of topics and payload formats
Reading data
Standardised OPC UA read and subscription services
Device publishes values to agreed topics
Writing data
Standardised write services and methods
Application publishes commands or values to agreed topics
Bidirectional support
Built into the OPC UA service model
Possible through clients that both publish and subscribe
Security
Application certificates, signing, encryption, authentication and access control
Commonly TLS, certificates or credentials, and broker access-control rules
Cloud distribution
Possible, but often requires more configuration and lifecycle management
Naturally suited to distributed, brokered and cloud-oriented communication
Bandwidth
Depends on services, information model and encoding
Low protocol overhead; total load depends on payload, frequency and QoS
Typical use
PLC, machine, SCADA, MES and local system integration
Fleet monitoring, telemetry, remote devices and cloud platforms

It is also important to note that 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

  • 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

  • OPC UA PubSub messages

 

This flexibility makes MQTT easy to adapt, but it also means that 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.

For example:

​

Device or gateway → Telemetry topic → DCC

 

DCC → Command topic → Device or gateway → PLC register

 

Device or gateway → Acknowledgement topic → DCC

 

A typical flow could be:

  1. A device publishes telemetry to a data topic.

  2. Inuatek DCC subscribes to the topic and receives the values.

  3. The device subscribes to a separate command topic.

  4. DCC publishes a requested command or value to that topic.

  5. The device validates and processes the request.

  6. The device publishes an acknowledgement or updated value back to DCC.

 

This can be implemented using ordinary MQTT publish/subscribe logic and an agreed payload format.

 

Possible industrial use cases include:

  • Acknowledging or clearing an alarm

  • Changing an approved setpoint

  • Writing a value to a PLC register

  • Updating a device configuration

  • Resetting a counter

  • Triggering a predefined machine or gateway function

 

The implementation must define more than just the topic name.

 

A robust two-way integration should also define:

  • Which values may be written

  • Which users or applications are authorised

  • Valid ranges and data types

  • How commands are acknowledged

  • How errors are reported

  • Timeout and retry behaviour

  • Whether duplicate commands can be processed safely

  • What happens if communication is interrupted

  • How commands and results are recorded in an audit trail

 

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, for example, 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 be used to:

  • Clear an alarm

  • Change a setpoint

  • Write a value to a register

  • Update an operating parameter

 

The exact implementation depends on the capabilities of the device and the agreed MQTT topic and payload structure.

​

Read the DCC two-way MQTT documentation

 

A similar publish/subscribe model could also be developed for other generic MQTT devices without introducing Sparkplug B.

​

Such an implementation would require a defined command structure, device-side subscription logic and appropriate security and validation.

​

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

  • Online and 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

  • The data type of each metric

  • Whether a device is online

  • Whether the received data remains valid

  • 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 can already be bidirectional.

 

Instead, Sparkplug B standardises how bidirectional industrial communication can be represented through defined Node Command and Device Command messages.

​

Does DCC support Sparkplug B? Yes, but it depends on the implementation. For instance the DCC support for IXON is based on Sparkplug B.

​

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 features such as:

  • A browsable object-oriented address space

  • Rich relationships between industrial objects

  • Standardised services

  • Methods and events

  • Historical access models

  • 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.

​

For example:

​

PLC or machine

↓

OPC UA

↓

Edge gateway

↓

MQTT with Sparkplug B

↓

Broker and cloud applications

​

OPC UA provides structured local access to the machine, while MQTT and Sparkplug B provide scalable distribution and device-state management.

​

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.

​

This allows an architecture to retain OPC UA-defined information and message structures while using MQTT for brokered distribution.

​

Possible architectures therefore 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:

​

PLC or machine → OPC UA → Edge gateway → MQTT broker → 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

  • 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

 

Inuatek 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.

​

Connect any MQTT-enabled device to DCC

​

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

 

MQTT security is normally implemented through the complete MQTT deployment rather than through the payload format alone.

 

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 permissions

  • Topic-specific subscribe permissions

  • Certificate lifecycle management

  • Network segmentation

  • Logging and monitoring

 

The broker can, for example, permit one device to publish telemetry only to its own data topic while allowing it to subscribe only to its own command topic.

 

Sparkplug B does not replace these security mechanisms. It relies on the underlying MQTT infrastructure and its access-control configuration.

 

The correct question is therefore not simply:

​

 

Which protocol contains more security features?

​

The more useful question is:

​

Has the complete architecture 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:

 

PLC → OPC UA → SIA Connect or Teltonika gateway → MQTT → DCC

 

or:

​

PLC or HMI with MQTT support → MQTT → 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.

​

Read about IXON integration with DCC

​

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:

  1. The ability to decode the Sparkplug B payload structure used by IXON.

  2. An existing framework for controlled two-way communication through standard MQTT publish/subscribe logic.

 

A future generic Sparkplug B implementation could build on these capabilities while adding the required Sparkplug lifecycle, discovery and command conventions.

​

This would, however, require development and validation against the required Sparkplug scope.

Generic Sparkplug B is not currently offered as a standard DCC device type.

​

Inuatek is open to discussing a generic Sparkplug B 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.

​

This 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

  • 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?

Choose OPC UA when the main requirement is:

  • Rich industrial information modelling

  • Browsing and discovery

  • Standardised local interoperability

  • Direct interaction with industrial systems

  • Methods, events or complex structures

 

Choose MQTT when the main requirement is:

  • Scalable data transport

  • Remote monitoring

  • Edge-to-cloud communication

  • Distribution to several applications

  • Outbound communication from deployed equipment

  • Efficient communication across many devices

 

Choose Sparkplug B when you want:

  • A standard industrial topic namespace

  • Standard payload encoding

  • Automatic metric and device discovery

  • Birth and Death lifecycle handling

  • Standard device state management

  • Standardised MQTT command messages

 

Choose standard bidirectional MQTT when:

  • You control both ends of the integration

  • You can define your own topic and payload structure

  • Only selected commands or writable values are required

  • Full Sparkplug lifecycle behaviour is unnecessary

 

Choose OPC UA and MQTT together when you need both:

  • Structured local machine integration

  • Scalable remote and cloud connectivity

Frequently asked questions

Is MQTT a replacement for OPC UA?

Not generally.

​

MQTT is primarily a message transport,

​

OPC UA also defines an information model and standardised industrial services.

MQTT may replace OPC UA in simpler telemetry applications, but the two technologies are often complementary.

​

Is OPC UA better than MQTT?

​

Neither is universally better.

​

OPC UA is normally stronger when rich semantics, browsing and direct industrial interoperability are required.

​

MQTT is normally stronger for scalable, distributed and cloud-oriented message delivery.

​

Is MQTT only suitable for sending data to the cloud?

​

No.

​

MQTT can be used locally, at the edge or across the internet.

​

It can connect PLCs, gateways, applications and cloud services wherever a brokered publish/subscribe architecture is useful.

​

Is MQTT bidirectional?

​

Yes.

​

An MQTT client can both publish and subscribe.

​

A device can publish telemetry while subscribing to command topics. The cloud application can subscribe to telemetry and publish commands.

​

Sparkplug B is not required for this.

​

Can MQTT send a value back to a PLC?

​

Yes, provided that the PLC or connected gateway subscribes to an authorised command topic and contains logic for validating and writing the received value.

​

The implementation should include access control, validation, acknowledgements, safe failure behaviour and audit logging.

​

What does Sparkplug B add to MQTT?

​

Sparkplug B adds standard conventions for industrial topic structures, payloads, metrics, device identities, Birth and Death messages, state management and commands.

​

It makes MQTT-based industrial systems easier to integrate consistently.

​

Is Sparkplug B the same as MQTT?

​

No.

​

MQTT is the underlying publish/subscribe messaging protocol.

​

Sparkplug B defines how MQTT should be used for industrial data, device state and command exchange.

​

Does Sparkplug B make MQTT bidirectional?

​

No.

​

MQTT is already bidirectional because clients can both publish and subscribe.

​

Sparkplug B adds standard Node Command and Device Command message conventions for bidirectional industrial communication.

​

Can OPC UA communicate through MQTT?

​

Yes.

​

OPC UA PubSub can use MQTT as a broker-based transport while retaining OPC UA-defined message and information structures.

​

Does Inuatek DCC support two-way MQTT communication?

​

DCC supports controlled two-way MQTT communication for selected device integrations.

​

This is implemented through ordinary MQTT publish/subscribe logic and does not depend on Sparkplug B.

​

Does Inuatek DCC support Sparkplug B?

​

DCC currently understands the Sparkplug B payload format used by the IXON integration.

​

A complete generic Sparkplug B Host Application implementation is not currently provided as a standard DCC device type.

​

A broader implementation can be evaluated for a concrete customer or partner use case.

Connect industrial data without locking yourself into one protocol

Whether your machines expose data through OPC UA, MQTT or an industrial gateway, Inuatek DCC provides a scalable path from machine data to dashboards, alarms, fleet monitoring and external applications.

​

Use OPC UA where rich local industrial interoperability is required.

​

Use MQTT where scalable and efficient data distribution is required.

​

Use both where that creates the strongest overall architecture.

bottom of page