The short answer
ISA-18.2 Alarm Management
ISA-18.2 is the standard for alarm system management in the process industries. It defines an alarm as an audible or visible indication of an abnormal condition that requires a timely operator response, and it lays out a lifecycle from philosophy through identification, rationalization, design, implementation, operation, monitoring, and management of change. Its central premise is that an alarm without a defined operator response is not an alarm.
Key points
- If there is no action an operator can take, it is information, not an alarm.
- Every alarm needs a documented cause, consequence, response, and time available to respond.
- A widely cited target is fewer than about 150 alarms per operator per day in steady operation.
- Alarm floods during an upset are the failure mode that hurts most, and they are designed in.
- Rationalization is the step that produces the benefit, and the step most often skipped.
The definition does the heavy lifting
ISA-18.2 defines an alarm as an indication of an abnormal condition requiring a timely operator response. Every word narrows it. Abnormal excludes normal state changes. Requiring a response excludes anything nobody acts on. Timely excludes conditions that can wait for the morning.
Apply that test honestly to an existing system and most of the alarm list fails it. A pump running is not abnormal. A valve reaching commanded position is not abnormal. A daily report completing is not an alarm. These belong in event logs and status displays, and moving them there is most of the work of fixing an alarm system.
The lifecycle
- 1
Philosophy
The governing document. Defines what qualifies as an alarm at this facility, how priorities are assigned, what the annunciation and acknowledgement conventions are, and who may change an alarm. Without it, every later decision is arbitrary.
- 2
Identification
Collecting candidate alarms from P&IDs, hazard reviews, incident history, and operator experience.
- 3
Rationalization
The core step. Each candidate is tested against the philosophy. For those that survive, you document cause, consequence of no action, the specific corrective action, the time available to respond, and the resulting priority.
- 4
Detailed design
Setpoints, deadbands, on-delays, priorities, and how the alarm presents on the HMI.
- 5
Implementation
Configuration in the controller and SCADA, plus operator training on what changed and why.
- 6
Operation and maintenance
Running the system, including shelving and suppression used as designed rather than improvised.
- 7
Monitoring and assessment
Measuring alarm rates, finding the bad actors, and reporting. This is what tells you whether any of the earlier work held.
- 8
Management of change
A defined path for adding, removing, or retuning an alarm. Without it a rationalized system drifts back within a year or two.
Rate targets
The commonly used performance targets originate in EEMUA 191 and are referenced in ISA-18.2 practice. They describe a system an operator can actually work with.
| Metric | Target | Interpretation |
|---|---|---|
| Average alarms per hour | About 6 | Roughly one every ten minutes in steady operation |
| Average alarms per day | About 150 or fewer | Manageable across a shift |
| Peak alarms in 10 minutes | 10 or fewer | Above this, an operator falls behind |
| Time in flood condition | Under 1% | A flood is more than 10 alarms in 10 minutes |
| Contribution of top 10 alarms | Under 5% of total | A higher figure means a handful of bad actors dominate |
| Standing or stale alarms | Very few | An alarm active for days is furniture, not information |
Measure before you improve. Nearly every system that has never been assessed is dominated by a small number of bad actors, and fixing ten tags often cuts the total rate by more than half. That is the cheapest work available in alarm management.
Priority means response, not importance
Priority should be derived from the consequence of no action and the time available to respond. Assigning priority by how important the equipment feels produces a system where every alarm is high priority, which is the same as having no priorities.
| Priority | Typical basis | Share of total alarms |
|---|---|---|
| Critical / Emergency | Severe consequence, minutes to respond | About 5% |
| High | Significant consequence, limited time | About 15% |
| Medium | Moderate consequence, time available | About 80% combined with low |
| Low / Journal | Minor or informational, log only | Included above |
Techniques that reduce noise
- Deadband
- The alarm clears at a value offset from where it activated, so a measurement sitting on the threshold does not chatter. Set it wider than the normal noise on the signal.
- On-delay
- The condition must persist before it annunciates. A few seconds removes an enormous number of transient alarms without hiding anything real.
- State-based suppression
- Alarms that only make sense in a given operating state are suppressed in others. A low discharge pressure alarm on a stopped pump is noise by design.
- Shelving
- An operator temporarily silences a known nuisance alarm, with an automatic expiry and a visible record. Controlled and reversible, unlike quietly disabling it.
- First-out and cause grouping
- When one failure produces twenty consequential alarms, present the initiating one prominently rather than all twenty equally.
Alarm floods
A flood is more than about ten alarms in ten minutes at one operating position. It typically follows a single event: a power dip, a communication failure, or a plant trip that cascades. The operator most needs clarity at exactly the moment the system provides the least.
Floods are designed in, not accidental, and they are addressed at design time. Suppress the consequential alarms that a known initiating event always produces. Group by cause. Give the operator a display that shows the initiating condition rather than a scrolling list. In a distributed utility, a single radio failure producing one hundred and forty communication alarms is a design problem worth a day of engineering.
Frequently asked questions
- What is the difference between an alarm and an event?
- An alarm requires a timely operator response. An event is recorded but requires nothing. A pump starting is an event. A pump failing to start when commanded is an alarm.
- How many alarms should a system have?
- The standard sets rates, not counts. A large plant may have thousands of configured alarms and still be well within rate targets, because most are rarely active. A small plant with forty alarms can be unusable if six of them chatter constantly.
- Is ISA-18.2 mandatory?
- It is a consensus standard, not a regulation, and it is not generally mandated for municipal water and wastewater. It is widely treated as good practice, and it is often referenced in specifications. Where a regulator or insurer asks how alarms are managed, this is the framework they expect to hear about.
- Where do I start on an existing system nobody has ever rationalized?
- Measure for thirty days. Rank alarms by frequency. Take the top ten and address each one by fixing the underlying cause, adding a delay or deadband, changing the setpoint, or reclassifying it as an event. That work alone typically removes most of the volume, and it builds the case for funding a full rationalization.
Related topics
- The Alarm PhilosophyThe document that decides what is allowed to be an alarm: the definition, the criteria, the priorities and their meaning, the performance targets, the handling rules, and who owns it. Under ISA-18.2 it comes first.
- Alarm FloodsWhat an alarm flood is, why it happens at exactly the wrong moment, the ISA-18.2 rate targets, and the design measures that keep a power failure or a communication loss from burying the one alarm that matters.
- High Performance HMI DesignGrey backgrounds, reserved color, and displays designed to make abnormal conditions obvious rather than to look impressive in a demo.
- Alarms in the ControllerGenerating alarm conditions in the controller rather than in the graphics: why the PLC should own the alarm state, a standard alarm block with setpoints, deadband, and delays, equipment alarms, and packing alarm bits for SCADA.
- Alarm PriorityHow to assign alarm priorities that operators trust: a consequence-and-time matrix, three or four levels, the target distribution from ISA-18.2 and EEMUA 191, and the mistakes that make every alarm high.
- Alarm RationalizationThe meeting where every alarm earns its place: who attends, what is decided for each alarm, how to document it in a master alarm database, and how to run it at a utility that cannot spare a week.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.