Edge vs Cloud for Industrial Analytics

Walk any control room and you'll hear the question framed as a fight: edge or cloud. It's the wrong frame. A processing plant runs dozens of analytics workloads at once — a vibration threshold on a gearbox, a soft sensor estimating moisture in a dryer, a monthly yield model that compares twelve lines across two sites. These have nothing in common except that they all consume sensor data. Asking whether they belong "at the edge" or "in the cloud" as a single decision is like asking whether a plant should use motors or pumps.

So the useful version of the question is narrower. For a given workload, where does the computation belong — on a gateway next to the PLC, on a server in the plant room, or in a data centre two countries away? The answer depends on what the workload needs from latency, bandwidth, reliability, and the people who maintain it. Those are the axes worth arguing about. The hardware tier is downstream of them.

This piece works through those criteria one at a time, with a table you can map your own workloads onto, and ends with a plain rule for deciding. We instrument food, waste-to-energy, and metals plants for a living, and the pattern that holds across all of them is the same: the split is per-workload, and it's driven by physics and economics, not fashion.

First, the vocabulary

The terms have hardened enough that standards bodies now define them. In March 2018, NIST published a conceptual model that separates three layers below the cloud. NIST Special Publication 500-325 treats fog computing as a horizontal layer of physical or virtual resources sitting between smart end-devices and traditional cloud, built to support latency-sensitive applications. Edge, in that model, is the network layer closest to the devices themselves — local compute on or beside the sensor or meter. Mist is the thin slice running on the microcontrollers inside the devices. The point of the model isn't the taxonomy for its own sake; it's that these layers form a continuum, and work can be placed at whichever layer fits its constraints.

In plant terms, treat "edge" as everything from the gateway hardwired to your instrumentation up to the server rack in the plant room, and "cloud" as the off-site, multi-tenant compute you reach over a WAN. The grey middle — a beefy on-prem server doing site-wide analytics — behaves like the cloud for some criteria (it pools data across lines) and like the edge for others (it never leaves the building). Keep that nuance; it matters later.

Latency: control loops don't wait for a round trip

Latency is the criterion that ends arguments fastest, because for some workloads the budget is fixed by physics. A regulatory control loop closing on a valve, an interlock that trips a conveyor before a jam becomes a fire, a model that vetoes a setpoint — these can't tolerate a round trip to a remote data centre, and they can't tolerate the variance even when the average is fine. NIST's guidance for industrial control systems is blunt about this. NIST SP 800-82 Revision 2 (2015) contrasts ICS with ordinary IT on exactly this axis: control systems are time-critical and demand deterministic responses and high availability, where a corporate IT system can usually tolerate delay and the occasional retry. A WAN link gives you neither determinism nor guaranteed availability.

The fog and edge architectures were built around this gap. The OpenFog Reference Architecture, published in February 2017, opens by arguing that cloud-only designs can't meet the mission-critical demands of industrial data, where latency can run into the sub-millisecond range and the network has to be there every cycle. That document carried enough weight that the IEEE adopted it as the basis for a standard, IEEE 1934, in June 2018. The engineering takeaway is older than the standard, though: anything inside a closed loop stays local. Full stop.

But most analytics aren't inside a loop. A bearing-temperature trend that alarms when a rise sustains for ten minutes doesn't care whether the math runs on the gateway or in Frankfurt — a few seconds of network delay is invisible against a ten-minute window. And a yield comparison that runs overnight cares even less. So latency sorts workloads cleanly into three buckets: hard-real-time (edge, non-negotiable), operator-timescale (either, decide on other grounds), and batch (cloud is fine, often better). Most of the noise in edge-versus-cloud debates comes from people applying control-loop latency logic to workloads that live in the second or third bucket. That mistake has a price: you end up over-provisioning edge hardware and writing brittle local code for analytics that would have been cheaper, simpler, and more maintainable as a scheduled job somewhere central. Sort the bucket first, then argue about hardware.

Bandwidth and cost: data has gravity

The second criterion is the one that quietly drives most real decisions: moving data costs money, and high-rate industrial data is expensive to move in bulk. A single vibration sensor sampled fast enough to catch bearing defects produces a firehose — kilohertz sampling, continuous. Stream the raw waveform from every drive in a plant to the cloud and you'll pay for the link, pay for ingest, and pay for storage, mostly to warehouse data nobody ever queries.

