The Pareto Principle in Controls: What Do You Really Need to Know?

Hey folks, Phil Zito here and welcome back. In this post, we're going to be applying the Pareto principle to controls and we're going to cover what you really need to know.

So, in our previous post, we kind of went through the philosophy of being a controls tech, what behaviors tend to lead you to growth in your career. Now we're going to switch gears, and we're going to look more on the technical side of things. We’re going to answer the question, “What do you need to actually know, in order to succeed in building automation?”

Well, a lot of folks have a lot of different answers.

• You go into a group that's mainly mechanics and they're going to tell you that you need to be a mechanic for a couple years before you go into controls.
• You go into a group of a bunch of programmers and they're going to tell you that you need to know programming.
• You go to designers; they're going to say designing.
• You go to folks who have more of an IT background, guess what they're going to say? You guessed it, IT.

So initially, there's a bias on all sides, right? And we need to accept that. But if we look at where the industry is trending, that tends to be a decent signal flare for us to kind of guide our careers, and figure out, if we want to have a high paying job, if we want to have a future that really is not dependent so much on someone saying they have no need for that anymore, then we want to pay attention to what the market’s doing, what the industry is doing. At the same time, we also want to pay attention to what has stayed consistent within the market over the past several decades.

So, where do you start? Well, I like to start with what has stayed consistent, and then once I have that figured out, then I look at where the market is going, where the industry is going. So, let’s stay consistent. Well, we still do point to point checkout, right? That hasn't changed. We still do functional test, we still create graphics, we still program building automation systems, we still do check out, we still do service, we still sell stuff, we still project manage things.

Alright, so if we took all of those, and we broke those down into some core foundational knowledge sets, what would we have to know? Well, if you look at install, and I like to try to bunch these up. So, if we look at installation, we look at point-to-point checkout functional test, and we look at service, we can bunch those up into kind of three buckets. That would be electrical, HVAC, and BAS.

Then if we look at design and programming, that's more HVAC, BAS, electrical with a little bit of IT mixed in there. You can argue that some of the install, functional test, and point-to-point checkout is IT as well.

Okay, so you have these things, right? We have all of these different buckets, so how do we start to pick out what we want from each bucket to focus in on from a skills perspective. Let's look at the installer, service tech, and point-to-point check out functional test. So, as we start to look at what is applicable to us in these areas, first thing that comes to mind, is do we do HVAC first, do we do BAS first, do we do electrical first? Which one?

Well, in my opinion, you should understand BAS first, then HVA, then electrical. Now that flies in the opinion of a lot of folks, and maybe it's because I don't come from an HVAC background, I'm willing to concede on that potentially. But if you don't understand your basic tools that you can apply to an HVAC system, from a controls perspective, then you're not going to be able to do anything. You can understand HVAC all day long, but if you don't understand what a controller is, what a protocol is, what different inputs and outputs are, then it's not really going to matter that you understand in great detail how an HVAC system works.

Now some folks will argue that by default, learning an HVAC system, like learning a mixed air single path, or learning 100% outdoor, or learning a central plant. In order to learn those things, you're going to have to understand BAS inputs and outputs, you're going to have to understand BAS controls. I disagree with that premise, because I've run into a lot of mechanics who were way more versed on mechanical systems than I, but they didn't understand basic safety circuits, they didn't understand sensor types, they didn't understand signal types, they didn't understand basic protocols.

So oftentimes, I would go on service calls and these mechanics who knew the system wasn't working, because they didn't understand BAS, and the devices, and the electrical side, they couldn't fix it. So, in my opinion, you should know the fundamentals of BAS first.

What should we really narrow in on? We should understand BAS architectures. So, we should understand:

• When do you use a supervisory device?
• When do you use a server?
• When do you use an advanced application controller?
• When do you use a three-tier IP architecture?
• When do you use a four-tier architecture?
• IP or non-IP?

