Sending every raw reading from a remote site up to the cloud, then waiting for an answer to come back, is often slower and more expensive than it needs to be. Edge analytics moves the analysis itself, whether that is a simple threshold, an aggregation, or a machine-learning inference, onto the gateway at the site so decisions can be made where the data is born. This guide explains what runs at the edge, why it cuts latency and cellular bandwidth, and how edge and cloud analytics work together rather than competing.
Edge Analytics in one line: Edge analytics is the practice of running analytical work, such as threshold checks, data aggregation, or machine-learning inference, directly on an edge gateway at the site rather than sending all raw data to a central system first. By computing results close to the source, it cuts the latency of round-tripping to the cloud and reduces how much data must travel over expensive or limited links. It complements cloud analytics rather than replacing it, handling fast local decisions while the cloud handles heavier, fleet-wide work.
The defining idea of edge analytics is location. Instead of shipping every raw sample upstream and analysing it in a central platform, the analytics runs on the gateway or edge device sitting at the site, next to the sensors and controllers. That analytics can range from the trivial to the sophisticated. At the simple end it might be a threshold rule that raises an alarm the moment a pressure exceeds a limit. In the middle it might aggregate a stream of one-second readings into a one-minute average or a min, max, and mean. At the advanced end it might run a trained machine-learning model that scores incoming vibration data for signs of a developing fault.
It is worth being precise about what edge analytics is and is not. Edge computing, in general, is about having compute capability at the edge of the network at all. Edge analytics is specifically the analytical workload that runs on that capability, the thresholds, aggregations, and inferences that turn raw signals into results. An edge gateway is the hardware and connectivity; edge analytics is what you make it do with the data before that data goes anywhere else. The distinction matters because you can have edge compute without doing much analysis on it, and the value shows up only when you actually process at the source.
Running analytics locally also means the site can keep making decisions even when its link to the cloud is down. A threshold that closes a valve or a local inference that trips an alarm does not need a connection to work, because the logic lives on the gateway. This local autonomy is a quiet but important benefit: the site stays smart during an outage instead of going blind until connectivity returns.
The first payoff of edge analytics is speed. If a decision requires a round trip to the cloud, its response time is limited by the network, and over a cellular or satellite link that delay can be significant. By evaluating the rule or model on the gateway, the site reacts in the time it takes to run the computation locally, not the time it takes to reach a distant data centre and hear back. For anything where a fast local response matters, moving the analysis to the edge removes the network from the critical path.
The second payoff is bandwidth, and for remote industrial sites this is often the bigger one. Many gateways connect over metered cellular or satellite links where every megabyte has a cost, and sending high-frequency raw data continuously is wasteful. Edge analytics lets the gateway do the filtering and summarising locally, then send only what matters: an aggregated value instead of a thousand raw samples, an alert instead of the whole stream that triggered it, or a model's verdict instead of the sensor data it scored. The volume travelling over the expensive link drops dramatically while the useful information is preserved.
There is also a resilience angle to the bandwidth story. Because the edge is already reducing and prioritising data, a site can keep the most important information flowing even when the link is degraded, sending compact results while deferring bulk detail. This graceful behaviour under poor connectivity is exactly what remote operations need, and it comes naturally once the analysis has been pushed to the edge instead of being centralised.
Edge analytics is not a rival to cloud analytics; the two divide the labour. The edge is the right place for fast, local, per-site decisions and for reducing data volume: threshold alarms, aggregation, and lightweight inference. The cloud is the right place for anything that needs scale, history, or a fleet-wide view: training models across many assets, comparing sites against each other, running heavy analytics over years of history, and coordinating decisions that span locations. A well-designed system uses each for what it does best.
A common and effective pattern is to train in the cloud and run at the edge. The cloud gathers data from a whole fleet and trains a model, then that model is pushed down to the gateways to run locally on live data. The edge does the low-latency scoring; the cloud periodically retrains as new data accumulates and redistributes the updated model. This split keeps inference fast and bandwidth low while still letting the model learn from the entire fleet, and it is one of the clearest illustrations of edge and cloud analytics complementing each other.
A cloud SCADA platform such as Merobix sits naturally at the centre of this arrangement. Gateways in the field run edge analytics to filter, aggregate, and locally decide, then forward compact results into the cloud historian and dashboards where the fleet-wide analysis and long-term history live. For an operator with many remote sites on limited links, that division is what makes the whole system both responsive and affordable: the edge keeps each site quick and thrifty, and the cloud keeps the bigger picture in view.
Edge computing is the general presence of compute capability at the edge of the network, near the sensors and controllers. Edge analytics is specifically the analytical workload that runs on that capability, such as threshold checks, data aggregation, and machine-learning inference. In other words, edge computing is the platform, and edge analytics is what you actually do with it to turn raw data into results at the source.
Instead of streaming every raw reading upstream, the gateway processes data locally and sends only the useful output: an aggregated value rather than a thousand samples, an alert rather than the whole stream, or a model's verdict rather than the sensor data behind it. This dramatically reduces the volume travelling over metered cellular or satellite links while preserving the information that matters, which is why it is so valuable for remote sites.
No, the two are complementary. The edge is best for fast local decisions and reducing data volume, while the cloud is best for heavy analysis, long-term history, and fleet-wide views such as training models across many assets. A common pattern is to train a model in the cloud and run it at the edge, so each layer does what it does best.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.