When you’re asked to review someone else’s building automation system (BAS) programming, it’s a bit of a daunting task. This is because those of us who program building systems (or really any computer-driven system) for a living figure out that there are a million different ways to capture the same process in any given programming language. Usually no two people will do it the same way.
To further complicate things, in the building energy industry, “Control sequences,” (the English specification of what a building automation system’s [or BAS] programming is supposed to accomplish) “are often poorly written or incomplete.”[1] Because of this there are opportunities to save energy everywhere that often go overlooked for long periods of time because we have a hard time effectively connecting engineers to programmers. A review of controls programming and how it implements a sequence of operations can yield unexpected energy savings, but this review rarely occurs in our industry.
Using Schematics to Convey Control Sequences and Design Intent
In reviewing several BAS designs over the course of my career, I have found one thing to be true – design intent is never fully clear, and therefore it is rarely fully realized. That is unless there are good schematics with lots of detail or a thorough commissioning agent on the project. Some might argue that detailed schematics are expensive, and there are no guarantees that someone will take the time to understand them in order to be implemented correctly. However, it’s been my experience that understanding seems to come easier with a picture for most people than it does with words - indeed, a schematic is worth a thousand words. Therefore, a good schematic or diagram will generally provide a better communication of design intent, and at a lower total up front cost due to its facilitation of a quicker understanding of that design intent (read as: less requests for information [RFIs] or a lower chance of surprises during commissioning).
An Example Using Hysteresis
For example, let’s take a programmatic concept that I’ve seen many variations of over the years – thermostat control with hysteresis. You’d think there is only one way to define this concept, and thus only one way to implement it, but I’d argue that different people will understand it and program it differently. Now, first let’s use verbiage to explain hysteresis. Wikipedia explains it as:
“In control systems, hysteresis can be used to filter signals so that the output reacts less rapidly than it otherwise would, by taking recent history into account. For example, a thermostat controlling a heater may switch the heater on when the temperature drops below A, but not turn it off until the temperature rises above B.”
Source: https://en.wikipedia.org/wiki/Hysteresis#Control_systems
The hysteresis in this application is more accurately coined as a “differential” between the temperatures of which you want the thermostat to turn on and when you want it to turn off. Some controls products take differential as an input instead of hysteresis. Here is what that looks like graphically:
Above we have shown a 2°F differential, with a starting (trip-on) set point of 70°F and a specific trip-off temperature specified. As shown, there is little left to the imagination. But is this what everyone thinks about when they hear the term Hysteresis? Or is it a split of this differential around setpoint as shown here:
My point being that what someone will throw around as a commonly perceived to be understood term, “hysteresis” can actually result in control behavior that is not quite what was intended. These slight differences in control, when multiplied by 100 VAVs per floor, on a seven floor building, can have an energy impact that is not immediately obvious to the design engineer or end user!
What If the community of design engineers could graphically show sequences as a series of standardized logic blocks with their mathematical algorithms defined and published? What if these logic blocks were abstract versions of all the basic control functions every HVAC control product has because they’re the basic elements of control logic (such as my example of hysteresis above)? With minimal high level verbiage accompanying the logical schematic the required sequence would be provided and the intent would be better realized. Here is an example of what that might look like:
Not only does this speak to a controls programmer in their native language, it also makes sure all the details are provided to the programmer so there is minimal loss of design intent.
Standardization Across the Industry
If this was an adopted industry approach for engineers with a focus on up-front energy savings, the opportunities for energy savings would be identified more easily in the design phase. Or, as sequences evolve over time, a retro-commissioning project would be able to quickly identify older sequences that could be updated to save energy. Conveying sequences graphically could provide our industry with a new approach to help lower upfront costs, and operating costs by allowing us all to speak the same language at a uniform level of detail that we currently just don’t do.
Good building mechanical designs are able to convey lots of detail graphically. Electrical systems show almost every detail graphically. So why not control sequences? As a service, Cx Associates provides review of control sequences. If you want us to provide you with an analysis of your most commonly used sequences (if you’re an engineer or a controls provider) and generate graphical block schematics for your use in a project, reach out to us today!
[1] Mark Hydeman, P.E., Fellow Member, ASHRAE; Steven T. Taylor, P.E., Fellow Member, ASHRAE; and Brent Eubanks, P.E., Associate Memeber ASHRAE “Control Sequences & Controller Programming” ASHRAE Journal Mar 2015.
