Modbus RTU vs Modbus TCP vs OPC UA: Which to Use

Modbus RTU vs Modbus TCP vs OPC UA: Which to Use

The protocol you choose today will stay with the installation for its entire service life. Ten, fifteen years.

And yet it's usually decided in five minutes, by inertia: "the sensor already came with Modbus." Nobody would wire a plant without a drawing, but the communications architecture — which is exactly as structural — gets improvised node by node.

In this article you'll find the complete criteria for the three options that cover 95% of the projects that come through Industrial Shields: Modbus RTU, Modbus TCP, and OPC UA. Plus the answer to the question that's come up in every conversation for the last few years: where does MQTT fit into all this? — including when it replaces OPC UA and when using it is a serious mistake. At the end, the reference architecture we recommend, with all three (or four) protocols placed exactly where each one wins.

The comparison in one table

The table gives you the summary; the real criteria come from understanding what problem each one solves.

Modbus RTU: the veteran that refuses to die (rightly so)

Serial over RS-485, master-slave architecture, binary frame with CRC16, and a 3.5-character silence separating frames. Simple to the extreme — the full spec reads in an afternoon — and that's why everything speaks it: from a 1985 drive to an energy meter built this year.

Real strengths:

• Up to 1,200 meters of bus with no extra electronics: no standard Ethernet run gets there without fiber or repeaters.
• Excellent noise immunity: the RS-485 differential pair rejects common-mode noise that would wreck a single-ended signal — exactly what you need next to a drive.
• Zero infrastructure cost: two wires and a common reference. No switches, no IP addresses, no IT department involved.

Real limitations:

• A single master: nobody else can query the bus. If the SCADA wants to read the same sensors the PLC reads, it either goes through the PLC or it doesn't happen.
• Sequential polling: the master asks each slave in turn. With 20 slaves and large register maps, your refresh cycle stretches into seconds — physics, not configuration.
• Manual addressing: every slave with its address set by DIP switch or menu, documented on a piece of paper somebody has to keep up to date.
• Zero security: whoever taps the bus can read and write. Inside a machine, that's acceptable; going outside it, it isn't.

Modbus TCP: the same language, over Ethernet

The same old register semantics, wrapped in TCP/IP over port 502. What changes is everything else: several simultaneous clients against the same device, star topology with switches, and local network speeds.

Real strengths:

• Coexistence with the existing network: the same structured cabling, the same switches (ideally segmented).
• Diagnostics with standard tools: a ping locates a downed node; Wireshark shows you every transaction. Diagnosing RS-485 takes an oscilloscope and patience; diagnosing Modbus TCP takes a laptop.
• Concurrency: the PLC controls, the SCADA supervises, and the maintenance laptop queries — all at once, against the same slave.
• Easy scaling: adding a node is a patch cable to a switch, not opening a live bus.

Real limitations:

• Still no native security: the frame travels in plain text with no authentication. The right answer is architecture: segment the OT network (its own VLAN, firewall toward IT) and never expose port 502 outside it.
• Still a flat register map: register 40021 means "furnace temperature" only because a spreadsheet somewhere says so, and someone will eventually lose that spreadsheet. The protocol carries numbers, not meaning — and that limitation is the doorway to what comes next.

OPC UA: the one with the data model built in

Here the category changes. OPC UA doesn't transport registers — it transports objects with semantics. The variable is called "Furnace1.Temperature," it carries units, a timestamp, and data quality, and the client discovers it by browsing the server's address space — no mapping spreadsheet needed. Connect the MES client to the server and you see the machine's structure the way you'd browse folders.

It also brings what Modbus never had: security by design. Session signing and encryption, mutual authentication via certificates, users with per-node permissions. It's the only one of the three you can defend in a cybersecurity audit without hiding behind "it's on an isolated network."

The cost: complexity. An OPC UA server isn't something you stand up in an afternoon: address space, security profiles, certificate management. It consumes real memory and CPU, and on a small microcontroller it simply doesn't fit with all its layers — its natural home is Linux-based equipment acting as a server or gateway at the OT/IT boundary.

The practical consequence: OPC UA doesn't compete with Modbus for the field bus. It competes for the boundary: the point where plant data gets handed off to systems that aren't part of the plant — MES, historian, ERP, another company.

What about MQTT? A different league — and here's the full picture

