OPC UA, MQTT and Modbus: choosing the right industrial protocol

Why this decision is more expensive to reverse than it looks

Protocol choice tends to get made quickly, early, and by whoever is writing the first integration. It then quietly determines the shape of everything built afterwards: how devices are addressed, what the network has to permit, how security is enforced, how much engineering is needed each time a new machine is added, and whether a consumer three years from now can understand the data without a phone call.

By the time those consequences are visible, there are usually devices in the field, a data historian full of records in a particular shape, and a team that has learned one way of doing things. Changing course is possible but it is rarely cheap.

What follows is an attempt to set out the three protocols you will actually encounter in industrial work, what each is genuinely good at, where each will let you down, and how to decide between them for a specific situation rather than in general.

The layers underneath the question

Part of the confusion in this area comes from comparing things that do not occupy the same position in a system. It helps to separate three distinct jobs.

• Getting data out of equipment. Reading a register from a drive, a PLC or a meter. This is where Modbus lives, along with the various industrial Ethernet protocols.
• Describing what the data means. Knowing that register 40001 is a motor temperature in tenths of a degree Celsius, without anyone having to tell you. This is what OPC UA adds.
• Transporting data somewhere else. Getting readings from a plant to a server, across a network that may be unreliable, behind firewalls nobody wants to open. This is where MQTT is strongest.

A complete system usually needs all three jobs done. Whether one protocol does more than one of them is a design decision.

Modbus: the one you will meet whether you chose it or not

Modbus was published by Modicon in 1979 for talking to programmable controllers. It is startlingly simple, it is unencumbered, and that combination made it the default. Four decades later it remains the interface most widely offered by industrial equipment, which means that in retrofit and integration work you rarely choose Modbus. You inherit it.

How it works

Modbus is a request and response protocol. A client asks, a server answers, and nothing is sent unless it was asked for. There is no mechanism for a device to report a change on its own; if you want to know about something, you poll for it.

Data is organised into four tables, and this structure is worth understanding because it explains many of the protocol’s quirks.

The two transports you will encounter are Modbus RTU, which runs over serial lines, commonly RS-485, and Modbus TCP, which runs over Ethernet on port 502. RTU addresses up to 247 devices on a shared bus. TCP drops the address in favour of IP but otherwise keeps the same structure, which is why converting between them is mechanical.

What it does well

It is easy. A competent engineer can implement a working Modbus client in a day, and there is a library for every language and platform worth naming. It is deterministic in the sense that polling behaviour is entirely predictable. It is supported by an enormous installed base. Over RS-485 it will run reliably over distances and in electrical conditions that would defeat Ethernet.

Where it falls short

Three limitations matter in practice, and all three are consequences of its age rather than defects in its design.

It has no security at all. No authentication, no encryption, no integrity protection beyond a checksum for transmission errors. Anyone who can reach the network can read every register and, on writable ones, change them. A Modbus/TCP Security variant exists but is rarely found in the field. In practice Modbus is protected by network segmentation, physical access control and by keeping connections read-only, not by anything in the protocol.

It does not describe itself. A Modbus device exposes numbered registers and nothing more. Register 40001 might be motor temperature in tenths of a degree, or pressure in kilopascals, or an arbitrary status word. The protocol has no opinion. That knowledge lives in a document, and if the document is lost or wrong, the data is meaningless. A large share of integration effort on Modbus systems is spent establishing what the registers actually contain.

Anything larger than 16 bits is a convention, not a standard. Floating point values and 32-bit integers occupy two registers, and the specification does not say in which order. Different manufacturers chose differently. The resulting byte-order and word-order confusion is a genuine, recurring source of integration bugs, and the only reliable fix is to read a known value and check which interpretation produces it.

The 40001 problem: addressing conventions

One more piece of Modbus folklore deserves explaining, because it costs newcomers a day and occasionally costs experienced engineers an afternoon.

Documentation frequently refers to registers as 40001, 40002 and so on, or 30001 for input registers. These are not the numbers that travel on the wire. They come from an older convention in which the leading digit indicated which of the four tables was meant: 0 for coils, 1 for discrete inputs, 3 for input registers and 4 for holding registers. The remaining digits were a one-based index into that table.

The protocol itself uses a zero-based address within a table chosen by the function code. So holding register 40001 in a manual is address 0 with function code 03. Register 40100 is address 99.

Matters are made worse by the fact that some manufacturers document the wire address directly, some document the historical five-digit form, and a few document something in between with no indication of which they mean. The result is an off-by-one error that reads plausible but wrong data from the neighbouring register.

