OPC UA and MQTT are two of the most important communication technologies in modern industrial automation.

Both can move data from machines to software.

Both can connect PLCs with higher-level systems.

Both appear constantly in discussions about IIoT, Industry 4.0, edge computing and smart manufacturing.

So it is easy to assume that they are competing protocols and that an automation engineer needs to choose one.

That is not quite correct.

OPC UA and MQTT solve different parts of the industrial communication problem.

And in many of the best architectures, they are used together.

If you are deciding how to connect a PLC, SCADA system, edge gateway, MES platform or cloud application, understanding that difference can prevent a lot of unnecessary complexity.

This article explains OPC UA and MQTT from a controls engineer’s perspective — without turning it into a networking textbook.

The Short Answer

If you only want the practical answer:

Use OPC UA when you need rich, structured access to industrial equipment.

Typical examples:

PLC to SCADA
PLC to HMI
PLC to engineering software
machine data browsing
alarms and events
structured machine models
read/write access to controller data

Use MQTT when you need lightweight, scalable distribution of data between many systems.

Typical examples:

factory to cloud
edge gateway to analytics platform
remote sites
IIoT
dashboards
multiple data consumers
event-driven architectures
unreliable or bandwidth-constrained connections

And when you need both?

Use OPC UA to understand the machine and MQTT to distribute the data.

That architecture is increasingly common.

What Is OPC UA?

OPC UA stands for:

Open Platform Communications Unified Architecture

It is much more than a simple data-transfer protocol.

OPC UA defines:

how industrial data is represented;
how clients discover it;
data types;
objects;
variables;
methods;
events;
alarms;
historical information;
authentication;
encryption;
communication services.

The OPC Foundation describes OPC UA as a platform-independent architecture designed to enable secure and reliable information exchange from sensors and control systems through MES and ERP applications and into IIoT environments.

This is an important distinction.

OPC UA does not simply send:

Temperature = 72.4

It can describe what that information actually represents.

A machine might expose a structure such as:

PackagingLine
 ├── Conveyor01
 │   ├── Speed
 │   ├── Running
 │   ├── Fault
 │   └── MotorCurrent
 │
 ├── Conveyor02
 │   ├── Speed
 │   ├── Running
 │   └── Fault
 │
 └── Production
     ├── TotalCount
     ├── RejectCount
     └── CurrentRecipe

A client can browse that hierarchy and understand the data structure.

That is one of OPC UA’s biggest strengths.

What Is MQTT?

MQTT stands for:

Message Queuing Telemetry Transport

Despite the name, MQTT is fundamentally a lightweight publish/subscribe messaging protocol.

Instead of one device directly asking another device for information, MQTT normally uses a central component called a:

Broker

Devices publish messages to topics.

Other applications subscribe to those topics.

For example:

factory1/line2/conveyor3/speed

The PLC or edge gateway might publish:

1.75

Any system subscribed to that topic receives the new value.

That could include:

SCADA;
dashboard;
database;
analytics platform;
cloud service;
mobile application;
maintenance system.

The publisher does not need to know who is listening.

OASIS defines MQTT as a lightweight client/server publish-subscribe messaging transport designed for constrained environments and situations where bandwidth is limited. MQTT 5.0 supports three Quality of Service levels as well as persistent sessions and other delivery controls.

That decoupling makes MQTT extremely scalable.

The Fundamental Difference

The easiest way to understand the distinction is this:

OPC UA understands industrial information.

MQTT moves messages.

MQTT deliberately does not define what the payload means.

The MQTT specification treats the application payload as content defined by the application itself.

You could publish:

{
  "speed": 1.75,
  "running": true
}

Or:

1.75

Or a binary payload.

Or XML.

MQTT does not care.

That flexibility is powerful.

But it also creates a problem.

How does another system know what the message means?

That is where standards such as Sparkplug become important.

OPC UA vs MQTT at a Glance