This is why the lightweight telemetry protocols exist. MQTT became an OASIS Standard in October 2014 (version 3.1.1) precisely as a publish/subscribe transport for constrained settings where a small code footprint matters and bandwidth is at a premium. It's a good tool. But the cheapest byte to transmit is the one you never send. The edge's strongest economic argument isn't speed — it's reduction. Compute the bearing's envelope spectrum on the gateway, send the three numbers that summarise its health, and you've cut a kilohertz stream to a trickle. Send the raw waveform only when the summary crosses a line and you want a human to look.

That pattern — process locally, forward the distillate — is the core of edge analytics, and it inverts the cost equation. The cloud's per-gigabyte economics punish you for sending everything; the edge's job is to make sure you don't have to. The OpenFog architecture frames the same idea as bandwidth conservation: act on data close to its source, and push only what's worth moving up the hierarchy.

The flip side is just as real. Once data is distilled and landed, the cloud's economics run the other way. Pooling a year of distilled telemetry from twenty lines to train a model, or to benchmark one site against another, is something a plant server can't do cheaply and a data centre does well. Storage and elastic compute are genuinely cheaper at scale off-site. So cost doesn't favour one tier — it favours edge for raw, high-rate reduction and cloud for pooled, low-rate retention and heavy training. The mistake is paying cloud rates to move raw data the edge should have distilled first.

Reliability: the link will drop

Plant networks are not data-centre networks. The WAN uplink from a remote site — a quarry, a digester, a substation — drops, and it drops at the worst times. Any workload that has to keep working when the link is down belongs at the edge, full stop, because a cloud dependency becomes a single point of failure the moment connectivity is part of the control path.

