Modbus vs OPC UA vs MQTT: Which Industrial Protocol Fits

A plant has 40 energy meters that speak Modbus, a new line whose controllers expose OPC UA, and a request from management to see everything in a cloud dashboard by next quarter. The Modbus vs OPC UA vs MQTT question rarely has a single answer because the three solve different problems: Modbus moves register values, OPC UA describes what the values mean and secures access to them, and MQTT distributes messages to whoever subscribes. This article compares how each one works, what each specification provides, what independent measurements found about their performance, and how to calculate whether a Modbus network can poll fast enough.

Key Takeaways

• Modbus is request-response: a client asks, a server answers. Its data model is four tables of numbered bits and 16-bit registers, with no names, units or types. A single read returns at most 125 registers.
• OPC UA servers expose an address space of typed, linked nodes that clients can browse, plus services for reading, writing, subscriptions, alarms and events. Security (authentication, signing, encryption) is part of the specification.
• MQTT 5.0 is a publish-subscribe transport through a broker, with three delivery guarantees: at most once, at least once and exactly once. It carries any payload and defines no data model.
• In Profanter et al.’s 2019 benchmark, MQTT had the smallest connection and message overhead, while the open62541 OPC UA implementation had among the lowest round-trip times. Results depended on the implementation and load.
• The choice often follows the layer: Modbus at legacy devices, OPC UA for structured plant data, MQTT for many-to-many or plant-to-cloud distribution.

The problem: three protocols, three different jobs

Industrial data has to cross several boundaries: from a sensor or drive to a controller, from controllers to supervisory systems, and increasingly from the plant to cloud or enterprise applications. Each boundary has different needs. At the device, simplicity and compatibility with installed equipment matter most. In the plant, operators and engineers need to know what each value is, in what unit, and who’s allowed to change it. Between plant and cloud, connections are intermittent, firewalls block inbound traffic, and many consumers want the same data.

Comparing the protocols as if they were alternatives for the same job leads to bad choices, such as running cloud analytics by polling Modbus registers over a VPN, or putting a full OPC UA stack on a sensor that only needs to send one number.

What each specification provides

Modbus: registers and requests

The Modbus Application Protocol specification (V1.1b3, published by the Modbus Organization) defines a simple client-server exchange. A client sends a request with a function code and an address range; the server returns the data or an exception. The data model has four primary tables: discrete inputs (read-only bits), coils (read-write bits), input registers (read-only 16-bit words) and holding registers (read-write 16-bit words). A Read Holding Registers request can return at most 125 registers, a limit set by the protocol’s 253-byte maximum data unit.

What Modbus doesn’t define is what a register means. Register 40,021 might be a temperature in tenths of a degree, the low half of a 32-bit float, or a status bitfield, and the only way to know is the device’s register map. Byte and word order for 32-bit values varies between manufacturers. The same application protocol runs over serial lines (RTU) and over TCP/IP, and the Modbus Organization has also published a Modbus Security protocol that wraps Modbus/TCP in TLS, but much installed equipment predates it.

OPC UA: an information model with security

The OPC UA specification (published by the OPC Foundation as OPC 10000 and as the IEC 62541 series) describes itself as “a platform-independent standard that enables various systems and devices to communicate securely and reliably.” Its central idea is the address space: a server represents its data as nodes connected by references, with attributes describing each node, so a client can browse the server and find, for example, a pump object with a speed variable in revolutions per minute, a setpoint it may write, and alarms it can subscribe to.

On top of the address space, OPC UA defines services for reading and writing, subscriptions that notify a client when values change, and alarms and events. Security is part of the specification: the overview lists mechanisms “for authentication, encryption, and integrity checks,” with messages that can be signed and encrypted at the transport level and users authenticated when a session starts. Beyond the session-based client-server model, OPC UA PubSub moves data from publishers to subscribers and “is not bound to a particular messaging system”; it can run over MQTT, among others.

Companion specifications standardize information models for particular kinds of equipment, so that machines from different vendors expose similar structures.

MQTT: publish-subscribe through a broker

