QSE Logo

LetsTalk2015@QSEng.com
612.308.4716

Commissioning: Equipment Data Overload

It has been a year since I wrote about the difficulties associated with commissioning systems that include on-board equipment controllers in addition to a central building automation system (BAS). Equipment manufacturers are able to put more and more control functionality into their equipment in the factory, and this is desirable from a cost and efficiency perspective. What we are seeing, though, is the increased need for systems integration, something the typical design/construction process does not do well.

Years ago, with the advent of direct digital control for building systems, all elements of an HVAC system would have been monitored and controlled by a single central BAS. The central system was the keeper of all data associated with the system and had full control over how each device was manipulated. It was complicated but technically possible to coordinate (integrate) all of the HVAC devices (fans, pumps, dampers, valves, etc.) to work together.

For example, if one had a large building requiring multiple air handling systems, those systems could be controlled together to best meet the needs of the building. That might involve staging the air handlers on/off as loads changed. It might mean controlling all return air fan speeds from the same control signal to maintain a single building pressure setpoint.

Today, on most commercial and many institutional buildings, we are seeing rooftop air handling units (RTUs) that come from the factory as self-contained systems with all sensors, control devices, DDC panels, and control software already in place. Although these systems might do just fine in a stand-alone application (i.e., a building small and simple enough to require only one RTU), they are not coming from the factory with a robust ability to integrate with each other or with other building systems.

One area of improvement over the past decade has been significantly improved communication from stand-alone controllers. Manufacturers of RTUs, chillers, boilers, computer room air conditioning units, etc., are now offering the option of sharing all of their on-board controller information with the central building automation system. Central building automation systems and their programmers are also more adept at receiving and processing that data. Although this sounds great on the surface, it has not yet translated into better building systems integration or performance.

Receiving all of the data from the on-board controllers has created a data paralysis at the central automation system. What is the BAS supposed to do with the data? What is important? What should be alarmed? What should be displayed on the central computer graphics? These are questions that never needed to be answered before and, therefore, there is no process for a project team to deal with them.

It would be easy to say that the design engineers should clearly define all of this in the bid documents. However, without sole sourcing manufacturers of major HVAC equipment (which almost never happens), the design team does not know which manufacturers will be selected for installation. As such, they do not know the exact points available for integration or the manufacturer’s on-board control sequences of operation. It is impractical in today’s architectural/engineering market to expect the design team to create different control system specifications around every possible combination of equipment manufacturers for air handlers, boilers, chillers, etc.

Instead, I would like to suggest that the design engineers define the equipment control points they think are important to be shared with the central automation system. The specification can be written such that those points are required from the on-board equipment controller, regardless of what other points might be available. If a piece of equipment cannot provide that minimum list of shared points, it would not be an acceptable product.

One key to successfully integrating an on-board equipment controller with the building automation system (BAS) is to specify the requirements in both sections of the bid documents, i.e., in the equipment specification section and in the BAS specification section. If the equipment manufacturer is clear on what points need to be shared and the BAS contractor is clear that those points will be coming to the central system from the equipment, that is a first step towards good integration.

Similarly, if the BAS is to provide any commands to the equipment controller, those need to be clearly defined in both sections. Typical commands from the BAS to on-board controllers tend to be of the “setpoint” and “mode” type. For example, the BAS may provide the supply water temperature setpoint for a boiler or an occupied/unoccupied mode signal for a rooftop unit.

The design engineers can then move on in the BAS specification to define exactly what the BAS is to do with the data coming from the equipment and how it will determine what signals to send back to the equipment controllers. In addition to incorporating these shared points into the customized sequence of operation, the design engineer should make it clear which (if not all) of them need to be displayed in the BAS graphical user interface and not simply buried in the BAS database.

  

Commissioning: Getting It Right

Engineered Systems, July 2012

by
Rebecca Ellis, PE, LEED AP BD+C, CCP, CPMP, CxA
President
Questions & Solutions Engineering
1079 Falls Curve
Chaska, MN  55318
rteesmag@QSEng.com