Feature	OPC UA	MQTT
Main purpose	Industrial interoperability	Message transport
Typical architecture	Client/server or PubSub	Publish/subscribe
Broker required	No for Client/Server	Normally yes
Data model	Rich information model	Not defined by MQTT
Browsing	Excellent	No native browsing
Read/write PLC data	Excellent	Possible, application-specific
Methods/commands	Native services	Application-specific
Alarms/events	Native support	Must be designed
Historical data	Supported by UA services	Normally external database
Bandwidth	Moderate to efficient	Very lightweight
Many subscribers	Possible, especially PubSub	Excellent
Cloud integration	Good	Excellent
Edge/IIoT	Good	Excellent
Low-bandwidth links	Possible	Excellent
Semantic context	Excellent	Requires payload conventions/Sparkplug
Security model	Built into UA architecture	Usually TLS + broker authentication/ACL
Best use	Machine/system interoperability	Distributed data pipelines

The important conclusion is that these technologies overlap, but they are not identical.

Architecture 1: OPC UA Client/Server

The most familiar OPC UA architecture looks like this:

┌──────────────┐
│    SCADA     │
│ OPC UA Client│
└──────┬───────┘
       │
       │ Browse / Read / Write
       │
┌──────▼───────┐
│     PLC      │
│ OPC UA Server│
└──────────────┘

The client connects directly to the server.

It can:

browse available nodes;
subscribe to values;
read values;
write values;
call methods;
receive events;
access historical information where supported.

For machine-level integration, this model is extremely useful.

A SCADA system can connect to a PLC and discover what information the PLC exposes.

No MQTT broker is required.

Architecture 2: MQTT Publish/Subscribe

MQTT normally looks more like this:

                 ┌───────────────┐
                 │    SCADA      │
                 │  Subscriber   │
                 └──────▲────────┘
                        │
┌─────────────┐         │
│ PLC / Edge  │    ┌────┴─────┐
│ Publisher   ├───►│   MQTT   │
└─────────────┘    │  Broker  │
                   └────┬─────┘
                        │
         ┌──────────────┼───────────────┐
         │              │               │
         ▼              ▼               ▼
     Database       Dashboard        Cloud

The PLC does not need individual connections to every consumer.

It publishes once.

The broker distributes the message.

This is one reason MQTT works so well when industrial data needs to move to many different applications.

Example: One PLC and Five Consumers

Imagine an S7-1500 contains production information that must be consumed by:

SCADA;
MES;
maintenance dashboard;
cloud analytics;
production database.

With traditional point-to-point communication, the controller or gateway may need to maintain multiple relationships.

With MQTT:

PLC / Gateway
       │
       ▼
    Broker
   /  |  |  \
  /   |  |   \
SCADA MES DB Cloud Dashboard

The data producer becomes decoupled from the consumers.

Adding another subscriber normally does not require modifying the publisher.

That is extremely attractive for enterprise-scale industrial architectures.

Where OPC UA Is Better

1. Connecting PLCs to SCADA

This is one of OPC UA’s natural use cases.

A SCADA system needs more than a stream of disconnected values.

It benefits from:

structured tags;
data types;
quality information;
timestamps;
alarms;
events;
browsing;
read/write operations.

OPC UA provides those concepts natively.

For Siemens users, S7-1200 and S7-1500 systems can expose controller data through an OPC UA server where supported and configured.

Antomatix has a practical tutorial showing how to connect a Siemens PLC to OPC UA clients including UaExpert and Node-RED:

2. Browsing Unknown Systems

This is an underrated advantage.

Suppose you connect to an OPC UA server you have never used before.

A client such as UaExpert can browse the server’s address space.

You may discover:

Machine
 ├── Status
 ├── Speed
 ├── Recipe
 ├── Alarms
 └── Diagnostics

MQTT does not provide this kind of universal browsing mechanism.

You need to know the topic structure.

For example:

factory/line1/machine1/status
factory/line1/machine1/speed
factory/line1/machine1/recipe

Without documentation or an agreed convention, a subscriber may not know what exists.

This difference becomes increasingly important as systems grow.

3. Rich Industrial Information Models

OPC UA can represent relationships between objects.