The reliable approach is empirical rather than documentary: read a register whose value you can independently verify, such as one the machine displays on its own panel, and adjust until the numbers agree. Once established for a device family, record the convention alongside the register map so nobody has to rediscover it.

OPC UA: the one that knows what the data means

OPC UA, standardised as IEC 62541, was released in 2008 as the successor to the older Windows-bound OPC Classic. It is a considerably more ambitious thing than Modbus. Where Modbus offers numbered registers, OPC UA offers a structured, browsable, self-describing address space.

The information model is the point

This is the feature that justifies the additional complexity. An OPC UA server does not simply expose values; it exposes nodes with types, names, units, data types, relationships to other nodes, and metadata about quality and timestamps. A client can connect to a server it has never seen and browse what is there.

The practical consequence is that integration effort falls as the number of devices rises. With Modbus, every new machine means obtaining and verifying a register map. With OPC UA, a client can discover the structure. Companion specifications extend this further by standardising the model for particular equipment classes, so that two machine tools from different manufacturers present their data in a recognisable common shape.

Security is built in, not added

OPC UA includes authentication using X.509 certificates, message signing, encryption, and user-level authorisation, with defined security policies that specify which algorithms are used. Sessions are established, audited and can be revoked.

This is not free. Certificate management is genuine operational work: certificates have to be issued, trusted, renewed and revoked, and a mismanaged certificate store is one of the most common causes of an OPC UA connection that used to work and now does not. But the capability is there, which cannot be said of Modbus.

Two communication patterns

Classic OPC UA is client and server. A client connects, browses, reads, writes, calls methods, and can create subscriptions so the server pushes changes rather than requiring polling. Subscriptions matter: they remove the largest inefficiency of the Modbus model.

Since Part 14 was added in 2018, OPC UA also supports publish and subscribe, which decouples publishers from consumers and can run over UDP for speed or over MQTT and AMQP for reach. OPC UA PubSub over MQTT is worth knowing about, because it dissolves the apparent either-or between the two: you can carry OPC UA’s information model inside MQTT’s transport.

Where it costs you

It is heavy. A full OPC UA stack needs meaningfully more memory, processing and flash than a Modbus implementation, which puts it out of reach of the smallest microcontrollers. Setup is more involved, and the certificate handling in particular is a source of operational friction. Client-server also expects inbound connections to port 4840, which network administrators are often unwilling to permit from outside the plant.

MQTT: the one that gets data out of the building

MQTT was created in 1999 by Andy Stanford-Clark at IBM and Arlen Nipper, for a SCADA system monitoring oil pipelines over satellite links. That origin explains its character: it was designed from the start for expensive, slow and unreliable connections, which is exactly the situation of a great many industrial sites.

The broker model

MQTT is publish and subscribe through a central broker. Publishers send messages to a topic. Subscribers register interest in topics and receive matching messages. Neither knows about the other, and neither has to be online at the same time.

Topics are hierarchical strings such as plant1/line3/press2/temperature, and subscribers can use wildcards: + matches one level, # matches everything below a point. Subscribing to plant1/# gives you everything from that plant without enumerating the devices.

Quality of service and the features that matter operationally

MQTT defines three delivery guarantees, and choosing wrongly is a common and avoidable cost.

Two further features earn their place in industrial use. Retained messages mean the broker keeps the last value published to a topic and gives it immediately to any new subscriber, so a dashboard that has just started does not sit blank waiting for the next reading. Last Will and Testament lets a client register a message that the broker publishes if that client disconnects unexpectedly, which is how you find out a device has dropped off rather than simply gone quiet.

MQTT 5.0, published in 2019, adds reason codes that explain failures instead of merely closing the connection, shared subscriptions for load balancing across consumers, message expiry, and user properties for metadata. If you are starting new work and your broker and libraries support it, there is little reason to choose 3.1.1.

The gap in MQTT, and Sparkplug B

MQTT’s specification says nothing about payloads. A message is a topic string and a blob of bytes. That flexibility is why MQTT spread so widely, and it is also its biggest practical weakness in industrial settings: every organisation invents its own topic structure and payload format, and every integration then requires a conversation about what the convention is.

Sparkplug B addresses this. It is a specification that layers on top of MQTT and defines a topic namespace, a payload encoding, and a state model including birth and death certificates so consumers know the difference between a device that is idle and one that has gone away. If several vendors or teams will publish to a shared broker, adopting Sparkplug avoids having to create and then enforce a convention of your own.

Head to head

The comparison below is the summary. The paragraphs above are what it actually means.

Choosing: a decision path that works

Rather than asking which protocol is best, work through the constraints in the order that actually removes options.

Question one: is the equipment already installed?

