Alarm system performance metrics (ISA-18.2, EEMUA 191): computing them from a SCADA export

Measure before you rationalize

Every alarm rationalization project starts with the same question: do operators receive more alarms than they can handle? Without numbers the discussion runs on impressions ("we have too many alarms") and no decision sticks. With a few weeks of log data you know where to act, and you can measure the improvement afterwards.

ISA-18.2, IEC 62682 and EEMUA 191 describe these metrics and give orders of magnitude. The definitions below are working definitions, good enough for a diagnosis. For a contractual commitment, your copy of the standard is the reference. Published summaries of ISA-18.2 recommend basing the figures on at least 30 days of data.

First: from log lines to episodes

An alarm export contains lines: activation, return to normal, acknowledgement, sometimes shelving or suppression. The metrics are about episodes (one activation and what follows it), not about lines. Three reconstruction rules avoid most errors:

1. An episode starts at an activation and ends at the next return to normal of the same alarm (tag plus condition: HI, HIHI, FAULT and so on).
2. An acknowledgement belongs to the latest unacknowledged episode of the same alarm.
3. An alarm already active when the log starts (a return to normal with no earlier activation) does not count as an activation.

Timestamps need care: local time or UTC, daylight saving changes, day-first or month-first date formats. A one-hour shift is enough to create a flood that never happened.

The eight metrics

The benchmark column gives figures commonly cited from ISA-18.2, per operating position (one console and the operator who watches it).

The same published table also expresses the rate per 10 minutes (about 1, at most about 2) and per day (about 150, at most about 300), and lists two zero targets that a log export rarely lets you measure: unauthorized suppression and unauthorized changes to alarm attributes.

How to read the results

A good average can hide floods. A site averaging 4 alarms per hour can still spend a large part of its time in flood after each electrical trip. Floods are when mistakes happen: always look at the peak and the time in flood, not only at the average.

The Pareto tells you where to work. On most sites a handful of alarms makes up a large share of the volume. Fixing the most frequent ones (deadband, delay, a badly placed limit, an alarm that should be an event) is usually the fastest way to bring the overall rate down.

Chattering is fixed in the controller, not in the HMI. An alarm that activates and clears several times a minute is oscillating around its limit. The remedy is a deadband (the alarm only clears after a margin) or an on-delay (the condition must persist for a few seconds).

Stale alarms erode trust. An alarm that has been active for three weeks is an alarm nobody reads any more. Either it signals a real problem left to drag on, or it requires no action and is not an alarm.

Too many high priorities sort nothing. If half of the activations are "high", the operator handles them in order of arrival. Priority follows from the severity of the consequence and the time available to act, and that rule belongs in the alarm philosophy.

Traps in the export

• State-column formats (active 0/1, acknowledged 0/1): an activation is a 0 to 1 transition of the active column, a return to normal a 1 to 0 transition.
• Logs without states (one line per activation): you can count activations, but not fleeting or stale alarms, nor acknowledgement times.
• Several operating positions in one log: flood thresholds are per position. Either split the log by console or multiply the thresholds by the number of positions.
• Too short a period: on less than an hour of log, an hourly rate means nothing.
• Information lines (events, operator messages) mixed with alarms: exclude them, otherwise they inflate every metric.

A simple first calculation

Counting activations in 10-minute slots and finding the flooded slots takes a few lines:

function countPerSlot(activations, start, end, slot = 600000) {
  const n = Math.ceil((end - start) / slot), bins = new Array(n).fill(0);
  for (const t of activations) if (t >= start && t < end) bins[Math.floor((t - start) / slot)]++;
  return bins;
}
const floodedSlots = (bins, limit = 10) => bins.flatMap((v, i) => (v > limit ? [i] : []));

Timestamps are in milliseconds. Fixed slots slightly underestimate peaks compared with a sliding window, because a burst can straddle two slots, but they are enough for a first diagnosis. For the sliding-window peak, keep the activations sorted and move two indexes along the array so that the window never spans more than 10 minutes.

Try it on your own log

A free online alarm log analyzer lets you try these metrics on your own export. For the way alarms are displayed once the volume is under control, the High-Performance HMI guide covers priorities and redundant coding, the alarm list, and floods, chattering and shelving, with tested web code. If you are building the alarm screens yourself, hmi-kit provides an alarm banner, an alarm list sorted by acknowledgement state and priority, and an event log with CSV export, as Web Components. Neither product computes the metrics above: they deal with presenting alarms, not analysing logs.

Sources

• ANSI/ISA-18.2, Management of Alarm Systems for the Process Industries (not reproduced)
• IEC 62682, Management of alarm systems for the process industries (not reproduced)
• EEMUA Publication 191, Alarm systems, a guide to design, management and procurement (not reproduced)
• Siemens, Improving alarm management with ISA-18.2, Part 2, Process Online, March 2014 (table of recommended metrics citing ANSI/ISA-18.2-2009)
• Marcus Tennant, Implementing alarm management per the ANSI/ISA-18.2 standard, Control Engineering, 2013
• Pages checked on 2026-10-27