MQTT Version 5.0, an OASIS Standard published in March 2019, is a client-server publish-subscribe transport. Clients publish messages to topics on a server (the broker), and the broker forwards each message to the clients subscribed to matching topics. Publishers and subscribers don’t need to know about each other, and devices only make outbound connections, which works well through firewalls.

The specification defines three qualities of service: QoS 0, “at most once,” where “message loss can occur”; QoS 1, “at least once,” where messages “are assured to arrive but duplicates can occur”; and QoS 2, “exactly once.” It also defines retained messages, so a new subscriber immediately receives the last value on a topic, and a Will message that the broker publishes if a client disconnects abnormally, which gives a simple way to detect an offline device. Session expiry intervals control how long the broker keeps a disconnected client’s state.

MQTT says nothing about the payload. A temperature can be sent as plain text, JSON or a binary structure, and topic naming is up to the system designer. Conventions such as Sparkplug, or OPC UA PubSub over MQTT, add the structure that MQTT itself leaves out.

What measurements show

Profanter, Tekat, Dorofeev, Rickert and Knoll compared OPC UA, ROS, DDS and MQTT at the 2019 IEEE International Conference on Industrial Technology, using open-source implementations on two real-time Linux machines. MQTT (Eclipse Paho) had the lowest protocol overhead, 17 bytes for connection setup, while OPC UA had higher overhead per message. In round-trip time with the system idle, the open62541 OPC UA PubSub implementation was the fastest of the middleware tested for most message sizes, followed by DDS and OPC UA client-server, with MQTT slower and showing the most outliers. Under CPU load, OPC UA latency stayed close to idle while MQTT and DDS slowed by roughly 300 µs. The authors caution that the results reflect the specific implementations.

A study by Silveira Rocha and colleagues in Acta IMEKO (2019) compared OPC UA PubSub and MQTT for plant-to-cloud exchange, measuring transferred data and round-trip time across several cloud scenarios, and concluded that the better choice depends on the scenario. The common thread is that implementation and deployment matter as much as the protocol.

A Modbus polling budget, worked through

Modbus over a serial line is polled one device at a time, so the question is whether a full cycle fits the update rate. Illustrative numbers for an RTU network:

• 50 meters, each read with one request for 20 holding registers, at 19,200 baud.
• Request: 8 bytes. Response: 5 bytes of framing plus 40 data bytes, 45 bytes.
• Each RTU character is 11 bits on the wire, so 53 bytes is 583 bits, about 30 ms at 19,200 baud.
• Silent intervals between frames of 3.5 character times, about 2 ms each, twice per transaction: about 4 ms.
• Device response time (from the meter’s documentation; here an illustrative 10 ms).

One transaction takes about 44 ms, so a full cycle of 50 meters takes about 2.2 seconds. If the dashboard needs one-second updates, the options are a higher baud rate, fewer registers per poll, splitting the meters across two or three serial lines, or a gateway that polls locally and publishes changes upstream. Over Modbus/TCP the wire time shrinks, but each device’s response time and the client’s request handling still add up.

Modbus vs OPC UA vs MQTT compared

Property	Modbus	OPC UA	MQTT
Pattern	Request-response (client polls server)	Client-server sessions with subscriptions; PubSub option	Publish-subscribe through a broker
Data model	Four tables of numbered bits and 16-bit registers	Typed, browsable address space; companion information models	None; payload and topics defined by the system
Meaning of values	Device register map	In the model (names, types, units, relationships)	By convention (for example Sparkplug)
Security	None in the base protocol; Modbus Security adds TLS for TCP	Authentication, signing, encryption in the specification	TLS and broker authentication, configured by deployment
Delivery	Response or timeout per request	Session-based; subscriptions with queues	QoS 0, 1, 2; retained messages; Will message
Overhead	Very low	Higher per message	Very low
Typical place	Field devices, meters, drives, legacy equipment	Controllers, SCADA, MES, machine-to-machine	Edge-to-cloud, many consumers, intermittent links

What to actually do

