Inappropriately Configured Alarm Conditions

April’s column kicked off a series that dove deep into the concept of building automation system (BAS) alarms. That series was supposed to end last month, but in the process of writing those articles, I realized I have more to say on the topic. So here is my victory lap!

BAS alarms are intended to notify building operators when something isn’t right with the systems they control. Investigations into such alarms can take various levels of effort, depending on one’s familiarity with the system. Regardless, no one likes wasting their time on alarms that turn out to be red herrings. Often, the condition that generates the alarm was incorrect to begin with! Inappropriately configured alarm conditions are commonplace, and they generate inefficiencies in building operations by wasting operators’ time and energy. Below are three examples of common, inappropriately configured alarm conditions.

Common Examples

1. Chiller Failure Alarm:

Integration from a chiller onto a BAS typically includes the BAS enabling/disabling the chiller. When enabled, the chiller’s onboard controller then executes the logic for controlling all the integral components of the chiller. The BAS often monitors chiller status as well. If the chiller is enabled by the BAS but fails to run, it would seem to make sense to alarm such a scenario on the BAS for the building operator to investigate. It would be common for such an alarm to be specified, and programmed, to be generated on a mismatch between command and status (i.e., an alarm would be generated if the chiller was enabled, but status was not proven for a period of time). However, configuring the alarm this way may lead to nuisance alarms. If the chiller does not have adequate turndown, its onboard controller may intentionally be cycling the unit on and off during periods of low cooling load. During each off cycle, chiller status would be lost and an alarm would be generated. Receiving an alarm during each off cycle will prove to be a nuisance.

This example highlights the difference between a Start/Stop command and an Enable/Disable command. Such terms are often used interchangeably, but there is a difference. Both are binary outputs sent from a BAS to a piece of equipment. The Start/Stop command would expect to have the equipment turn and off accordingly, an example would be the command sent to an exhaust fan. The Enable/Disable command point is a permissive command, telling the equipment it is allowed to run should its onboard controller determined it is needed and it safe to do so. Understanding this concept can help prevent the inappropriate configuration of alarms when an Enable/Disable command is being utilized.

In the case of the chiller failure alarm, it would be best to configure an alarm that monitors the chiller’s general alarm point that its onboard controller would generate in the case of an issue with the chiller. Additionally, one could alarm when the chilled water supply temperature rises above a high limit threshold for a period of time (just don’t forget to suppress when the system is disabled or immediately after it is started¹).

2. Low Flow Alarms:

Full integration of a large piece of equipment onto the BAS by communicating with the onboard controller over the BAS network provides a lot of information to the BAS. But with such opportunity comes nuances that may plague us. Onboard controllers for equipment like chillers, boilers, and packaged steam-to-hot-water heat exchangers, often have an integral flow switch that must prove adequate flow prior to allowing the equipment to run. It is common for these onboard controllers to broadcast a no-flow alarm anytime those flow switches fail to prove, even if the equipment is currently disabled. If the BAS is configured to monitor that networked alarm point, and then push an alarm notification to the building operator when it’s triggering, that building operator may receive a nuisance alarm when the equipment is disabled.

If a no-flow alarm is specified to be generated on the BAS, it is best the BAS monitor the networked alarm point from the onboard controller, but only trigger an alarm notification for the building operator if that point is in alarm (i.e., the flow switch is not proving flow) and the equipment has been enabled for a period of time. This may sound cumbersome, but I have seen numerous pieces of equipment, from different manufacturers, whose onboard controllers do not suppress no-flow alarms when the equipment is disabled.

3. High Humidity Switches:

Humidifiers located in ducted air systems often have an associated high-humidity switch located downstream of them. These switches are often hardwired to disable the humidifier in the event the humidity in the duct exceeds an adjustable threshold (see Figure 1). This is to prevent saturating the supply duct. See Figure 2 for a controls diagram of a make-up air unit utilizing such a switch.

The high-humidity switch can also be monitored by the BAS by use of a binary input to the BAS controller. With the additional information comes opportunity. Now, the building operator can use this switch to identify if something is going wrong with the humidifier. It is common for such an alarm notification to be specified, and programmed, to be generated anytime that switch triggers. This would be another example of an inappropriately configured alarm condition. Why? Because there are times when it is expected this switch should trigger under normal operating conditions. For example, if it is very hot and humid outside, the cooling valve in Figure 2 may be modulating to maintain a supply air temperature of approximately 55°F and the humidifier would be off. If the dewpoint of the entering air is above 55°F, then the leaving air will be quite saturated, often to a relative humidity value above that of the switch’s setting. In such instances, the high humidity switch will trigger, but do we really want an alarm in such a case? No, we don’t, we only want a high humidity alarm when the system suspects faulty humidifier operation.

If a high-humidity alarm is specified, then an appropriate alarming condition would be if the high-humidity switch triggers while humidifier was enabled. And to be clear, there should not be an alarm delay on this one.

Another way to do this would be to issue an alarm if the cooling valve was closed and the high-humidity switch triggered. This may allow for the system to identify a leaking humidifier valve, but it may also result in nuisance trips during certain ambient conditions (e.g., 53°F and 100% relative humidity).

Conclusion

Commissioning providers can bring value to the owner by critically thinking through the specified and programmed alarm conditions. Identifying shortcomings in the logic that will produce nuisance alarms is just the first step. Ensuring those shortcomings are addressed is the next step, as there is no sense in someone else wasting time discovering this shortcoming for themselves sometime in the future.