On August 20, 2026 in Automation, Industrial, Industrial Automation, IoT by Abhishek Jadhav

MQTT reduces point-to-point integration and supports scalable data exchange across brownfield industrial systems

Effective industrial connectivity is important for moving machine and process data between sensors, programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, and enterprise applications. Implementing the appropriate communication protocols directly supports condition monitoring, predictive maintenance, energy management, and production analysis.

However, connectivity does not scale easily in brownfield facilities. These plants have several generations of PLCs, sensors, fieldbuses, and proprietary systems that were designed for local control. As such, they struggle to share industrial data with enterprise and cloud applications.

The Message Queuing Telemetry Transport (MQTT) protocol addresses this by providing a lightweight publish/subscribe (pub/sub) messaging layer for industrial data. The protocol allows the edge gateway to publish data once to an MQTT broker and then distribute it to multiple authorized systems.

In our last part of this blog series on industrial networking, we explored the ways Single Pair Ethernet (SPE) frees automation systems of several constraints associated with traditional Ethernet. Here, we dig into why conventional industrial connectivity becomes difficult to scale, how MQTT reduces point-to-point integration through a broker-based pub/sub architecture, and how MQTT 5.0 and Sparkplug support manageable industrial deployments.

Why Industrial Connectivity Struggles at Scale

While industrial connectivity operates effectively at a small scale, it becomes harder to manage as more devices, protocols, applications, and sites are added.

Legacy Systems and Multiple Protocols

The wide range of fieldbus and industrial protocols makes it difficult and time-consuming to integrate data from sensors, PLCs, and remote devices. It also makes standardization harder.

Industrial protocols, such as Modbus Transmission Control Protocol (TCP), Ethernet Internet Protocol (EtherNet/IP), and Open Platform Communications Data Access (OPC DA), rely heavily on a synchronous, request-response, client-server model. In this model, an external client (e.g., a SCADA system) must continuously request data from the server (e.g., the PLC) at a fixed interval (e.g., every 500 milliseconds), even if the process value has not changed.

Continuous polling has several problems, including high network overhead and processor saturation. Managing multiple connection requests and executing continuous read/write cycles consumes central processing unit (CPU) resources. This can degrade the performance of the controller’s real-time safety and execution loops.

OPC Unified Architecture (UA) addressed many of these issues by introducing platform independence, robust security profiles, and an object-oriented, browsable address space. However, OPC UA client-server architectures still require a direct connection between every client and the server.

Point-to-Point Integration Complexity

Point-to-point integration becomes harder to manage as more devices and applications are added to the network. In a direct point-to-point architecture, connecting 50 PLCs to five enterprise applications could require as many as 250 separate application-to-PLC connections. Adding to the complexity is that all applications will have to maintain their own link to every PLC.

Even a change to the tag name, register address, or network configuration would require updates in every connected application. If the engineering team does not update one connection, it can disrupt the data flow and make the overall architecture difficult to maintain.

Scaling from PoC to Production

At the proof-of-concept (PoC) stage, custom Python scripts, local CSV file exports, or SQL database connections work for a single-connection pilot. But production-grade deployment introduces operational requirements that these custom, ad hoc integrations cannot fulfill.

In the case of remote sites, the network connectivity depends on high-latency, low-bandwidth, or metered cellular and satellite networks. The continuous, high-frequency polling over these connections can be cost-inefficient and unreliable.

In addition, operational governance is crucial. When the systems are scaled to thousands of data points, they require standard naming rules, consistent data schemas, and centralized access controls. Without these, the broker can accumulate fragmented and unorganized data.

Designing Industrial Data Connectivity for Scalability

To address the limitations of traditional industrial communications, operational technology (OT) architects are adopting MQTT, which typically runs over TCP/IP or another transport that provides ordered, lossless, and bidirectional communication.

Unlike direct client-server integrations, MQTT uses a broker to separate data producers from data consumers. Publishers send messages to named topics on the broker, while subscribers receive messages from the topics they need. In this approach, the publisher does not need to know which applications are consuming the data, and subscribers do not need direct connections to the original device.

