Today, HVAC equipment is increasingly being provided with factory packaged controls. Much of the work of an HVAC Controls contractor is now integrating this equipment into the Building Automation System (BAS), while trying to make it operate in a way that meets a very specific sequence of operation for a given project. The problem often encountered is that the equipment's factory programming doesn't align exactly with the language in the sequence, leaving the BAS contractor responsible for reconciling the differences between manufacturer's programming and the engineer's sequence. This can sometimes lead to overly complex programming, or worse, manipulating variables that leave the equipment running less efficiently than it would if it was just allowed to run how it was designed.
In the past, when packaged controls were not as common, the task of a BAS contractor was arguably easier. An engineer would outline a sequence of operations, and the programmer would develop a program to fulfill that sequence. The programmer had complete authority, determining which variables and setpoints to implement. They had a clear idea not just about programming the system, but also how to design the operator's interface. Meaning they could explain not only why a system was operating the way it was, but could also guide building operators with certainty on actions to take when a problem did arise. When a piece of equipment is running on someone else's logic, those answers aren't always so clear.
How many times have you heard the words "This system hasn't worked since day one!"? This statement is often a sign that a BAS contractor tried to put a square peg into a round hole. To satisfy a sequence, sometimes programmers can end up over-controlling a unit, resulting in poor performance. Contractors and engineers end up in a finger-pointing contest because nobody can describe exactly where the fault lies. Sadly, it's the building owner or FM team that's usually left holding the bag, dealing with a system that's hard to operate, doesn't seem to work correctly, and no clear direction on who to turn to.
To mitigate this, we can start at the design phase of a project. When factory packaged controls are specified, instead of having a static sequence, it could instead have language that simply describes the system's intent. This would allow some degree of flexibility on sequence. Each manufacturer's rep would be responsible for ensuring their proposal meets the design's intent. Designers need to have an understanding that there are nuances between different manufacturers, and the controls contractor can't change the internal programming of packaged equipment. If customization is required, specify field-installed controls.
Once we get to the design and software engineering phase of the control system, BAS contractors need to thoroughly understand the selected equipment's internal programming. This usually means lots of reading through O&M manuals and point mapping tables to understand with certainty how a piece of equipment is programmed to run. The integrator should program to the minimal amount necessary for it to meet the design's intent; i.e., occupancy commands, temperature or pressure setpoint resets, etc.. In the end, commissioning agents could adopt intent-based performance objectives that they could use to verify system functionality, rather than rigid steps that must be met in an exact order to be deemed complete.
I'll borrow from the legend Bruce Lee to summarize my thoughts: "If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.”
If BAS programmers can be allowed to "be water", adapting to the equipment rather than trying to work against it, integrations will flow, not crash.
Comments