By Bill Gnerre and Kevin Fuller
From the December 2017 Issue
The occupancy permit has been issued, and you move into your brand new building. Just a few weeks in, and the maintenance staff is already chasing complaints that spaces are too hot or too cold. They complain that the building’s control system isn’t working right and needs to be straightened out. A month goes by, and the first utility bills arrive, “Yikes, we’re using way more energy than we expected!” Does any of that sound familiar?
Facility management groups are constantly tinkering, trying to get their buildings to operate in an efficient, consistent, and predictable manner. Just when they think they might have things stabilized, the weather changes and they are off again on the quixotic quest to get the building under control. Why is it that with all the advanced technology available today that new buildings still have all the efficiency and operational problems that are commonplace?
We’ll try to answer that question and explain why today’s design engineering, controls installation, and commissioning processes predictably deliver inefficient building automation — the root cause of most operational problems in new construction. Inadequate automation quality is the product of three vendors: design engineers who write sequences of operation that provide the specification for how the building automation software must work; control contractors who are contracted to implement the engineering specs; and commissioning providers who perform functional tests on the automation that cannot possibly validate 24×365 operation.
Meanwhile, all vendors are under pressure to get the building’s occupancy permit, including the owner. In short, the industry’s long-established process used for the specification, implementation, and verification of HVAC automation cannot produce a quality result.
Let’s look at some of the underlying business realities driving the behaviors of design engineers, control contractors, commissioning authorities, and building owners.
The design engineering community varies widely in the way it documents the sequences of operation (SOO). Some are quite exacting, with long detailed instructions, while others cut and paste from prior work and leave it up to the control contractors to sort out the details. SOO are a set of instructions for control system programmers to create the automation code that runs the building. Vague instructions result in poor quality automation; highly detailed instructions may or may not result in good quality automation.
One thing is unavoidable. The design engineer is responsible for how the building is defined to operate. However, the current process doesn’t give them any control over the outcome, and they receive little or no feedback on how their buildings actually perform, which limits what they can learn from prior projects.
One would assume it’s in the best interest of the control companies to deliver well-programmed buildings, however, their business realities can conflict with that goal. If the control contractor receives a SOO that lacks specificity or specifies dated, inferior sequences, what should they do? Fill in missing information or submit a request for improved sequences? Their business reality is meeting specifications while staying within budget. Profit is a function of time, so fewer hours means more profit.
But delivering inadequate building automation code isn’t all on the design engineer. We frequently see buildings where the SOO was clear, but simply not implemented as specified. The same functions can be implemented differently if different technicians did the work, which can cause the overall system to not work as designed. Code often doesn’t handle seasonal changes well and lacks resiliency to equipment failure.
We acknowledge that control contractors are usually under very demanding installation time constraints and have dependencies on other vendors, such as electricians, plumbers, mechanical contractors, etc. Given their reality, it’s impressive that they get the system installed at all, but it is also a reality that it costs the same to deliver good software as to deliver subpar software.
Commissioning agents are also limited by contract to provide certain defined services. While many commissioning agents provide design review and feedback, there’s little feedback on what the engineer didn’t provide. Whether that’s a level of detail, or an entire sequence, it’s always harder to identify and document what is missing. Yet, it’s that missing information that often leads to gaps in the automation.
Relative to the acceptance phase of commissioning, the functional tests are very different than 24×365 operation. This is an important step in verifying the control system programming, but it’s not a proxy for confirming full load, year-round operation. It’s also not a proxy for looking at the actual automation code. In certain cases, it’s easier (i.e. faster and cheaper) to identify logic problems in the code than to devise and execute a sequence test and evaluate the data.
The building owners have a role in this scenario as well. Slipping the occupancy date is often impossible, and buildings are too often accepted as substantially complete before commissioning is finished. But it’s more complicated than just the time crunch to take occupancy.
We recently polled a roomful of owners, each with large portfolios, asking how many had built a new facility within the last couple of years. Nearly everyone raised their hand. We then asked how many of those operated as efficiently as expected and with minimal operational problems. Not only did all hands go down, but just the idea drew a notable amount of laughter.
The point being, owner expectations are low. They cannot imagine what it would be like to have building automation that works smoothly. They have not been given the tools in the form of data and contract terms—nor do they have the background—to demand and enforce a better result.
Building Automation: Long-Term Impact
Well-programmed automation costs less to run than poorly programmed automation. Automation directly affects various costs throughout the 20 to 30 year life of the control system:
- Energy costs
- Maintenance costs
- Equipment life
- Energy services costs
We built a 20-year financial model with differential costs between each of these categories that compares the cost of good automation compared with what is typically delivered today. The value of getting the automation right is crystal clear. For example, the added cost on a 70,000 square foot college building to get the automation right is less than 0.3% of construction costs. If we just consider the impact on energy costs, the simple payback is well below two years. If we include all the cost areas and calculate a net present value to represent a more complete total cost of ownership picture, the payback can be measured in weeks.
The industry must admit there’s a systemic problem that’s been around for a long time. Is there a grand conspiracy to pull the wool over the eyes of the building owners? No. Rather, it’s a collection of siloed disciplines, each optimizing their own business. The concept that the building’s automation must run precisely has not existed among any of the vendors involved, or the owner for that matter.
One bright spot we see is ASHRAE’s pending Guideline 36P, High Performance Sequences of Operation for HVAC Systems, which we hope will have a significant impact over time. Guideline 36P not only provides guidance to the design engineer to create excellent sequences, it offers a standardization and consistency that can be applied across all buildings, and implementation instructions that controls contracts can use.
In the future, the ASHRAE 36P guideline could be expected to also address performance testing, giving commissioning agents an industry standard of excellence to evaluate how the sequences of operation actually function.
With all the talk about saving energy, climate change, and alternative energy in the buildings industry, it’s time for the stakeholders to apply science and engineering to the way buildings run. It’s time to realize that running a building is a software problem and not a hardware problem. It’s time that the automation code reaches current standards for software development.
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.
Editor’s Note: Read the follow-up article from Gnerre and Fuller here on FacilityExecutive.com.
Do you have a comment? Share your thoughts in the Comments section below or send an e-mail to the Editor at firstname.lastname@example.org