If it is, you do not have a free choice. You use whatever interface the device physically offers, and for older equipment that is Modbus, a proprietary serial protocol, or nothing at all. When it is nothing at all, the answer is external sensing: vibration, current, temperature and cycle timing can be measured without any cooperation from the machine. We cover that approach in detail under legacy machine retrofit.

Question two: who has to interpret the data, and do they know the equipment?

If the consumer is one application written by the same team that configured the device, Modbus with a documented register map is sufficient and cheaper. If the data will be consumed by systems and people who were not involved in the installation, self-description starts to pay for itself, and OPC UA becomes the better answer.

Question three: where does the data have to go?

If it stays within the plant network, MQTT is optional. If it has to reach a cloud service, a remote team or a corporate network across a link that is not guaranteed, MQTT’s buffering, session persistence and outbound-only connection behaviour make it the pragmatic choice. Few network administrators will open an inbound port into a plant. Almost all will permit an outbound TLS connection.

Question four: what are the devices capable of?

A microcontroller with a few hundred kilobytes of flash will run Modbus or MQTT comfortably and will not run a full OPC UA stack. If the endpoints are constrained, that decides it, and the richer protocol moves to the gateway.

The combinations that appear in practice

Most real systems are not one protocol. These three arrangements cover a large share of industrial deployments.

Modbus to MQTT

A gateway polls Modbus devices, converts readings into meaningful topics and publishes them. This is the workhorse of retrofit projects. It leaves the installed equipment untouched, adds no risk to the control system when the gateway reads only, and produces modern data from old machines. The work that matters is in the translation: turning register 40001 into plant1/line3/press2/motor_temp_c is where the register map becomes real, and where the word-order questions get settled once instead of in every consumer.

OPC UA to MQTT

Where equipment already speaks OPC UA, a gateway reads it using subscriptions and republishes northbound over MQTT. You keep OPC UA’s typed model on site and gain MQTT’s tolerance of bad links off site. OPC UA PubSub over MQTT is the standardised form of this idea, carrying the information model within MQTT transport rather than flattening it.

Sparkplug B across a shared broker

Where multiple systems and vendors publish to one broker, Sparkplug provides the shared vocabulary that plain MQTT lacks. It is closely associated with the unified namespace idea: a single broker holding a current, structured picture of the whole operation, which any authorised system can subscribe to rather than requesting point-to-point integrations with each source.

Security, compared honestly

Industrial networks were built on an assumption of physical isolation that connecting them to anything immediately invalidates. It is worth being precise about what each protocol does and does not give you.

Whichever you choose, the protections that carry most of the weight are architectural: segmenting operational networks from IT, keeping connections read-only unless writing is genuinely required, and treating the boundary between the two as something that is designed rather than something that happened. We touch on this in AI for industrial machinery and in device security and OTA updates.

What none of these three do

It is as useful to know where this comparison stops.

Deterministic real-time control. Motion control and anything with a hard cycle-time guarantee uses industrial Ethernet designed for it, such as EtherCAT or PROFINET IRT. OPC UA has work in this direction through Time Sensitive Networking, but the three protocols discussed here are for monitoring, supervision and non-critical control.

Safety functions. Safety-related control has its own standards, its own approval requirements and its own engineering discipline. Monitoring data should inform maintenance and operational decisions, not be placed where a wrong value can cause harm.

Low-power wide-area connectivity. None of these is what a battery-powered sensor in a field uses to reach the world. That is LoRaWAN, NB-IoT or similar, with MQTT typically starting at the gateway. We compare those options in wireless connectivity selection.

Three worked situations

Twelve machines, mixed ages, one dashboard

Most expose Modbus TCP or RTU; two expose nothing. The practical design is an edge gateway per area polling the Modbus devices, external vibration and current sensing on the two that offer no interface, normalisation into a consistent topic structure at the gateway, and MQTT northbound to a broker with a dashboard and historian subscribed. OPC UA adds cost here without adding much, because a single team owns all the mappings.

A machine builder shipping to customers

Here the consumer is unknown at design time, which changes the answer. An OPC UA server on the machine, ideally following the relevant companion specification, lets each customer’s existing systems discover and interpret the data without a bespoke integration document per site. An MQTT publishing option alongside it serves customers who want data sent to their own cloud.

Remote assets on poor connectivity

Pumping stations on cellular coverage that comes and goes. MQTT is the clear transport: persistent sessions and local buffering mean readings queue during an outage and flush on reconnection rather than being lost. QoS 1 for telemetry, QoS 2 for the rare command. Modbus locally to the RTU if that is what it speaks. Whether OPC UA is worth adding depends entirely on whether anyone other than the owning team will consume the data.

