Software vs. Hardwired Interlocks: Part I

The devil is in the details. This especially runs true when it comes to the automation of HVAC systems. The slightest nuances, if misunderstood, can have devastating effects. One prime example is the importance of understanding the difference between software and hardwired interlocks.

Definitions

An interlock is a dependency between two processes. Process 2 cannot operate unless Process 1 is in a certain state. For example, if a supply air duct static safety switch triggers (Process 1), the air handling unit is disabled (Process 2). If hot water flow is not proven through a steam-to-hot water heat exchanger (Process 1), then the control loop which modulates the steam control valve (Process 2) will be disabled and the valve will remain closed.

Interlocks are everywhere in control systems. The nuances exist in how such interlocks between processes are carried out. Hardwired interlocks have an electrical relay which informs Process 2 of what is happening with Process 1. For example, if a duct static safety switch triggers, it will close an electrical contact, which will energize a relay, which will in turn kill power to the AHU’s supply and return fans.

Software interlocks incorporate a microprocessor (e.g. a direct digital controller) into the mix, which has to first identify what is happening with Process 1, make a decision, and send a signal to manipulate Process 2.

Confusing the Two Approaches

There are pros and cons to both kinds of interlocks. Hardwired interlocks are regarded as more reliable and are easier to troubleshoot, but they are limited in nature to binary processes and are generally more costly to implement. Software interlocks require the programming of the interlock to be correct and the microprocessor to be functional, which leaves more room for error, but they also provide more flexibility both during initial install and in future modifications to the system.

Issues often occur when there is confusion for how interlocks between processes are to be carried out. In my experience, the root causes of such issues include:

• Lack of detail, or discrepancies within the design documents.
• Lack of communication between the electrician and the controls programmer, though they are typically both employed by the temperature controls contractor.
• Lack of understanding of the concepts by many in the industry.

Below, as well as in next month’s column, I provide examples of where confusion between the concepts of software interlock and hardwired interlock has tripped up project teams.

Example 1: AHU Freezestat Response

Several years ago, our firm was called in to opine on a dispute between a building owner and temperature controls contractor. The building had recently undergone a control system upgrade, but during the first cold snap of the winter, an AHU’s cooling coil froze and created nearly $20,000 in damage.

Prior to the control system upgrade, the existing, antiquated control system had gone dark. No existing programming, setpoints or other data could be extracted from it. The temperature controls contractor was contracted to install all new direct digital controllers, but retain all existing sensors, controlled devices and associated wiring unless if they were found to be inoperable. They were to program the new controllers to the original sequences of operation found in the original control system’s as-built shop drawings. All figures shown in this article are excerpts from the original control system’s as-built shop drawings, as they were the blueprint for which the contractor performing the control systems upgrade was to work off of. The controls diagram of the AHU in question is shown in Figure 1.

Figure 1: AHU control system diagram. (Excerpt from original control system’s as-built shop drawings, which were to serve as the blueprint for the contractor performing the control system upgrade to work off of).

Investigation into the frozen coil incident revealed that when the freezestat (FS-1) had tripped, the AHU’s Supply Fan had disabled. The issue was that even though the Supply Fan disabled, the Minimum Outdoor Air Damper remained open and the Intake Fan in the outdoor air duct continued to run, blowing cold outdoor air onto the cooling coil until eventually it ruptured.

Figure 2: AHU sequence of operation. (Excerpt from original control system’s as-built shop drawings, which were to serve as the blueprint for the contractor performing the control system upgrade to work off of).

The as-built sequence of operation for the AHU is shown in Figure 2, with key sections of interest to this issue highlighted in blue. These highlighted sections, coupled with the fact that the Intake Fan did not have a separate binary output command from the BAS controller, can be paraphrased in laymen’s terms as follows.

• Interlock 1: The operation of the Intake Fan will not occur until the Minimum Outdoor Air Damper Position is proven open.
• Interlock 2: The Minimum Outdoor Air Damper will not be commanded open unless Supply Fan status is proven to be on.
• Interlock 3: The Supply Fan will not be allowed to operate if the low limit thermostat (aka Freezestat FS-1) is triggered.

The questions become, how were these three interlocks to be carried out (i.e. software or hardwired) and what went wrong during the control systems upgrade?

• Interlock 1 was intended to be a hardwired interlock. This is clear through the yellow highlighted note in the controls diagram (Figure 1) as well as in the yellow highlighted circuitry in Figure 3.
• Interlock 2 was not specified to be a software interlock, but that is clearly the only option when there is no wiring shown for a hardwired interlock in Figure 3 which would interrupt the BAS command to the damper (see blue highlighted circuitry).
• Interlock 3 was intended to be a hardwired interlock, as you can see in the wiring diagram (green highlighted circuity of Figure 3).

It turned out Interlock 2, the software interlock which prevents the Minimum Outdoor Air Damper from opening if Supply Fan status is not proven, was not programmed. When the freezestat triggered, the Supply Fan disabled, but the Minimum Outdoor Air Damper was still commanded open based off the occupancy schedule. Once that damper’s end switch proved open, the Intake Fan blew cold air onto the cooling coil until it eventually froze and burst, creating substantial water damage. 

Figure 3: AHU control wiring diagram. (Excerpt from original control system’s as-built shop drawings, which were to serve as the blueprint for the contractor performing the control system upgrade to work off of).

The temperature controls contractor who had performed the control system upgrade was operating under the assumption that Interlock 2 was hardwired, or at the very least the freezestat would kill power to the Intake Fan. Though such hardwired interlocks would be appropriate here, it was clear in the documentation they were working off of that they did not exist. Our opinion was that their lack of programming of this software interlock was the root cause of the frozen cooling coil and associated damage. The resolution to this issue included not only the programming of this software interlock, but also the installation of additional hardwired interlocks between the fans to provide additional safety nets against future coil freezes.  

Conclusion

This example is admittedly difficult, but I hope it underscores just how nuanced these concepts can be, why clear specification is required, and just how important it is to get right. This project forced me to think far deeper than I ever wanted to about the concepts of interlocks, but it has served me well as I have since run into numerous incidents with misapplications of interlocks. Next month I will provide additional examples on where a misunderstanding of the concepts of hardwired and software interlocks has tripped up other project teams I have been a part of. The intent for these two articles is to motivate commissioning providers to better understand the concepts, and be more equipped to identify where misapplication of such interlocks exists in the systems they are commissioning.