This is the reliability argument the fog model leans on hardest. Industrial environments see intermittent connectivity as normal, not exceptional, and an architecture that assumes a clean pipe to the cloud will fail in exactly the conditions where you need it most. The practical rule we apply: the edge must degrade gracefully. A gateway should keep running its local logic, keep buffering telemetry, and reconcile with the cloud when the link returns — never freeze because a server is unreachable. (We've watched a perfectly good dashboard go blank during an outage while the plant itself ran fine on its PLCs; the analytics layer should be at least that resilient.)

Cloud platforms answer with their own reliability story, and it's a real one: redundant data centres, replication, and availability targets a single plant server can't match for the data that lives there. So reliability cuts both ways too. The link between you and the cloud is the weak point, not the cloud itself. Edge wins where continuity-through-disconnection is the requirement; cloud wins where durable, redundant retention of already-landed data is the requirement.

The criteria, side by side

Here's the comparison condensed. Read it by row — pick the criterion that dominates a given workload, and it usually points at a tier. Few workloads are dominated by a single row, which is why most plants end up with a split architecture rather than a winner.

Data model and interoperability: the part that decides whether any of this works

None of the placement logic matters if the data arrives without meaning. A gateway that ships a raw register value tagged 40021 has moved a number, not information — somebody downstream still has to know that register 40021 on that Modbus device is a discharge temperature in degrees Celsius. That's where the interoperability standards earn their place. OPC-UA (standardised as IEC 62541) carries not just values but a semantic information model: the data describes itself, so an analytics layer at any tier can consume it without a hand-maintained tag dictionary. That self-description is what lets you move a workload from edge to cloud later without rewriting the integration.

The architectural reference models make the same point at a higher level. The Industrial Internet Consortium's Industrial Internet Reference Architecture describes a three-tier structure — an edge tier gathering data through gateways, a platform tier managing and processing it, and an enterprise tier serving applications and decisions. The value of thinking in tiers is that it forces you to define the contract between them. Get the data model right at the edge tier and the question of where a workload runs becomes a deployment choice, not a rebuild. Get it wrong and every workload is welded to the tier it was first written for.

This is the strongest argument for not treating edge and cloud as opposing camps. A workload that's clearly cloud today — a yield model — may need to push a slimmed-down version down to the edge tomorrow for a faster local reaction. If the data speaks OPC-UA and moves over MQTT with a stable model, that migration is a configuration. If it speaks raw Modbus registers decoded by a script someone wrote in 2016, it's a project. The interoperability layer is what keeps placement reversible, and reversible placement is what lets you start simple and move work as you learn where it belongs.

Security: the boundary changes when the data moves

Every tier you add is a tier you have to defend, and edge-versus-cloud changes the shape of the attack surface rather than shrinking it. The OT security frame here is the zones-and-conduits model in ISA/IEC 62443: group systems with shared security requirements into zones, and treat every communication path between zones as a conduit with its own controls. A gateway that bridges the control network to a cloud uplink is a conduit by definition — arguably the most consequential one in the plant — and it has to be designed as such. The series keeps maturing; the product-security-lifecycle part, IEC 62443-4-1, was published in February 2018.

Edge and cloud pull in opposite directions on this. Keeping data and inference local shrinks the conduit to the outside world — less data crosses the plant boundary, so there's less to intercept and fewer places residency rules are violated. That's a genuine security argument for the edge, and for some plants (and some data-residency obligations) it's decisive. But the edge also multiplies endpoints: every gateway is a small computer that needs patching, hardening, and monitoring, and a fleet of them in dusty cabinets is harder to keep current than a handful of servers a cloud team patches on a schedule. NIST SP 800-82 spends much of its length on exactly this tension — adapting IT security controls to equipment whose first duty is uptime and safety, not confidentiality.

So the honest security read is a trade, not a win. Edge reduces what leaves the building but increases what you have to maintain in the field; cloud centralises patching and monitoring but widens the conduit and puts your data under someone else's roof. Pick the failure mode you can actually manage with the staff you have.

Maintenance and lifecycle: who keeps it running at 3 a.m.

The criterion engineers underweight at design time and curse at operating time is maintenance. A clever edge model on one gateway is easy. The same model on two hundred gateways across six sites, each needing firmware updates, certificate rotation, and the occasional rollback when a release misbehaves, is an operations problem that dwarfs the original analytics. The eight design pillars in the OpenFog architecture put reliability, availability, serviceability, and manageability on equal footing with the compute itself — because a node you can't update remotely is a node you'll eventually drive to in a van.

Cloud workloads invert the burden. You don't own the servers, you don't patch the OS, and scaling is somebody else's capacity planning. What you trade for that is dependence on a link and on a vendor's roadmap and pricing. Neither model is maintenance-free; they just move the work. Edge concentrates it in the field, where access is hard and the environment is hostile. Cloud concentrates it in the contract, where the risk is lock-in and recurring cost. A plant with a strong controls team and few sites may find the edge cheaper to run; a lean team spread across many sites often does better leaning on managed cloud for everything that can tolerate the link. And the honest figure to budget isn't the cost of building the edge node — it's the cost of operating a fleet of them over a ten-year asset life, in cabinets you'd rather not open on a Sunday.

Where this reasoning breaks

The clean per-criterion logic above has limits worth stating plainly, because they're where real designs go wrong.

First, the buckets bleed. A workload that's comfortably operator-timescale today can become latency-critical the moment someone wires its output back into control — the "advisory" model that quietly becomes an interlock is a common and dangerous drift. Re-examine placement whenever a workload's consequences change, not just when its math does.

Second, the edge is not free compute. A gateway sized for thresholds won't run a heavy model, and the temptation to push ever-larger workloads down to "save bandwidth" hits a wall of memory, thermal limits, and the same patching burden multiplied across the fleet. Edge reduction pays off for high-rate raw data; it doesn't pay off for everything.

Third, hybrid is the normal end state, not a failure to decide. Almost every plant we work with runs hard-real-time logic at the edge, distillation and short-horizon analytics on a plant server or gateway, and pooled training and reporting in the cloud. The architecture isn't a choice between two tiers — it's a pipeline across all of them, and the engineering is in the contracts between the stages, not in picking a side.

Which fits your plant

Stop asking "edge or cloud" as a plant-wide policy. Ask it per workload, and run each one down a short checklist. Is it inside a control loop, or could its output ever be wired into one? If yes, it's edge, and that's the end of the conversation. Does it consume high-rate raw data — vibration, fast process variables — that's expensive to ship whole? If yes, the reduction belongs at the edge even if the analysis lands in the cloud. Must it keep working when the WAN drops? Edge. Does it need to compare lines, sites, or years, or to train on pooled history? Cloud. Is the binding constraint that data must not leave the building? Edge, regardless of what the other rows say.

Most workloads answer "yes" to more than one row, which is exactly why the durable answer is a hybrid built on a clean data model. Put the determinism and the data-reduction at the edge, the pooling and the training in the cloud, and a self-describing model — OPC-UA over MQTT, or equivalent — in between so work can move when you learn more. That's the architecture we build toward when we deploy an edge telemetry and analytics platform: local compute that survives a dropped link, distillation that keeps the bandwidth bill sane, and a clean contract upward so the off-site layer sees meaning, not raw registers.

The plants that get this right don't win an argument about tiers. They retire the argument. Each workload sits where its latency, bandwidth, reliability, and maintenance constraints put it, the data model lets it move when those constraints change, and nobody has to defend a religion about edge or cloud — because the building runs either way.