The Protocol Fragmentation Problem: MQTT vs OPC UA vs Modbus

Modbus was designed in 1979. Its creators were solving a specific problem: how do you get a Modicon PLC to talk to peripheral devices over a serial line? The protocol reflects that context — it's simple, deterministic, and built for point-to-point polling in a pre-TCP world. It's also still running in an enormous percentage of industrial facilities because it works and replacing it costs money.

OPC UA was ratified in 2008. It was designed for a completely different problem: how do you exchange structured, self-describing data between PLCs, SCADA systems, and enterprise applications across heterogeneous networks, with security baked in? It's sophisticated, verbose, and carries more overhead than most field devices can handle.

MQTT was designed in 1999 for pipeline monitoring via satellite links with high latency and low bandwidth. It's a lightweight publish-subscribe protocol built for constrained environments where you can't afford to keep a persistent connection open. In modern IIoT, it gets used as the transport layer between edge gateways and cloud brokers.

These three protocols were not designed to interoperate. They were designed to solve different problems. When you have all three in the same facility — which is most industrial facilities built over more than a decade — you have a protocol fragmentation problem.

What Modbus Actually Does (and Doesn't Do)

Modbus RTU runs over RS-485 serial. Modbus TCP runs over Ethernet. Both use the same application layer protocol: a master polls a slave device at a specific address, requesting coil states, discrete inputs, holding registers, or input registers. The response comes back as raw bytes with no semantic context.

Register 40001 on one manufacturer's device might be the motor speed in RPM. On another manufacturer's device, 40001 might be a bitmask of fault codes. The protocol has no mechanism for describing what the data means. You need the device's register map documentation, and you need to know where you stored it.

Modbus also has no built-in security. No authentication, no encryption, no integrity checking. On a physically isolated OT network behind a proper firewall, that's acceptable. On any network with external connectivity, it's a liability. This is one of the reasons organizations are moving away from Modbus for new installations — not because it doesn't work, but because it creates compliance problems.

The practical consequence: polling 200 Modbus devices at 1-second intervals with a single master generates significant bus load on RS-485. At 19200 baud with 20-register reads, you can poll maybe 50 devices per second before you start getting timeout errors. For high-frequency vibration data, this is a fundamental limitation — you can't get 100Hz samples from 100 devices over a single Modbus RTU bus.

OPC UA: Power and Overhead

OPC UA solves the semantic problem that Modbus ignores. An OPC UA server exposes a structured address space — nodes with names, data types, engineering units, and hierarchical relationships. When you browse an OPC UA server, you see "MotorSpeed_RPM" as a Float with units "rpm" and a display name in multiple languages. The protocol carries its own schema.

OPC UA also has proper security: X.509 certificates, message signing, encryption, and user authentication. For the IT/OT boundary problem, this matters a great deal. An OPC UA endpoint can require certificate-based mutual authentication before it hands over any data.

The downside is resource consumption. An OPC UA stack requires meaningful CPU and RAM — typically 64MB RAM minimum, which eliminates most low-cost sensor nodes. The protocol is also stateful: clients subscribe to monitored items and maintain sessions. If the gateway restarts, subscriptions need to be re-established. Under poor network conditions, this creates reconnection storms that can destabilize the server.

OPC UA is the right choice for higher-level integration — getting data from a modern SCADA system, a CNC controller, or a DCS. It's not practical for a low-power temperature sensor that runs on two AA batteries.

MQTT: The Transport Layer That Became an IIoT Standard

MQTT's publish-subscribe model maps well to sensor networks. Sensors publish to topics; subscribers receive messages without polling. The broker handles fan-out. Quality-of-Service levels (0, 1, 2) let you trade delivery guarantees against overhead. QoS 1 — at-least-once delivery with acknowledgment — is what most sensor data pipelines use.

MQTT 5.0, published in 2019, added properties that help with sensor data specifically: message expiry intervals, user properties for metadata, and reason codes on disconnect. The earlier MQTT 3.1.1 is still more widely deployed in hardware that hasn't been updated.

MQTT's payload format is undefined. The broker routes bytes. Most IIoT deployments use JSON payloads or binary formats like MessagePack or CBOR. JSON is human-readable during debugging but 3-5x larger than a well-structured binary format for the same data. At 10,000 messages per second, that overhead matters.

MQTT Sparkplug B — a payload definition standard built on top of MQTT — attempts to solve the semantic problem by defining a specific protobuf-based schema for industrial data. It's gaining adoption in new OT deployments but is not yet widespread in existing infrastructure.

The Integration Problem in Practice

In a real facility, you might have: 80 Modbus RTU devices on three RS-485 loops, 40 OPC UA servers on CNC machines and one DCS, and a dozen MQTT-native sensors deployed in a recent upgrade. You also have BACnet on the building management system and some proprietary serial devices that predate any standard protocol.

Getting all of that data into a unified time-series store requires a translation layer for each protocol. The Modbus devices need a polling master that maps registers to tag names. The OPC UA servers need a client that subscribes to relevant nodes and translates the data model. The MQTT devices need a broker, a consumer, and payload parsers.

The engineering effort to build and maintain this from scratch is substantial. We estimate 3-6 months of integration engineering for a mid-size facility with 300+ devices, before any analytics work begins. That's the real cost of protocol fragmentation — not the protocols themselves, but the translation layer that every deployment has to build.

What We'd Tell Someone Starting a Deployment Today

Don't try to standardize on a single protocol. You're not going to replace your Modbus devices, and you shouldn't. Use a platform that handles protocol translation as a core function, not a custom integration project. Insist on seeing support for all five of: Modbus RTU/TCP, OPC UA, MQTT, BACnet, and at least one analog input standard (4-20mA or 0-10V).

For new sensor deployments, use MQTT-native hardware where you can — it's cheaper, simpler, and the broker-based architecture scales horizontally. For existing OT infrastructure, OPC UA is the right integration layer when the equipment supports it. For legacy PLCs and field instruments that aren't being replaced, Modbus isn't going anywhere.