Instead of simply exposing:

MotorSpeed

the system can describe a motor as an object containing:

Motor
 ├── Command
 ├── Running
 ├── Speed
 ├── Current
 ├── Fault
 ├── FaultCode
 └── OperatingHours

Industry companion specifications can take this much further by standardising how particular machines, devices and industries describe information.

This is extremely useful when interoperability matters.

4. Direct Commands and Methods

OPC UA is not limited to telemetry.

Clients can interact with servers using standard services.

Depending on the implementation, an application can:

write values;
invoke methods;
acknowledge alarms;
request historical data;
interact with structured objects.

MQTT can also be used for commands.

For example:

factory1/line1/conveyor/start

But the meaning and behaviour of that command must be defined by your application architecture.

MQTT itself does not define an industrial command model.

Where MQTT Is Better

1. Sending Data to the Cloud

MQTT is extremely well suited to vertical connectivity:

Machine
   ↓
PLC
   ↓
Edge Gateway
   ↓
MQTT Broker
   ↓
Cloud

Its lightweight messaging architecture and publisher/subscriber decoupling make it attractive when data must cross network boundaries and reach remote services.

This is why MQTT appears so often in IIoT architectures.

2. Distributing Data to Many Applications

This is where MQTT really shines.

Imagine production data needs to reach:

Grafana;
InfluxDB;
MES;
maintenance software;
energy dashboard;
cloud analytics.

With MQTT, each application can subscribe independently.

The publisher does not need to manage every consumer.

This can make architectures dramatically easier to extend.

3. Remote Sites

Consider:

pumping stations;
solar farms;
water treatment assets;
remote warehouses;
agricultural systems;
energy installations.

The connection may be:

4G;
5G;
satellite;
VPN;
constrained WAN.

MQTT was specifically designed to minimise protocol overhead and work efficiently across constrained or unreliable networks.

For this type of architecture, MQTT often makes more sense than maintaining numerous direct application-to-device sessions.

4. Event-Driven Systems

Traditional polling might work like this:

SCADA → PLC: What is the temperature?
PLC → SCADA: 42.1

SCADA → PLC: What is the temperature?
PLC → SCADA: 42.1

SCADA → PLC: What is the temperature?
PLC → SCADA: 42.3

Publish/subscribe allows the producer to publish according to the design of the system:

Temperature changed → Publish

That can reduce unnecessary traffic and makes it easier for multiple applications to consume the same information.

OPC UA subscriptions also provide change-based data delivery, so this is not exclusively an MQTT capability.

The key difference is MQTT’s broker-centric distribution model.

The Big MQTT Problem: Context

Suppose I publish:

factoryA/line3/device7/value

Payload:

What does 173 mean?

Temperature?

Speed?

Pressure?

Fault code?

Production count?

This is one of the fundamental limitations of plain MQTT.

MQTT defines message transport.

It deliberately does not define industrial semantics.

The Eclipse Foundation’s Sparkplug documentation highlights exactly this issue: standard MQTT does not prescribe a topic namespace or payload encoding.

Enter MQTT Sparkplug

Sparkplug builds an industrial framework on top of MQTT.

It defines:

topic namespace;
payload structure;
device identity;
metric representation;
birth messages;
death messages;
session state;
industrial data conventions.

The Eclipse Foundation describes Sparkplug as an OT-focused MQTT specification intended to provide topic namespaces, payload definitions and session-state management suitable for real-time SCADA and industrial applications.

In simplified terms:

MQTT provides the transport.

Sparkplug provides industrial rules around that transport.

That makes MQTT much more useful in structured industrial environments.

Plain MQTT vs Sparkplug

Plain MQTT might look like:

factory1/line2/motor7/speed

Payload:

You decide:

topic design;
payload format;
timestamps;
quality;
device state;
connection status.

With Sparkplug, many of those conventions are standardised.

This improves interoperability between industrial applications.

Does That Make Sparkplug the Same as OPC UA?

No.

They overlap, but their design philosophy is different.

OPC UA provides a broad industrial information architecture with:

