Preparing the file
The tool accepts most text exports: semicolon, comma, tab or pipe separators, with a header row. At minimum it needs:
| Column | Example | Required |
|---|---|---|
| Timestamp | 10/12/2026 2:03:27 PM or 2026-10-12T14:03:27 | yes |
| Alarm | TT-104 or "Furnace temperature high" | yes |
| State | ON / OFF, 1 / 0, Came In / Went Out | no, but recommended |
| Priority | High, 1, Critical | no |
Columns are guessed from the headers; check them in the lists that appear after loading. For the state column, pick the value that means "alarm comes in": an activation is only counted if the alarm was not already active.
The Try with sample data button loads a fictitious 24-hour log with a chattering alarm and a flood, so you can see what the results look like.
What the tool computes
| Indicator | Method used here |
|---|---|
| Alarms per hour per position | activations ÷ log duration ÷ number of operator positions |
| 10-minute peak | highest number of activations in a fixed 10-minute slot, per position |
| Time in flood | share of 10-minute slots with more than 10 activations per position |
| Share of the 10 most frequent | activations of the 10 most active alarms ÷ all activations |
| Chattering alarms | alarms activated 3 or more times within one minute, at least once |
| Stale alarms | alarms that stayed active for more than 24 hours, or are still active after more than 24 hours at the end of the log |
| Priority distribution | share of each value of the priority column among activations |
Fixed 10-minute slots slightly underestimate peaks compared with a sliding window. For a first diagnosis the difference does not matter.
How to read the results
A good average can hide floods. A site averaging 4 alarms per hour can still spend several percent of its time in flood after every trip. Those are the moments when operators make mistakes: always look at the peak and time in flood, not only the average.
The top 10 tells you where to work. On most sites a handful of alarms makes up a large part of the volume. Fixing the ten most frequent ones (deadband, on-delay, misplaced limit, alarms that are not really alarms) often cuts the overall rate dramatically.
Chattering alarms are fixed in the controller, not the HMI. An alarm that comes and goes several times a minute oscillates around its limit; the cure is a deadband or an on-delay.
Stale alarms erode trust. An alarm active for three weeks is an alarm nobody reads anymore: either it flags a real problem left unresolved, or it calls for no action and should not be an alarm.
Limits of this tool
- It does not handle daylight saving changes or time zones: times are read as written.
- It does not rebuild acknowledgements or shelving.
- It handles one date format at a time; for ambiguous dates (03/04), choose day/month/year or month/day/year.
- Very large files (hundreds of thousands of rows) work but slow the browser down.
Going further
Displaying alarms well matters as much as rationalising them. The High-Performance HMI guide covers priorities, the alarm list and alarm floods, and the hmi-kit components provide an alarm banner and an alarm list sorted by priority. The 8 high-performance HMI rules put alarms back into the overall approach.
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)