Hey folks, Phil Zito here and welcome back. In this post, we're going to be talking about how to systemize your building automation career.
Quite often, and this is happening with increased frequency, folks are asking how they get into building automation. How do they get to the next level in their career? Like, what do they do? So, what can people do to really take their career to the next level?
Oftentimes, I will ask folks, what they enjoy doing. What do you want to do? There is definitely a discovery piece. What really sets the people apart from the people who go from being a technician to a programmer in a matter of months? How do you do that, and how do you be effective at that?
It's actually not as hard as you think. So, the trick to being able to accelerate your career is creating a system of progression. What do I mean by a system of progression? Well, system of progression is:
- Identify your start point.
- Identify your end point.
That's pretty easy. If you're able to do an honest assessment of yourself, and you're able to say, I have no inspect background, no electrical background, I don't know what a computer is, etc, and that's worst case scenario, and I want to be someone who's writing API's for a major Fortune 100 company, then we have our one start point, and we have our one endpoint. Now, the tricky part where everyone gets kind of held up is in the middle. That's where folks really struggle to figure out what they're going to do. So, that is what we're going to focus on today.
First things first, we need to figure out the endpoint. Where do you want to end up? What are you passionate about? Now, the reality is, you may start by saying, “Phil, I'm really passionate with working with my hands. That's very interesting to me. I like to be outside doing work, etc.” Then you know, you pull it back, and next thing you know, you're like, “Phil, I'd really like to sit at a desk and write programs every day.” Okay, well, those are two totally different things.
So, things will come up in life. That being said, do your best to figure out what you like to do so you can figure out your end position. How do you figure out what you like to do? Well, you look at the times when stuff just seemed to fly by. When did you go and you lose track of time because you were working on something? Maybe it was when you were designing something, maybe you were fidgeting with something trying to troubleshoot it. Maybe you were trying to like engineer out some home improvement project.
Those could all be signs of maybe liking to troubleshoot. Maybe you want to move into a lead service tech role. If you like to do home projects of some sort, maybe you want to do project management or a design role. If you sit there and you'd like to work with your hands, maybe you want to be a technician role. If you like computers, do you find yourself losing yourself on Stack Exchange and stuff like that? Maybe you want to be a programmer, or an integrator.
Once you have that idea, then you put that at your endpoint. Now you look at what you need to do in order to have that role. So, if I were to go to Google and type in building automation programmer, I have a result for a Controls Engineer. That usually is someone who needs to program. Now that I see this programming job description, I'm going to start to figure out what I need.
I need an analytical mindset, or educational experience and stuff like that. It does say you shall be responsible with end-to-end programming, including creating the program, testing the program and troubleshooting the program. Okay, that's good. We have to test, we have to write a program, we have to troubleshoot a program. So, we have a couple things going on here that we can say that these are the things we need to do.
Now, let's stick with writing a program. Okay, so writing a building automation program, what do you need to know to do that? Well, if you've been through our programming course, you know our approach to programming is to read the sequence of operations, break it out into segment chunks, identify the design patterns, and write the program.
Now, the biggest challenge any of you are going to face, if you're not in the industry right now, is getting your hands on building automation stuff. Like how can you go about getting your hands on building automation gear, so that you can test out and work on all this stuff? Easy IO, I don't know how accessible their stuff is anymore now that they've been acquired by Johnson Controls, but that used to be one of my go-tos. Contemporary Controls, they're still a good go-to for lab material. Anyone who's based on like the Sedona framework, they're pretty open.
Everyone has issues getting materials right now. So, you just have to accept that. But getting your hands on the software, going to any Sedona platform, is usually going to be one of your easiest ways. Someone commented saying it's hard because it's locked behind vendors. That's why I point people to Contemporary Control and their BACnet Pi thing is called BAC-PI board. It's a Raspberry Pi board that runs the Sedona framework, and Sedona’s going to give you the ability to do graphics. That Pi board is going to give you the ability to do basic IO, it's going to give you the ability to mess with BACnet/MSTP, BACnet/IP, SNMP, OPC, etc. It's going to give you the ability to do some basic server stuff, I believe. So yeah, that's a good labbing product.
So, once you've got that out of the way, let's get back into that writing a program. Okay, so you're at point A with no experience and you want to get to point D of writing a program. How can you do it? Well, the first thing is we have to know what it takes to write a program. You have to understand BAS software, you have to understand HVAC, and you have to be able to interpret HVAC documentation in order to turn that documentation into code.
So, you know, we wrote up our Ultimate Guide to Building Automation Programming where it goes through kind of an approach on programming. What you're going to do here is, you have your programming, and you've broken out HVAC into a portion. Now a lot of folks will tell you that you need to be a mechanic to properly understand HVAC, etc, etc. I have no mechanical background, yet I was programming within a year due to this approach. What I did was, I went and studied ASHRAE manuals on HVAC sequencing. I went and identified the concepts that repeated here.
This is where the different kinds of thinking come into play. You start to identify the patterns, so you have to understand HVAC theory, things like psychometrics, things like heat transfer, things like systems operations, safety, etc. But you also have to understand what that translates to in code.
Now, once you've done that, and you've started to build out this HVAC training portion of it, you obviously have the BAS portion of it. So, now you have to take that HVAC experience and translate that to code, and you start with stuff that's super simple. Maybe an exhaust fan. How do you program an exhaust fan? I think most of us would say, for an exhaust fan, you take the comparative object, right, a comparative object is going to compare two numeric values. It's going to say, when numeric value one is greater than the numeric value two, it enables a Boolean output, which enables a fan. So, you've learned a basic programming pattern.
Now with that pattern, that same comparative pattern, you can enable chillers, you can enable boilers. So, you have to know HVAC theory, not HVAC hands-on, but HVAC theory. Then you have to understand patterns. For those of you who are managers reading this, this is the exact way that you can develop your own team. For those who are self-developing, same thing. You sit there and you say, okay, now I have to learn my patterns. Once you learn those patterns, you can move progressively. Once you've mastered one pattern, you can move progressively to other sequences.
Now, note that all along the way here, you're doing this all alone. I realize that it's going to be very difficult. I realize that it is going to be challenging. So ideally, you would get yourself a mentor, a BAS mentor, maybe even get a job at a BAS company. Along the way, you are studying these things, you're doing your day-to-day installer tasks, or your designer tasks, whatever role you have. Then you're doing these tasks outside of work hours. Once you have built up your understanding of a design library, so HVAC design libraries, you're going to start writing full-fledged programs. You're going to test these out to see if they work.
So, we have HVAC, we have programming design patterns, and we have writing full blown programs. That takes care of the programming piece, but now we still have the test, and we have the support. So, now we move on to testing, and now you have to start learning your testing methodologies.
This is where you would research how you test programs, and you're going to get a lot of line code stuff that's not going to make sense to you. But there are going to be a couple of things like variable testing, read through testing, and isolation testing. Those are the three primary testing methodologies we teach.
- Variable testing is where you change a variable, and you see if it affects the program the way it should.
- Read through testing is where you read through the sequence, and you try to execute the sequence.
- Isolation testing is where you isolate a certain portion of the sequence and you test.
So, once you've learned these test methodologies, and you've practiced them, then you can move to the final phase, which is troubleshooting. This is where you can work with your company, or maybe you join a community like our Smart Buildings Community, and you can start asking for code.
Then you can ask if someone will send you bad code. You could try to figure out why it's bad code, and you can start troubleshooting it. You can start figuring out why is this code bad? Reading bad code is going to teach you how to write good code. So, through all of this, you have a systemized approach to go and program. But that's all that programming portion. Like I said, most of you are going to have to get a job at a controls company, or those of you who are managing, are going to have to be leading technicians to this point.
Which brings us to the technician. Alright, so how do you do that? Well, this is where things start at that starting point where you have to do an honest assessment of yourself. Do you have the electrical baseline knowledge? Do you understand electrical theory, Ohms Law, etc? Do you understand baseline HVAC? Do you understand baseline building automation? Are you good at working with your hands, etc?
So now you have to systemize your approach into that. So, I've showed you a system for building automation programmer, now for the technician, systemizing that, you're going to say, how do I get into that role? Well, we go back to Google and type building automation technician to see what job descriptions it gives us. Okay, so baseline understanding of mechanical knowledge and electrical knowledge to ensure proper implementation of I/O, testing of I/O, which is inputs and outputs, and adjustment of field documentation.
Okay, so what that basically means is this person has to understand how to run electrical wire, wire up inputs and outputs, test those inputs and outputs, and then update documentation. That's like a basic technician role, right? So how do you learn that? Well, this is where you would start to realize what is building automation? You'd start to study that.
So, understanding building automation, understanding the electrical, and understanding the HVAC. So, from a building automation perspective, understanding something like building automation controllers, they take data from inputs, they process that data, and then they drive outputs, right? Your job as a technician is to bring in the inputs and outputs to the controller so it can do its job. Simply put, you have to understand what inputs and outputs are.
Fortunately for you, there's only so many input and output types. On the input side, we have resistive, dry contact, pulse, milliamp, and voltage. Those are our standard input types. On the output side, we have internally sourced, externally sourced voltage, we have our voltage DC, and we have our milliamp outputs, and we have our floating outputs, which are a combination of 24-volt source voltage.
Once you understand that, though, you basically know all of the major IO types. Whether you work for Delta, Johnson, Siemens, Schneider, whoever, those inputs and output types don't really change. Sure, some controllers source their own voltage for powered sensors on inputs. Sure, some controllers will bridge or use Triax for externally sourcing voltage, but by and large inputs and outputs are the same.
So, you've started at that individual system. Now you branch out. Electrically, what do you need to do? How do you run wire? How do you strip wire? How do you connect wire? How do you wire up different input and output types? Fortunately, for that, once again, there's only so many ways you wire up inputs and outputs. You know, a floating actuator, there's only really one way you wire that up. For proportional actuators, you have a couple of ways to wire them up, but you know, there's only a couple.
So, once you start to figure that out, then you have to say okay, on the HVAC side, how and where do I install these and what sensors do I use? How do I test that they're working? Once you have that, you've built basically the systemized chart of a technician role. Then finally, how do you interpret documents and update them?
These are all things that if you get very clear on through, you know, YouTube resources through stuff like our blog or our courses, or working a day-to-day job, you can clearly figure out how to do each one of those. Once you've built out those, and you've worked in that role, then you can progress to that programmer approach that I've talked about.
I hope this systemized approach is making sense. We’ve done multiple posts on this topic, what you need to know to have a career in building automation, etc. But I wanted to give you kind of the logic-thought process that if I were in your shoes, I would be using on a day-to-day basis to shortcut my career. If I knew I wanted to be a programmer, I would understand what the programmer needs to know, what role comes before a programmer that supports that, and I would be doing this in the shortest amount of time possible. The quicker you can get to that programmer role, the quicker you can gain the experience of programming.
I'm not a believer of doing years and years in a previous role so that you can kind of have the experience. I believe the way that you actually have the experience is by having the experience in that role. I know that's kind of counter to our industry. Our industry, for some odd reason, seems to take pride in “doing your time” and “doing years”. And, you know, every time I bring it up on social or something, someone inevitably posts like, a 10-page list of what a technician needs to know. Then I look at that, and I'm like, that's totally overkill.
So, just be honest with yourself, and I believe that if you follow the system, you should be able to progress rather rapidly through your career. This can apply to anything: sales, project management, running a business, O&M work, contractor, direct work, etc.
Thanks a lot for being here and take care.
