Connecting PLC data to the cloud means reading tags from the controller over a protocol it already speaks, handing them to an edge gateway, and publishing them outbound over an encrypted connection, usually MQTT, to a broker or platform. Done right, no inbound firewall ports open and the PLC never touches the internet.
Every plant that wants live dashboards, remote visibility, or AI on its production data eventually faces the same plumbing question: the data is in the PLC, the software is in the cloud, and something has to bridge the two without creating a security hole or flooding the network. The good news is that the pattern is well established. This post walks the whole path, from tag to cloud, including the parts most write-ups skip: store-and-forward, report by exception, and what happens when the internet drops.
What does it take to connect PLC data to the cloud?
Four things: a way to read the PLC, an edge device to do the reading, a transport to the cloud, and a destination that gives the data somewhere useful to land. The read side is protocol work. Modern controllers often expose an OPC UA server or a native Ethernet protocol; older ones speak Modbus or a vendor serial protocol. The transport side is almost always MQTT today, because it was designed for exactly this job: small messages, unreliable networks, outbound-only connections.
What you should not do is wire cloud software directly to the controller. PLCs run scan cycles measured in milliseconds and were never built to serve dozens of remote clients. A misbehaving poller can load a controller's communication processor enough to matter. The edge gateway exists to protect the PLC as much as to move the data.
How do you get data out of the PLC in the first place?
You use whatever interface the controller already has, in this order of preference. If the PLC exposes an OPC UA server, use it: you get typed data, browsable structure, and built-in security. If it speaks an industrial Ethernet protocol, a gateway or driver can poll it directly; EtherNet/IP and PROFINET are the two dominant families, managed by ODVA and PROFIBUS & PROFINET International respectively. If it is older, Modbus RTU or TCP is often the lowest common denominator, and for controllers with no usable port at all, you move to the retrofit playbook covered in how to connect legacy machines.
Two practical notes from real floors. First, inventory your tags before you connect anything; most projects discover that tag names are inconsistent across lines and nobody remembers what half of them mean. Budget time for that cleanup, because the cloud inherits whatever naming mess you send it. Second, decide the sampling rates by question, not by habit. A machine state change matters the moment it happens. A temperature might only need a value every few seconds. Polling everything at maximum speed is the classic way to load both the controller and the network for no benefit.
What does an edge gateway do?
The gateway is the translator and the shock absorber. On the southbound side it speaks PLC protocols and polls locally, where latency is sub-millisecond and bandwidth is free. On the northbound side it converts to MQTT and publishes only what changed. In between, it does the three jobs that make the difference between a demo and a production system:
Buffering. When the internet connection drops, the gateway stores messages locally and forwards them when the link returns, so a two-hour outage becomes a gap-free backfill instead of lost history. Report by exception. Instead of shipping every poll result, it publishes on change, which typically cuts traffic by an order of magnitude or more on slow-moving signals. Normalization. It attaches units, names, and structure, ideally following the Sparkplug specification, so consuming systems receive data that describes itself. This is also where edge computing earns its keep: computing an OEE input or filtering a noisy signal at the gateway beats shipping raw data to the cloud and paying to process it there.
Why is MQTT the default transport to the cloud?
Because its design matches the problem. MQTT is a publish-subscribe protocol: the gateway publishes tag data to a broker, and any number of applications subscribe without adding load on the plant. The connection is initiated outbound from the plant, which means the firewall stays closed to inbound traffic. Messages are small, quality-of-service levels handle unreliable links, and the "last will" mechanism tells subscribers when a publisher disappears. It is a mature open standard: OASIS maintains it, and it is published as ISO/IEC 20922.
On top of plain MQTT, the Sparkplug specification adds the state management and payload structure that industrial systems need, including birth and death certificates so every subscriber knows exactly which devices are online and what their tags mean. Many plants organize the resulting topic space as a unified namespace, a live, hierarchical model of the whole operation that every system reads from and writes to. OPC UA also has its own publish-subscribe option, and the honest answer on choosing between them is covered in OPC UA for machine connectivity: most real architectures use OPC UA at the machine and MQTT to the cloud.
How do you keep the connection secure?
The rules are short and non-negotiable. All traffic leaves the plant outbound over TLS; nothing on the internet can initiate a connection inward to a controller. The PLC network stays segmented from the business network, with the gateway or a DMZ broker as the only crossing point, which is the spirit of the long-standing Purdue reference model even as architectures modernize. Credentials are per-device certificates or accounts, not one shared password, so a compromised device can be revoked without touching the rest. And write access is disabled by default: a cloud connection for visibility should be read-only until there is a specific, reviewed reason for anything to write back down.
None of this is exotic. It is the same posture your IT team already applies to everything else, applied consistently to OT. The projects that get in trouble are the ones that treat security as a later phase.
What are the steps to connect a PLC to the cloud?
- Inventory the controllers and tags. Model, firmware, protocol options, and which tags actually answer business questions. Start with one line, not the whole plant.
- Choose the read path per controller. OPC UA where available, native Ethernet drivers or Modbus where not, retrofit sensors where there is no port at all.
- Install the edge gateway. On the machine network, with store-and-forward enabled and report by exception configured per signal.
- Stand up the broker and namespace. Define the topic hierarchy once, with real names, before the first tag flows. Renaming later is painful.
- Connect outbound over TLS and verify the failure modes. Pull the network cable, watch the buffer fill, reconnect, and confirm the backfill lands with correct timestamps.
- Land the data somewhere with context. A historian for trends, and an operational layer that ties tags to orders, people, and paperwork so the data means something.
What do you do with the data once it lands?
This is where most projects stall, and it deserves more attention than the plumbing. Tags in the cloud are still just tags. A count of 4,812 becomes useful when it is attached to the work order it produced, the shift that ran it, and the quality checks that signed it off. That joining work is a data model question, not a networking question, and it is the difference between a cloud historian and an operational system; the reasoning is laid out in the AI-native MES data model.
This is also exactly where Harmony AI sits. Harmony AI connects your PLCs, sensors, and existing software into one operational layer alongside your digitized paperwork, so machine data lands with context instead of piling up in a bucket. It works with the equipment you have, mixed vintages included, with no rip-and-replace, and Harmony AI engineers deploy on your floor in person to wire it to your actual lines. You can see what that looked like on a real plant in the CLS case study, and estimate what your unconnected downtime costs with the ROI calculators.
What do the standards say?
- MQTT is an open OASIS standard, published internationally as ISO/IEC 20922 in 2016, and is the dominant transport for industrial data to the cloud.
- Eclipse Sparkplug, which defines MQTT topic structure and payloads for industrial data, was published as ISO/IEC 20237 in 2023.
- OPC UA is standardized as IEC 62541 by the OPC Foundation, with client-server access and a publish-subscribe extension in Part 14.
- EtherNet/IP, standardized by ODVA in 2000, and PROFINET, from PROFIBUS & PROFINET International, are the two dominant industrial Ethernet protocols you will poll on the plant side.
All four are open, vendor-neutral, and stable over decades. Build on them and the stack outlives any single supplier.