Pick by layer, not by fashion

Keep Modbus where the devices already speak it, use OPC UA where structured, secure plant data is needed, and use MQTT where many systems consume data or the link crosses into the cloud.

Document Modbus register maps like code

Record each register’s meaning, unit, scale, data type and word order in a version-controlled map, and test it against a known value on the real device.

Calculate polling cycles before adding devices

Use the worked budget above with your baud rate, register counts and device response times. Add a margin for retries.

Turn on security where the protocol has it

Use OPC UA’s signed and encrypted modes with real certificates, not the “None” policy, and run MQTT over TLS with per-device credentials. Keep Modbus on isolated networks or behind a gateway.

Define the MQTT payload and topics up front

Agree on a topic structure, a payload format, timestamps and units before the first device publishes, or adopt a convention that already defines them.

What not to do

Don’t poll field devices directly from the cloud. And don’t treat an MQTT topic name as a data model; without agreed payloads, every consumer has to guess.

How to put it to work

If you have an hour

Draw your data path from sensor to dashboard and label each link with the protocol it uses, who initiates the connection and whether it’s secured.

If you have a sprint

Build a gateway prototype that polls a few Modbus devices locally, maps registers to named, typed values, and publishes changes over MQTT or exposes them through OPC UA. Measure the polling cycle.

If you want it to last the product’s lifetime

Keep register maps, OPC UA models and MQTT topic and payload definitions in version control with the firmware and gateway configuration, and review them whenever a device or consumer is added.

The question to ask yourself: “If someone new connects to this data next year, will they be able to tell what each value means without asking the person who set it up?”

Frequently asked questions

Is OPC UA replacing Modbus?

Not in installed equipment, where Modbus remains widespread because it’s simple and cheap to implement. OPC UA is more common in new controllers and supervisory systems, and gateways often translate Modbus data into an OPC UA model.

Is MQTT better than OPC UA?

They do different jobs. MQTT is a lightweight transport for distributing messages through a broker and defines no data model; OPC UA defines an information model, services and security. OPC UA PubSub can even use MQTT as its transport.

Is Modbus secure?

The base protocol has no authentication or encryption. The Modbus Organization publishes a Modbus Security protocol that uses TLS for Modbus/TCP, but much installed equipment doesn’t support it, so Modbus networks are usually isolated or reached through a gateway.

Which protocol has the lowest latency?

It depends on the implementation and load. In one 2019 benchmark of open-source implementations, the open62541 OPC UA PubSub implementation had among the lowest round-trip times, and MQTT had the lowest overhead but more latency outliers.

Can I use MQTT and OPC UA together?

Yes. A common pattern is OPC UA inside the plant and MQTT from an edge gateway to the cloud, and OPC UA PubSub can publish its messages over MQTT.

Related reading: the 4–20 mA current loop explained, edge vs cloud processing for industrial data and designing dashboards operators act on.

Sources

1. Modbus Organization. Modbus Application Protocol Specification V1.1b3, and related specifications. https://modbus.org/modbus-specifications
2. OPC Foundation. OPC 10000-1: OPC Unified Architecture, Part 1: Overview and Concepts, section 4. https://reference.opcfoundation.org/specs/OPC-10000-1/4
3. OASIS (2019). MQTT Version 5.0. OASIS Standard, 7 March 2019. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
4. Profanter, S., Tekat, A., Dorofeev, K., Rickert, M., & Knoll, A. (2019). “OPC UA versus ROS, DDS, and MQTT: Performance Evaluation of Industry 4.0 Protocols.” 2019 IEEE International Conference on Industrial Technology (ICIT), 955–962. https://doi.org/10.1109/ICIT.2019.8755050
5. Silveira Rocha, M., Serpa Sestito, G., Dias, A. L., Turcato, A. C., Brandão, D., & Ferrari, P. (2019). “On the Performance of OPC UA and MQTT for Data Exchange Between Industrial Plants and Cloud Servers.” Acta IMEKO, 8(2), 80–87. https://doi.org/10.21014/acta_imeko.v8i2.648