Alarm management: the lifecycle, rationalisation and the measures, with a worksheet
What an alarm is for, the ten-stage lifecycle ISA-18.2 and IEC 62682 describe, what the philosophy settles once, the questions rationalisation asks of every alarm, the performance measures and their benchmarks, how the bad actors are found and fixed, and the systems around it. With a free rationalisation worksheet.
Key takeaways
- An alarm exists to tell an operator that something needs their action, in time for the action to matter. Anything else on the alarm list is noise that hides the ones that do.
- ISA-18.2 and IEC 62682 describe a lifecycle: a philosophy set once, candidates identified and rationalised against it, designed, implemented, operated, monitored, and every change sent back through rationalisation.
- Rationalisation is the gate. Each candidate has to name its cause, the consequence of no action, the operator's action and the time to respond. An alarm with no action is removed.
- Performance is measured, per operator console, against published benchmarks: about one alarm per ten minutes on average, fewer than ten in any ten minutes, less than one per cent of time in flood, and a handful of standing alarms at most.
- A few bad actors usually make most of the load. Fixing the top ten, by deadband, delay, setpoint or removal, is where most of the improvement comes from.
Walk into most control rooms and the alarm list is scrolling. Hundreds of entries a shift, most of them acknowledged without being read, because the operators learned long ago that nearly all of them say nothing they can act on. Then one of them does, and it is on the fourth page.
Alarm management is the discipline that fixes that, and it has been standardised: ISA-18.2 in 2009 and its international form IEC 62682, both grown from the EEMUA 191 guide. The standards describe a lifecycle rather than a project, because an alarm system that is rationalised once and then changed without discipline is back where it started within a few years.
This guide sets out what an alarm is and is not, the lifecycle stage by stage, what the philosophy has to settle, how rationalisation works and the questions it asks of every alarm, the performance measures and their benchmarks, how the bad actors are found and fixed, and where programs fail. A rationalisation worksheet comes with it. It sits beside the data historian guide, because the events that are not alarms belong there.
Free download
Alarm rationalisation worksheet
A worksheet that asks the rationalisation questions of every candidate alarm, with five worked rows on a crusher lubrication system, the performance measures and their benchmarks, and the lifecycle on a sheet of its own.
What an alarm is for
The standards' definition is short: an alarm is an audible or visible means of indicating to the operator an equipment malfunction, process deviation or abnormal condition requiring a response. The last two words are the test. If no operator response follows, it is not an alarm. A trip the interlock has already handled is an event. A filter differential the planner will act on next week is a notification. A pump that has started is a log entry. All of those belong in the historian and the event journal, and none of them belong on the list the operator has to read in a hurry.
The reason the test matters is attention. An operator can read and act on a small number of alarms in a ten-minute window, and every alarm that carries no action takes a share of that attention from the ones that do. A plant that raises six hundred alarms a shift is not six times safer than one that raises a hundred. It is less safe, because the operator has been trained by the system to acknowledge without reading.
An alarm with no operator action is not an alarm. It is noise with a colour.
The lifecycle
ISA-18.2 and IEC 62682 describe alarm management as a lifecycle of ten stages. The order matters less than the two rules it encodes: nothing becomes an alarm without passing rationalisation, and nothing is changed without passing it again. The philosophy is written once and everything else refers to it. Monitoring runs continuously and feeds both the operation and the next round of rationalisation.
1Philosophy
Sets the site's rules once: what an alarm is for, the priorities and their meaning, the performance targets, the roles
The alarm philosophy document
2Identification
Finds candidate alarms from the hazard studies, the control narrative, the operating procedures and incident history
A list of candidates, each with a reason
3Rationalisation
Tests every candidate against the philosophy: consequence, operator action, time to respond, priority, setpoint
The master alarm database, with the ones that failed the test removed
4Detailed design
Specifies how each alarm is implemented: deadband, delay, suppression, shelving, the display
Configuration ready to load
5Implementation
Loads and tests the configuration, trains the operators on the new alarms and their responses
Alarms live, with the response written against each
6Operation
Operators respond to alarms, shelve nuisances under rules, and report what the system does badly
Alarm and response history
7Maintenance
Alarms out of service for maintenance are tracked and returned; faulty instruments fixed rather than suppressed
Out-of-service log
8Monitoring and assessment
Measures the system against the targets: rates, floods, stale and chattering alarms, priority distribution, the bad actors
A monthly performance report
9Management of change
Any new or changed alarm goes through rationalisation again, not straight into the control system
The master alarm database stays the truth
10Audit
Periodic check that the lifecycle is being followed, and the philosophy still fits the plant
Audit findings into the philosophy
→ Every alarm passes rationalisation once
↻ Every change passes it again
| Stage | What it does | What it produces |
|---|---|---|
| Philosophy | Sets the site's rules once: what an alarm is for, the priorities and their meaning, the performance targets, the roles | The alarm philosophy document |
| Identification | Finds candidate alarms from the hazard studies, the control narrative, the operating procedures and incident history | A list of candidates, each with a reason |
| Rationalisation | Tests every candidate against the philosophy: consequence, operator action, time to respond, priority, setpoint | The master alarm database, with the ones that failed the test removed |
| Detailed design | Specifies how each alarm is implemented: deadband, delay, suppression, shelving, the display | Configuration ready to load |
| Implementation | Loads and tests the configuration, trains the operators on the new alarms and their responses | Alarms live, with the response written against each |
| Operation | Operators respond to alarms, shelve nuisances under rules, and report what the system does badly | Alarm and response history |
| Maintenance | Alarms out of service for maintenance are tracked and returned; faulty instruments fixed rather than suppressed | Out-of-service log |
| Monitoring and assessment | Measures the system against the targets: rates, floods, stale and chattering alarms, priority distribution, the bad actors | A monthly performance report |
| Management of change | Any new or changed alarm goes through rationalisation again, not straight into the control system | The master alarm database stays the truth |
| Audit | Periodic check that the lifecycle is being followed, and the philosophy still fits the plant | Audit findings into the philosophy |
The philosophy, settled once
The alarm philosophy document is the site's rulebook, and its value is that it is written before any individual alarm is argued about. It defines what an alarm is and is not. It sets the priority levels, usually three or four, and the matrix that assigns them from the consequence of no action and the time the operator has to respond, so that priority is derived rather than chosen. It sets the performance targets the system will be measured against. It gives the rules for shelving a nuisance alarm, suppressing alarms by plant state, and taking alarms out of service for maintenance. And it names who may change an alarm and how.
Without a philosophy, every rationalisation meeting re-argues the basics, every engineer sets priority by feel, and the result differs by area and by year. With one, the meetings are short and the outcomes consistent, which is what makes a master alarm database possible.
Rationalisation: the questions every alarm answers
Rationalisation is a review of each candidate alarm by a small team, an operator, a process or control engineer and a facilitator, against the philosophy. For each alarm the team records the cause, the consequence of no action, the operator's specific action, the time available to take it, and from those the priority, the setpoint with its basis, and the deadband or delay that stops it chattering. An alarm with no operator action is removed. An alarm that duplicates another is removed. A diagnostic that belongs to maintenance becomes a notification from the historian instead.
The columns below are the worksheet's, and the worked rows in the template show a crusher lubrication system through the process: two of five candidates are removed, one because the interlock has already acted and one because the action belongs to the planner. The output is the master alarm database, which from then on is the truth about every alarm, and the control system is configured from it rather than the other way round.
| Column | What goes in it |
|---|---|
| Tag | The point in the control system |
| Description | What the alarm is, in words |
| Alarm type | As it says |
| Cause | What has happened in the process when this alarm comes in |
| Consequence of no action | What happens if the operator does nothing |
| Consequence class | From the philosophy's scale |
| Operator action | The specific action the operator takes. If there is none, this is not an alarm |
| Time to respond | How long the operator has before the consequence, from the process dynamics |
| Priority | From consequence and time to respond, by the philosophy's matrix |
| Setpoint | The value, with its basis |
| Deadband or delay | To stop chattering, from the signal's noise |
| Keep | As it says |
| Reason if removed | Duplicate, no action, covered by another alarm, diagnostic not alarm |
| Rationalised by, date | As it says |
Measuring the system
An alarm system is measured per operator console against the benchmarks the standards and EEMUA 191 publish. They are targets rather than limits, and a plant far above them has operators who cannot be using the list as intended. The measures come from the alarm journal in the control system or the historian, and a monthly report of them is the monitoring stage of the lifecycle. The maintenance KPIs guide places them beside the other measures a plant reads.
| Measure | Benchmark | Why it matters |
|---|---|---|
| Average alarm rate | Fewer than 1 per 10 minutes, about 150 a day | About 2 per 10 minutes, 300 a day, is the most that is manageable |
| Peak alarm rate | Fewer than 10 in any 10 minutes | A flood is more than 10 in 10 minutes |
| Time in flood | Less than 1 per cent of hours | During a flood the operator cannot read the alarms, so each one is noise |
| Stale alarms | Fewer than 5 standing for more than 24 hours | A standing alarm nobody acts on trains the operator to ignore the screen |
| Chattering and fleeting | None | An alarm that cycles more than a few times a minute is a deadband or delay problem |
| Priority distribution | About 80 per cent low, 15 per cent medium, 5 per cent high | If most alarms are high priority, the priorities mean nothing |
| Top ten contributors | Less than 1 per cent of the load each | A handful of bad actors usually make most of the load |
| Suppressed out of service | All known and tracked | An alarm suppressed and forgotten is a protection that is gone |
Finding and fixing the bad actors
In almost every alarm system a small number of alarms produce most of the load. The monthly report ranks them, and the top ten are reviewed one at a time. Most have one of four fixes. A chattering alarm needs a deadband or a delay set from the signal's noise. A standing alarm that nobody acts on needs its setpoint moved, or the underlying fault fixed rather than lived with. An alarm that floods after a trip needs suppressing by plant state, so that once the trip has occurred its consequences do not each announce themselves. And an alarm with no action, which rationalisation should have caught, is removed.
The faulty instrument deserves its own mention. An alarm that is bad because the transmitter is bad is a maintenance problem, and suppressing it while the transmitter stays broken removes a protection. The maintenance stage of the lifecycle exists to track exactly that: which alarms are out of service, why, and when they come back.
Fix the top ten and the list usually halves. Then the next ten.
The system around it
The control system raises the alarms, but the discipline lives in the systems around it. The master alarm database is the record, kept in a tool built for it or, at a smaller plant, in a controlled spreadsheet with the rationalisation worksheet as its shape. The alarm journal is read from the control system or the historian, and the monthly measures are a report built on it, which is the kind of software work Enco does. Management of change links the database to the control system's configuration, so that a changed setpoint in the controller without a changed row in the database is a finding, not a mystery.
The OT security guide covers the engineering access that changes alarms, and the plant protocols guide the path the journal takes out of the control network.
Where programs fail
- No philosophy, so every rationalisation meeting starts from scratch and the result depends on who was in the room.
- Rationalisation done once as a project, then alarms added straight into the control system for years.
- Priority set by how worried the engineer was, so most alarms are high and the priority means nothing.
- Events and diagnostics on the alarm list because the control system made it easy.
- Consequential alarms not suppressed by state, so every trip produces a flood and the one useful alarm is buried.
- Nuisance alarms shelved and forgotten, with the shelf as the permanent fix.
- A faulty instrument suppressed instead of repaired.
- No monthly report, so nobody knows the rate until the incident investigation reads the journal.
Common questions
What is alarm management?
The practice of designing, rationalising, operating and monitoring the alarms on a plant's control system so that each one tells an operator about something that needs their action, in time, and nothing else competes with it. ISA-18.2 and its international equivalent IEC 62682 set out the lifecycle, and EEMUA 191 is the guide most of the practice grew from.
What is alarm rationalisation?
The review of every candidate alarm against the site's alarm philosophy, asking what causes it, what happens if the operator does nothing, what the operator should do, how long they have, and what priority and setpoint follow. An alarm that has no operator action, duplicates another or is a diagnostic rather than an alarm is removed. The output is the master alarm database, which becomes the one record of what every alarm is for.
How many alarms per hour is acceptable?
The benchmarks in ISA-18.2 and EEMUA 191, per operator console, are an average of about one alarm every ten minutes, roughly six an hour and 150 a day, with about two every ten minutes as the most an operator can manage. More than ten in any ten minutes is a flood, during which the operator cannot read what is arriving. Many plants run at several times these rates and have operators who have learned to ignore the screen.
What is an alarm flood?
A period in which alarms arrive faster than an operator can read and act on them, usually defined as more than ten alarms in ten minutes. Floods typically follow a trip or a process upset, when one cause produces dozens of consequential alarms, and the one alarm that says what to do is buried among them. Suppression of consequential alarms by state, and the removal of alarms that carry no action, are the usual fixes.
What should an alarm philosophy document contain?
The site's rules, set once: what an alarm is and is not, the priority levels and the consequence and time-to-respond matrix that assigns them, the performance targets, the rules for shelving and suppression, the roles and the management of change process, and the colours, sounds and display conventions. Every later decision in the lifecycle refers back to it, which is what makes the rationalisation consistent across teams and years.
What is the difference between an alarm and an event?
An alarm needs an operator to act. An event is something the system records because it is useful to know later: a trip that an interlock has already handled, a pump that started, a setpoint change. Events belong in the historian and the event log, where engineers and planners read them. Putting them on the alarm list is the most common way the list grows past what an operator can use.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- ISA-18.2, Management of alarm systems for the process industries (ISA)
- IEC 62682:2022 Management of alarm systems for the process industries (IEC)
- EEMUA 191, Alarm systems: a guide to design, management and procurement (EEMUA)
- SP 800-82 Rev. 3, Guide to operational technology security (NIST)
- ISO 14224:2016 Collection and exchange of reliability and maintenance data for equipment (ISO)
Related case studies and tools
- Automated operations reporting (case study)
- Bridging OT and IT with custom software (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.