By Bill Gnerre and Kevin Fuller
In our previous article [appearing in the Facility Executive, December 2017 issue] about why today’s automation delivery process consistently yields inefficient buildings, we discussed how the industry’s current construction process produces sub-standard building efficiency. This is largely caused by insufficient automation software, which occurs because of how design engineering, controls contracting, and commissioning efforts do and don’t work together.
Let’s see where that leaves us. Your building is complete and you’ve taken occupancy, maybe a few months ago, a few years ago, or even longer. Are all the spaces in the building comfortable? Is the energy use at or below what it was designed to be? Is your maintenance load low, enabling staff to focus their efforts elsewhere? If you answered “yes” to all of these questions, keep doing what you’re doing. For most of you that had some “no” answers, we’ll try to give some guidance on how to resolve the automation issues that are at fault.
Dealing With Symptoms Gets You Nowhere
First, a little advice about what not to do. Our industry is enamored with detecting and prioritizing faults. If your building is well programmed, but older so most of the issues are mechanical in nature, this approach can work. But most buildings aren’t running well in the first place, or are too new to be having a lot of mechanical failures. Chasing symptoms only creates the illusion of progress. If you are constantly putting out fires, you’re not making your automation deficiencies go away.
Let’s look at some examples that show how inadequate automation can be found and fixed.
Did The Engineer’s Sequence Follow ASHRAE?
You put in a VAV system and have a variable frequency drive (VFD) on your fan, but it never varies, and static pressure is constantly high. To determine how it’s supposed to work, don’t start with the engineer’s sequences of operation (SOO), start with ASHRAE. Compare the ASHRAE standard to the engineer’s SOO. Using ASHRAE standards and guidelines as your evaluation criteria removes subjectivity. The right approach is no longer an opinion, but based on research and facts.
Shown below is an excerpt from ASHRAE 90.1 that describes how a static pressure reset should work. If the SOO doesn’t address static pressure reset at all, or if it does so in vague language such as “Fan speed shall vary to meet the needs of the zones,” then you have a design problem. However, if the SOO spells out the criteria for when to adjust the static pressure set point, how much it should be adjusted, how often conditions should be evaluated, when to alarm operators, etc., the problem isn’t the SOO, it’s in the implementation.
In either case, the end solution is the same—add a comprehensive reset program to the automation logic. Whether you must start with a new sequence or can go to the controls contractor depends on what your evaluation told you. Remember, when it comes to the SOO, vagueness is the enemy of proper automation.
Something Simple Can Easily be Overlooked
The above static pressure issue is easy to spot. Here’s an example of an often overlooked problem managing reheat. ASHRAE 90.1 says that supply air temperature into the space should not be more than 20°F higher than the space set point. Limiting VAV discharge air temperature prevents stratification of the air so the heat gets to the occupants and not the ceiling.
We find that this is frequently left out of the SOO by the engineer, and thus not implemented in the automation. It leads the behavior shown in Figure 1 below, which causes stratification.
While the static pressure example needs explicit instructions, this example can often be easily implemented, so long as the engineer’s sequence specifies the limit be there. One BAS vendor (see Figure 2) has built the function into the controller, so it is as simple as clicking the “Discharge Air Reset by Zone Control” button.
The Automation Code – Where it All Happens
BAS manufacturers have different programming approaches. Some are old-style line code, and some are object oriented. If most of your issues are in the automation code, the more you understand how that works, the better you can manage the building and remediation efforts.
Line Code Example
Line code as shown on the right is an older programming language, but perfectly capable of running any building. A big advantage to owners is that it’s very transparent. This short snippet deals with setting up operating modes, control ranges, economizer mode, and a decision tree regarding which mode is active.
While you may not understand the code itself, the comments are in plain English. They should explain what the code does, so if the comments don’t clearly communicate how the code works, then likely the programmer didn’t think through the logic. If you can follow the comments, then at least you have a good starting point.
Graphical/Logic Objects Example
This is a more modern programming language built using a visual language so that control engineers can build automation code without necessarily being software programmers. You don’t write and interpret text-based instructions, but build and follow graphical logic diagrams.
Most facilities personnel do not have the background or expertise in these languages, and why should they? If you don’t know how to read the code, then ask your control contractor to walk you through the logic that runs the building. In a couple of hours, you’ll know whether they fully understand how the building should run. If their explanation is satisfactory, then you have a chance to fix automation problems. But, if they don’t have an acceptable answer, then it’s time to step back and start with the design intent and the SOO.
If you can still talk to the design engineer, you should ask the same question. Then compare notes. If you’re not satisfied with either explanation, then likely you need to go back to the design intent. You may have to pay the for the time but it’s a worthwhile investment.
Automation Code Basis For Building Performance
Despite what ASHRAE says, or what the engineer’s SOO states, what runs the building is the automation code. It’s software. Never lose sight of that fact. It’s where you must make the fixes to achieve operational performance, equipment and calibration issues aside. To get automation back on course we recommend you check the following:
- Did the engineer’s SOO follow the ASHRAE standard?
- Was the engineer’s SOO specific and unambiguous?
- Did the control contractor meet the SOO?
- Can the control contractor and/or the design engineers explain how the automation is supposed to work?
- Review the automation code
This is far from a comprehensive list of what you can do if your existing buildings’ automation isn’t working properly, but these are the foundation elements of how the building is supposed to run. Operating buildings efficiently, for years, is not a hardware problem. It’s a software problem, and the industry need to place the automation software into a more prominent role.
Gnerre is CEO and co-founder of Waltham, MA-based Interval Data Systems, and he has overseen the company’s evolution from an EEMS software vendor, to an analytic services provider, to its current building automation software (BAS) service offering.
Fuller is executive vice president at Interval Data Systems, where he is responsible for product development, marketing, and program management for several of the firm’s largest customers. His current work is focused on getting BAS automation software correct, starting with design, through implementation, and ongoing operations.