MQTT does not necessarily eliminate polling at the machine level. In a brownfield facility, an edge gateway may still poll a PLC through Modbus TCP, OPC DA, or another legacy protocol. The difference is that the gateway collects the value once and publishes it to the MQTT broker, which then distributes the message to every authorized subscriber. This reduces the number of direct PLC connections and prevents multiple applications from acquiring the same data independently.

For example, an edge gateway can read vibration data from a motor drive over Modbus TCP and publish it to an MQTT topic. The same data can then be used by a SCADA system, a predictive maintenance tool, an energy management application, and a cloud data lake.

This solution allows the gateway to publish once and have four consumers receive the data without any of them ever connecting to the drive or the Modbus network. Adding a fifth consumer requires no change to the gateway or the drive; the consumer only has to subscribe to the relevant MQTT topic on the broker.

MQTT Standards for Industrial Deployments

It is important to understand the different MQTT standards for successfully implementing networking technology in complex industrial environments.

MQTT 3.1.1

MQTT 3.1.1 has been widely adopted across Internet of Things (IoT) and telemetry systems because of its simplicity, small code footprint, and low packet overhead. It supports a minimum two-byte fixed header, three quality-of-service (QoS) levels, persistent sessions, and retained messages.

However, MQTT 3.1.1 provides limited operational context for large industrial deployments. It does not include standardized packet-level fields for adding custom metadata, although applications can still place metadata inside the message payload. Its

Additionally, error reporting with MQTT 3.1.1 is basic. CONNACK packets can identify a small number of connection failures, such as invalid credentials or insufficient authorization, while a rejected subscription is reported only as a general failure. This limited feedback makes it harder to identify and troubleshoot problems across remote systems.

MQTT 5.0

MQTT 5.0 extends the broker-based pub/sub model of MQTT 3.1.1, with features that make large deployments easier to operate. These additions improve error reporting, connection management, metadata handling, and message distribution across multiple applications.

One of the key changes is the use of reason codes. With MQTT 5.0, packets such as CONNACK, PUBACK, SUBACK, and DISCONNECT can include a standardized code that explains if an operation succeeded or why it failed. This gives clients and operators information when troubleshooting connections.

The standard also allows the broker to send a DISCONNECT packet before closing a connection. The packet can include a machine-readable reason code and, optionally, a human-readable reason string. For example, a broker approaching its connection limit could tell a client that the server is unavailable, that the client has exceeded a quota, or that the client should reconnect to another server.

Sparkplug

Even with MQTT’s efficient pub/sub transport, it does not define how industrial topics should be organized, how process values should be encoded, or how applications should determine whether a device and its data remain valid.

Different vendors may use their own topic structures and payload formats, making it difficult for SCADA and analytics applications to interpret the data consistently. Sparkplug addresses this problem by adding a common industrial topic structure, payload format, and device-state model on top of MQTT.

Sparkplug is an open specification hosted by the Eclipse Foundation that defines an MQTT topic namespace, a payload representation, and a session-state management model for industrial applications. The current Sparkplug 3.0 establishes rules for how MQTT clients representing industrial edge nodes, devices, and host applications should organize and exchange information consistently.

Conclusion

As industrial organizations connect more assets, applications, and remote sites, traditional point-to-point integrations become increasingly difficult to maintain. MQTT addresses this challenge with a lightweight publish/subscribe architecture that decouples data producers from data consumers, reducing connection complexity and improving scalability.

By enabling edge gateways to collect data once and distribute it through a broker, MQTT helps organizations extend the value of existing brownfield equipment without overloading controllers or creating hundreds of direct integrations. MQTT 5.0 further improves large-scale deployments with enhanced diagnostics and connection management, while Sparkplug adds the standardized topic structure, payload format, and device-state awareness needed for reliable industrial interoperability.

Together, these technologies provide a practical foundation for moving operational data from the plant floor to SCADA, analytics, cloud, and enterprise systems, helping manufacturers build more connected, manageable, and data-driven operations.