ISA-18.2 alarm management means treating alarms as an engineered system with a lifecycle and a defined state model, not as a list of tags with a red color. In an HMI builder, that comes down to a few behaviors you can test: alarms move through unacknowledged, acknowledged, returned-unacknowledged, shelved, suppressed and out-of-service states, acknowledging never clears an active alarm, and deadband and on-delay stop values chattering at a limit. LADX HMI/SCADA implements that state machine and lets you run it against the PLC logic at a desk.
What ISA-18.2 actually asks for
ISA approved ISA-18.2, Management of Alarm Systems for the Process Industries, in June 2009 (Processing magazine). The current edition is ANSI/ISA-18.2-2016, and the international equivalent is IEC 62682:2022 (IEC webstore). The ISA18 committee continues to develop the standard and its technical reports covering design, installation, operation and maintenance of alarm systems (ISA18 committee). It applies to continuous, batch and discrete processes, so a packaging line or a CIP skid is in scope as much as a refinery.
The core idea is a lifecycle: write an alarm philosophy, identify candidate alarms, rationalize each one (cause, consequence, operator action, time to respond, priority), design and implement, then monitor, maintain and manage changes. Most of that is engineering work on paper. The part an HMI builder owns is detailed design and implementation, and that is where small mistakes ruin good rationalization.
The stakes are not abstract. At BP's Texas City refinery in March 2005, a distillation tower overfilled during a restart and the explosions killed 15 workers and injured 180 (U.S. Chemical Safety Board). exida cites Texas City when it describes poor alarm management as a leading cause of major incidents and unplanned downtime (exida).
The alarm states your HMI must implement
| State | What the operator sees | Common mistake |
|---|---|---|
| Unacknowledged, active | Flashing, audible | Horn silence treated as acknowledge |
| Acknowledged, active | Steady indication | Acknowledge clears the alarm |
| Returned, unacknowledged | Still listed until acknowledged | Alarm disappears unseen |
| Shelved | Hidden, with expiry and audit | Shelving never expires |
| Suppressed by design or out of service | Hidden by logic or maintenance | No list of what is hidden |
The rule most implementations get wrong is the second row. Acknowledging tells the system the operator has seen the alarm. It must never clear an alarm whose condition is still true. LADX HMI enforces that rule in its state machine, along with shelving that expires on its own (LADX HMI/SCADA).
Chatter, deadband and on-delay
A tank level sitting right at its high limit will alarm and clear dozens of times an hour. Each one is a nuisance, and nuisance alarms teach operators to ignore the banner. Two settings fix most of it. Deadband means the value must fall back by a set margin before the alarm returns to normal. On-delay means the condition must persist for a set time before the alarm is raised. Set them per alarm during rationalization, not as a global default nobody revisits.
Floods are the other failure. When a pump trips, its low-flow, low-pressure and downstream level alarms often all fire within seconds, and the operator has to work out which one started it. Design for that at the HMI stage: suppress consequential alarms by logic when the root cause is already active, keep a first-out indication on trip sequences, and make the alarm summary sortable by time and priority so the first alarm is easy to find.
Bulk alarm limits: a starting point, not rationalization
Defining alarms one at a time is why most analog points end up with none. LADX HMI can take a selection of analog tags, say forty transmitters, and propose hi, hi-hi, lo and lo-lo limits as a percentage of span with escalating priorities, with a preview before anything is written. Use that to get structure in place quickly, then rationalize. A percentage of span knows nothing about the process. Some of those forty points need only one alarm, and some need none at all.
Transform Your Alarm Management with ISA-18.2
International Society of Automation - ISA
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeTest alarms against the running logic
Alarm behavior usually gets its first real test at site, when the process upsets for the first time. That is late. In LADX HMI the runtime is the ladder simulator: press run, the logic solves, trends fill and alarms evaluate against the same tags the program writes. You can drive a level past its limit, watch the alarm raise after the on-delay, acknowledge it, confirm it stays active, and watch it return through the deadband. Trend recordings keep the minimum and maximum per interval, so a short spike is not averaged away.
Know the limits. LADX HMI does not talk to plant equipment: connection settings for OPC UA, Modbus TCP, EtherNet/IP or S7 are recorded for handover, not dialed. It does not produce a FactoryTalk View or WinCC project, because those are closed formats. It exports a single HTML file that runs the screens and logic in a browser. It is also not a historian. For the production SCADA choice, see our comparison of Ignition vs FactoryTalk View, and for screen design, our guide to high-performance HMI and ISA-101.
Next step
If your alarm list grew by accretion and operators have stopped reading it, start with the philosophy and a bad-actor report, then rationalize. Our controls engineering team designs HMI and SCADA alarm systems on Studio 5000, TIA Portal and Ignition projects, and LADX is available to in-house teams through our industrial AI service. Contact us with your alarm count and platform and we will suggest where to begin.
