Alarm management in building automation

In many buildings, the alarm screen on the building automation system (BAS) shows hundreds of active alarms. Most are old, irrelevant or repeating, and operators have learned to ignore them. The danger is that a genuinely important alarm, such as a freezestat trip, a failed exhaust fan in a laboratory or a high temperature in a server room, gets lost in the noise.

Alarm management is the discipline of making sure every alarm means something and that the right person responds to it in time. The process industries have formal standards for this, including ISA-18.2 and EEMUA 191. Buildings rarely need that level of formality, but the same principles apply and can dramatically improve how a facility runs.

What an alarm should be

A useful working definition: an alarm is a notification that requires an operator to take action within a defined time. If no action is needed, it is not an alarm. It might be an event to log, a status message or a maintenance notice, but it should not compete for attention with conditions that need a response.

Every configured alarm should be able to answer four questions:

1. What condition does it indicate?
2. What is the consequence if nobody responds?
3. What action should the operator take?
4. How quickly must that happen?

If those answers are unclear, the alarm needs to be redesigned or removed.

Common causes of alarm floods

• Default alarms left enabled. Controllers often ship with alarms on every point, which contractors leave in place.
• Limits too tight. A space temperature alarm at 1 K from setpoint will trigger every time the system recovers from setback.
• No delays. Alarms fire on momentary excursions during start-up, changeover or sensor noise.
• Alarms in unoccupied modes. Temperature alarms trigger at night when setpoints are intentionally relaxed.
• Cascading alarms. A single failure, such as an AHU fan trip, generates dozens of downstream zone temperature and airflow alarms.
• Chattering. An alarm repeatedly clears and returns because there is no deadband.
• Stale alarms. Alarms for equipment removed years ago, or faults nobody is going to fix, remain active indefinitely.

Alarm priority levels

A clear priority scheme helps operators decide what to do first. A three or four level structure works well for most buildings.

Many low-priority items are better handled by fault detection and diagnostics or the maintenance management system than by the BAS alarm screen.

BACnet supports this structure through notification classes, which define priority, acknowledgement requirements and recipients for groups of alarms. Using notification classes consistently makes alarm routing much easier to maintain.

Rationalizing an existing alarm system

Alarm rationalization is a structured review of every configured alarm. A practical process for an existing building:

1. Export the alarm configuration and history. Identify the most frequent alarms over the last few months. Often a small number of points produce most of the alarm volume.
2. Fix or remove the worst offenders first. Correct the cause, adjust limits, add delays or disable alarms that serve no purpose.
3. Review every remaining alarm against the four questions above. Assign a priority, a response and a responsible party.
4. Add conditional logic. Suppress zone alarms when the serving AHU is off or in unoccupied mode, and suppress downstream alarms when the upstream equipment has already alarmed.
5. Set deadbands and delays. For example, a space temperature alarm might require a sustained deviation of several kelvin for 15 to 30 minutes in occupied mode.
6. Define routing. Decide who receives each priority, during and outside working hours, and how: BAS workstation, email, text message or a monitoring service.
7. Document the result in an alarm schedule that forms part of the operations and maintenance documentation.
8. Monitor and repeat. Review alarm counts monthly and revisit the configuration whenever systems change.

Designing alarms on new projects

On new construction, alarms should be specified rather than left to the contractor. The controls specification or the sequences of operation should include an alarm schedule listing each alarm, its limit, delay, priority, conditions for suppression and notification recipients.

During commissioning, critical alarms should be tested end to end. That means creating the alarm condition, confirming it appears at the workstation with the correct priority and text, confirming that remote notifications reach the right people, and confirming it clears properly. Life-safety related alarms, such as those associated with smoke control or laboratory exhaust, often need coordination with the fire alarm system and may be subject to integrated testing requirements.

Writing good alarm messages

An alarm message should tell the operator what is wrong and where, in plain language. Compare:

• Poor: "AHU3_SAT_HI"
• Better: "AHU-3 (Level 2 east) supply air temperature high: 18.5 C, setpoint 13 C. Check chilled water valve and supply."

Include equipment name, location, measured value, limit and a short suggested action where possible.

Measuring alarm system performance

Simple metrics help keep alarms under control:

• Number of alarms per day, and per operator.
• Number of standing alarms that have been active for more than a set period.
• The top ten most frequent alarms each month.
• Average time to acknowledge critical and high priority alarms.

The process industry guidance suggests that an operator can reliably handle only a modest number of alarms per hour. The exact target matters less than the trend: alarm counts should fall after rationalization and stay low.

Frequently asked questions

Should every sensor have an alarm?

No. Alarm only on conditions where an operator needs to act. Sensor failures are worth flagging, but usually at low priority unless the sensor is critical to safety or a critical space.

Who should own the alarm configuration?

The building owner or facility manager should own the alarm schedule, with changes made by the controls contractor under a documented process. That prevents gradual drift back to an alarm flood.

Key takeaways

• An alarm should require an operator to take action within a defined time; anything else belongs in a log or maintenance system.
• Most alarm floods come from defaults, tight limits, missing delays and cascading alarms.
• Use a clear priority scheme with defined responses and routing for each level.
• Rationalize existing alarms by tackling the most frequent first, then reviewing every alarm systematically.
• Specify alarms on new projects and test critical alarms end to end during building commissioning.