MQTT doesn't compete with Modbus, and only sometimes competes with OPC UA. It's a publish/subscribe protocol through a central broker: nodes don't talk to each other, they publish messages on "topics" and the broker distributes them to whoever's subscribed. It was built for telemetry over poor links, and at that it remains unbeatable: minimal header overhead (fits comfortably on an ESP32), tolerance to disconnections, and a model that scales to thousands of nodes without anyone polling anyone.

When MQTT replaces OPC UA (and wins):

• Telemetry to the cloud or a remote central system: many scattered nodes, intermittent links (WiFi, 4G), data flowing in one direction. An ESP32 PLC publishing over MQTT is simpler, cheaper, and more robust than any alternative.
• Greenfield IIoT architectures where you control both ends and can fix the data contract: with the Sparkplug B specification, MQTT also gains session state ("birth/death certificates") and a defined data model, covering part of the semantic ground OPC UA occupies.
• Volume and scale: when what you need is moving time series from hundreds of machines into a historian, the pub/sub model crushes client-server on efficiency.

When using MQTT is a serious mistake:

• Control: sending commands to actuators through a broker means putting an intermediary — a single point of failure with unbounded latency — inside your control loop. QoS 1 or 2 guarantee delivery, not timing. A stop command that arrives "guaranteed, but late" is not a stop command.
• Interoperability with third parties without a prior contract: plain MQTT doesn't define what's inside the message — every integrator invents their own JSON. OPC UA bakes the data model into the standard; with MQTT (without an agreed Sparkplug), you're back to the mapping spreadsheet, just in topic form.
• Anything whose absence would stop or damage the machine: last week's rule applies here too — data that can arrive late travels by pub/sub; control travels over deterministic, point-to-point protocols.

The short version: MQTT moves data upward extraordinarily well; it doesn't move responsibility downward. OPC UA still wins when the boundary demands standard semantics, certifiable security, and interoperability with third-party systems; MQTT wins when the boundary is yours, the nodes are many, and the link is poor.

The reference architecture: RTU at the bottom, TCP in the middle, UA/MQTT at the top

This is the architecture we recommend — and the one we build — for a typical plant. Three levels, each protocol placed where it wins:

Level 1 — Field bus: Modbus RTU. From the PLC downward: drives, sensors, energy meters, I/O slaves. Long distances, noise, minimal cost, devices from any decade. One bus (or several) per machine, wired in line, terminated, shielded — as covered in last week's wiring mistakes.

Level 2 — Control network: Modbus TCP. Between PLCs, and from the PLCs to the local SCADA. A segmented OT Ethernet network, industrial switches, concurrency so control and supervision don't step on each other. HMIs live here too.

Level 3 — OT/IT boundary: OPC UA and/or MQTT. A gateway — a Linux DIN-rail device — concentrates data from the lower levels and hands it upward: OPC UA for MES, historians, and third-party systems that demand semantics and security; MQTT for telemetry to the cloud or a central system. It's the only point that crosses the firewall, and it crosses with encryption and certificates — never exposing Modbus directly to IT.

The strength of this architecture is that each level isolates the one below it: you can upgrade the SCADA without touching the field bus, or switch cloud platforms without touching control. And the gateway translates once, in one place, with one documented mapping.

The decision rule, in short

• Field bus to drives, sensors, and I/O slaves → Modbus RTU (and let it keep going).
• Communication between PLCs, and PLC to local SCADA → Modbus TCP.
• OT/IT boundary: handing data to MES, historians, or another company → OPC UA.
• Mass telemetry, remote nodes, intermittent links, cloud → MQTT (never control).

If your installation doesn't fit this scheme, the right question usually isn't "which protocol?" but "which level of the architecture am I missing?"

📥 Download the checklist: "From Arduino prototype to industrial installation"
The 12 steps — communications included — for taking your project from the workbench to the electrical panel, in printable PDF.
Download the free checklist →

Almost our entire range speaks several of these protocols at once: the M-Duinos come with Ethernet and RS-485 (Modbus) built in, the ESP32 PLCs add WiFi and BLE, and the Raspberry Pi PLC family speaks Modbus RTU, Modbus TCP, RS-485, and Ethernet on top of Linux. If you're wondering what to put at the OT/IT boundary, start with the GateBerry — a Raspberry Pi-based gateway that bridges sensors, local equipment, and the cloud, fully compatible with Node-RED, MQTT, and open platforms: GateBerry industrial PLC gateway — it's the question we resolve most often.