Designing a topic namespace that survives contact with reality

If you choose MQTT, you will design a topic structure, whether deliberately or by accident. Doing it deliberately costs an afternoon. Doing it by accident costs a migration two years later, when every consumer has hard-coded assumptions about strings that turned out to be temporary.

The principle that matters most: topics should describe where something is in the physical world, not how it happens to be connected today. Physical location changes slowly. Network addresses, vendor names, gateway assignments and device models change often, and anything encoded in a topic becomes a breaking change when it does.

A hierarchy following the shape of the operation works well, broadly along ISA-95 lines: enterprise, site, area, line, cell, device, then the measurement.

Two further habits pay for themselves. Put the unit in the metric name or in the payload, so motor_temp_c rather than motor_temp, because ambiguity about units is a recurring source of expensive confusion. And separate command topics from telemetry topics by a clear prefix, so that broker access control can grant read access to data without granting the ability to write commands.

If this is starting to sound like work you would rather not invent, that is precisely the argument for adopting Sparkplug B, which has already made these decisions and documented them.

Sizing: what the numbers actually look like

Protocol discussions often skip arithmetic, and it is usually the arithmetic that decides whether a design is workable.

Modbus polling budgets

Modbus RTU on a serial line is bounded by baud rate, and it is easy to plan a system that cannot physically deliver the update rate it promises. A read of ten holding registers means an eight-byte request and a twenty-five-byte response, plus the mandatory silent intervals either side and the device’s own response time.

At 9600 baud with eight data bits, no parity and one stop bit, each byte occupies about 1.04 milliseconds. The request and response together are roughly 34 milliseconds of line time, the silent intervals add around 7, and device turnaround commonly adds 10 to 50 more. Call it 50 to 90 milliseconds per transaction. Twenty devices on that bus, polled in turn, gives a cycle time of one to nearly two seconds, before any retry.

At 115200 baud the line time collapses to about 3 milliseconds and device response time dominates, giving perhaps 15 milliseconds per transaction and a cycle of around a third of a second for the same twenty devices.

Two conclusions follow. If you need sub-second updates from many devices, split the bus rather than raising the baud rate and hoping, because RS-485 reach and noise immunity degrade as speed rises. And poll each value no faster than it can meaningfully change: a one-second poll on a bearing temperature that moves over minutes consumes bus time that a genuinely fast-moving value could have used.

MQTT message volume

The other arithmetic that catches projects out is storage and bandwidth. A modest JSON message carrying a timestamp, a value and some identification runs to roughly 100 bytes on the wire once framing and TLS overhead are counted.

The bottom row is where cloud ingestion and storage bills become a board-level conversation. The usual remedy is publishing on change rather than on a timer, with a heartbeat so consumers can distinguish a stable value from a dead device. On slow-moving industrial signals this routinely cuts volume by an order of magnitude or more without losing anything anybody was going to look at.

Binary encodings reduce it further. Sparkplug B uses protocol buffers rather than JSON for exactly this reason, and on a metered cellular link the difference is directly a monthly cost.

Commissioning: what to test before you believe it

A data pipeline that works on the bench and fails in the plant usually fails in one of a small number of predictable ways. These are worth testing deliberately rather than discovering.

• Verify register interpretation against a known value. Put a known temperature on a sensor, or read a value the machine’s own display shows, and confirm your pipeline reports the same number. This catches scaling factors, signed and unsigned confusion, and word order in one step.
• Pull the network cable. Then watch what happens: does the gateway buffer, for how long, and what does it do when the buffer fills? Silently discarding the oldest readings and silently discarding the newest are both defensible choices, but you should know which one you have.
• Confirm the Last Will and Testament actually fires. Kill a publisher without a clean disconnect and check that consumers are told. A device that goes quiet and a device that is reporting a steady value can look identical on a dashboard otherwise.
• Test broker restart. Do subscribers reconnect automatically, do retained messages come back, and do persistent sessions behave as expected?
• Record certificate expiry dates. For both OPC UA and TLS-secured MQTT. An expired certificate on a working system produces a confusing outage, often long after the person who installed it has moved on.
• Load test at realistic rates. A broker handling ten messages a second during commissioning tells you nothing about its behaviour at ten thousand.
• Verify read-only really is read-only. If the design says the gateway never writes, confirm it at the network level rather than trusting the configuration.

A short glossary

Mistakes worth avoiding

