Learn Automation with MINATA #55: HMI Alarm Design — A Good Alarm Has to Lead to an Action
HMI Alarm Design: A Good Alarm Has to Lead to an Action
A good alarm leads the operator to the right action, not merely to the knowledge that something is wrong. A screen full of alarms at the same priority, with cryptic names and no hint of what to do, teaches operators to acknowledge everything and move on — including on the day the alarm actually matters.
Priority by consequence
Do not give the same priority to a loss of safety, a maintenance warning and an operational notice. Rank them by consequence and by how quickly someone has to react:
| Priority | Meaning | What the operator does |
|---|
| Critical | Loss of safety, machine stopped | Intervene immediately |
| High | A fault that halts the cycle | Deal with it soon; maintenance may be needed |
| Warning | Approaching a threshold, maintenance due | Monitor and plan |
| Information | An operational event | Note it; no intervention needed |
An alarm name has to say three things
The name and text should state which device, what condition, and the first step to take. "Infeed conveyor: timeout waiting for a part — check sensor B3 and the part supply" is far more useful than "Error 102". Nobody on the night shift carries the fault-code table in their head.
Preventing alarm floods
When one root fault drags a cascade of secondary alarms with it, the operator loses sight of the cause. Reduce the flood by grouping alarms under their root cause, adding a sensible delay for signals that oscillate, and not raising an alarm for a condition that needs no intervention at all. The goal is that every alarm that remains is worth looking at.
Log it, to improve it
Log the moment an alarm appears, is acknowledged and clears. That data tells you which alarms sound most often, which sit unacknowledged longest, and where the design should be fixed instead of the operator being left to endure it.
A worked engineering situation
When a conveyor times out waiting for a part, the HMI shows which conveyor, which sensor to check and which machine step is stopped — rather than only a code reading "Error 102". The operator goes straight to the point that needs attention. A week of alarm logs then shows that this sensor sounds far more often than the rest, which leads to a decision to adjust where it is mounted.
The alarm list, the priorities and the wording all follow the alarm philosophy of the system and the operating requirements.
Common mistakes
- Every alarm at the same priority, with no ranking by consequence.
- Alarm names that are codes, naming neither the device nor the response.
- Alarm floods, where one fault brings a cascade of secondary alarms.
- Alarms raised for conditions that need no intervention, adding noise.
- No logging, so nobody knows which alarms need improving.
HMI alarm checklist
- [ ] Alarms are ranked by consequence and by reaction time.
- [ ] The text names the device, the condition and the first step.
- [ ] Flood control exists, with alarms grouped by root cause.
- [ ] Appearance, acknowledgement and clearing are all logged.
- [ ] The log is reviewed periodically to improve the alarm design.
An alarm that leads to an action is an alarm worth trusting. #56 widens the view to SCADA monitoring, turning the state of many machines into operating information.
Read more automation knowledge at MINATA: https://minatavn.com/en/blog/industrial-automation
Previous — #54: Backing up a PLC program: https://minatavn.com/en/blog/automation-54-plc-program-backup
Next — #56: SCADA monitoring: https://minatavn.com/en/blog/automation-56-scada-monitoring
View all MINATA technical articles