Configuring an alarm is the act of telling the SCADA system what counts as abnormal for a value and how loudly to say so when it happens. It sounds like it should be a single setpoint, but a well-built analog alarm is a small cluster of settings that together decide whether an operator gets a clear, timely, trustworthy signal or a stream of nuisance chatter they learn to ignore. The stakes are higher than they look, because an alarm that cries wolf is worse than no alarm at all, it trains people to dismiss the very signals that are supposed to protect the process. This guide walks through configuring one analog alarm from start to finish: assigning it to a tag, setting the high and low limits including the more urgent second thresholds, choosing a priority, adding the deadband and delay that stop it from chattering, and writing a message an operator can act on at three in the morning.
How to configure an alarm in SCADA in one line: To configure an alarm in SCADA, assign it to the tag you want to monitor, enter the limits that define abnormal, a HI and a LO for a warning band and a more urgent HI-HI and LO-LO for the danger band, and give each limit a priority that reflects how serious it is. Add a deadband so the alarm does not flicker on and off as the value hovers at the limit, and an on-delay so a brief spike does not raise it, then write a short, specific message that tells the operator what is wrong and what to do. Enable the alarm and test it by driving the value past the limit to confirm it behaves as intended.
An alarm has to be attached to a tag, because the alarm's whole job is to watch that tag's value and react when it leaves the normal range. So the first step is to select the tag the alarm belongs to, an analog value such as a pressure, level, temperature, or flow. This is also where you confirm the tag itself is sound, reading a good-quality live value in sensible units, because an alarm built on a tag that is mis-scaled or reading bad quality will fire on nonsense. The alarm can only be as trustworthy as the point it watches, so it is worth glancing at the live value before you go any further.
The core of the configuration is the set of limits, the values at which the alarm activates. A typical analog point gets four limits arranged as two bands. The HI and LO limits mark the edge of the normal operating range, the point where an operator should start paying attention but the situation is not yet dangerous. The HI-HI and LO-LO limits sit further out and mark genuinely serious conditions, the point where action is required now to avoid a trip or damage. Configuring both bands gives the operator graduated warning: a HI alarm says keep an eye on this, while a HI-HI alarm on the same tag says act immediately. Not every point needs all four; a simple value might use only a single HI, while a critical one uses the full set.
Choosing the actual limit numbers is an engineering judgment, not a formality. The HI should sit above the normal operating band by enough that ordinary process variation does not trip it, but below the point where anything is actually wrong, so it warns without crying wolf. The HI-HI should sit at the real threshold of harm, above which the process is genuinely in trouble. Setting a HI too close to the normal range floods operators with warnings for conditions that are fine, while setting it too high means the warning arrives too late to matter. Good limits come from knowing the process, and they are worth revisiting after the alarm has run for a while and its real behavior is visible.
Priority is how the alarm tells an operator how much it matters, and it is what lets a well-run system stay calm during an upset. When many alarms are active at once, priority is what sorts the one that could hurt someone from the one that is merely inconvenient, so a HI-HI on a critical vessel gets a high priority while a HI on a comfortable buffer tank gets a low one. Priority typically also drives how the alarm looks and sounds, its color, whether it makes noise, and where it sits in the alarm list. Assigning priority thoughtfully is central to a usable alarm system, because if everything is high priority then nothing is, and operators lose the ability to triage.
Deadband is the setting that stops an alarm from flickering when a value sits right at its limit. Without it, a pressure hovering exactly at the HI limit crosses back and forth by tiny amounts and generates a storm of alarm-on and alarm-off events, each one a line in the log and a distraction on the screen. Deadband requires the value to fall back below the limit by a defined margin before the alarm clears, so a pressure that alarms at 100 might not clear until it drops back under 98. This single setting is one of the most effective tools against nuisance alarms, because the chattering-at-the-limit case is one of the most common sources of alarm noise.
On-delay, sometimes called a time delay or debounce, attacks a different source of nuisance alarms: brief, transient excursions that cross the limit for a second and return. A momentary spike from electrical noise, a pump start surge, or a quick process transient is often not a real alarm condition, and raising an alarm for it just adds noise. An on-delay requires the value to stay past the limit for a set time, a few seconds, before the alarm actually activates, filtering out the transients while still catching any condition that persists. Together, deadband and delay are the difference between an alarm that fires only on real, sustained abnormalities and one that chatters at every wiggle, and tuning them is usually where a noisy alarm gets fixed.
The alarm message is the text an operator reads when the alarm activates, and it deserves real thought because it is what turns a raised alarm into a correct response. A vague message like PT-301 HI forces the operator to go look up what PT-301 is and figure out what to do, which wastes time in exactly the moment when time matters. A good message names the equipment in plain language, states the condition, and where possible hints at the action, Well 3 discharge pressure high, check for a downstream blockage. Writing the message from the point of view of a tired operator at three in the morning, who may not know this particular site well, is the discipline that makes an alarm actually useful rather than merely present.
No alarm is finished until it has been tested, and testing means driving the value past the limit and confirming the alarm does exactly what you configured. You want to see it activate at the right threshold, display the right priority and message, respect the deadband when it clears, and honor the on-delay so a quick blip does not raise it. Testing on a live tag can be done by creating the condition safely where possible, or by using a simulation or a forced value where the tool allows it. Skipping the test is how a mis-typed limit or an inverted comparison, an alarm set to fire when the value is low instead of high, survives into production and fails silently on the day it is needed.
For remote and unmanned sites, the alarm you configure is often the only thing standing between a developing problem and an expensive failure, because nobody is on site to notice. In a cloud SCADA platform such as Merobix, an analog alarm configured on a tag from a distant well, tank, or pump station is evaluated continuously and surfaced to whoever is on call, so a HI-HI on a remote vessel reaches a phone even though the site is hours away. That remote context raises the stakes on everything in this guide: the limits have to be right because nobody is there to double-check, the deadband and delay have to be tuned because a nuisance alarm at 2 a.m. from a site you cannot see is especially corrosive to trust, and the message has to be clear because the person receiving it is deciding whether to drive out in the dark. Configuring the alarm well is what makes remote operation safe rather than merely possible.
A HI alarm marks the edge of the normal operating range, the point where an operator should start paying attention but nothing is yet dangerous. A HI-HI alarm sits further out and marks a genuinely serious condition that requires action now to avoid a trip or damage. Configuring both on the same tag gives graduated warning, so the operator gets an early heads-up from the HI and an urgent call to act from the HI-HI. The LO and LO-LO pair does the same on the low side.
Two settings handle the two common causes. Deadband stops flicker when a value hovers right at its limit by requiring the value to fall back past the limit by a margin before the alarm clears, so an alarm at 100 might not clear until 98. An on-delay stops brief transient spikes from raising an alarm by requiring the value to stay past the limit for a few seconds first. Tuning these two together is usually how a noisy alarm gets quieted.
The message is what an operator reads at the moment they must decide how to respond, so a vague one wastes time exactly when time matters. A good message names the equipment in plain language, states the condition, and hints at the action, rather than showing only a cryptic tag name. This matters even more for remote sites, where the person receiving the alarm may be on call, unfamiliar with the site, and deciding whether to drive out in the middle of the night.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.