Miles Ryan, P.E., writes a monthly column in Engineered Systems Magazine on Building Commissioning. Read September’s column below:

Figure 1: BAS graphic of an AHU

It is common for commissioning providers to manipulate setpoints and perform other overrides via a Building Automation System’s (BAS) graphical user interface while functional performance testing. During the process, there are instances when the system does not respond to the manipulations as expected. This forces the temperature controls contractor to open the program and start digging through the programing code for an answer as to why that is. Those contractors will often tell you they prefer to be reviewing code as opposed to navigating graphics. They often state they don’t look at the graphics because “someone else on their team handles them” or as one contractor recently told me, “I don’t need pretty pictures to understand how a system operates.” Experiencing these situations, and hearing this rhetoric again and again makes one wonder, “do Cx providers need to know BAS programming to effectively do our job?” My answer to that is not that black and wide.

My Journey With Programming

I was very intimidated by looking at programing when I first started in commissioning. I had limited exposure to BAS programming in graduate school and never had any formal training on the topic. However, I did have confidence in my understanding of control theory and the reasoning behind many of the sequences of operation we typically see specified for various HVAC systems. Thus, I felt confident I could confirm compliance with those sequences by living on the graphics alone.

Two projects in particular forced me to get comfortable digging into the programming. One was a new hospital that was suffering from major network insufficiency, which caused great delays in live data updating on the graphics. Due to schedule constraints, we were forced to do the majority of our testing while looking at live data in the block-based (aka graphical) programming pages of the BAS. See Figure 2 for an example of block-based programming.

Figure 2: Example of block-based programming, also known as graphical programming

On the second project, the functional testing phase started off with many issues that forced the controls contractor to constantly be reading through lines and lines of text-based code (see Figure 3 for an example of text based code). It was an out-of-state project where I didn’t exactly have the easy option to walk away and come back when they got better prepared, so I asked for a tutorial on how to navigate the programming so I could assist in the troubleshooting process from my computer. I must have read every line of code for that entire project multiple times over and found myself more confident in living in the programming than the graphics by the end of it.

Figure 3. Example of text-based programming, also known as line-based programming

Don’t get me wrong, I am not a programmer. Being a third party commissioning provider, I see many different vendors’ systems, which all lay out their programing in different ways. But I am learning more and more every day, and those two projects referenced above are what initially pushed me out of my comfort zone. This is not to say I have abandoned testing via the BAS graphics. There are plenty of reasons why I continue to do so.

Why Test Via The BAS Graphics?

There are plenty of benefits to testing via manipulations to points shown on the graphics. These include, but are probably not limited to the following:

• It takes the point-to-point checkout further than merely ensuring the BAS controller is communicating with the input and output devices.
  • Where points (setpoints, temperature readings, valve commands, etc.) are not labeled correctly or are shown in the inappropriate location on a graphic, those are called mis-mapped points. Additionally, such points may not be reporting values at all. The prevalence of such issues is very high in this industry, and testing via the graphics allows for an additional filter to catch mistakes.
• It allows for the visualization of the whole system.
  • The graphic screen includes a depiction of all key components, as well as input and output devices, of a system. This makes it easier to catch items that are out of place, even if those points were not necessarily being investigated at the time.
• It provides vetting of the level of intuitiveness and functionality being provided to future building operators.
  • In most cases, building operators will only be navigating the graphics in lieu of digging into the programming. Testing through the graphics ensures the appropriate level of adjustability is provided to the staff.
• It ensures project completion.
  • Often the graphics are one of the last components of the BAS to be completed for a project. Utilizing them for testing helps confirm controls contractors complete their full scope of work.

The Benefits of Being Proficient in Programming

Even when you test via manipulations to the BAS graphics, there will always be instances when the contractor has to dig into the programming to figure out why the system is responding in a manner that is unexpected. A commissioning provider could sit there and wait for them to come back with some explanation as to what they found and, when appropriate, how they corrected it. Or the commissioning provider could become actively involved and get more out of the experience. Forcing yourself to gain proficiency in reading programming allows you to:

• Bring more value to the troubleshooting process.
• Learn to communicate better with the controls contractor when you can proficiently use the programming jargon they are familiar with.
• Build credibility and rapport with the controls contractor.
• Help better facilitate dialogue between the controls contractor and others on the team who are not proficient in the intricacies of programming language.
  • This is especially important during coordination meetings with the owner, design engineer and other construction team players when providing updates and proposed resolutions to issues identified during the functional testing process.
• Identify issues that may be realized in the future.
  • You will learn to look for more of the nuanced issues which may not come to light during testing, but very well could rear their head in the months after the owner takes occupancy.
  • You get much more out of your testing experiences if you can actively follow along with how issues are resolved, as the same issue will likely be encountered on one of your future projects. Stay tuned for next month’s column on several examples of this.
• You become flexible in your testing approach.
  • Having the ability to review and understand the programming will allow you to confidently deviate from your test procedure if you can see a more efficient and/or effective way to test something given the manner in which that portion of the sequence was programmed.

Conclusion

So, do commissioning providers need to know BAS programming? No, they can still be effective without that skill. However, they will be a lot more effective on multiple fronts once they start gaining proficiency. I know from my personal experiences that my commitment to gaining proficiency in programming has made me far more effective at troubleshooting issues, anticipating issues to come, facilitating conversations between the controls programmer and others on the project team, as well as being more flexible on how I go about verifying the programming’s compliance with the specified sequence of operation. As intimidating as it can be, I challenge you to push yourself out of your comfort zone. There are plenty of online training resources to assist you along the way.