When do you make these decisions? Then naturally, we progress downward from the top, supervisory device, server device, down, and we progress to the field controller and the IO. We should start to understand control modes:

• What's the difference between stage control mode?
• Floating control mode?
• On Off control mode?
• PID mode?

I mean, it amazes me, whenever I post something on PID. You would think, as a content creator, you would expect that after you've created a piece of content, multiple times, I still get people asking, “Where’s the content for PID?” We have four PID Loop tuning videos, and they're free on YouTube, yet, every time I talk about PID, I get tons of people asking for the PID content. So, that shows me, and based on my own experience, that there's a ton of people who don't understand control modes.

Alright, so you go from supervisory devices, down to controllers, understanding controller types and architectures, to control modes, to IO, inputs and outputs:

• How do the different inputs and outputs work?
• When would you use a milliamps sensor versus DC sensor?
• What's an externally versus internally sourced?
• Why would you potentially not want to power all your outputs from your controller?
• Why would you maybe want to?

These are all things that you need to understand, in my opinion, before you ever get to the HVAC point. Let's be real, the reality is, for a lot of people in their initial career in building automation, they're going to go out on a job site, and they're going to install controllers, they're not going to install the sensors because that's typically being installed by the electrical sub. They're going to install the controllers, they're going to connect the wires to the controller, if the electrical subs are not already doing that, and then they're going to do point-to-point calibration and functional test.

It's at this point, at that functional test point, that the HVAC comes into play. Not before, not after, so HVAC comes in, right at that functional test. Because up to this point, you can install controllers, you can wire up trunks, you can create different architectures, you can implement different IO devices. But at the point when you need to perform functional test, which means you need to ensure that the sequence of operations is actually performing according to what is supposed to happen that's where you have to have the HVAC knowledge.

What HVAC knowledge do you have to have? This is a hot area of debate, when you get into conversations with folks in Facebook groups or on forum groups, you'll see it divided into two camps. You'll see folks who believe you need to have a journeyman mechanical level knowledge in order to understand controls, and then you'll find folks in the other camp like myself, who believe you need to have a systems theory knowledge set.

So, what's the difference? Well, you know, a really solid mechanic is going to have systems theory, or at least they should, otherwise their apprenticeship has just totally screwed them over. But they should have a solid understanding of systems theory being like, “If I have an air handler, and it doesn't have the right discharge air temp, how does that affect VAV boxes downstream from the air handler?” Or “If I have a chilled water plant and a bunch of air handler valves open up on the cooling coil, how does that affect plant pressure?” That’s systems thinking, that's inter-connections between systems.

The other camp will believe that you need to know how to change motors, you need to know how to install coils, you need to know how to install wells, hot tap, stuff like that. In my experience, you don’t need to understand that to be a successful BAS installer or service technician. You really just need to understand enough to diagnose that it is an HVAC system problem, and then get the appropriate people to fix it.

I think that's one of the problems we see in the industry, as far as talent development and talent acquisition, is you have these camps that are so divided. You have a lot of legacy people of the belief that you need to have significant mechanical experience. That precludes folks who have the right amount of experience in everything else from actually getting into this field.

So, from the installation perspective, from the functional test, from the point-to-point, all that stuff, BAS first, HVAC systems theory next, and then electrical knowledge. Understanding things like Ohms Law, AC versus DC, how transformer loading works. So, for example, you have an activated load and an un-activated load. You turn on an actuator, and the watt draw from that actuator is going to increase when it's actually actuated, sometimes by as much as 100 to 200%. That naturally increases the VA load, but yet a lot of people will size VA loads for their transformers based on unactuated devices, unloaded devices. Then they wonder when the system's working, why the transformer is sagging, why the secondary is sagging and not performing.

So, having that baseline electrical knowledge of:

• These are the key concepts of electrical circuits
  • how they work
  • simple circuit
  • parallel circuit
  • series circuit
• This is how safeties work
• This is basic electrical safety.

