This circumstance often results in vast relief from the design engineers because their review of the submittal’s sequences of operation is reduced to a spot check of the copy/paste function. For the commissioning professional, this circumstance should raise a red flag. Why is a seemingly “perfect” controls submittal potentially dangerous? One or more of the following may apply:

• The controls contractor hasn’t given any thought to the specified sequences and what it will take to implement them.
• The contractor may not have seen or programmed anything so complicated before.
• The contractor’s product-specific software and hardware may preclude programming exactly as defined in the specification.
• The contractor has standard ways of doing things differently from the design, and the plan is to “meet the intent” of the design sequence of operation but not necessarily in the specified manner.
• Contractor may put in “extras” over and above the specified sequences as part of their standard programming.

The first two bullets should make anyone anxious about the control system’s potential outcome. The remaining bullets are not necessarily bad, but they represent missing communication.

It is absolutely critical for a smooth functional performance testing process that the control submittal reflect the contractor’s intended sequence of operations programming. This is almost never exactly as specified by the designers.

The timing of this conversation and coordination with the controls contractor is challenging. The controls submittal is invariably reviewed early in the construction phase. This can be months, if not years, before the controls need to be programmed, started up, and commissioned. The controls contractor is not realistically in a position to assign a programmer to the job, and the project engineer and/or project manager who compile the submittal do not necessarily know how the sequences will be programmed in the end.

Discussing the details of how certain sequences will actually be implemented without the programmer involved is inefficient at best and totally ineffective at worst. I propose that “review and approval” of the sequences of operation section of the controls submittal be postponed until the controls contractor commits to a specific programmer who can sit at the table during controls integration meetings to explain his/her approach to and logic for the specified sequences. That information needs to be documented in writing for official approval by the designers and for the controls as-built documents relied on so heavily by future operators.

 The commissioning functional performance test procedures should be based on the approved programming sequences. Developing test procedures based on the specified sequences of operation will result in time-consuming functional testing delays while the controls technician explains to the commissioning professional how the programming differs from the design. The “how will it really be controlled/programmed?” conversation should occur before test procedure development and field testing.