Related Articles

 

North Central College: A Leader in Solar PV Arrays Among Small Colleges - This past October, North Central College moved forward on...

 

From Old to New: VRF Improving the College Campus - A proven HVAC technology worldwide, Variable Refrigerant...

 

Archives > November 2014 > Making the Most of Your Building Automation System Tools

Making the Most of Your Building Automation System Tools

Microsoft CEO Steve Ballmer once indicated that most software users only use about 20% of a program's features. This seems to be a common adage within the IT industry, although pessimists insist the 20% figure is too high. My experience with Building Automation Systems (BAS) makes me side with the pessimists.

By: Steve Tom

Most systems offer a wealth of features that are seldom used to their full potential. This is especially true when it comes to detecting and troubleshooting problems with mechanical equipment that are wasting energy and making people uncomfortable. A New Buildings Institute study found over half the building systems they studied had serious faults, and the Department of Energy estimates proper Fault Detection and Diagnostics (FDD) could cut facility energy use by 15%. Facility managers recognize the importance of these problems, and a host of third party analytics programs are coming into the market to meet this need, but I worry these new programs will be just as underutilized as the BAS they’re using as their data source. In this article I will offer a few suggestions as to how facility managers can use common BAS tools, specifically Alarms, Trends, Reports, and Video, to find and diagnose problems.

Alarms are probably the most misused feature in a BAS. People don’t even complain about them anymore. They just ignore them. The problem is that there are way too many false alarms. As an industry, we created alarms that were easy to implement rather than alarms that were meaningful to the user. My “rules” for creating useful alarms are:

1. Only alarm conditions you care about: If you’re not going to respond, it shouldn’t be an alarm. I’ve met building operators who routinely ignore all room temperature alarms, assuming that if it’s bad enough the occupants will call to complain. While that’s not my approach, for those users it makes no sense to generate alarms when a room is too hot or too cold because that will only clutter the Alarm page and make them more likely to miss an important alarm. To cite a different example, some users really like alarms on air handling unit (AHU) filters. The alarms can be based upon runtime hours or on pressure drop across the filter, but it tells the maintenance crew that the filter needs to be changed. Other maintenance staffs schedule recurring maintenance on a building-by-building basis and will not send a technician out to change a single filter. They’ll send a team to the building, say, once every six months to service all the AHUs in a building, including changing the filters. For these people, filter alarms are useless.

2. Minimize Single Condition Alarms: There are a few situations in a building, such as smoke in a return air duct, where a single condition warrants an alarm. Most HVAC situations aren’t that simple. One of the reasons many people ignore room temperature alarms is because they’re often based on a single condition, such as “Alarm if temperature > 80 °F.” In general, I don’t care if a room is over 80 °F on a weekend, when there’s nobody in the building. Even during the week, I’d want to know (a) Is the room occupied? (b) Has the HVAC been running long enough that the room should be cooler? (c) Is 80 °F well above setpoint? (d) Has the setpoint just been changed? And (e) has the room been this warm for a while, or is this just a transient condition? (Like when somebody opens a door during the summer and a gust of hot air hits the sensor.) Adding enabling conditions like this to your alarm logic eliminates many false alarms and lets you focus on situations that really do indicate a problem.

 
  Figure 1: Temperature leaving the cooling coil (yellow line, top) drops when stages 1, 3, and 4 turn on, but there is no drop when stage 2 turns on.

3. Block Cascading Alarms: Sometimes a single mechanical failure can cause problems in many different parts of a building. For example, if a cooling coil goes bad in an AHU, every room supplied by that AHU is going to get hot. That could cause dozens or alarms, when the only alarm you really care about is the one that says the AHU is broken. A problem with a campus chiller plant can generate hundreds of “This room is too hot!” alarms across a campus. Hidden amidst those hundreds of alarms is the one alarm that tells you what you really need to know. Since you know in advance that a chiller problem will affect hundreds of rooms, you need to program your alarm logic to block all “hot room” alarms when there’s a problem with the chiller plant. Similar logic can prevent nuisance alarms when there’s a problem with a heating system, the fan in an AHU, or any other situation where one piece of equipment affects many rooms.

4. Better late than false: You need to know about life/safety problems immediately. Smoke alarms, flame detectors, freezestats, and similar problems should be reported without delay. Most HVAC problems are not that critical. With FDD, your goal is to find equipment that is not operating  properly. Sometimes the conditions that indicate failure are difficult to pin down. When a cooling coil turns on, the air should get cooler. How much cooler? How soon? It’s tough to say exactly. What if a blast of hot air enters the duct when the coil turns on? The temperature may rise even though the coil is working. One thing you do know, however, is that if the coil is well and truly broken, it will fail every time it turns on. If your logic only generates an alarm if the coil fails, say, 7 out of 10 times, you can be pretty sure an alarm means the coil really is broken. This is illustrated in Figure 1.