address spaces;
objects;
services;
methods;
alarms;
events;
information models.

Sparkplug provides an industrial framework for transmitting structured OT information using MQTT.

For many projects, Sparkplug solves exactly the right problem.

For others, OPC UA’s richer service and information model is more appropriate.

OPC UA Also Supports Publish/Subscribe

This is where the comparison gets more interesting.

OPC UA is not limited to Client/Server.

The standard also defines:

OPC UA PubSub

With PubSub, publishers and subscribers can be decoupled.

The OPC Foundation specifies both brokerless forms, such as datagram-based communication, and broker-based models that can use standard messaging systems including MQTT.

Yes:

OPC UA can use MQTT as a transport.

So technically, asking:

OPC UA or MQTT?

can sometimes be the wrong question.

A system can use:

OPC UA information model
        +
OPC UA PubSub
        +
MQTT broker

The OPC Foundation explicitly defines MQTT mappings for OPC UA PubSub.

That architecture combines MQTT-style distribution with OPC UA data modelling.

Think in Layers

A useful way to understand this is to separate the problem into layers.

Information

What does the data mean?

Motor
 ├── Speed
 ├── Current
 └── Fault

OPC UA is very strong here.

Messaging

How does the information move?

Publish → Broker → Subscribe

MQTT is extremely strong here.

Application

What consumes the data?

SCADA
MES
dashboard
database
cloud
digital twin

Once you think in layers, the supposed competition between OPC UA and MQTT becomes much less confusing.

Security: OPC UA vs MQTT

Both technologies can be deployed securely.

But the security architecture is different.

OPC UA

OPC UA includes security mechanisms for:

application authentication;
user authentication;
encryption;
message signing;
integrity;
certificates.

The OPC Foundation defines these security concepts directly as part of the UA architecture.

That makes security an integrated part of OPC UA rather than something entirely external to the protocol.

MQTT Security

MQTT deployments commonly use:

TLS;
username/password authentication;
client certificates;
broker access-control lists;
topic permissions.

The broker becomes a critical part of the security architecture.

For example:

PLC01 may publish:
factory/line1/#

Dashboard may only subscribe:
factory/line1/#

Maintenance app may publish:
factory/line1/commands/#

Good broker configuration can provide very granular permissions.

But remember:

MQTT itself is a messaging protocol, not a complete industrial-security architecture.

Authentication, broker configuration, certificates, ACLs and network segmentation still need to be designed correctly.

What About Performance?

There is a common oversimplification:

MQTT is lightweight, OPC UA is heavy.

That can be misleading.

MQTT does have a very small protocol overhead and is specifically designed for lightweight communication.

But actual network usage depends heavily on:

publishing frequency;
payload format;
topic length;
JSON vs binary encoding;
QoS;
TLS;
number of tags.

OPC UA can also use efficient binary encoding and subscriptions.

So protocol choice should not be based solely on a claim that one is always faster.

Choose based on the architecture.

MQTT QoS Explained Quickly

MQTT provides three Quality of Service levels.

QoS 0 — At most once

Send it.
No acknowledgement required.

Fastest and lowest overhead.

A message may be lost.

Good for frequently updated telemetry where the next message will replace the previous value anyway.

QoS 1 — At least once

The sender receives an acknowledgement.

The message should arrive, but duplicates can occur.

Applications need to tolerate duplicate messages.

QoS 2 — Exactly once

Provides the highest MQTT delivery assurance through a more involved handshake.

It also has more overhead.

OASIS defines all three delivery levels in MQTT 5.0.

Using QoS 2 everywhere simply because it sounds safest is usually not good architecture.

Choose QoS according to what the information represents.

PLC Control Is Different From Data Integration

This point is critical.

Neither OPC UA nor MQTT should automatically replace deterministic industrial control protocols.

Consider:

PLC → Servo drive

or:

Safety PLC → safety I/O

That is very different from:

PLC → cloud analytics

Real-time machine control may require technologies such as:

PROFINET;
PROFIsafe;
EtherNet/IP;
CIP Safety;
EtherCAT;
dedicated motion networks.