So, what I'm getting at here is that you don't have to be a master of HVAC, of electrical, or even of BAS in order to be successful in installation, functional test point-to-point check out. What do you need then? You need to do a task matrix.

Anyone who ever asked me how I succeed in XYZ role, I say, “What are the tasks you do most often?” In the case of an installer, you're lining out subcontractors, you're validating that sensors were installed properly, you're ensuring that point-to-point calibration is done, you're mapping those controllers into a supervisory device, maybe even mapping them into graphics.

So, what skills does that require? That requires those electrical and HVAC skills, so that you know sensor placement and you know that sensors are properly installed. Requires that BAS knowledge so that you understand what sensors should be used, what they should be connected to, and what controller type should be used.

So, as you start to do that task matrix, you can break down your skills, and you're able to determine that maybe you don't need to get an electrical license, maybe you don't need to do a five-year mechanical apprenticeship, maybe you just need to have XYZ things.

So, the natural progression from installation or service technician is towards designer/programmer roles. If we think about that, how do we make that shift? I find that the shift to designer is much more difficult than the shift to programmer. Programming, if you have a mind for it, is simply being able to interpret a sequence of operations and figure out what logical operators, which logic blocks, apply to what sequence language.

If you came upon a sequence and it said that the fan will be enabled and must prove status within 30 seconds, otherwise the system will go into alarm, and that's also dependent on occupancy, then right off the bat you should know that fan command is an AND block with occupancy and fan command. Then you can interrupt that AND block with a status block with a time delay, with a knotted input so that that status stays true until that on delay makes, and then that knotted input basically breaks. It's kind of hard to explain verbally, it's more of a visual thing to explain, but that's kind of how you think through from a programmatic perspective.

Taking logic and turning it into program is not terribly difficult if you have a mind for it and you understand the blocks. Design though, this is the natural progression of careers, technician, designer, programmer, that's typically how things happen. Well, how do you make that progression to designer? Designer, in my opinion, is the most difficult role in building automation. You have to have a solid electrical understanding, you have to understand BAS devices and all of their capabilities, and you have to be able to interpret sequences and turn those sequences into schematic drawings, both from an electrical perspective, a mechanical perspective, and a controls perspective.

We need to show the BAS network layout, we need to show how that works, how it should be wired up. We need to show our electrical details so that our electricians can properly install, and we need to show our mechanical one lines so that folks can understand where device placements are supposed to happen. We also have to do sanity checks on sequence of operations to make sure that they can even operate.

So how do you get to that point? What do you really need to know? Once again, it comes down to a job task breakdown. So, first job task is building our network riser. What do we need to understand? We need to understand protocols and protocol limitations. You need to understand RS-45 is the protocol behind BACnet MSTP, and the limitations associated with that, right, 32 devices a segment, 3300 feet, polarity sensitive, etc.

Once we understand the specifics in regard to networks on the serial network side, then we go to the IP side. We have to understand things like:

• How does IP work?
• How would we connect to maybe a Lutron lighting system or to a Crestron AV system?
• What would we do from an IP perspective?
• What would we do if we had a ring architecture for a bunch of IP controllers?
• What about a bus architecture?
• What about a daisy chain architecture?

Understanding those things then enables us to make the appropriate architecture choices. So, that's our network riser. That's just one piece of the submittal set.

Then from there, we go to either, depending on how you organize your drawings, a system drawing and system sequence of operations, or we go to a controller drawing, bill of material, and electrical details. It really just depends.

If you go to a system drawing, you have to first be able to interpret mechanical plans, you have to be able to digest those plans, pull the information from those as well as from the specification, be able to do sanity checks on those, be able to read equipment schedules and understand it’s this model control, or this model rooftop, or this model chiller. Probably going to have to do this kind of one line.

