OPC UA vs Modbus vs MQTT: which protocol for which job

OPC UA (IEC 62541) is a standard for industrial data exchange that carries values together with their structure, units and built-in security; Modbus sends only register values, while MQTT is a lightweight publish/subscribe protocol often used to send data to the cloud.

The three are not rivals for the same job. Modbus is the simplest way to read a field device. OPC UA describes a whole system, from a tank to its gauge, alarms and history, in a model that other software can browse. MQTT moves messages efficiently over unreliable or expensive links. Choosing well means matching the protocol to the distance, the data and the people who will maintain it.

At a fuel terminal the split is easy to see. Tank gauges, flow computers and valve actuators answer Modbus on RS-485 or Ethernet. The terminal automation system, SCADA and historian need named, timestamped values. A head office or a cloud dashboard needs a compact stream from many sites over links that are not always up.

So the useful question is not which protocol is best, but which protocol serves which link. The answer is almost always a combination, and the meeting point is a gateway or server that translates one protocol into another.

OPC UA lets a client ask a server what a value belongs to, which unit it uses and whether it can be trusted, along with the value itself.

OPC Unified Architecture is maintained by the OPC Foundation as the OPC 10000 series and published by the IEC as IEC 62541. Part 1, Overview and Concepts, release 1.05.06 of October 2025, describes an AddressSpace of nodes linked by references. A tank can be an object with child variables for level, temperature and alarm state, each with a data type, an engineering unit and a quality status.

Security is part of the standard rather than an add-on. Clients and servers authenticate with certificates and exchange messages over a secure channel that can sign and encrypt. Clients can subscribe to changes instead of polling, and since newer releases the specification also defines a PubSub model alongside client/server. IANA registers TCP port 4840 for the OPC UA connection protocol.

The previous generation, classic OPC such as OPC DA, was built on Microsoft COM/DCOM, which tied it to Windows and made it hard to pass through firewalls. OPC UA was redesigned to run independently of the operating system, on Linux servers, PLCs and small gateways, and to carry its own security inside the protocol.

The cost is complexity. An OPC UA server needs certificate management, a designed information model and engineers who understand both. For a single meter on a serial line, that effort rarely pays back.

The quickest way to see the difference is to ask what each protocol knows about the data it carries.

Modbus knows addresses and 16-bit words. OPC UA knows objects, types, units and quality. MQTT knows topics and payloads; the payload format is left to the application unless a convention such as Sparkplug from the Eclipse Foundation defines it. Network behaviour differs too. Modbus and OPC UA client/server are request-driven, while MQTT clients keep one connection to a broker and send only when they have something new.

That difference shows up on the bill and on the screen. Polling one hundred Modbus registers every second sends the same unchanged values again and again. An OPC UA subscription or an MQTT publisher with a deadband sends a level only when it moves by more than a set amount. On a cellular link the saving is real; on a plant LAN it matters less than simplicity.

Choose the protocol per link, not per project: the cable from a gauge, the link between control systems and the path to a remote server each have different needs.

Keep Modbus where the device only speaks Modbus and the link is short and local. Use OPC UA where several systems on site must share structured data and the owner wants security that an auditor can verify, for example under the IEC 62443 series. Use MQTT where sites are remote, links are cellular, and the receiving side is a central server or cloud platform.

Two cautions apply to every choice. Never expose Modbus TCP directly to the internet, since it has no authentication. And check what the software at the other end actually supports before writing it into a specification.

Think about the team that will run the system after commissioning. A Modbus line can be checked by a technician with a laptop and the vendor map. An OPC UA server needs someone who can renew certificates and edit the information model. An MQTT broker needs someone who manages accounts, topics and backups. Pick a design the site can maintain.

In Citia projects, Modbus usually stays at the device, and a gateway or server moves the data to the system that needs it.

At Rich machine connectivity in Serang, the acquisition path links PLCs, ECUs and Advantech EdgeLink over the plant network to the iFactory platform for OEE dashboards. INTEGRA TMS follows a similar pattern at fuel terminals: a gateway in the server room passes ATG readings to an SQL database for live levels, history and tank tickets.

For spread-out sites, CATALYST Telemetering carries river level, pipeline pressure and panel readings to a cloud server and dashboard. INTEGRA CTP, still in development, puts gateways and edge software at each site and keeps PLC control and safety permissives in the local control system. Security for these links follows the layered approach described in Citia's note on secure system integration.