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

The protocol you choose stays with the installation for its whole service life, often ten or fifteen years. Yet it is usually chosen by inertia: "the sensor already came with Modbus". This guide gives the criteria for the three options that cover most plant projects, places MQTT among them, and ends with a reference architecture where each protocol works at the level where it wins.

1. Level 1Field busModbus RTU on RS-485: drives, meters, sensors, I/O slaves
2. Level 2Control networkModbus TCP on Ethernet: PLCs, local SCADA, HMIs
3. Level 3OT/IT boundaryOPC UA on a gateway: MES, historian, third parties
4. TelemetryCloud or centralMQTT through a broker: data up, never control down

Modbus RTU vs Modbus TCP vs OPC UA vs MQTT: comparison table

The table is the summary. The choice comes from the problem that each protocol solves, explained below.

When should you use Modbus RTU?

Modbus RTU is a binary master and slave protocol on a serial line, usually RS-485. Each frame ends with a CRC-16, and frames are separated by a silence of at least 3.5 characters (a fixed 1.75 ms above 19,200 bit/s). The specification is short, so almost every drive, energy meter, sensor and I/O module speaks it, from devices built decades ago to this year's models.

Strengths:

• Up to 1,200 m of bus without extra electronics, at low baud rates (around 100 kbit/s or less). A copper Ethernet segment stops at 100 m.
• Good noise immunity. The RS-485 receiver reads the difference between two wires, so noise that reaches both wires in the same way cancels out. That matters next to drives and contactors.
• No infrastructure. A twisted pair and a common reference: no switches, no IP addresses, no IT department.

Limitations:

• One master only. If the SCADA needs the same values that the PLC reads, it gets them through the PLC.
• Sequential polling. The master asks each slave in turn. At 19,200 bit/s, reading 10 registers from one slave takes about 20 ms on the wire plus the slave response time, so 20 slaves with large register maps push the update cycle to seconds.
• Manual addressing. Each slave has its address set by DIP switch or menu, and the register map lives in a document that someone must keep up to date.
• No security. Anyone connected to the bus can read and write. That is acceptable inside a machine, not outside it.

Most intermittent RTU faults are electrical: see RS485 troubleshooting: step-by-step bus fault diagnosis and PLC wiring mistakes. For master and slave sketches on Arduino and ESP32 based PLCs, see Modbus RTU with Arduino and ESP32 based PLCs.

When should you use Modbus TCP?

Modbus TCP carries the same function codes and registers inside TCP/IP, on port 502, with a 7-byte MBAP header in place of the slave address and the CRC. What changes is the network: several clients can talk to the same device, the topology is a star with switches, and the speed is that of the local network.

Strengths:

• It uses the plant Ethernet. The same structured cabling and switches, ideally in a separate OT segment.
• Diagnosis with standard tools. A ping finds a node that is down, and Wireshark decodes every transaction. RS-485 needs an oscilloscope and patience; Modbus TCP needs a laptop.
• Concurrency. The PLC controls, the SCADA supervises and a maintenance laptop reads, all at the same time.
• Easy to extend. A new node is a patch cable to a switch, not a change on a live bus.

Limitations:

• No security in plain Modbus TCP. Frames travel in clear text without authentication. The Modbus Organization publishes a secure variant with TLS (Modbus/TCP Security, port 802), but few field devices support it. In practice the answer is architecture: an OT network with its own VLAN, a firewall towards IT, and port 502 never exposed outside it.
• Still a flat register map. Register 40021 means "furnace temperature" only because a spreadsheet says so. The protocol carries numbers, not meaning, and that is the gap OPC UA fills.

Working examples with Python and Node-RED are in the Modbus TCP and RTU guide for Raspberry Pi PLCs, and with CODESYS in Setting up Modbus on a Raspberry Pi PLC with CODESYS.

When should you use OPC UA?

OPC UA does not transport registers: it transports objects with meaning. A variable is called, for example, Furnace1.Temperature, and it carries its data type, units, a timestamp and a status code. A client browses the address space of the server and finds the variables without a mapping spreadsheet: connect an MES client and you see the structure of the machine like a folder tree.

It also brings what Modbus never had: security by design. Signed and encrypted sessions, mutual authentication with X.509 certificates, and users with rights per node. Of the three, it is the only one you can defend in a cybersecurity audit without saying "it is on an isolated network".

The cost is complexity. A server needs an address space, security policies and certificate management, and it uses real memory and CPU. Small embedded profiles exist, but a full server with security fits best on Linux equipment that acts as a server or gateway at the OT/IT boundary.

So OPC UA does not compete with Modbus for the field bus. It competes for the boundary: the point where plant data goes to systems outside the plant, such as an MES, a historian, an ERP or another company. An example with flows is in OPC UA server on a Raspberry PLC with Node-RED.

Where does MQTT fit, and when is it a mistake?