Then you have to be able to draw out mechanical one lines. You have to be able to actually represent visually, the mechanical system you are trying to implement. So, you have to have that mechanical knowledge. You have to understand how systems are designed, how sequences work, and how they're selected.

Once again, you don't have to understand how to install a motor. You don't have to understand how to install coil, but you do need to understand:

• What is hot deck/cold deck unit?
• What is a centrifugal chiller?
• What is a variable speed chiller?
• What is the difference between a decoupled loop and a mixing primary secondary loop?
• What's a primary secondary tertiary loop?

So, you once again have to have that HVAC systems theory.

Now you have to communicate all of that to an electrical sub so that they can properly install it. So, now you need to be able to research multiple catalog sheets for multiple products, represent the installation of those different products in your control system. Because remember, each controller for each manufacturer, is going to wire up sensors differently. Some controllers are going to source voltage, some controllers are not going to source voltage. So, you need to be cognizant of this. You need to think through how all of this works.

Okay, so you have controllers, you have these inputs and outputs, and you have this electrical knowledge for the inputs and outputs. You need to now translate this to an electrician, who can follow these and install them. You also need to size transformers, understand how many devices can go on a transformer, and things like that. So, you have to have an electrical knowledge, IT, mechanical, and BAS. That's why I think the designer role is quite possibly one of the most difficult roles.

Then we have programmers. So, programmer role, what do you do with it? How does it work? How do you execute a programmer role? How do you have the appropriate knowledge for a programmer role?

Well, once again, we come back to sequences. We need to be able to understand what's going on with sequences, and we need to have a baseline understanding of BAS controllers and output types so that we can create programs that work.

So, what do we do? We have to first understand logic. We have to understand things like Boolean logic, switches, flip flops, gates, etc, all that fun stuff. Then, once you understand what those logic blocks do, you have to be able to take that logic block and apply it to controls sequencing, to a sequence of operations. That, quite possibly, is the most difficult part of programming.

Actually writing a program, once you know the logic blocks, just comes down to design patterns, right? So, what do you really need to know when you're programming? You need to know design patterns; you need to know how to look at a sequence chunk. So, maybe you have some start/stop logic, or some lead/lag logic, or maybe you have state-based control logic that switches between heating or cooling states.

So, you take these logic states, and then you're going to naturally translate those logic states to different program chunks. You might say, I'm going to use this OR block, in this PID block and the switch block, and that's going to make up a chunk that will say, if I have a call for cooling, or I'm below discharge, air temperature, setpoint, I'll enable this PID block. Maybe you're using free cooling versus mechanical cooling, and you'll switch between the switch that will drive the outside air damper, and during mechanical cooling, that switch is going to drive the outside air damper to 20% or minimum outside air. Then, during free cooling, that switch is actually going to be connected to another PID loop that's driving to DAT, and you're going to be taking the value from that. So, there's all sorts of kind of nuances in the sequence chunks.

So, how do you apply this to your career? Quite simply do a matrix. I went through three matrixes, one for install, one for design, and one for programming. So, do a job task matrix, job task analysis, figure out what job tasks, and then figure out associated skills aligned to the shop tasks. That's the first thing.

If you're teaching this, maybe you're running an organization where you're trying to teach some newer folks how this all works, do a job task breakdown. Figure out exactly where your team needs to perform what tasks, figure out where they're performing them inefficiently, and then train accordingly. So, for example, if your team is doing a great job on VAV boxes, then it makes no sense to train them on VAV boxes, right? Find something they're underperforming on, like chilled water plant setup. Maybe they're underperforming on hot water plant setup. So, train them on that.

Focus in on the job tasks that are non-performing. I’ve covered this in the past about using job codes and task codes on your projects to track performance so that you can appropriately analyze cost underruns and cost overruns so that you can then appropriately train and develop your team and then staff your team appropriately.

If you have any questions, as always, do not hesitate to leave them below. I hope you appreciate these more kind of behind-the-scenes, kind of thought processes.

So, thanks a ton and take care.