If alarm conditions are evaluated only in the cloud, then an alarm can only be raised for data that has reached the cloud. A trip that occurs while the link is down would go undetected until connectivity returns, which is the worst possible time to be blind to a trip. Edge-triggered alarming evaluates the alarm rules on the gateway itself, so a condition is detected and latched at the site the instant it happens, independent of the link, and reconciled with the central system once the connection is back. This guide explains what edge-triggered alarming is, how latching preserves an alarm through an outage, and why local evaluation is essential for reliable alarming at remote sites.
Edge-Triggered Alarming in one line: Edge-triggered alarming is the evaluation of alarm conditions on the gateway itself rather than in the cloud, so a trip is detected and latched immediately at the site and survives a loss of connectivity. When the link returns, the locally raised alarms are reconciled with the central system, giving operators an accurate alarm history even for events that occurred while the site was offline.
An alarm is fundamentally a rule applied to a measurement: if a pressure exceeds a limit, if a level falls below a float, if a temperature climbs too fast, raise an alarm. The question is where that rule runs. In a cloud-only design, the raw readings are sent up and the alarm logic lives centrally, so an alarm is only raised once the data has arrived and the cloud has evaluated it. That is fine while the link is healthy, but it ties the entire alarming function to the availability of the wide-area connection.
Edge-triggered alarming moves the rule down to the gateway, where the measurements are actually taken. The gateway holds the alarm definitions and evaluates each reading against them as it is acquired, raising the alarm locally the moment a condition is met. Because this happens at the site, on data that does not need to travel anywhere first, the detection is both immediate and completely independent of the link. A trip is recognized at the source, in the same place and at the same time as the reading that caused it.
This does not mean the cloud is uninvolved. The central system typically still holds the master alarm configuration, presents the alarm state to operators, manages acknowledgement, and keeps the authoritative history. What changes is that the detection and initial latching happen at the edge, and the cloud becomes the place where locally raised alarms are collected, displayed, and reconciled. The edge and cloud share the alarming responsibility, with the edge owning the time-critical detection and the cloud owning the presentation and management.
Detecting an alarm at the edge is only half the value; the alarm also has to survive if the link is down when it trips. This is where latching matters. A latched alarm, once raised, stays asserted until it is explicitly acknowledged and reset, rather than clearing itself the moment the condition passes. On a gateway, latching means that a trip which occurs and then clears during an outage is not forgotten: the gateway holds a record that the condition was reached, along with when it happened, so the event is not lost just because it was brief and no one was connected to see it.
Consider a pressure that momentarily exceeds its limit while the site is offline and then settles back. Without edge evaluation and latching, that excursion leaves no trace centrally, because the peak may never have been sampled to the cloud and the condition was over before anyone could see it. With edge-triggered, latched alarming, the gateway detected the excursion as it happened, latched the alarm, and stamped it with the time, so a complete record of the trip exists locally even though the condition itself has passed and the link was down throughout.
Latching at the edge also preserves the sequence and timing of events, which is often what an operator most needs after the fact. When several alarms occur during an outage, the gateway can record the order and the timestamps as they truly happened at the site, rather than in the jumbled order in which a backlog might later upload. That local sequence of events is far more useful for understanding what actually unfolded than a set of alarms that all appear to arrive at once the moment the link comes back.
For unattended remote sites, alarming that depends on the link is alarming that fails exactly when it is needed. Connectivity outages and process upsets are not independent; the same storm or power event that knocks out the modem may also disturb the equipment. A cloud-only alarm scheme is silent during that window, so the operation could suffer a genuine trip and have no alarm and no record of it until the link recovers. Edge-triggered alarming removes that dependency, ensuring the alarm is detected and latched regardless of what the link is doing.
When the connection returns, reconciliation stitches the two views together. The gateway uploads the alarms it raised and latched during the outage, with their original timestamps, and the central system merges them into the master alarm history and state. Operators then see not only the alarms that are active now but the ones that tripped while the site was dark, in the order they occurred, and can acknowledge them properly. The outage becomes a period the alarm record covers rather than a hole in it.
This is why a cloud SCADA platform such as Merobix benefits from gateways that evaluate and latch alarms locally. The platform provides the central alarm management, operator interface, and authoritative history, while the edge guarantees that no trip goes undetected simply because the link was down when it happened. The division of labour gives operators alarms they can rely on across a fleet of remote sites, with the immediacy and independence of local detection combined with the visibility and management of a central system, and a complete history that survives even total loss of connectivity.
An alarm deadband is a signal-filtering technique that prevents an alarm from chattering around its limit by requiring the value to move back by a margin before the alarm clears. Edge-triggered alarming is about where the alarm is evaluated, namely on the gateway rather than the cloud, so trips are detected and latched locally and survive connectivity loss. One concerns how an alarm behaves near its threshold; the other concerns where the evaluation runs.
A latched alarm stays asserted once raised until it is explicitly acknowledged and reset, rather than clearing when the condition passes. At the edge, latching means a gateway holds a record that a condition was reached, and when, even if the excursion was brief and the link was down. This ensures a momentary trip during an outage is not lost, because the gateway captured and held the event with its timestamp.
The alarms the gateway raised and latched during the outage are uploaded with their original timestamps and reconciled into the central system's alarm history and state. Operators then see the alarms that tripped while the site was offline, in the order they occurred, and can acknowledge them properly. This turns a connectivity gap into a period the alarm record fully covers rather than a blind spot.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.