POST 2 · ISA 18.2 SERIES
An Automated NSW Smart Solutions Guide
Publish Date: 05/14/2026
The Three Qualifiers
Ask a group of facilities engineers or automation technicians to define an alarm and you will get different answers. Some will say it is any notification the system generates. Others will tie it to a setpoint being exceeded. A few might mention severity. Almost nobody mentions operator response.
ISA 18.2 is specific about this, and that specificity matters. The standard’s definition, applied consistently, eliminates a large percentage of what most building automation systems are currently treating as alarms.
Alarm: The Standard Definition

Three things must all be true for a notification to qualify as an alarm:
- It is directed to the operator. Not a log entry, not a trend alert, not an automated report. An active indication delivered to the person responsible for responding.
- It indicates a process deviation, abnormal condition, or equipment malfunction. The underlying condition must be genuinely outside normal operating parameters in a meaningful way.
- It requires a timely response. The operator must take a specific corrective action within a defined time window to prevent a defined consequence. This is the most important element, and the one most commonly missing from BAS configurations.
If a notification fails any one of these three criteria, it is not an alarm by definition. It may still have value, but it belongs in a different category.
Alert: A Different Category
The standard explicitly separates alarms from alerts:

Alerts are informational. They tell the operator something is worth watching. They do not require a specific corrective action within a specific time window. Alerts and alarms should be treated differently in system design, display prioritization, and operator training.
In practice, a large number of BAS notifications labeled as alarms are actually alerts. Some are neither, because they require no operator response at all.
Why Timely Response Is the Critical Criterion
The phrase “requiring a timely response” connects every alarm to two specific, documented values:
- A defined operator action: What specifically must the operator do when this alarm activates?
- An allowable response time: How long does the operator have to take that action before a defined consequence occurs?
If you cannot answer both questions for a given notification, that notification has not been properly configured as an alarm. It should not be in the alarm system in that role.
This requirement is the most practically disruptive part of the definition. It means that adding an alarm requires knowing in advance what the operator is supposed to do and what happens if they do not do it in time. Most informal alarm configuration practices do not come close to meeting this standard.
Some Common BAS Notifications Fail the Test
Applying the three-part definition to typical building automation notifications shows how many do not qualify as alarms. The table below gives some representative examples.

Two Problems This Definition Reveals
Applying this definition to an existing BAS usually turns up one or both of the following problems.
Over-alarming
Status points, informational notifications, and maintenance reminders are configured as alarms. This inflates alarm rates, conditions operators to ignore the alarm system, and buries the notifications that actually need attention. When everything is an alarm, nothing gets treated like one.
Alarms with no documented response
Some notifications do qualify as alarms but were configured without a documented operator action or an allowable response time. They cross a threshold but fail the response test. These alarms cannot be properly prioritized because priority is based on consequence severity and response time, and neither has been defined.
Both problems get addressed during rationalization, which is covered in Post 4. Rationalization is the formal process of applying the definition to every candidate alarm, documenting the operator action and consequence, and assigning priority and classification.
A Simple Filter for Right Now
Before rationalization is complete, two questions can help identify obvious non-alarms in an existing system:
- Question 1: What specific action is the operator supposed to take when this notification activates?
- Question 2: What is the consequence if that action is not taken within a specific amount of time?
If either question cannot be answered, or if the answer to the first question is nothing or call maintenance with no time constraint attached, the notification is a candidate for reclassification as an alert, a maintenance task, or removal from the alarm system.
This is not a substitute for rationalization. But applying this filter to the most frequent alarms in a system will usually identify the highest-impact targets for remediation quickly.

Next: Post 3 - Writing an Alarm Philosophy: Your System's Governing Document | ISA 18.2 Series for Building Automation Professionals
