ISA-18.2 and IEC 62682: the alarm management lifecycle, rationalization, alarm floods and KPIs

One framework, two documents

ANSI/ISA-18.2, Management of Alarm Systems for the Process Industries, was first published in 2009. The IEC used it as the basis for IEC 62682 in 2014, and ISA then issued a second edition, ANSI/ISA-18.2-2016. IEC 62682 edition 2.0 followed on 8 December 2022. Its scope covers alarms presented to the operator from the basic process control system, annunciators, packaged systems and safety instrumented systems, in continuous, batch and discrete processes.

When IEC 62682 first appeared, exida listed the differences from the 2009 ISA text. Many recommendations became requirements, and alarm shelving became a capability the control system supplier must provide. The recommended deadband values, latching in the state diagram and some performance metrics were removed. The lifecycle stayed the same.

ISA's ISA-18 series page also lists technical reports for the individual stages, among them TR18.2.1 (alarm philosophy), TR18.2.2 (identification and rationalization), TR18.2.4 (enhanced and advanced methods), TR18.2.5 (monitoring, assessment and auditing), TR18.2.7 (packaged systems) and TR18.2.8 (non-alarm notifications).

This article covers alarm management in depth. For how ISA-18.2 fits with the HMI standard ISA-101 when a SCADA system is replaced, see SCADA upgrade with ISA-101 and ISA-18.2; for how alarms are shown on the displays, see ISA-101 explained.

What counts as an alarm

The standard defines an alarm as an audible and/or visible indication to the operator of an equipment malfunction, process deviation or abnormal condition that requires a response. Rockwell's rationalization white paper turns this into four tests:

• the condition is abnormal and needs operator action;
• ignoring it has a real consequence;
• the operator has enough time to act;
• the alarm is unique and points to the root cause.

These four tests expand the three conditions often used as a short rule — an abnormality, a required operator action and enough time to act — by adding that the alarm must be unique. A signal that fails a test is not an alarm. Record why, and keep it as an event or a notification if it is still useful. In Rockwell's paper, candidate alarms come from hazard identification and LOPA reviews, incident investigations, licensor recommendations and the existing alarm database.

The lifecycle, stage by stage

A new system starts at the philosophy. An existing system usually starts at monitoring and assessment, and an audit is the third entry point.

Siemens describes the later stages as continuous work, not a one-off project. Monitoring compares performance with the KPIs and finds bad actors to fix. Changes are reviewed and approved before implementation, and the master alarm database is updated. Periodic audits compare operation with the philosophy, and the philosophy is revised with the findings. Rockwell adds that an audit can find improvements for any stage.

Alarm classes group alarms with similar characteristics. Rockwell notes that ISA-18.2 does not require any particular classes, and suggests groups such as environmental, process safety and diagnostics; one alarm can belong to more than one class. Siemens notes that safety alarms from a safety instrumented system are typically treated as highly managed alarms.

Rationalization: deciding and documenting each alarm

Rockwell's white paper lists nine steps: check validity; determine the consequence of inaction; document cause, confirmation and corrective action; document response time; assign priority; classify; set the limit; set the other attributes; and decide on special handling. The first four steps are knock-out tests — an alarm that fails them is removed.

• Consequence is the direct, immediate result of no response, not a chain of further failures.
• Corrective action must be something the operator does. Acknowledging the alarm does not count.
• Time to respond runs from the alarm to the last moment an action can still prevent the consequence. If that is too short for the operator to confirm and act, use automation such as an interlock instead of an alarm.
• Priority comes from severity and time to respond, looked up in the philosophy's matrix. Rockwell's example grades severity for personnel, environment and financial loss, with urgency bands of more than 30, 15–30, 5–15 and less than 5 minutes. Use no more than three or four priority levels.
• Limits should not be default percentages of range such as 10, 20, 80 and 90 % (Siemens), or other simple percent-of-range rules (Emerson/exida). Leave time to respond; Rockwell suggests using process history to see where normal operation ends.

