Edge computing answers a practical question in distributed oil and gas: when your sites are remote and your connectivity is a flaky cellular signal, how much of the work should happen out there versus in the cloud? The answer, increasingly, is "some at the edge, some in the cloud." This guide explains what edge computing means in a SCADA context and why it matters for remote operations.
Edge Computing (in SCADA) in plain English: Edge computing means processing data at or near where it is generated - on a device in the field - rather than sending everything to a central cloud or server first. In SCADA, edge devices collect, filter, buffer, and pre-process field data before it travels upstream.
Three practical reasons drive edge computing in the field. First, resilience: an edge device buffers data locally when the network drops and forwards it when the link returns, so nothing is lost on a lossy cellular or satellite link. Second, bandwidth and cost: pre-filtering and report-by-exception at the edge mean you transmit meaningful changes, not a firehose of raw readings, which saves cellular data and battery. Third, latency: time-critical local logic or alarms can run at the edge without a round trip to the cloud.
In short, the edge handles what must be immediate or must survive an outage; the cloud handles storage, analytics, and the operator experience.
An edge device might be a gateway at a wellsite that reads local PLCs and RTUs, applies logic and report-by-exception, and publishes to the cloud over MQTT Sparkplug B. It bridges legacy field protocols to modern cloud messaging. This is how cloud-native SCADA reaches sites reliably: a small, low-power edge agent does the field-side work, and the managed cloud does the rest. Merobix uses this pattern - edge buffering plus MQTT Sparkplug B - so remote sites stay reliable without a server room.
It is not either/or. Cloud SCADA gives you no infrastructure to run, elastic storage, analytics, and access from anywhere; the edge gives you resilience, low latency, and bandwidth efficiency at the far end. The strong architecture is hybrid: edge devices in the field feeding a cloud platform. Purely cloud with no edge struggles on bad links; purely edge with no cloud loses the analytics and remote-access benefits.
Edge computing in SCADA means processing field data on a device at or near the site - collecting, filtering, buffering, and pre-processing it - before sending it upstream, instead of shipping all raw data to the cloud first. It adds resilience, saves bandwidth, and cuts latency.
Edge processing happens in the field for resilience, low latency, and bandwidth efficiency; cloud SCADA provides elastic storage, analytics, and access from anywhere with no infrastructure to run. The best architecture is hybrid - edge devices feeding a cloud platform.
Because connectivity is unreliable. An edge device buffers data during outages and forwards it when the link returns, filters to report only meaningful changes to save cellular data and battery, and can run time-critical local alarms without a cloud round trip.
It reads local PLCs, RTUs, and sensors, applies logic and report-by-exception, buffers through outages, and publishes to the cloud - often over MQTT Sparkplug B - bridging legacy field protocols to a modern managed platform.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix pairs edge buffering with a managed cloud - remote sites stay reliable, and you run no infrastructure.