Cloud analytics can spot an abnormal reading only after the reading has reached the cloud. When the backhaul is down, that means a developing fault can go unnoticed for as long as the outage lasts, precisely when a remote site is least attended. On-device anomaly detection moves the first line of detection onto the gateway itself, so a lightweight model or statistical check running locally flags something wrong the moment it appears, regardless of the link. This guide explains what on-device detection is, the kinds of local checks that fit on constrained hardware, and why catching a fault at the edge is valuable when the connection cannot be relied upon.
On-Device Anomaly Detection in one line: On-device anomaly detection is the practice of running lightweight statistical checks or compact models on the gateway itself to flag abnormal readings locally, rather than relying solely on cloud analytics. Because the detection happens at the edge, a developing fault is caught immediately and even during a communication outage, so the site can react or record the event without waiting for a round trip to the cloud.
In a cloud-centric architecture, the intelligence that recognizes an abnormal reading lives centrally. Data flows up from the field, models in the cloud examine it, and if something looks wrong an alert flows back. That works well when the link is healthy, but it has a structural blind spot: nothing can be detected in the cloud that has not reached the cloud. During a backhaul outage the data is stuck at the edge, and any anomaly it contains is invisible centrally until connectivity returns and the backlog uploads, by which time the abnormal condition may have progressed for a long time.
On-device anomaly detection closes that gap by running detection where the data is born. The gateway examines each reading, or short windows of readings, against a local notion of normal, and raises a flag as soon as something falls outside it. Detection no longer depends on the round trip to the cloud, so an abnormal pressure, a stalled reading, or a sudden spike is recognized at the site in near real time, independent of whether the wide-area link happens to be up at that moment.
This does not replace cloud analytics; it complements it. The cloud remains the place for heavy models, cross-site comparison, and long historical analysis that a small gateway cannot perform. The edge handles the fast, local, always-available first check. The two form a layered scheme in which the edge catches the obvious and the urgent immediately, while the cloud provides the deeper, fleet-wide intelligence when the data arrives, and the edge's early flag travels up with the data to be reconciled centrally.
The models that run on a gateway are necessarily modest, because the hardware is constrained in compute, memory, and often power. Fortunately, a great deal of useful anomaly detection needs very little. The simplest and most robust checks are statistical: comparing a reading to a rolling mean and standard deviation and flagging values that fall too many deviations away, watching the rate of change and flagging a jump that is too fast to be physical, or detecting a reading that has gone flat or frozen when it should be varying. These cost almost nothing to compute and catch a wide range of real faults.
Slightly more elaborate checks add context. A gateway can learn a typical operating envelope for a variable, perhaps how a pressure normally behaves at a given time of day or under a given operating mode, and flag departures from that envelope rather than from a single fixed threshold. It can correlate two related signals and notice when their usual relationship breaks, such as a flow that should track a pump's state but no longer does. These remain lightweight but adapt to the process rather than relying on static limits.
At the upper end, compact machine-learning models small enough to run on embedded hardware, sometimes called tiny machine learning, can be deployed to the gateway to score readings against a learned model of normal behaviour. These can capture patterns too subtle for simple thresholds, but they bring the practical burdens of any deployed model: they must be trained, packaged to fit the device, and eventually updated as conditions change. Many field deployments favour the simpler statistical checks precisely because they are transparent, cheap, and need little maintenance, reserving heavier models for cases that genuinely require them.
The strongest argument for edge detection is availability. Remote sites lose connectivity, and outages have an unhappy way of coinciding with the very disturbances that also stress equipment, such as storms and power problems. If a fault develops during an outage and detection lives only in the cloud, no one learns of it until the link returns, and the site meanwhile has no idea anything is wrong. On-device detection means the site itself recognizes the anomaly the instant it occurs, and can act on it or at least record it prominently, no matter the state of the link.
That local recognition enables local response. A gateway that detects an anomaly on its own can take immediate action defined for the site, such as recording the event with full fidelity, activating a local indication, or, where the architecture allows, participating in a local protective response, all without waiting for a decision from the cloud. When the link is restored, the flag and the surrounding data upload together, so the central system learns not only what the readings were but that the edge already judged them abnormal and when, which speeds up the operator's assessment.
For a cloud SCADA platform such as Merobix overseeing many remote sites, on-device anomaly detection strengthens the field's resilience without replacing the platform's central role. The edge provides an always-on first line that keeps watching even when a site is cut off, and the cloud provides the broader analysis, cross-site perspective, and history once the data arrives. An anomaly detected at the edge during an outage becomes a flagged event the platform can surface as soon as the site reconnects, so a fault that began in the dark does not stay hidden until someone happens to look at the trend.
Cloud analytics examines data after it has reached the cloud, using powerful models and cross-site history, but it cannot see anything the link has not delivered. On-device detection runs on the gateway itself, so it flags anomalies immediately and even during outages, using lightweight checks suited to constrained hardware. The two are complementary: the edge provides fast, always-available first-line detection and the cloud provides deeper, fleet-wide analysis.
Not necessarily. Many effective edge checks are purely statistical, such as flagging readings that fall too many standard deviations from a rolling mean, that change faster than is physically plausible, or that have frozen when they should be varying. These are cheap, transparent, and need little maintenance. Compact machine-learning models can catch subtler patterns, but they add training and update burdens, so simpler statistical checks are often preferred in the field.
The flag raised at the edge is stored with the surrounding readings and uploaded when connectivity is restored, along with the rest of the buffered backlog. The central platform then sees not only the raw data but that the gateway already judged it abnormal and at what time. This lets the cloud reconcile the local judgment with its own analysis and surface the event to operators as soon as the site reconnects.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.