Alarm management is one of the most overlooked areas of process plant operations. A poorly designed alarm system creates alarm floods during process upsets — the exact moment operators need clarity most. ISA-18.2 / IEC 62682 provides the framework for designing rational alarm systems that inform operators rather than overwhelm them. Understanding the standard is not just about compliance; it is about building systems that actually support safe operation.

Why Alarm Management Matters

Studies of major industrial incidents consistently identify alarm system problems as contributing factors. The Texas City refinery explosion (2005) involved operators dealing with over 40 alarms in the minutes before the incident. The Buncefield oil storage fire (2005) involved an alarm that had been in bypass for months. Operators who face 10 alarms per minute during an upset cannot make good decisions — the cognitive load prevents it.

A well-managed alarm system alerts operators to genuinely abnormal situations that require action, in time to take that action. Nothing more, nothing less.

Key ISA-18.2 Performance Metrics

ISA-18.2 defines performance targets for alarm system operation. These are the metrics every alarm management programme should measure:

  • Alarm rate (steady-state): Target is fewer than 1 alarm per 10 minutes per operator position (6 per hour). Rates above 1 per minute (60 per hour) are considered “very likely to be problematic”.
  • Alarm rate during upsets: Even during major upsets, the alarm rate should ideally not exceed 10 per minute per operator. Flood conditions (more than 10 per minute sustained for 10 minutes) require documentation and root cause analysis.
  • Standing alarms: Alarms that remain active for extended periods (more than 24 hours) are considered standing alarms. A healthy system has fewer than 5 standing alarms per operator console at any time. Standing alarms cause operators to stop paying attention to the alarm list.
  • Stale alarms: Alarms that have been in their current state for more than 24 hours. Target is zero stale alarms as a normal operating condition.
  • Chattering alarms: Alarms that activate and clear more than 3 times in any 10-minute window. These are diagnostic indicators of poor deadband settings, oscillating processes, or instrument problems. Target is zero chattering alarms.

The Alarm Rationalisation Process

Alarm rationalisation is the systematic review of every alarm in the system to confirm it meets the definition of an alarm: a signal that indicates an abnormal condition requiring operator action within a defined time. The rationalisation process, defined in ISA-18.2 Clause 6, produces an Alarm Database (also called a Master Alarm Database or MADB) that documents for each alarm:

  • Alarm setpoint and deadband
  • Cause of the alarm condition
  • Consequence if unaddressed
  • Maximum time to respond (time-to-respond)
  • Recommended operator response
  • Alarm priority (Critical, High, Medium, Low)

Priority rationalisation is critical. A system where 80% of alarms are “Priority 1 Critical” is not useful — operators cannot distinguish genuinely critical alarms from routine notifications. ISA-18.2 recommends that fewer than 5% of alarms should be Priority 1, with the majority at medium or low priority.

Alarm Priority Philosophy

ISA-18.2 recommends a consequence-based approach to alarm priority:

  • Priority 1 (Critical): Potential for catastrophic consequences — major injury, fatality, or severe equipment damage. Operator must respond within 5 minutes. Examples: high-high pressure approaching relief valve set pressure, runaway reaction temperature.
  • Priority 2 (High): Significant consequence — production loss, minor equipment damage, or environmental release. Operator should respond within 10-15 minutes.
  • Priority 3 (Medium): Moderate consequence — degraded operations, reduced efficiency. Operator should respond within 30-60 minutes.
  • Priority 4 (Low): Minor consequence — informational, maintenance advisory. Can be addressed during the shift.

Common Alarm System Problems and Fixes

  • Nuisance alarms: Alarms that activate during normal, expected operations — during startup, for example, when a process is intentionally outside normal limits. Fix: use time delays, suppress alarms during defined states, or use state-based alarm management (SBAM) to load different alarm setpoints during startup, normal operation, and shutdown.
  • Chattering alarms: Caused by process oscillation near the alarm setpoint, or insufficient deadband. Fix: increase the alarm deadband so the alarm requires the process to move further away from the setpoint before clearing, preventing rapid repeat activation.
  • Incorrect alarm setpoints: Alarms set at values that are actually within the normal operating band, or set based on instrument range rather than process knowledge. Fix: rationalise setpoints against actual operating limits and consequence analysis.
  • Suppressed alarms that are never re-enabled: Operators silence an alarm to deal with a problem and forget to re-enable it. Fix: implement timed shelving (maximum shelving period of 24 hours with automatic re-enable) and a shelved alarm management workflow.
  • Alarm flooding during upsets: A single upstream event triggers hundreds of consequential alarms. Fix: implement alarm suppression grouping, where the root cause alarm triggers suppression of all downstream consequence alarms, presenting the operator with one actionable alarm rather than an overwhelming flood.

Implementing ISA-18.2 in Practice

A full ISA-18.2 compliant alarm management programme involves several work phases:

  1. Benchmark: Collect alarm performance data from the historian for the past 30 days. Calculate alarm rates, identify top 10 most frequent alarms, count standing and chattering alarms. This baseline establishes where you are today.
  2. Bad actor resolution: Fix the top 10 most frequent alarms first. These typically account for 40-60% of total alarm activity. Resolution methods include setpoint adjustment, deadband tuning, time delays, and suppression during defined operating states.
  3. Rationalisation: Conduct a formal rationalisation review for all alarms, producing the Master Alarm Database. This is typically a team exercise involving control system engineers, process engineers, and experienced operators.
  4. Documentation: Update the alarm database in the DCS to match the rationalised setpoints, priorities, and descriptions. Alarm response procedures (documented in the MADB) are made accessible to operators from the HMI.
  5. Monitoring and continuous improvement: Establish regular alarm performance reporting (monthly) and a process for reviewing new alarms before they are added to the system. Prevention of alarm addition without proper rationalisation is as important as fixing existing problems.

Alarm management is not a one-time project — it is an ongoing discipline. Systems that are rationalised and then neglected return to poor performance within 1-2 years as processes change, equipment degrades, and new alarms are added without review.