Design engineers need to step up how their specs sort out sequencing details.

Last month, this column addressed the timing of control system design at a very high level. This month, I would like to drill down a bit and discuss an aspect of control system design which has proven particularly challenging for commissioning — the documentation and integration of on-board equipment controllers.

More and more equipment is coming with its own factory-installed and programmed controllers. This can be true for boilers, chillers, rooftop units, makeup air units, heat pumps, etc. How these on-board controllers are integrated — or not — into the overall HVAC systems can demand an inordinate amount of commissioning attention.

One of the fundamental issues is the difficulty in obtaining detailed sequences of operations for the controllers from the manufacturer. That level of detail is not typically provided as part of a standard equipment submittal package. Once the documentation is provided as part of a re-submittal, it invariably comes in a generic format with multiple options defined. This requires at least one more re-submittal where the manufacturer identifies which options will be set-up/programmed for the current project.

Unfortunately, this level of review and re-review prior to ordering the equipment is not practical given most construction schedules, and equipment will be ordered with an understanding that the control system information will be ironed out later.

Later Can’t Wait

“Later” can easily be put off — regardless of commissioning efforts to expedite — until equipment startup when the start-up technician performs the actual setup/programming of the on-board controllers. This will be done based on the technician’s past experience, best intentions, and often-limited understanding of how the equipment fits into the bigger picture of the HVAC system.

After startup, the pursuit of documentation could be frantic as the overall system functional performance testing approaches and the commissioning professional has no customized controller information with which to develop final test procedures. Having the start-up technician write down exactly how a particular controller was programmed would be best but, again, proves to be a time-consuming challenge with mixed results. Having the commissioning professional witness every startup procedure and document all of the settings is another option, but is not typically part of a commissioning scope of services.

It is not unusual to begin functional testing without the project-customized equipment control sequences due to project schedule pressures. In this case, functional testing is the process by which the commissioning professional learns how the equipment works, not “testing” at all, but “investigation.” This takes more time in the field than performing a focused test of pre-defined sequences of operation. To be most effective, this also requires the participation of the start-up technician (or someone else fluent in the on-board controller and its programming) to demonstrate controller performance and interpret the often-cryptic user interface.

That’s the sad story of the construction phase. Why did I start there? Because we see almost no attempt at specifying, documenting, or coordinating on-board equipment controllers in the design phase.

Too Many or Not Enough

In the worst of cases, we see design specifications which call for on-board controllers in the individual equipment specification sections plus control points and sequences of operation for the same equipment in the DDC system specification section. At a minimum, I believe the design engineer is responsible for coordinating how each component of the HVAC system is to be controlled and ensuring there is neither duplication nor missing details.

Even when the controls responsibility is clearly defined between DDC and on-board controllers, there is almost always a scarcity of information regarding the on-board controller sequences of operation. Regardless of who is responsible for providing the control components and logic, I believe the design engineer is responsible for defining the expected operation. For on-board controllers, this means the effort spent understanding the capabilities of the manufacturer’s hardware and software should be expended in the design phase so that the engineer can specify which options are to be selected for the project.

If there is to be any interface between the on-board controllers and the DDC system, this also needs to be unambiguously defined in the design specification. Simply stating that the equipment controller shall “integrate with the DDC system” is not specific enough. The design needs to define which points are to be monitored by the DDC system, which alarms are to be sounded at the DDC system; what information the on-board controller should accept from the DDC system (setpoints, schedules, etc.), which on-board controller points should be displayed on the DDC system graphics, etc.

If we can all agree that the building owner is entitled to obtaining accurate, customized, and timely documentation of all aspects of the control system — including the details of the on-board equipment controllers — at the end of construction, I propose that it will be most efficient and effective to start that documentation in the design phase. Even if we need to pay design engineers more to do the communication and coordination with the equipment manufacturers, it is much better to have a clear set of contract documents than to try to accomplish all of the coordination and review during the construction and startup phases. ES