• Choosing a protocol before establishing what the equipment exposes. In retrofit work this is decided for you, and discovering that after the architecture is drawn wastes a design cycle.
• Treating MQTT as a data model. It is a transport. Without an agreed topic structure and payload format, every consumer needs a briefing. Decide the convention deliberately, or adopt Sparkplug.
• Polling faster than the process changes. A one-second poll on a temperature that moves over minutes produces load and storage cost without producing information.
• Disabling OPC UA security during commissioning and never re-enabling it. It is a common and understandable shortcut that quietly becomes permanent.
• Ignoring register word order until the numbers look wrong. Establish it once, at the gateway, and record it.
• Writing to equipment because the protocol permits it. Read-only unless writing is genuinely required, and when it is, treat it as a separate decision with its own risk assessment.
• Building an island. A system that collects beautifully and integrates with nothing does not change any decision, which was the point of collecting.

How we help

Protocol selection is rarely a standalone piece of work. It usually arrives inside a larger question about getting data out of equipment and turning it into something that changes a decision. Where we are involved, it typically covers:

• Survey and assessment. Establishing what each machine actually exposes, which is frequently different from what the documentation says, and whether external sensing is needed where no interface exists.
• Architecture. Deciding which protocol sits at which level, where translation happens, and how the system behaves when a link or a broker is unavailable.
• Gateway hardware and firmware. Custom electronics where the environment or the interface rules out off-the-shelf equipment, and the firmware for acquisition, buffering and publishing. See embedded firmware development.
• Register map recovery. Establishing empirically what undocumented Modbus registers contain, including resolving scaling and word order.
• Integration. Into SCADA, historians, maintenance systems and dashboards, so the data reaches the people who act on it. See cloud and dashboards, and our guide to SCADA and PLC integration.
• Security design. Segmentation, read-only boundaries, certificate and credential handling that your team can actually operate.

If you are earlier than that and the question is really about what to measure at all, sensor selection and signal conditioning is the better starting point, and predictive maintenance programmes covers where this data usually ends up being used.

If you take one thing away

The question “which protocol should we use” almost always turns out to be the wrong question. The useful one is “what does each part of this system need to do, and what constraints are fixed rather than chosen”.

Answer that and the protocols largely select themselves: the installed equipment dictates the field layer, who consumes the data dictates whether self-description is worth paying for, and the network between the plant and its destination dictates the transport. Most working industrial systems end up using more than one protocol, not through indecision, but because the problems at each level are genuinely different.

Questions we are asked about this

Common questions

What clients ask before starting

Is OPC UA better than MQTT?

Neither is better in the abstract; they solve different problems. OPC UA describes what data means, which matters when a consumer has to interpret a machine it was not built for. MQTT moves data efficiently over unreliable networks without caring what it contains. A great many real architectures use both: OPC UA to read the machine, MQTT to carry the result north.

Can I replace Modbus with OPC UA?

On equipment that supports it, yes, and you gain self-description and real security. On installed equipment, usually not, because the Modbus interface is what the device physically offers. The normal path is to keep Modbus at the device and convert at a gateway rather than replace what is working.

Does MQTT work without internet access?

Yes. MQTT needs a broker, not the internet. A broker running on a local server or an edge gateway keeps a plant working entirely offline, and can forward to a cloud broker when a connection is available.

What is Sparkplug B and do I need it?

Sparkplug B is a specification layered on MQTT that defines the topic structure, the payload format and how devices announce themselves and report state. Plain MQTT leaves all of that to you. If several teams or vendors will publish to the same broker, Sparkplug saves you from inventing a convention that everyone then has to be told about.

Which protocol is best for battery powered sensors?

Usually none of these three directly. Battery devices typically use a low-power radio such as LoRaWAN or NB-IoT to reach a gateway, and the gateway speaks MQTT onward. MQTT itself is lightweight but still assumes a maintained TCP connection, which is expensive on a battery.

Is Modbus secure?

No. Modbus has no authentication and no encryption; anyone with network access can read and write registers. Modbus/TCP Security exists but is rarely deployed. In practice Modbus is protected by network segmentation and by keeping it read-only where possible, not by anything in the protocol.

Do these protocols give real-time control?

Not in the deterministic sense. OPC UA, MQTT and Modbus are suitable for monitoring, supervision and non-critical control. Hard real-time motion and safety use dedicated industrial Ethernet such as EtherCAT or PROFINET IRT, and safety functions are a separate engineering discipline.

How do I get data out of a machine with none of these interfaces?

Measure it externally. Vibration, current, temperature and cycle timing can be sensed without any cooperation from the machine, then published using whichever protocol suits upstream. This is the usual approach for older equipment.

Start a conversation

What are you trying to connect?

Tell us what the equipment is, what it exposes, and where the data needs to end up. If you have register maps or documentation, that speeds the conversation considerably.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in