How to Get Modbus Data to the Cloud: Edge Gateway, MQTT and Buffering

Getting Modbus data to the cloud is probably the most repeated connectivity project in industry: almost every plant has drives, meters, power analysers or controllers that speak Modbus, and almost none can exploit them from outside the electrical cabinet. The standard solution is an edge gateway that reads Modbus TCP or RTU on the local network, converts the registers into data with a name and a unit, publishes them over MQTT and retains them in a local buffer when the connection fails. In this guide we walk through that architecture step by step.

Why Modbus is still at the centre of the plant

Modbus was published in 1979 and remains the de facto interface of a huge share of industrial equipment: variable frequency drives, energy meters, power analysers, temperature probes, controllers of every range. It is simple, royalty-free and implemented by every manufacturer, which is why it is not going away: the practical question is not how to replace it, but how to get its data off the local bus and put it where the business can use it.

The protocol does have three limitations that condition the whole design: data consists of numbered registers with no name or unit, communication is polled (a master asks, a slave answers, nobody announces changes) and there is no encryption or authentication. None of the three is a problem inside the cabinet; all three are the moment the data wants to travel.

Modbus TCP vs Modbus RTU: what you have installed

Before designing anything it helps to know which of the two variants lives in the plant, because it changes the wiring but not the architecture:

• Modbus RTU travels over an RS-485 serial pair: a multi-drop wired bus, robust and cheap, common in meters and cabinet equipment. Each bus admits a single master, which means that if the SCADA already polls that bus, the gateway cannot ask over the same pair of wires at the same time: it connects to a second port on the device, integrates upstream of the SCADA or reads through a serial gateway.
• Modbus TCP encapsulates the same protocol over Ethernet and IP. It admits several simultaneous clients against the same device, so the gateway can poll without disturbing what already exists. It is the easy case and an increasingly common one.

In practice, almost every project is mixed: TCP for the recent equipment, RTU for the installed base. A gateway that speaks both variants avoids intermediate converters and unifies the configuration; the general criteria for selecting a capture system are in the pillar on the industrial data acquisition system.

Why Modbus cannot go straight to the cloud

The initial temptation is to open a port and query the device from outside. It is a bad idea because of the three limitations above, now amplified:

• Security. Modbus neither authenticates nor encrypts: exposing a Modbus device to the Internet grants read and write access to whoever finds the port. The OT network must stay closed; the data goes out, inbound connections do not come in.
• Semantics. In the cloud, "register 40012 = 4523" means nothing. The meaning (which signal it is, at what scale, in what unit) lives in the manufacturer's documentation, and someone has to apply it close to the device, once, before publishing.
• Reliability. Modbus polling needs a stable, low-latency connection to the device. A WAN with outages does not provide one: polling must happen on the local network and the leg to the cloud must tolerate interruptions without losing data.

All three objections point to the same solution: an intermediary on site that polls locally and publishes outwards.

The architecture: an edge gateway in between

The established pattern is an edge gateway: an industrial device on the plant network acting as a Modbus client downwards and a secure publisher upwards. Its responsibilities, in order:

• Poll each Modbus device at the configured interval, over TCP or RTU, grouping reads so as not to saturate slow buses.
• Map and scale: convert each register into a signal with a business name, data type, scaling factor and unit.
• Timestamp at the moment of capture, so the historian does not depend on the latency of the leg to the cloud.
• Publish upwards over an outbound, encrypted connection, normally MQTT.
• Retain in a persistent local buffer everything that could not yet be delivered.

With this design, the OT network exposes no inbound port: the gateway originates a single outbound encrypted connection. That security approach is developed in the guide to zero trust in industrial OT.

From Modbus registers to MQTT messages

For the leg to the cloud, the usual transport is MQTT: a lightweight publish-subscribe protocol, designed for imperfect networks, where the gateway publishes each signal on a topic and any authorised consumer subscribes without touching the plant. The contrast with the alternative is analysed in OPC UA vs MQTT; for the Modbus case, MQTT contributes exactly what is missing:

• From polling to events. The gateway polls locally, but upwards it can publish only changes of value: less traffic and more expressive data.
• Semantics in the message. The topic and payload carry name, unit and timestamp: the consumer does not need to know any manufacturer's register maps.
• Decoupling. Adding a new consumer (dashboard, historian, analytical model) is a subscription, not another integration against the device.
• Guaranteed delivery. The protocol's QoS levels and persistent sessions cover the micro-outages; the local buffer covers the long ones.

The piece that connects that publication with the systems above is MQTT integration, and the shared topic tree is the foundation of the unified namespace.

Buffering: what happens when the network drops

The difference between a serious installation and a demo shows the day the WAN goes down for hours. Without a buffer, that period disappears from the historian and with it any calculation that needs it: consumption per shift, downtime, traceability. With a persistent local buffer, the gateway keeps polling during the outage, writes each reading to its storage (which survives a restart) and resends everything in order once the connection recovers, with the original capture timestamp.

Two sizing decisions matter: how much autonomy is wanted (hours or days of retention, depending on signals and frequency) and how resending behaves so as not to saturate the link when the network returns. The technical detail is in the guide to industrial edge with buffering and QoS.

Step by step: from registers to dashboard

1. Inventory the sources. Which Modbus devices exist, which variant (TCP or RTU), slave address, and what register map documentation is available from each manufacturer.
2. Select the signals. Not every register is worth the effort: start with the signals with clear business value (consumption, states, counters, alarms) and expand later.
3. Define the mapping. For each signal: register, data type, scaling factor, unit and name within the asset hierarchy (plant, line, machine, signal). This dictionary is the most valuable deliverable of the project.
4. Deploy the gateway. On the plant network, with access to the devices over TCP or to the RS-485 bus, and with a single outbound encrypted connection to the broker or the platform.
5. Configure polling and publishing. Intervals per signal, publish-on-change where it makes sense and the local buffer enabled from day one.
6. Validate end to end. Compare readings against the device's display, provoke a controlled network outage and check that the historian is complete after reconnection.
7. Connect the consumption. With the data published and normalised, the dashboard, the historian or the analytical model subscribe; adding the next consumer no longer touches the plant.

How Captia Connect does it

Captia Connect implements exactly this architecture as the acquisition layer of Captia's data platform:

• Native Modbus TCP and Modbus RTU over RS-485, alongside OPC UA, MQTT, OpenWebNet, IEC 870-5-102, REST API, webhooks and CSV: mixed projects are solved with a single capture system.
• Normalisation at the source: the mapping from registers to signals with name, scale and unit is done at the edge, once.
• Local buffering and persistence without connectivity: data is retained on site during outages and resent once the connection is restored.
• Secure delivery through outbound encrypted connectivity and on-premise, hybrid or cloud deployment according to each company's policy.

Once the Modbus data is on the platform, Captia.ai turns it into operational value: web SCADA, dashboards, rules and alerts on the same signals. This capture layer as a whole is what in our catalogue we call edge ingestion, and its place in the complete architecture is on the industrial data platform hub.

Frequently asked questions about Modbus and cloud

If you have Modbus meters, drives or controllers whose data ends at the electrical cabinet, at Captia Connect we build this complete journey: local polling, normalisation, secure publication and loss-free buffering, integrated into the industrial data platform. The first step is an inventory of devices and signals with value.