OPC UA and MQTT are extremely useful for information exchange.

They are not universal replacements for all control networking.

Practical Example 1: PLC to SCADA

Requirement:

An S7-1500 must provide:

machine status;
speeds;
alarms;
production counters;
operator commands.

My first choice would normally be:

OPC UA

Why?

The SCADA application benefits from:

browsing;
structured tags;
direct read/write;
quality;
events;
security;
device context.

Architecture:

S7-1500
OPC UA Server
      │
      ▼
SCADA OPC UA Client

Simple and logical.

Practical Example 2: PLC Data to Cloud

Requirement:

Production data from 50 machines must reach a cloud analytics platform.

I would strongly consider:

MQTT

Architecture:

50 PLCs
   │
   ▼
Edge Gateway
   │
   ▼
MQTT Broker
   │
   ├── Cloud
   ├── Historian
   ├── Dashboard
   └── MES

The broker architecture becomes extremely valuable here.

Practical Example 3: One Machine, Many Consumers

Requirement:

Machine information must go to:

SCADA;
OEE;
maintenance dashboard;
database;
cloud.

Possible architecture:

PLC
 │ OPC UA
 ▼
Edge / Data Gateway
 │
 │ MQTT
 ▼
Broker
 ├── SCADA / enterprise subscriber
 ├── OEE
 ├── Database
 ├── Dashboard
 └── Cloud

This is where using both technologies becomes very powerful.

Practical Example 4: WinCC Unified and MQTT

Modern HMI platforms are increasingly supporting MQTT directly.

Antomatix has already demonstrated a practical WinCC Unified architecture:

WinCC Unified
      ⇅
MQTT Provider
      ⇅
Mosquitto Broker
      ⇅
External Client

This can be useful for:

dashboards;
commissioning tools;
Node-RED;
data logging;
external applications.

Full tutorial:

Practical Example 5: Remote Factory

Imagine a manufacturing site in another country.

The site has:

20 machines
↓
Local SCADA
↓
Edge gateway
↓
Corporate cloud

Inside the plant:

OPC UA

may be ideal for collecting structured machine information.

Across the WAN:

MQTT

may be ideal for publishing selected information.

Architecture:

PLCs
 │
 │ OPC UA
 ▼
Edge Gateway
 │
 │ MQTT/TLS
 ▼
Central Broker
 │
 ├── Analytics
 ├── OEE
 └── Enterprise Systems

This hybrid model is one of the most useful patterns to understand.

What About Siemens?

Siemens automation platforms increasingly support both communication approaches.

A modern Siemens architecture may include:

S7-1500 OPC UA server;
OPC UA clients;
WinCC Unified;
MQTT connectivity;
edge applications;
external brokers.

TIA Portal V21 also expanded integration capabilities around MQTT and OPC UA in the Unified ecosystem.

What About Allen-Bradley?

The same architectural principles apply in Rockwell environments.

Even where the controller itself is primarily built around EtherNet/IP and CIP, higher-level architectures increasingly involve:

OPC UA gateways;
edge platforms;
MQTT brokers;
cloud connectors;
historians;
enterprise applications.

You should therefore think beyond:

What protocol does my PLC support?

and ask:

How should information move through the entire system?

That is the more important engineering question.

MQTT Topic Design Matters More Than People Think

Poor topic architecture can create chaos.

For example:

PLC1/temp
PLC2/temp
machine5/value1
lineA/status
random/device/thing

This may work with five devices.

It becomes a disaster with 500.

A better hierarchy might look like:

company/site/area/line/device/metric

For example:

antomatix/plant01/packaging/line02/conveyor07/speed

Then wildcard subscriptions become powerful.

Subscribe to:

antomatix/plant01/packaging/#

and receive everything inside packaging.

Good namespace design is part of system architecture.

OPC UA Namespace Design Matters Too

OPC UA can also become messy.

Just because the protocol supports information modelling does not mean every implementation is automatically well structured.

A server exposing:

Tag0001
Tag0002
Tag0003
Tag0004