Each result goes into the master alarm database: the authorised list of rationalized alarms and their attributes. For planning, an Emerson/exida article puts a review team's pace at about 100–200 alarms per day.

Alarm states, shelving and suppression

Siemens' summary of ISA-18.2-2009 lists these states: normal, unacknowledged, acknowledged, returned to normal but unacknowledged, latched (unacknowledged or acknowledged), shelved, suppressed by design, and out of service. IEC 62682 dropped latching from its state diagram. In the same summary, the audible signal applies only to unacknowledged alarms. OPC UA Part 9 (Alarms and Conditions) also models shelving, suppression and out of service. This matters when a SCADA system receives alarms from another system over OPC UA.

Floods, chattering and stale alarms

• Alarm flood. EEMUA 191 treats a flood as starting when a 10-minute period has more than 10 new alarms. It ends at the first 10-minute period with fewer than 5. Many sources simply count 10-minute periods with more than 10 alarms. VanCamp reports that badly performing systems can see more than 250 alarms in one 10-minute period. Rockwell lists alarm flood suppression and state-based alarming among the special-handling options decided during rationalization.
• Chattering and fleeting alarms go in and out of alarm repeatedly within a short time. Criteria vary; VanCamp gives the most common one as three or more activations within one minute. The fix is deadband and on/off delays. Siemens gives starting values: flow 5 % and 15 s, level 5 % and 60 s, pressure 2 % and 15 s, temperature 1 % and 60 s. IEC 62682 deliberately left such values out, so treat them as starting points only.
• Stale alarms stay active for more than 24 hours. Siemens notes that in many control rooms more than half of the standing alarms are for motors that are simply not running. This is where state-based alarming helps.

Performance metrics and where the numbers come from

The figures are per operator position, measured over at least 30 days (Siemens). Sources differ. Yokogawa's summary of ISA-18.2 labels about 150 alarms per day as very likely acceptable and about 300 as the maximum manageable. VanCamp (2016), drawing on EEMUA 191, ISA-18.2 and IEC 62682, uses a target of below 288 and an action limit above 432. An earlier Emerson/exida article uses below 300 and above 600.

The chart shows why one average is not enough. A single upset pushes the shift average above 2 per 10 minutes, even though the rest of the shift is quiet. It also shows that the two flood definitions give different numbers: 3 windows have more than 10 alarms, but by the EEMUA start/end rule the flood lasts 5 windows, until the count drops below 5. State which definition a report uses. Report the average, flood time and bad actors together. A few sources usually dominate. Rockwell says bad actors can account for up to 80 % of the alarm load, and Siemens that up to 80 % of alarms may come from 10–20 tags.

Applying it during a DCS or SCADA upgrade

The alarm configuration has to be rebuilt during an upgrade anyway, so it is the cheapest moment to apply the lifecycle.

1. Export the old alarm configuration — tag, condition, limit, priority, enabled state — into a spreadsheet. This is the first draft of the master alarm database. Siemens notes that one analog point can carry six or more alarms, many of them defaults.
2. Pull at least 30 days of alarm history from the old alarm log or historian. Calculate the baseline: alarms per 10 minutes per console, time in flood, top 10 bad actors, chattering and stale alarms.
3. Write or update the alarm philosophy before configuring the new system.
4. Rationalize with operations, process and safety engineers. Emerson/exida suggest the bad actors as the starting point. Fixing them gives quick relief, but each fix should still go through rationalization, and the rest of the list still needs review.
5. Import limits and priorities from the database instead of retyping them. Check the configuration against the database at FAT.
6. Include packaged units. IEC 62682 covers alarms from packaged systems, and ISA has a technical report on them (ISA-TR18.2.7). On EPC projects, put the alarm philosophy into package specifications at the design stage. Do the same for safety-system alarms in an ICSS.
7. After go-live, schedule a KPI report from the alarm log or historian. Send every alarm change through management of change, and plan periodic audits. Siemens recommends periodically comparing the running configuration with the master alarm database to catch unauthorised changes.

For the wider picture of SCADA layers, see What is SCADA.