Hey folks, Phil Zito here and welcome back. In this post, we are going to be continuing our series on building automation roles and we are going to look at the BAS Programmer role.
The BAS programmer role. This is, in my opinion, the most sought-after role in building automation. It's the role that seems to be the most difficult for people to fill. It's the role that I see a lot of people wanting to aspire to, and it's the role that in my opinion can be the most difficult from a learning and development perspective.
The Programmer role has so many requirements as far as skill set, but it also has so many areas in which it's not very clear. So, let's clearly define this role. There are three types of programming from a building automation perspective.
The first type is where, not all software has this, but a lot of it does, you basically use selection tools and templates to create programs. It's not really as much programming as it is selecting the appropriate system sequence that matches up with the sequence of operations from the design documents. So basically, for those of you who are unfamiliar, a lot of manufacturers have software where you can basically go through and say, “This is a fan coil, this is a rooftop, it has electric heat, it has gas heat, it has a damper, it doesn't have a damper,” and then the software will actually build the program for you.
This is interesting to me, for several reasons. I'm going to briefly segue here, so if you're not interested in history, and my thoughts on the future of the industry, you can scroll down a bit. What's interesting to me is they've been talking about this for a while, I remember when I worked at Johnson Controls, and we had this tool called Presto. It would allow you to select system designs. We made an effort to give it to engineering firms so that they could select their system design, and it would automatically output a sequence of operations, as well as drawings, graphics, and programs that matched that system selection. ALC has it, I think Siemens has it as well, and I know a couple other folks have it as well, similar software.
You would have thought that would have caught on by now as it seems like a rather efficient way. The problem with these tools is that engineers like to engineer and on plan and spec, this stuff can work just fine. It's plan and spec as long as it aligns with the engineer’s boilerplate design. What you have to realize on a lot of plan and spec is there is a boilerplate pre-design that is being used to keep design cost down, and as long as your sequence matches up with that, you're good to go.
Where I think the future is going is more customized selection, especially with all this talk about net zero, which I don't think it's going to happen anytime soon. I think people are being idealistic. We are going to be focusing once again, once we get past all this IAQ stuff on energy efficiency, it's just going to be a focus point. Not saying I agree or disagree with that, but it will be a focus point which will require different sequences, which will require facilitating tools to help develop those sequences.
So why do I tell you all this? If you are a BAS programmer, and all you do is use selection tools, which a lot of people do, or you use a database of predesigned programs, which a lot of people do and there's nothing wrong with that, then your skill set focus is really going to be primarily on HVAC sequencing and understanding effects of both HVAC sequencing choices as well as controller selection choices on the execution of a sequence.
What I mean by that is, if you understand that this unit is DX heat, and it has no form of bypass, then putting a VFD on it, it's probably not going to work on the supply fan. You'll ice up the compressors, which would probably be a bad thing. You only know that if you have some basic HVAC background, and so selecting systems is not as simple as just selecting them. You have to understand the ramifications of the selections you make.
That being said, that brings us to our second type of programmer, which is the custom programmer. This is the one that, to me, is a lot of fun. Custom programming is fun, because it's like adult Legos, right? You get to build stuff from scratch. I will tell you, this is becoming increasingly rare because, at this point in life, pretty much everything under the sun has been programmed. So, unless it's some new ASHRAE guideline 36 stuff, or maybe some new IAQ sequences, you're pretty much going to have it in the library.
I do like doing custom programming. I like building state-based programming, and this requires programming knowledge. You have to understand the blocks, you have to understand design patterns. Design patterns are basically layouts for executing certain types of programming. You execute a certain type of programming again, and again and again, and you might as well have a pattern for it because it never changes. So, you have design patterns, you have understanding block logic, and just understanding basic logic flows, and how all that works.
Then comes the third type of programming, which I see increasing, but I don't see it increasing to the point where I would really recommend you learn all of it. This is API scripting, data consumption, data normalization, and data programming. Now I know it's really cool to talk about API's, data feeds, digital twins, all that fun stuff. The reality is, since the market is still largely plan and spec, you're probably not going to be working with that.
Now, I do like having a scripting background. Personally, I think techs, designers, and programmers should have a scripting background. They should understand how to script and how to write scripts. So, scripts are not full programs. They are functions and snippets of code that enable you to execute things. For example, PowerShell, or BASH, or anything like that, where you are able to write a script that would execute stuff. I like to use this for Windows Server setups.
If you've ever been through our IT for BAS Professionals course, you know I'm a fan of not using the GUI version of a server OS. I'm a fan of using a non GUI version, GUI being graphical user interface, because you can do pretty much everything through PowerShell. It's faster, and you can actually get more precise. So, understanding scripting, I believe, adds a valuable skill set. Plus, I've also seen it for automation. If I want to script a bunch of production of duplicate Excel sheets, or I want to take a bunch of data in or out of a program, I can write a script to do that.
So, how do you gain these skills? How do you gain these programming skills? Well, I am on the fence with this. On one hand, I went directly into programming. You know, I was a tech, but I was really programmer, or actually a tech, programmer, and designer all at the same time, working for a small controls contractor. So, on one hand, I believe that you can walk right into programming. It will be painful, it'll be very difficult, and you'll have to put a lot of study into your HVAC knowledge and sequencing knowledge.
Now, when people hear me say that I often get emails saying, “Phil, no one could go program a heat pump chiller, or fan wall, or whatever,” and I agree. Coming in straight off the street, going into a programming role and writing a program for a fan, probably not going to happen. But let's be real. How many times do you go, and the first job you get is a fan wall? Most of the jobs you're going to get are going to be packaged rooftops, VAV units, air cooled chillers, maybe a centrifugal with a primary secondary, not terribly difficult sequences.
Now, I know they're not the easiest sequences, but they're also not terribly difficult. So, if you are able to read the Honeywell Gray Manual, if you're able to read some of the ASHRAE documents on HVAC sequencing, some of the Tailor engineering guides, some of the TRANE engineering guides, you'll be pretty solid, if that's how you learn. Now, that's big IF. If you're not a visual learner, if you're not someone who can read information, consume it, practice it, and apply it, and you're also not committed to doing program practice at home in your off hours, then you are probably not going to succeed as a self-taught programmer.
I'll be honest, if you're not willing to put in the program practice, then you probably should just stay a technician because you're not going to be a very good programmer. The really good programmers that I know, whether they took the long route and went through a technician, designer, programmer role, and they took a couple years, or whether they're like myself, and they went really accelerated, the one thing both have in common is practice. They practice their trade, they actually look at it as a trade because it is a trade. It is a skill that you have to develop.
So, how do you learn this stuff? Well, I already gave you a couple points, right? Honeywell Gray Manual, I believe every BAS professional should read it. That'd be really cool if they rewrote it, but I mean, it's still applicable today. It has a really good breakout on PID loops, a really good breakout on control modes, really good breakout on control and system theory. Read some of the Taylor engineering guides if they're still freely available, or if they're behind a paywall. Also, the ASHRAE guidelines and the ASHRAE Reference Sequences, I believe that's what they're called. I encourage you to read those as well.
So, a lot of studying, a lot of practicing, get yourself a controller, get yourself control software that can emulate a programmed environment and start programming stuff. Start doing things like loop logic, start-stop with locking logic, sequencing logic. Try to do some state-based control where you have a cooling mode and heating mode, and certain things change depending on what type of mode you're in, maybe using multiplexer blocks, stuff like that. Start to experiment with that and see what happens, make changes, see what happens.
Always, always seek out the difficult projects. Seek out the projects that scare you, that you feel you're not ready for because you probably aren't ready for them. But here's the news, most of the marquee projects, most of the really cool sequences, a lot of people haven't done those before. So, the people doing it with you probably are not ready for it, and that's kind of the little secret. These folks will say they have 30 years experience, but when you dig into that 30 years experience, there's a lot of people who have 30 years experience doing the exact same thing all the time.
It's why it was a running joke back when I worked for an OEM that the 30-year guys didn't know how to use the new software. They were wizards with the old software, but when it came to anything IT or anything with the new software, they couldn't figure it out. All they'd ever known was doing one single thing.
Now, this isn't a dig on experienced folks. I guess I put myself into the experienced folks category, but it's also just something to be aware of that you can't sit there and hold yourself back from opportunities, simply because you feel you're not ready. You will never be ready. It's a matter of planning:
You're going to plan. What am I trying to learn here? What am I trying to do here? Then you're going to do your plan. Then you're going to correct your plan. So, am I getting the results from my plan that I wanted? Is the program working? If it's not, why is it not? Then I'm going to correct those.
You could argue that you assess before you correct; you assess the results, and then you correct.
So:
- Plan
- Do
- Assess
- Correct
If you follow that methodology to almost any form of learning, you're going to find yourself in a much better place. You plan your learning, you plan your exercises, you do them. You assess, “Am I getting the results I want,” and then you correct.
Now how do you get a role in BAS programming? Well, if you've taken the long path, it's as simple as applying for a programming role because almost anyone will hire someone with a couple years of experience if they can program. But let's say you don't have any years of experience, and you do want to get brought on as a programmer. Internships are probably your best bet, if not hiring into a technician role at a smaller contractor, because you'll most likely be doing programming there.
Additionally, you can do programming on your own time. Find a way to get access to software. If you're really fired up about it, you will find a way to go on a Facebook group or Reddit group and you will find a way to get access to BAS software. Practice and then send your practice programs and explain what you're doing to an Operations Manager.
I don't know why enough people don't do this. They still go through HR screenings, and they get blocked because they don't have experience. I'm telling you, there is no good ops manager out there, who would pass up on someone who wrote them and said, “I'm passionate about BAS programming. I taught myself HVAC. I am practicing programming at night, and here's how I'm doing it. Here's some sample programs I wrote. I really would like to be a junior programmer at your company.”
I'm telling you, if you do that, no one else is doing that, and that shows a level of effort, intensity and focus that no one else is willing to take. You will be shocked by how many people respond positively to that. I talk to ops managers every single day, and you know what they tell me? They say the exact same thing that if the people were just motivated to learn and study because now everyone views themselves as this invaluable asset and think they don’t have to study anymore. So, as soon as they get someone who is putting in the effort, putting in the hours, they want to hire that person.
Alright folks, I hope this helped. BAS Project Manager is up next!
Take care!
