Software vs. Hardwired Interlocks: Part II

Last month’s column introduced the concept of an interlock. 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 operation (Process 2) is prohibited. There are both software interlocks and hardwired interlocks, and confusion between the two can often trip up a project team. The previous column provided one such example. This month’s column provides two more. 

Example 2: Duct Mounted Smoke Detector Shutdown of FCU

Last month’s column stated one of the drawbacks of a software interlock is it requires the programming of the interlock to be correct and the microprocessor (e.g. a DDC controller) to be functional for the interlock to work correctly. There is more room for error with such an approach. I was on a project recently which demonstrated this. 

On the project, there were several FCUs large enough to warrant a duct mounted smoke detector, which was wired to the fire alarm system. The fire alarm system was to disable the FCU should smoke be detected in the duct. The design wasn’t explicitly clear that the disabling of the unit would be through a hardwired interlock, but a fire alarm binary input (which would be needed for a software interlock) was clearly missing from the points list. It would make sense that they intended a hardwired interlock for such a critical application, as hardwired interlocks are regarded as more reliable.

Figure 1: Safety shutdown relay for FCUs. (Excerpt from temperature control shop drawings)

The temperature controls contactor interpreted the design as needing a hardwired interlock as well, as they clearly showed it in their safety shutdown relay and fan enable wiring details (see Figures 1 and 2, both excerpts from the approved temperature controls submittal).

Figure 2: Starter with safeties wiring detail for FCUs. (Excerpt from temperature control shop drawings)

During functional testing of the FCU, I never intended to test the fire alarm shutdown due to a duct mounted smoke detector trip, as a separate team from my office was testing all fire alarm devices in the building at a later date. In reviewing the programming of the FCU, I noticed that a binary input coming from the fire alarm system to the BAS was in the programming. The programming showed that the FCU would be disabled by the BAS controller if this binary input from the fire alarm system triggered. Essentially, it looked as though a field modification had possibly replaced the hardwired interlock with a software interlock. 

What made it worse, the programming had the FCU only being shut down by this fire alarm binary input if the fan had been running at least 10 minutes. The sequence of operation for the FCU discussed a minimum ON time for the FCU to prevent short cycling during normal operation, but that minimum ON time was certainly not intended to apply to such a life safety shutdown scenario. What if the fan enables and smoke is detected 1 minute into operation? The fan would continue to propagate the smoke for another 9 minutes before it shuts down!

When I started to question the presence of a software interlock, which if even allowed was certainly insufficient, I was assured that a hardwired interlock existed, and the fire alarm contact was also being monitored. I was told the programmed software interlock was just belts and suspenders. 

I did not have the means to adequately test the fire alarm system that day, so I informed the fire alarm commissioning team from my office of my concerns. I asked that prior to testing the duct mounted smoke detector shutdown of the FCUs, that they ensure the FCU was just enabled, so that it was within the 10-minute minimum run time when they tripped the duct mounted smoke detector. None of the FCUs disabled on a smoke detector trip when testing with this approach, proving a hardwired interlock had in fact not been installed and the software interlock was indeed insufficient. Had I not noticed this in the programming and the fire alarm team encountered the FCUs after they had been running for 10 minutes, this mistake would likely never have been caught which would put future occupants at risk.

Example 3: Inappropriate Killing of Power to Hot Water Control Valve

Last month’s column stated one of the drawbacks of a hardwired interlock is they are inherently binary processes, which limits what you can do with them. I was on a project recently which demonstrated this.

The sequence of operation for an AHU described when the AHU would shut down; if unit is indexed to maintenance mode by the building operator, on a signal from the fire alarm control panel, or on a trip from the low static safety switch, the high static safety switch or the freezestat. When the AHU is shutdown for any of those reasons, the sequence outlines what is to occur (see Figure 3). 

Figure 3: AHU shutdown sequence of operation.

The designer wanted the heating water control valve and its associated coil pump to remain under control. This means the valve would modulate to maintain the heating coil leaving air temperature at 45°F, and the pump would run whenever the valve was opened. 

During functional testing of the AHU, we intentionally tripped the high static safety switch. I noticed the heating valve was commanded closed, which made sense as the heating coil discharge air temperature was well above 45°F setpoint. But I noticed the position feedback from the control valve was reading 100% open. I thought that was odd, so I walked over to the heating valve and confirmed it was indeed full open, despite being commanded closed. 

Consulting with the temperature control contractor’s electrician, he stated he installed a hardwired interlock which cuts power to the heating valve if the safety circuit is triggered (i.e. if any of the safety switches trigger or the fire alarm signals a shutdown, the heating valve loses power). And this valve was a normally open valve, meaning it fails to the open position on a loss of power. Though not specified, he had wired it this way as the client has requested that of him on other buildings.

While the static safety was still tripped, I overrode the heating coil discharge air temperature setpoint of 45°F to a value higher than the sensor reading and watched the heating valve command slowly start to increase. It was apparent the software interlock between the AHU being disabled (Process 1) and the heating valve controlling to an unoccupied heating coil discharge air temperature setpoint (Process 2) was indeed programmed correctly. However, Process 2 was being hijacked because the heating valve went to its fail-safe position of full open due to the unspecified hardwired interlock that was put in place. 

This approach of killing power to the heating valve is sometimes used on freezestat trips, but I do not believe I have ever seen it used for fire alarm or static safety trips. All of these safeties require manual reset, which usually can take some time for the facility staff to properly investigate and then perform that reset. During that time, the inside of the AHU can get really hot with a wide open heating valve which can create various issues when the AHU is restarted. I did not agree with this hardwired interlock, and neither did the design team. It was eventually removed.

Conclusion

I hope the three examples provided in these two articles get you thinking more about interlocks. They are everywhere, and the nuanced differences between software and hardwired interlocks often trips up project teams. The intent for these two articles is to motivate commissioning providers to better understand the concepts, and be more equipped to identify where misapplications of such interlocks exist in the systems they are commissioning.