MQTT does not compete with Modbus, and only sometimes with OPC UA. It is a publish and subscribe protocol through a central broker: nodes do not talk to each other, they publish messages on topics, and the broker delivers them to the subscribers. It was made for telemetry over poor links: the fixed header is only 2 bytes, it tolerates disconnections, and it scales to thousands of nodes without polling.

When MQTT is the better choice:

• Telemetry to the cloud or to a remote central system: many scattered nodes, intermittent links (Wi-Fi, 4G) and data that flows one way. An ESP32 PLC that publishes over MQTT is simpler and more robust than any alternative.
• New IIoT architectures where you control both ends and can fix the data contract. With Sparkplug B (Eclipse Foundation, published as ISO/IEC 20237), MQTT adds session state (birth and death messages) and a defined payload, which covers part of the ground of OPC UA.
• Volume: to move time series from hundreds of machines to a historian, publish and subscribe is more efficient than client and server polling.

When MQTT is a serious mistake:

• Control. Sending commands to actuators through a broker puts an intermediary, a single point of failure with unbounded latency, inside the control loop. QoS 1 and 2 guarantee delivery, not timing. A stop command that arrives late is not a stop command.
• Integration with third parties without a prior contract. Plain MQTT does not define the content of the message, and each integrator invents a JSON format. OPC UA puts the data model in the standard.
• Anything whose absence would stop or damage the machine. Data that can arrive late travels by publish and subscribe; control travels on deterministic, point-to-point protocols.

In short, MQTT moves data up very well; it does not move responsibility down. To start, see MQTT with Node-RED on a Raspberry PLC and MQTT over TLS on an ESP32 PLC.

Reference architecture: RTU at the bottom, TCP in the middle, OPC UA and MQTT at the top

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

Level 1, field bus: Modbus RTU. From the PLC down: drives, sensors, energy meters and I/O slaves. Long distances, noise, low cost and devices of any age. One bus or more per machine, wired as a line, terminated at both ends and shielded.

Level 2, control network: Modbus TCP. Between PLCs, and from the PLCs to the local SCADA and the HMIs. A segmented OT Ethernet network with industrial switches, where control and supervision do not get in each other's way.

Level 3, OT/IT boundary: OPC UA, MQTT or both. A gateway, a Linux device on a DIN rail, collects the data of the lower levels and passes it up: OPC UA for MES, historians and third-party systems that need meaning and security, and MQTT for telemetry to the cloud or a central system. It is the only point that crosses the firewall, with encryption and certificates. Modbus is never exposed directly to IT.

Each level isolates the one below it: you can replace the SCADA without touching the field bus, or change cloud platform without touching control. The gateway translates once, in one place, with one documented mapping.

The decision rule

• Field bus to drives, sensors and I/O slaves: Modbus RTU.
• Between PLCs, and from PLC to local SCADA or HMI: Modbus TCP.
• OT/IT boundary, data for an MES, a historian or another company: OPC UA.
• Mass telemetry, remote nodes, intermittent links, cloud: MQTT, never for control.

If an installation does not fit this scheme, the useful question is usually not "which protocol?" but "which level of the architecture is missing?".

FAQ about Modbus RTU, Modbus TCP and OPC UA

Is Modbus TCP faster than Modbus RTU?

Yes, in most installations. Modbus RTU runs at 9,600 to 115,200 bit/s and polls one slave at a time; Modbus TCP runs at Ethernet speed and accepts several clients. The registers and function codes are the same, so the response time of the device often becomes the limit.

Can Modbus RTU and Modbus TCP devices work in the same system?

Yes, through a gateway that is a Modbus TCP server on Ethernet and a Modbus RTU master on RS-485. The gateway translates the requests and the RTU slaves stay on their bus.

How many devices can a Modbus RTU bus have?

The protocol allows slave addresses 1 to 247. The RS-485 standard allows 32 unit loads per segment; transceivers with a fraction of a unit load or repeaters allow more devices. In practice the polling time sets the limit first.

Does OPC UA replace Modbus?

Not on the field bus. OPC UA needs more resources and its value is the data model and the security at the OT/IT boundary. The usual design keeps Modbus below and publishes the data with OPC UA from a gateway.

Is MQTT an alternative to OPC UA?

For telemetry to systems you control, yes, especially with Sparkplug B. For integration with third parties that need a standard data model, or for anything that must be audited for security, OPC UA is the safer choice. For control, neither replaces Modbus or a fieldbus.

More about industrial communications

• Modbus TCP and RTU guide for Raspberry Pi PLCs: Python and Node-RED examples
• Modbus RTU with Arduino and ESP32 based PLCs
• RS485 troubleshooting: step-by-step bus fault diagnosis
• OPC UA server on a Raspberry PLC with Node-RED
• Arduino PLC vs ESP32 PLC vs Raspberry Pi PLC: which to choose
• Industrial applications: 50 real examples by sector, with their signals and protocols