MQTT Over Modbus: Why Modern IIoT Chose a Different Protocol

Modbus TCP remains the workhorse of the factory floor. It moves data reliably between PLCs and HMIs over short distances on controlled networks. But when that same data must travel across cellular links, through firewalls, or into cloud analytics platforms, the protocol shows its age.

MQTT was designed from first principles for exactly these conditions. The architectural differences between the two protocols explain why modern Industrial Internet of Things (IIoT) stacks have converged on MQTT for anything beyond the local subnet.

The Request-Response Constraint

Modbus operates on a strict master-slave model. The client, typically a SCADA system or an edge computer, initiates every data exchange. The server, the PLC, only responds when asked. This model functions perfectly when the client knows exactly what data it needs and when it needs it, and when the connection between the two endpoints is stable.

The limitations become apparent when the system scales or when the network becomes unreliable.

Polling Overhead

Each Modbus read retrieves a fixed set of registers. To monitor one hundred data points scattered across a PLC memory map, the client must issue one hundred separate read requests, or carefully craft contiguous block reads that may include unnecessary data. Each request consumes bandwidth and, more importantly, processing time on the PLC. As the number of data consumers grows, the polling load multiplies linearly.

The Firewall Problem

Modbus TCP requires the client to initiate a connection inbound to the PLC. In a typical manufacturing network, this means opening a port on the industrial firewall and exposing the PLC to the enterprise network. Security teams rightly resist this configuration. The alternative is placing a polling device on the plant floor that pushes data upward, but that device must still poll the PLC using Modbus.

Disconnected Operation

If the Modbus client loses connectivity, data is lost for the duration of the outage. There is no inherent buffering or store-and-forward capability. When the connection is restored, the client resumes polling and the gap in data remains.

The Publish-Subscribe Alternative

MQTT inverts the communication model entirely. Devices publish messages to a central broker, and other devices subscribe to topics of interest. The broker handles distribution, decoupling the producer of data from the consumer of data.

Efficient Data Flow

A PLC gateway or edge device can publish a single message containing multiple data points to a topic such as `plant/line1/cell3/status`. Any number of subscribers, from a local dashboard to a cloud historian to a mobile maintenance application, receive that same message without placing additional load on the PLC. The data is pushed once, consumed many times.

Report by Exception

Modbus polling repeatedly asks "Has this value changed?" MQTT allows a device to publish only when a value changes significantly, a pattern known as Report by Exception. A temperature transmitter configured to publish on a deadband of 0.5 degrees Celsius sends data only when the temperature moves outside that window. This reduces bandwidth consumption by orders of magnitude and allows cellular-connected devices to operate economically.

Resilience Through the Broker

An MQTT broker can be configured to queue messages for disconnected subscribers. If a cloud connection drops for ten minutes, the broker retains the messages and delivers them when the subscriber returns. The data gap is filled retroactively. For critical applications, MQTT offers Quality of Service (QoS) levels that guarantee delivery at least once or exactly once.

Outbound-Only Connections

The most significant operational difference concerns network security. An MQTT client behind a firewall initiates an outbound TCP connection to the broker. No inbound ports need to be opened. The industrial network remains isolated from unsolicited external traffic while still enabling bidirectional data flow through the established socket.

Coexistence, Not Replacement

MQTT is not a replacement for Modbus on the factory floor. Modbus will continue to run inside machines and between controllers for decades. The two protocols occupy different layers of the automation pyramid.

The modern pattern places a protocol gateway at the edge. This device speaks Modbus TCP to the PLC on one interface and publishes MQTT messages to a broker on another. The PLC continues operating as designed, unaware that its data is now flowing into a much larger ecosystem.

Understanding the Design Tradeoffs

Modbus is deterministic. When a master sends a request, it receives a response within a predictable timeframe defined by the scan cycle of the PLC. This predictability is essential for closed-loop control.

MQTT is asynchronous. A message may arrive in ten milliseconds or ten seconds depending on network conditions. This latency is unacceptable for motion control but entirely appropriate for monitoring overall equipment effectiveness, tracking production counts, or sending maintenance alerts.

The choice between the two protocols is not a technical preference. It is an acknowledgment of the physical and operational constraints of the communication channel. A cable inside a control cabinet behaves differently than a satellite link to a remote pumping station. The protocols reflect that reality.

The migration toward MQTT in IIoT does not signal the obsolescence of Modbus. It signals the recognition that different parts of the industrial data journey require different tools. Understanding where each protocol belongs is the foundation of a coherent automation architecture.