Modbus, OPC UA or MQTT: which protocol for your plant?
Published 5 min readLeer en español
Short answer
They don't really compete: each fits a different level. Modbus is simple and universal for reading registers from field devices; OPC UA adds an information model and security at machine and PLC level; MQTT is lightweight and efficient for sending telemetry to SCADA or the cloud. Most plants combine them using gateways.
Key points
- Modbus reads and writes numbered registers: simple and almost universal, but it says nothing about what the data means and has no built-in security.
- OPC UA models data with names, types and units, and includes authentication and encryption, at the cost of more complexity.
- MQTT publishes messages through a broker; it is ideal for telemetry but doesn't define the data format unless you use Sparkplug B.
- The usual architecture combines all three: Modbus in the field, OPC UA at machine level and MQTT towards SCADA or the cloud.
- Never expose Modbus to the internet: segment the network and use gateways or a VPN.
If you’re connecting machines, meters or sensors, sooner or later you have to pick a protocol. Modbus, OPC UA and MQTT come up in almost every conversation and are often presented as alternatives. In practice they solve different problems. Here’s what each one does, how they differ and how to choose.
What is Modbus?
Modbus is a request/response protocol (originally master/slave, now usually called client/server) built around numbered registers. One device asks “give me registers 100 to 110” and the other replies with numbers. There are two main variants:
- Modbus RTU: over a serial bus, usually RS-485. Very common in energy meters, drives and simple controllers.
- Modbus TCP: the same data model over Ethernet.
Its big strength is that it’s everywhere and easy to implement. Its limits are just as clear: it has no semantics (register 104 doesn’t tell you whether it’s a temperature or a pressure, or in what units; that’s in the device manual) and no built-in security: anyone with network access can read and write.
What is OPC UA?
OPC UA (Open Platform Communications Unified Architecture) is an open standard for exchanging industrial data with an information model. Data isn’t just numbers: it has names, types, units, hierarchy and relationships. A client can browse a server and discover which variables exist without reading a manual.
Main features:
- Built-in security: certificate-based authentication, message signing and encryption.
- Two communication models: client/server for queries and writes, and PubSub for distributing data to many receivers.
- Companion specifications that standardise how particular types of machine are described.
The price is complexity: it needs more resources, more configuration (certificate management included) and more know-how to get the best from it.
What is MQTT?
MQTT is a lightweight publish/subscribe protocol. Devices don’t talk to each other directly: they publish messages to “topics” (for example plant1/pump3/pressure) on an intermediate server called a broker, and anyone interested subscribes to those topics.
It copes well with slow or unreliable links, uses little bandwidth and fits naturally with IT and cloud systems. It offers quality-of-service levels to guarantee delivery and supports TLS and authentication on the broker.
Its limitation: MQTT doesn’t define what goes inside the message. Every integrator can invent their own payload format and topic structure. Sparkplug B fixes this by adding a topic structure, a message format and device state management.
How do Modbus, OPC UA and MQTT compare?
| Aspect | Modbus RTU/TCP | OPC UA | MQTT |
|---|---|---|---|
| Model | Request/response on registers | Client/server and PubSub with an information model | Publish/subscribe via a broker |
| Data semantics | None: just numbers | Full: names, types, units, structure | None by default; Sparkplug B adds it |
| Security | Not built in | Certificates, signing and encryption | TLS and authentication on the broker |
| Complexity | Low | High | Low to medium |
| Device resources | Minimal | Moderate to high | Low |
| Typical use | Meters, drives, field sensors | PLCs, machines, SCADA/MES integration | Telemetry, remote sites, cloud and IT applications |
| Weak spot | Register map lives in each device’s manual | Configuration and learning curve | Incompatible payloads unless a standard is agreed |
How do they fit together in a real architecture?
Most plants don’t pick one; they use each protocol at the level where it fits:
- Field level: energy meters, drives and sensors speak Modbus RTU or TCP to the PLC or a gateway.
- Machine and PLC level: the PLC exposes its data via OPC UA, with names and units, to SCADA or other plant systems.
- Supervision and cloud level: a gateway or the SCADA itself publishes telemetry over MQTT to a historian, a dashboard or a remote server.
Gateways are what join the levels: they read Modbus, map registers to meaningful names and publish via OPC UA or MQTT. It’s important that control keeps working if the external connection drops: the plant shouldn’t need the internet to produce.
Which protocol should you choose for your case?
- You want to read existing energy meters or drives: almost certainly Modbus, because that’s what they ship with. See idle energy consumption: what your factory uses when it isn’t producing.
- You’re integrating several machines with modern PLCs into SCADA or MES: OPC UA, for its data model and security.
- You have remote sites on mobile connections (pumping stations, tanks, fields): MQTT, for its light footprint and tolerance of dropouts. We cover this in pumping station telemetry.
- You’re sending data to a cloud platform or IT applications: MQTT, ideally with Sparkplug B or a documented payload format.
- You’re designing your own device: offer Modbus at least for compatibility, and add MQTT or OPC UA if the destination needs it.
Questions to help you decide
- Which protocols do your existing devices already support?
- Who will consume the data: an operator, a SCADA system, a cloud application?
- Is the link local and stable, or remote and intermittent?
- Do you need to write setpoints, or only read data?
- What security requirements apply to the network?
What security precautions should you take?
- Don’t expose Modbus to the internet. It has no authentication: opening its port lets anyone read and write to your equipment.
- Segment the network. Separate the control network from the office network with firewalls and allow only the traffic you need.
- Use the security each protocol offers. With OPC UA, enable signing and encryption and manage certificates properly. With MQTT, use TLS, per-device credentials and per-topic permissions on the broker.
- Push data out; don’t let access in. It’s better for a gateway to publish outwards than for someone to connect inwards; if you need remote access, use a VPN.
How do you avoid vendor lock-in?
All three protocols are open, but that guarantees little if your data ends up in a proprietary format. Insist that the architecture uses documented standards, that the variable map and topic structure are written down, and that the data is yours and exportable. That way you can change SCADA, cloud platform or integrator without rebuilding the plant.
How we approach it at Kinetifab
We work only with open protocols (Modbus, OPC UA and MQTT) and design systems so that control runs locally, without depending on the internet. Before proposing an architecture we look at what you already have and what you need to measure, and the documentation is handed over to you. There’s more on our industrial automation page, or you can get in touch to talk through your case.