POST 1 · ISA 18.2 SERIES

An Automated NSW Smart Solutions Guide

Publish Date: 04/30/2026

If you have worked with building automation systems for more than a few years, you have probably seen the same thing happen. Alarms get added during commissioning, operators start silencing them without reading them, and eventually nobody trusts the system to tell them anything useful. The alarm count grows over time, and the actual value of the system goes down.

ISA 18.2 was written to address this problem. Its core contribution is an alarm lifecycle model that treats alarm management as an ongoing engineering process, not a one-time setup task. This post introduces that model. The rest of the series builds on it.

What the Lifecycle Model Does

The standard defines ten stages that cover everything from initial planning through decommissioning. Each stage has defined inputs, outputs, and requirements. The idea is that no stage gets skipped, because skipping one creates a gap that usually shows up as a problem somewhere else down the line.

Here is a summary of all ten stages:

Alarm Lifecycle Loop

The alarm lifecycle loop, as its name implies, is not a straight line from start to finish. It includes feedback loops that correct the system over time. You are never “done” managing your alarm system.

Loop 1: Monitoring and Change

Monitoring data identifies alarms that are misbehaving due to programming, hardware, or any non-design issue. These alarms are adjusted by the facilities team.

Example: An air handler supply fan status alarms after it is started. Facilities engineers find that the fan is working correctly, but it does not indicate properly on the BMS due to a bad current transformer. The alarm is shelved until the sensor is adjusted, restoring the run indication and fixing the status alarm.

Loop 2: Monitoring and Management

This activity kicks off when monitoring finds that an alarm’s design does not align with the goals of the alarm system. The setpoint may be wrong, the priority may be off, or the alarm itself may not be worth responding to. A formal change is initiated, and the alarm works through the applicable lifecycle stages.

Example: An air handler supply fan status alarms momentarily after it is started. The detailed design for the alarm has a ‘time to alarm’ of 60 seconds in the spec, but the current alarm does not have that functionality. The facilities team initiates a formal change to the alarm. Once approved by management, a 60-second time delay is added to the alarm, aligning it with the alarm’s detailed design.

Loop 3: Audit and Alarming Goals

This loop is what keeps your alarm strategy in lock-step with how your facility operates. Periodic audits evaluate whether the lifecycle steps are actually being executed, and whether the “philosophy” document still reflects how the facility actually operates. Findings feed back into philosophy revisions, which then improve all downstream stages. This is how the alarm system improves over time rather than just degrading slowly.

Example: During an alarm audit, it is noted when an air handler supply fan start / stop status alarm turns on, the VFD trouble alarm also turns on. The detailed design states that all motors should have a start / stop status alarm, but this alarm condition is already covered by the VFD trouble alarm. A change is initiated to change the supply fan start / stop status alarm to an alert and update the detailed design with the exception.

Where to Start

Not every facility starts from scratch. The standard defines three valid entry points into the lifecycle:

• Alarm Philosophy: The right starting point for new systems. The philosophy gets written before any alarms are designed.
• Monitoring and Assessment: A practical starting point for existing systems with no philosophy. Measure what you have, then use that data to develop the philosophy and set priorities.
• Audit: An initial benchmark audit against the standard’s requirements. Results are used to build the philosophy and identify the highest-priority remediation work.

For most building automation facilities, starting with monitoring is the most realistic option. Years of alarm history already exist. Mining that data to find the worst performers gives the improvement effort concrete, defensible targets right away.

Why Building Automation Needs This

Building automation systems are not typically designed with alarm management in mind as a discipline. Alarms get configured during commissioning, adjusted informally over the years, and rarely reviewed in any systematic way. The result is alarm systems that have stopped doing their job.

The ISA 18.2 lifecycle provides a structure to fix that. It does not mandate specific technologies or setpoint values. It defines a management approach that keeps the alarm system useful throughout its service life.
The posts that follow cover each stage of the lifecycle in detail. This post establishes the framework that makes the rest of it coherent.

KEY TAKEAWAY

Alarm management is not a commissioning task. It is a lifecycle discipline. ISA 18.2 defines ten stages, three feedback loops, and three entry points that together form a repeatable framework for designing, operating, and improving an alarm system over time.

Are you experiencing alarm floods? Inaction by your operators? Or just don’t know where to start with your alarms?

Reach out for a free consultation, sales@automatednsw.com 

Next: Post 2 - What Actually Makes Something an Alarm (vs. an Alert) | ISA 18.2 Series for Building Automation Professionals