HMI Alarm Configuration: How to Stop an Operator Drowning in Alarms
The test
An alarm is worth raising only if the operator must do something differently because of it. If the answer to "what should they do about this?" is "nothing", it is not an alarm. It is information, and it belongs on a screen, in a log, or nowhere.
Apply that test to any alarm list and it usually removes a third of it.
Alarm flooding, and why it is the real problem
When something significant fails, it rarely fails alone. A pump trips, so flow drops, so pressure drops, so level rises, so a downstream interlock fires, so three machines stop. One root cause, thirty alarms, arriving in under a second.
The operator now has to find the pump trip in a scrolling list while everything demands attention. In practice they acknowledge everything and look at the plant instead, which means your alarm system contributed nothing at the exact moment it was supposed to matter.
Three things reduce flooding:
1. Alarm on cause, not on consequence. If the pump trip is going to bring the line down, alarm the pump trip. The downstream stops are predictable results, not news. Log them; do not alarm them.
2. Suppress the dependent alarms. Most SCADA packages support shelving or suppression conditions: while the pump is tripped, do not raise the low-flow alarm. This is configuration work and it is what separates a considered alarm system from a generated one.
3. Delay the marginal ones. A value crossing a threshold for 200 ms is noise. Requiring it to persist for a few seconds removes most nuisance alarms without hiding anything real. See the on-delay pattern in PLC timer types.
Dead-band, or why one alarm becomes fifty
A level sits exactly on its high setpoint and ripples. Without a dead-band, it alarms, clears, alarms, clears, fifty times a minute. This one mistake produces more junk alarms than any other.
Set a dead-band: alarm at 80%, clear at 75%. The value must come meaningfully back before the alarm resets. Every SCADA package supports it, and it is left at zero far too often.
Priorities that mean something
Three priorities are usually enough, and more than four is always too many.
| Priority | Meaning | Expected response |
|---|---|---|
| High | Safety or major loss, act now | Immediate, stop what you are doing |
| Medium | Production will suffer if ignored | Within minutes |
| Low | Attend when convenient | This shift |
The discipline is in the distribution. If 60% of your alarms are High, you have no priorities at all, only a colour scheme. In a well-configured system High alarms are rare, and that rarity is what makes an operator turn their head when one appears.
Message text that helps
Bad: TT-4021 HIGH
Better: Dryer outlet temperature high, 96 C, limit 90 C. Reduce burner setpoint.
Include the tag, the readable name, the actual value, the limit and the expected action. The operator should not have to look anything up in the moment. Where the culture allows it, put the action in the text.
Acknowledgement and the audit trail
- Acknowledgement means somebody has seen it, not that the problem is fixed. Keep the two states separate: active/cleared and acknowledged/unacknowledged.
- An alarm that clears while unacknowledged must stay visible. Otherwise a brief but serious excursion vanishes and nobody knows it happened.
- Log everything with a timestamp, including who acknowledged. In pharma and food this is a regulatory requirement; everywhere else it is how you reconstruct an incident.
Measuring whether it is any good
The industry guidance, from EEMUA 191 and ISA 18.2, gives numbers you can actually check:
- Around one to two alarms per operator per ten minutes in steady operation is manageable.
- More than ten in ten minutes is generally beyond what a person can process.
- A handful of tags usually generate most of the alarms. Pull the alarm log for a week, count by tag, and fix the top ten. That single exercise typically removes half the total volume.
If you can say in an interview that you have counted alarms by tag from a historian and fixed the worst offenders, you are describing something most engineers have never done.
What to say in an interview
"What makes a good alarm?" is a standard SCADA question. The strongest answer is not a list of alarm types. It is: an alarm must be actionable, unique and have a defined operator response; the main failure mode is flooding, where one root cause raises thirty alarms, which is handled with suppression, dead-bands and delays; and you can measure whether an alarm system works by counting alarms per operator per ten minutes.
More like this in our free interview question prep tool.
Build one properly
Configuring alarms well is a design job, not a data-entry job, and it is learned by watching an operator use what you built. On the Automation Engineer Program trainees build HMI screens with alarms, trends and mimics for live client projects on WinCC, FactoryTalk and Ignition.
Related: What is SCADA, a beginner's guide, HMI design best practices.