Three protocols that carry a factory, and when each one is the wrong answer.

Modbus, OPC UA and MQTT are not competing choices. They answer different questions, and most factory integration problems come from asking one of them to do another one’s job.

An office network moves documents between people. A factory network moves measurements between machines, on a schedule, where being late is a failure and not an inconvenience. That difference is why industrial protocols exist at all, and why an engineer arriving from web development finds the assumptions inverted.

1. Modbus: old, limited, and everywhere

Modbus dates from 1979 and it is still the most widely implemented industrial protocol in existence. It has no security, no data types beyond registers and coils, and no discovery. It is a master polling slaves for numbered 16-bit registers.

# Reading a temperature from a Modbus device
from pymodbus.client import ModbusTcpClient

c = ModbusTcpClient('192.168.1.50', port=502)
r = c.read_holding_registers(address=40001, count=2, slave=1)

# The device returns two 16-bit words. What they MEAN is not in the
# protocol - it is in a PDF from the vendor. Scaling, byte order and
# sign convention all live outside the wire format.
raw   = (r.registers[0] << 16) | r.registers[1]
temp  = raw / 10.0   # because the manual says so

Where it goes wrong: the meaning of a register is documentation, not data. Byte order in particular is inconsistent between vendors, and a wrong assumption produces a plausible number rather than an error. I treat every new Modbus device as needing verification against a known physical value before its readings are trusted.

2. OPC UA: meaning carried with the data

OPC UA answers Modbus’s central weakness. It carries an information model: a node has a type, a unit, an engineering range and a human-readable name, all discoverable at runtime. You can connect to a machine you have never seen and enumerate what it offers.

Discovery — browse the address space instead of reading a manual.
Typed values — a temperature is a Double with a unit, not word 40001.
Security built in — certificates, encryption, user authentication.
Subscriptions — the server pushes on change, rather than being polled.

The cost is complexity. An OPC UA stack is orders of magnitude larger than a Modbus one, certificate handling causes most first-connection failures, and small embedded devices frequently cannot host it.

3. MQTT: designed for a bad network

MQTT assumes the connection is unreliable, the bandwidth is small and the device may be asleep. It is publish-subscribe through a broker, with quality-of-service levels and a last-will message the broker sends if a device disappears.

# QoS is the design decision, not the topic name
0  at most once   - fire and forget. Fine for a temperature every second.
1  at least once  - guaranteed delivery, duplicates possible.
2  exactly once   - guaranteed, no duplicates, most overhead.

# A counter published at QoS 1 will eventually double-count.
# A command published at QoS 0 will eventually be lost.

The trap: MQTT gives no ordering guarantee across topics and no meaning to the payload. Teams publish JSON and invent a schema per device, and two years later nobody can say what t1 means on the older line. MQTT solves transport, not semantics — pair it with a schema you enforce, or you have rebuilt Modbus’s problem with better networking.

4. Choosing, in practice

Question	Answer
Small PLC, fixed registers, local wired network	Modbus
Machine-to-system integration where meaning must travel	OPC UA
Many devices, intermittent link, telemetry to a platform	MQTT
Deterministic motion control	None of these — you need a fieldbus

Most real plants run all three: Modbus at the device edge because that is what the hardware speaks, OPC UA between machines and the MES, MQTT to move telemetry out to a platform. The integration work is the translation between them, and that translation is where units, scaling and timestamps get lost.

5. What I check first on any industrial data feed

Units and scaling, verified against a physically known value rather than against the manual.
Timestamps — is time stamped at the sensor, the gateway or the database? Only the first survives a network delay.
Behaviour on disconnect — does the consumer see stale data or no data? Stale is far more dangerous, because it looks correct.
Sample rate against the physics — sampling a 50 Hz phenomenon at 10 Hz produces a smooth, confident, wrong signal.

That last one is the same idea as testing: a number is only useful once you can say when to trust it. On a factory network the failure mode is rarely an error message. It is a plausible value that nobody questions.