While trends can be used to spot problems, they are more often useful to verify and diagnose problems. The cooling coil trend graph already shown as Figure 1 is one such example. It clearly shows that Stage 2 is not functioning correctly. However, life is too short to spend it peering at trend graphs to see if problems exist. It’s more useful to use alarms to alert you to potential problems, and then use trends to see what’s happening in more detail. As with Alarms, there are some general “rules” for trends that make them more useful:

1. Single value trends are almost useless: Using Figure 1 as an example, a trend of the discharge air temperature (the yellow line in the top graph) wouldn’t be very useful if it wasn’t combined with the lower trend lines that show when each cooling stage turned on. As a minimum, you should display the setpoint for all controlled values along with that value. That way you can see what the value was supposed to be and what it actually was. Displaying trends of other values that affect the performance (like the on/off status of the cooling stages in Figure 1) provides additional insight.

 
  Figure 2: VAV Box reheating valve performance - normal.

2. Copy useful trend groupings to all similar equipment: Once you’ve configured a trend graph to provide useful information, copy it to all similar equipment. For example, when taking a “first look” at a VAV box, I like to see graphs of the room temperature compared to the heating and cooling setpoints, along with a companion graph that shows the actual airflow and the airflow setpoint. By copying standard graphs to all similar equipment, if you suspect a problem in one piece of equipment you can easily compare it to the same set of points in equipment that is working properly. Figures 2 and 3 show the same set of trend points evaluating the reheat coils on two identical VAV boxes. In Figure 2 the coil is working properly. The top trend shows the actual flow (yellow) follows the setpoint (blue) very closely. The next trend down shows the discharge temperature from the box (yellow) is virtually the same as the supply air coming from the air handling unit (blue). This is as it should be, as the next trend down shows the reheat valve was commanded “OFF” during the entire period. The bottom trend shows the boiler and hot water pumps supplying the VAV box cycled on and off twice during the day. Compare this to the trends in Figure 3. This was an identical box in the same building on the same day. The airflow looks similar and the heating valve was commanded “OFF,” but the discharge temperature shot up every time the hot water system turned on. Clearly this valve is not closing completely. An alarm alerted us to a potential problem with this box, and having two identical graphs to compare made it very clear what was happening.

 
  Figure 3: VAV box with heating valve not closing completely.

3. Consider using scatter plots: Not all BAS systems offer scatter plots, but if your system includes them they can be a very useful tool for analyzing some systems. Figure 4 shows a scatter plot of the electrical demand (kW) vs the cooling load (tons) for two identical chillers. Performance of the two chillers was similar enough that looking at the data on any individual day would not have revealed a problem, but the scatter plot clearly shows that Chiller 1 consistently required more power than Chiller 2 for the same cooling load. Additional troubleshooting (including more trends) eventually uncovered a misconfigured sensor controlling Chiller 1’s cooling tower.

Many building automation systems include reporting packages, often including a number of built-in reports. These can be very valuable for troubleshooting. It is a good idea, for example, to periodically run a report to search for all “locked points” in a system. There are many valid reasons for a technician to lock a point during start-up, commissioning, troubleshooting, as a work-around for a failed sensor. These are all reasons to temporarily lock a point, but it is all too common for people to forget to unlock the point after the need for the lock has passed. Reports with a graphic interface can be especially useful for troubleshooting, as they allow you to evaluate a large amount of data at a glance. The “Environmental Index” report summarizes the comfort conditions in all zones supplied by a specific air handling unit over a 24 hour period. A detailed discussion of the impact comfort has on productivity, student learning, absenteeism, and other personnel issues is beyond the scope of this article, but suffice it to say that the cost of not providing a comfortable environment can easily dwarf your entire energy budget.

 
  Figure 4: kW vs Cooling Load for two identical chillers.

Video is a new BAS tool which is proving to be very useful in troubleshooting. Early versions of this tool were developed by users who used screen capture programs to “film” a BAS graphic over a period of time and then play it back at a higher speed so they could see in a few minutes what happened overnight or over a weekend. Now some BAS systems provide this as a built-in tool which allows users to view any graphic, pick a time period of interest, and view it in high speed or step through it. While it’s not possible to properly illustrate this in a written article, it makes an ideal tool to spot scheduling problems, rooms that are being unnecessarily heated or cooled when the building is unoccupied, morning start-up problems, or to step through a sequence of events that caused a problem.

To summarize, building automation systems can provide a wealth of information about your buildings. Tools such as alarming, trending, reporting, and video playback can help you manage your buildings to save energy while providing a healthy, comfortable environment for students and faculty. A tool is only useful if it’s used, however. The intent of this article has been to offer suggestions as to how you can make better use of the tools you already have.

 

 

About The Author
Steve Tom

,PE, PhD, is the Director of Technical Information at Automated Logic. He has more than 30 years of experience working with HVAC systems. At ALC Steve has coordinated the training, documentation, and technical support programs, and frequently works with the R&D engineers on product requirements and usability.

 

 

 

 

PUPN Magazine is a trademark of Flaherty Media, LLC, copyright 2017. PUPN Magazine and all contents are properties of Flaherty Media, LLC.