is not providing much useful context.

A better model is:

Line02
 └── Conveyor07
     ├── Status
     ├── Speed
     ├── Fault
     └── Diagnostics

Technology cannot compensate for poor information architecture.

Which Is Easier to Troubleshoot?

OPC UA

Tools such as UaExpert make browsing and testing very convenient.

You can:

connect;
inspect certificates;
browse nodes;
monitor values;
inspect data types;
test writes.

For commissioning, this is excellent.

MQTT

Tools such as MQTT Explorer or MQTTX allow you to inspect:

broker connections;
topic hierarchies;
payloads;
retained values;
subscriptions.

MQTT is also very easy to test once you understand the broker architecture.

Both have excellent commissioning workflows.

They simply expose information differently.

Which Is Better for Node-RED?

Both.

Node-RED has become extremely popular for automation prototypes because it can connect easily to:

OPC UA;
MQTT;
databases;
REST APIs;
dashboards;
Excel;
cloud services.

One very useful architecture is:

PLC
 │ OPC UA
 ▼
Node-RED
 │
 ├── Database
 ├── Excel
 ├── Dashboard
 └── MQTT

Antomatix’s existing OPC UA tutorial demonstrates using Node-RED to read Siemens PLC information and send the results into Excel:

Which Should You Learn First?

For a controls engineer:

Learn OPC UA first.

It maps closely to equipment integration and PLC/SCADA engineering.

Understand:

server;
client;
endpoint;
namespace;
NodeId;
subscription;
certificates;
read/write.

Then learn MQTT.

Understand:

broker;
publisher;
subscriber;
topics;
payloads;
QoS;
retained messages;
sessions;
TLS.

Once you understand both, modern industrial-data architectures become much easier to design.

Should PLC Programmers Learn MQTT?

Yes.

The role of the PLC engineer is expanding.

Modern projects increasingly connect the controller to:

MES;
cloud;
dashboards;
databases;
digital twins;
analytics;
commissioning applications.

Even if you never configure the enterprise platform yourself, understanding how your PLC data eventually reaches those systems makes you a better automation engineer.

Should Software Developers Learn OPC UA?

Also yes.

Developers entering industrial automation often understand:

REST;
JSON;
MQTT;
databases;
APIs.

But they may treat a PLC like a simple collection of variables.

OPC UA provides a much better model for understanding industrial equipment as structured objects.

That is particularly important as OT and IT continue to converge.

The Mistake I Would Avoid

The biggest mistake is choosing a protocol because it is fashionable.

For example:

MQTT is modern, so everything should use MQTT.

No.

Or:

OPC UA is industrial, so every connection should use OPC UA.

Also no.

Start with the requirement.

Ask:

Who produces the data?

Who consumes it?

How many consumers are there?

Does the consumer need to browse the system?

Is semantic context important?

Are commands required?

Is the connection local or remote?

Is bandwidth constrained?

Will consumers change frequently?

Is the system event-driven?

Does the architecture need a broker?

Those questions usually reveal the answer.

Decision Guide

Choose OPC UA when:

connecting PLCs to SCADA;
connecting PLCs to engineering software;
structured machine information matters;
browsing is useful;
direct read/write is required;
alarms and events matter;
rich data types are important;
machine interoperability is the priority.

Choose MQTT when:

sending data to cloud systems;
distributing data to many consumers;
working with remote sites;
network bandwidth matters;
publisher and consumer should be independent;
building event-driven systems;
scaling IIoT architectures;
multiple applications need the same telemetry.

Choose MQTT Sparkplug when:

you want MQTT architecture;
but need industrial topic conventions;
device state;
structured metrics;
OT-focused interoperability.

Choose both when:

PLC-level data needs industrial context;
but enterprise/cloud distribution requires scalable messaging.

For many modern factories:

“Both” is probably the most architecturally mature answer.

A Modern Industrial Architecture

