Alarm Rationalisation Analyser (EEMUA 191 / ISA-18.2)
Measure the alarm system from the SCADA alarm journal: alarm rate per operator, floods, the most frequent alarms, chattering and standing alarms, priority distribution and consequential alarms — against the EEMUA 191 and ISA-18.2 / IEC 62682 guidance — so the rationalisation starts where it pays most.
Alarm journal
Result
Open an alarm journal or load the sample.
What this tool is, how it works and how far to trust it
An analyser that measures an alarm journal against alarm management targets and finds the few alarms that cause most of the load.
Read this before relying on a result. Every method, formula, assumption and limit is stated here, so you can check the answer yourself instead of accepting it blindly.
What it can do
- Read an alarm journal CSV: time, tag, description, state (alarm / return / acknowledge) and priority (1–3 or high / medium / low).
- Compute the average alarm rate per 10 minutes and per day, the peak 10-minute rate and the share of time in flood, and list every flood with its main contributors.
- List the top 10 alarms and their share, chattering alarms (three within a minute), standing alarms (active over 24 h), the priority distribution and consequential pairs (B follows A within 2 s at least 80 % of the time).
Why you need it
- When every event is an alarm, operators stop reading them: a real trip is lost among door-open and spring-charging alarms.
- Rationalisation needs numbers: a handful of bad actors usually produce most of the load, and fixing them is the fastest improvement.
Understand this first
- EEMUA 191 and ISA-18.2 suggest about one alarm per 10 minutes per operator as manageable and more than 10 in 10 minutes as a flood.
- A suggested priority split is about 80 % low, 15 % medium, 5 % high; if everything is high, nothing is.
- Chattering alarms need a deadband, delay or filter; standing alarms need a fix in the plant or a shelving decision; consequential alarms can be suppressed when their cause is active.
- An alarm should require an operator action; events that need no action belong in the event list, not the alarm list.
What you need before you start
- An export of the SCADA alarm journal (CSV) covering at least a week of normal operation; a month is better.
- A current browser (Chrome, Edge, Firefox or Safari). Nothing is installed and your data is never uploaded; it is processed on your own computer.
How to use it
- Open the journal (or load the sample) and check the column mapping and the period.
- Read the KPIs against the targets, then the top 10, chattering and standing lists.
- Open each flood to see what started it; use the consequential pairs to propose suppression.
What you get
- KPI cards (rates, peak, flood share, priority split) with findings against the targets.
- Tables of floods, top alarms, chattering, standing alarms and consequential pairs.
How to read the results
- Top 10 alarms above about 50 % of the total: a short list of bad actors — fix them first.
- A flood at a trip with dozens of alarms: consider first-out and consequential suppression so the cause stays visible.
- Standing for days: the alarm either reflects a real defect to repair, or it should not be an alarm.
Technical basis
- EEMUA Publication 191; ANSI/ISA-18.2 and IEC 62682 performance indicators.
- Rates are counted from alarm (not return or acknowledge) records; standing = no return within 24 h or still active at the end.
Limits: when not to rely on it
- Operator workload depends on how many consoles share the alarms; the rates assume one operator position.
- The journal does not show whether an alarm was useful — the rationalisation decisions remain with operations.
Sample files for this tool
Download, open and compare with what the guide says you should see.
- S13_SCADA_alarm_journal.csv — SCADA alarm journal — one week
For preliminary engineering use. Results must be checked by a qualified engineer against the project's standards. How results are checked · Terms & disclaimer · Privacy · Build 7cfcbe2 · 2026-11-14