A practical factory architecture could look like this:

 ┌──────────────────────────┐
 │        PLC Layer         │
 │ Siemens / Rockwell / etc │
 └────────────┬─────────────┘
              │
              │ OPC UA
              ▼
 ┌──────────────────────────┐
 │      Edge / Gateway      │
 │ contextualise + filter   │
 └────────────┬─────────────┘
              │
              │ MQTT / Sparkplug
              ▼
 ┌──────────────────────────┐
 │       MQTT Broker        │
 └─────┬─────┬─────┬───────┘
       │     │     │
       ▼     ▼     ▼
      MES   OEE   Cloud
                   │
                   ▼
                Analytics

This architecture plays to the strengths of both technologies.

OPC UA provides industrial context near the machine.

MQTT provides scalable distribution higher in the architecture.

OPC UA vs MQTT: Final Verdict

So which protocol wins?

Neither.

Because they are solving different problems.

OPC UA is strongest when systems need to understand industrial equipment.

It provides:

structure;
semantics;
services;
browsing;
commands;
security;
industrial interoperability.

MQTT is strongest when systems need to distribute information efficiently.

It provides:

lightweight messaging;
publisher/subscriber decoupling;
brokers;
scalability;
flexible consumers;
excellent IIoT/cloud connectivity.

And technologies such as Sparkplug and OPC UA PubSub are increasingly bringing the two worlds closer together.

The future of industrial communications probably will not be:

OPC UA or MQTT.

It will increasingly be:

OPC UA and MQTT — each used where it makes the most engineering sense.

That is the distinction worth learning.

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

OPC UA and MQTT solve different parts of the industrial communication problem.

The Short Answer

Use OPC UA when you need rich, structured access to industrial equipment.

Use MQTT when you need lightweight, scalable distribution of data between many systems.

Use OPC UA to understand the machine and MQTT to distribute the data.

What Is OPC UA?

What Is MQTT?

Broker

The Fundamental Difference

OPC UA understands industrial information.

MQTT moves messages.

OPC UA vs MQTT at a Glance

Architecture 1: OPC UA Client/Server

Architecture 2: MQTT Publish/Subscribe

Example: One PLC and Five Consumers

Where OPC UA Is Better

1. Connecting PLCs to SCADA

2. Browsing Unknown Systems

3. Rich Industrial Information Models

4. Direct Commands and Methods

Where MQTT Is Better

1. Sending Data to the Cloud

2. Distributing Data to Many Applications

3. Remote Sites

4. Event-Driven Systems

The Big MQTT Problem: Context

Enter MQTT Sparkplug

MQTT provides the transport.

Sparkplug provides industrial rules around that transport.

Plain MQTT vs Sparkplug

Does That Make Sparkplug the Same as OPC UA?

OPC UA Also Supports Publish/Subscribe

OPC UA PubSub

OPC UA can use MQTT as a transport.

Think in Layers

Information

Messaging

Application

Security: OPC UA vs MQTT

OPC UA

MQTT Security

MQTT itself is a messaging protocol, not a complete industrial-security architecture.

What About Performance?

MQTT QoS Explained Quickly

QoS 0 — At most once

QoS 1 — At least once

QoS 2 — Exactly once

PLC Control Is Different From Data Integration

Practical Example 1: PLC to SCADA

OPC UA

Practical Example 2: PLC Data to Cloud

MQTT

Practical Example 3: One Machine, Many Consumers

Practical Example 4: WinCC Unified and MQTT

Practical Example 5: Remote Factory

OPC UA

MQTT

What About Siemens?

What About Allen-Bradley?

MQTT Topic Design Matters More Than People Think

OPC UA Namespace Design Matters Too

Which Is Easier to Troubleshoot?

OPC UA

MQTT

Which Is Better for Node-RED?

Which Should You Learn First?

Learn OPC UA first.

Should PLC Programmers Learn MQTT?

Should Software Developers Learn OPC UA?

The Mistake I Would Avoid

Who produces the data?

Who consumes it?

How many consumers are there?

Does the consumer need to browse the system?

Is semantic context important?

Are commands required?

Is the connection local or remote?

Is bandwidth constrained?

Will consumers change frequently?