17 min read

SBA 231: The 5-step Building Controls Hardware Engineering Process

By Phil Zito on Dec 14, 2020 6:00:00 AM

Topics: Podcasts

In this week's episode of the Smart Buildings Academy Podcast, you will learn the 5-step building controls hardware engineering process.

We will discuss:

How to perform proper takeoffs
How to evaluate device selection'
How to size systems
How to handle add alternates
How to design physical architectures
And much more

Click here to download or listen to this episode now.

Resources mentioned in this episode

Subscribe via iTunes

Subscribe via Stitcher

Show notes

Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito Episode 231. Hey folks, Phil Zito here and welcome to Episode 231 of the smart buildings Academy podcast. And in this episode we are going to be discussing the five step building controls hardware engineering process. So you're going to learn how to engineer building control systems at a high level. And then over the next couple podcast episodes, we're going to be diving a little bit deeper into each one of these five steps. This is going to parallel our controls engineering boot camp Early Access Program, which is opening up for enrollment on December 18. If you do hardware engineering, for building control systems, then you will definitely want to check out this course and the Early Access Program. You can find out more information about that as well as the show notes and links to other important pieces of information at podcast smart buildings academy.com forward slash 231 once again, that is podcasts smart buildings academy.com Ford slash 231. All right, so what is the building controls hardware engineering process? How does it work? Where do you get involved? And what are the key pieces of information you need to know about each step? Alright, so the five step building controls hardware engineering process is first step one release to operations project review. Step two is performing takeoffs. Step three is addressing all of the physical IO, and associated devices. Step four is going to be sizing your hardware, specifically your controllers. And then Step five is going to be handling your architecture. I've used these exact, exact five steps to do large projects to do small projects, they pretty much work for any project, you'll run into even integration projects where you really don't have that many physical IO or inputs and outputs. So step one, release to operations project review. Right here, you want to make sure, and this is critically important. I hammered this in all my project management podcasts. I hammer this in our technician courses and our project manager courses. But you need to ensure that there is a release to operations released operations is when the sales team goes to the operations team and says, Hey, we sold a project. Here it is, this is the scope of work. Here's the mechanical and specification documentation that we use to quote the scope of work. Here's the timeline, here's what's expected of you so that you can go and properly execute the project. Now we're going to take a brief segue here, talk about project execution, then we're going to tie this back into controls hardware engineering. One key point that I want you to understand is that control submittals, which are ultimately, a byproduct of the controls hardware engineering process, are usually the first thing that will be done on most controls projects. So whether it's a retrofit project or new construction project, when you're doing it, most of the time, you're creating control submittals first, so being able to properly engineer the hardware is going to be critical to getting those control submittals approved, and ultimately allowing you to make your first billing against the project so that you can get cash flow coming in the project. So I want to kind of tie that in. So what we're looking at the controls hardware engineering process is usually within percentage of completion 10 to 20% of the project. So that's usually by the time that rolls around, you want to be done with your controls hardware engineering process. My hope is that as we move through these next couple episodes, you will get some tidbits, some kind of ideas and strategies on how to really develop a process a repeatable process that can make this a little bit easier and more efficient for you. Because the reality is, if you do not have a defined process, you're not using templates you're not using is basically patterns and templates that you can plug into your engineering process, then you're doing things highly inefficient. Alright, so the first thing we need to know for step one is what required documents do we need? We need the scope of work. We need the actual specification and we need the mechanical, electrical and plumbing plans.

Phil Zito 4:59
So when we review these documents, the key points that we want to focus in on first off are the scope of work. Hopefully, your sales person did not give a device by device and point by point list of what will be provided in the scope of work. I really highly recommend unless it is required by the specification, I highly recommend against that level of detail that really pigeonholes you in to what you need to provide. And while there are a lot of really good sales people out there who are very technical in nature, who have mechanical engineering degrees and electrical engineering degrees, and maybe even came out of the field, the reality is, is that they don't necessarily engineer systems every day. And so for them to be engineering, the scope, getting to that level of granularity to where they define, we're going to provide these kinds of sensors unless it's required to bid the project, one that is costing them sales effort, but two, it's really pigeonholing you into providing a system design that may not be the right system design. There may be things that you learn as you have project meetings. And as you further review the specification and documentation that points out to you, hey, this really isn't the best architecture or I really shouldn't be using these four to 20 milliamp zone temp sensors, I should be just using regular resistive zone temp sensors. So the key focus points, I want you to dial in on our first the scope review of the scope letter. What you want to understand here is what systems are in scope. And this is going to become very important when we perform our takeoffs because we're going to align our takeoffs to the in scope system. So what systems are in scope, what is expected to be done with these systems, were there any hardware or software promises? software, however, is going to go more towards the software engineering, but you still need to be cognizant of it. And what timeline was promised what exclusions and what assumptions were made. All of this should help frame your template document, which is your scope or take off document I like to keep this in an Excel sheet. I like to normally share it on OneDrive, although you can do it on Google Docs as well. That way we have versioning. And multiple people can work off of it, especially if it's a very large project. And maybe you divide the hardware engineering one person is doing the plant one person's doing the air handlers, one person is doing the terminal units. I don't necessarily recommend doing that. I recommend typically one person doing the engineering because systems are interrelated. However, if you have to, you can do that if you use some of those collaboration tools that I mentioned. So we've done our initial look at the scope. Now we look at I it's it's a toss up whether you look at the spec or the MRP documentation first. So by looking at the specification first, where you want to dial in on is a couple things, first in the general category, and I'm going based off standard CSI spec format. So what you want to look at is in the general category, you want to dive into what are the required pieces of hardware manufacturers, what related divisions are quoted in this spec, because those related divisions could drive your hardware like if it's related to fire alarm or lighting, and you need to provide dry contact IO. That's important to understand because then that will go and dictate how you build out your hardware, how you build out your controller layouts, and potentially how you build out your panel layouts. So that's general section one. Now we move on to Section two, which is typically materials. And we're going to look at what parts and pieces are required. This is more of a familiarity glance, because we're going to be looking at this again in takeoffs. And then step three is execution. You want to understand how is this going to be executed? Now, you may ask yourself, why do I care how it's going to be executed for the hardware engineering process? Because let's say that you're expected to use IP enabled controls, and you're expected to execute those as part of the project and you know that it is gears not going to get there before the shell and core and everything is done and the building's conditioned, that may lead you to needing industrial switches to connect your systems. That may be an add alternate that you put in that may be something that you upsell. There's a variety of things that could influence your hardware engineering, then we move on that that MEP set, that MEP set is going to transition us into our takeoffs.

Phil Zito 9:58
So when we Look at the MRP set, I like to immediately go to the equipment schedule. I like to use that equipment schedule to build out my takeoff list. So we'll be starting to migrate to step two right now, which is takeoffs. So I take that equipment schedule and I start to build out my system count. I start to identify my system count, I document what ma p page, it's on, what type of system how many systems? Are there nuances? Do I need to submit any RFI or RFC s? Are these integrations, etc. And then I go, and I look at these system counts, and then I like to validate them against the floor plan. Why do I do that? Well, the reason why is let's say that we have a fan coil. And let's say that fan coils in the mechanical room with the chillers. And I know that now Now I have two hardware decisions I can make. I can say all right, I'm just going to use an IOM module off the chiller controller, and I'm going to use split programming if my controller allows it, if my software allows it. And I know this is a little crossing in the software engineering, but there's little software engineering in all hardware engineering. But I'm going to look at that and say, Okay, do I do a separate controller? So I have standalone for that fan coil? What is that fan coil serving? And then I make a decision standalone controller, or do I use the chiller controller, it's different choices based on cost based on system type building type. Now, let's say that same fan coils right next to that chiller mechanical room, but it's sitting in an IDF room, that would make something completely different now that IDF becomes its own critical asset, right? That's the data panel floor right there that has you know, switches and it gear for that floor. And that becomes Hey, we should probably have its own controller, we should have its own ups, potentially, etc. So we want to understand where things are laid out, because that is going to influence hardware selection, whether we share systems or divide systems. And then from there, once we've kind of made those rough decisions, we've said, okay, we believe we're going to go and use the chiller controller for both fan coils and chillers right in in that mechanical room. Now we go and we look at the specification. So if you followed me so far right, I start off with released operations. Step one, I review my scope, I start to build out my initial takeoff document, I review the specification, then I review the MEP set. Now in step two takeoffs, I've done the look at the equipment schedule. I've looked at the floor plans. I've looked at details. And I'm coming back to the specification again, to go and get a little bit more of a nuanced look at my systems. Is there anything in particular I need to be aware of? And you know, is there something in the specification that says I can't use the additional controller I need to have controller separated? Is there anything specific to my ups is or anything specific to my panel layouts, etc. Right now steps one and two, I'm just gathering information, I'm starting to get a sight

Phil Zito 13:33
picture of what my solution could look like. And this is naturally going to progress us to step three. Now step three, we're going to address the physical points. So we have our systems listed out right we have a full list of systems, maybe we have a chiller, or two maybe some fan coils, maybe some rooftops, maybe some terminal units, whatever. We have them listed on our takeoff document on tab one, then on tabs two through however many, we start to build our systems. And we want to build a system list for each specific system type, not for each specific system, but system types. So if you have a terminal unit with one stage reheat, and that terminal unit with two stage reheat and a cooling only terminal unit, you would have three system types. You may have 100 boxes, but you would have three system types. Now if you come along one of those cooling only boxes that has a alternate humidity sensor as well, then that becomes its own system type as well. So you kind of see. What we're looking to do here is we're looking to build kind of our kits. And it's at this point that I've got my system and I say my terminal unit and we're going to use a terminal unit with one stage reheat. That's super simple system, right. So what I would do is on that new tab on my Excel sheet, I would say Got my terminal unit, and it's gonna have these points. And I would say, okay, it's got a zone temp sensor, it's got, maybe, maybe for whatever reason, we are using a relay to drive the heat, instead of just directly connecting to the contactor. So we got an eye Dec relay or review one see really whatever, while we're starting to go now, and we're building out this points list, and then as we build out this points list, and we validate this points list against the mechanical plans, and ideally, the one line diagrams if they exist, we then go and compare it to the spec. And this is where we start to look at Value Engineering and alternates as well. So we look at the spec and we see what kind of devices what kind of IO, is it requiring us to have? Does it require us to have a specific zone sensor? What type? What functionality does that zone sensor require? And as we learn more about that, we then become better able to really understand

Phil Zito 16:03
what it is we're going to be picking for our inputs and outputs. So we figure out what zone sensor we're going to use. We figure out what's required, we pick that, we figure out what relay we're going to use for the heat we pick that we decide that we're going to use a basic VMA controller. We're not sizing it yet, though, we're not sizing it yet, that becomes really important. Now, let's say as we're reviewing the spec, there's some goofy requirement for a four to 20 milliamp sensor. I'm using this because the spec that we use in our courses, has goofy requirements that are purposely in there. Because I want people to go through the RFI RFC alternate value engineering process and discussions as part of the course exercises. I want them to become familiar with that. Because the reality is it's not always going to be cut and dry. Oftentimes, you're going to have to negotiate, you're going to have to say, Yeah, well, this is a school, does it really need this, and here's the additional cost and etc. Now, this also ties back to step one where I said, Did this salesperson give a very specific point by point description of what's provided, because if they did, that scope letter is now a legal document. And you're required to provide those unless you can get an alternate accepted as part of a request for change request for information requests for clarification, whatever process is part of your project vehicle, I hesitate to define a specific process because based on the project, that process may be different. It's not necessarily always called the exact same thing. So you need to be cognizant of that. Alright, so right now we've gone and we figured out our IO, we've listed out our IO, we started to figure out what parts and pieces we're going to put in. And we move on to Step four, which is sizing the controllers. Now we want to build out the controllers, we want to understand, what are we trying to do with them? Are we just looking at the lowest cost solution? Are we looking for potential capacity for growth? Is this a unfinished out space that needs flexibility? What are the outcomes we're looking for in these controllers? What are we trying to achieve? Do we want these controllers to be standalone functionality? Or do we care if they're dependent on a supervisory device, all of these questions we should be asking ourselves, and they will drive our selection of controllers, I almost never will select controllers or architecture. until I've built out the lower layer of the system. Some people like to start at the top and build their way down. I like to start at the bottom and build my way up. And here's my reasoning and logic behind that. You have one server, you let let's say for a building, you have one server, you may have a dozen supervisory devices, you may be have hundreds of controllers, and you may be have 1000s of sensors. If I make a cost impact decision on my sensors, that saves $10 per sensor, that's $10,000. That's a quick hit. And then that changed that selection, maybe I decided to use a network sensor instead of a wired sensor that has ramifications to all of the controllers. Now maybe I need to reduce my controller count. And that has ramifications to my bosses and to my supervisory devices. Maybe I need to reduce my supervisory count. And that has ramifications to my architecture. Maybe my supervisory count now is so low that I no longer need a server. And so you can see by starting at the lower level, I am then getting very crystal clear on what I need to size my system for and it is enables me to reduce costs by going and appropriately sizing from the bottom up. That's always been my approach. And it's worked for me rather well. So at this point, I've sized my controllers, I figured out what I want them to do. And it's at this point that I handle my architecture, which is step five. So here, I need to figure out what kind of architecture do I want? What am I trying to achieve with this project? Do I need remote access? Do I need it to be on a server? Does it tie into a greater, you know, company wide network?

Phil Zito 20:31
Is this a standalone low cost solution? Do I just simply want to display on the air handlers or on the chillers and have them stand alone with no supervisory control? What do I want from an architecture perspective, I first like to look at the supervisory devices. If this is, you know, a low cost standalone solution, then maybe I'm perfectly fine with just doing a supervisory device. And that's it, maybe I'm even perfectly fine with just doing an IP field controller for an air handler for a chiller, and then having downstream units like terminal units hooked up to the field bus of there and keeping the graphics in that actual IP controller. So that is an even more reduced cost architecture choice. So by taking this approach by thinking through, what do I actually want to achieve with my architecture, what are the end goals? What

Phil Zito 21:28
are the client expectations, and ultimately, what's the scope, the spec, the MEP requirements, that will then drive architecture design and architecture selection? In reality, controls engineering. I know this is a bold statement. But for most cases, it's not that difficult. There are some key concepts that we'll cover in a future episode, about valve sizing, about coil sizing about damper sizing. And most of those can be chalked up to equations and rules of thumb. And once you learn those, it's pretty easy to go and do proper sizing of valves and dampers and flow stations and pressure, transducers etc. So the reality is this pattern, or this five step process, while it has nuances when you get into the i o selection, other than that it's pretty plug and play. And so I want you to hear that. Because I find a lot of people really struggle with hardware engineering, they really struggle with, how do I pick the right controllers? How do I pick the architecture? They usually start at that point? How do I pick my supervisory devices? How do I pick my controllers? How do I do IP architecture? Or do I do field bus architecture? What am I doing? And that reason they have that much struggle on that is because one, oftentimes, they're not doing a full spec review, to they haven't started by addressing the physical points, and knowing what they actually have at the IO layer, which then will dictate their controllers, which then will dictate their supervisory and server layers. By starting with that you're going to find yourself in a much better spot, and it's going to guide different kinds of conversations. I know I know, it's easy for me to sit there and say that this is easy when I've done this time and time again, and I've taught it. But it really is just a set of repeatable processes, because what will happen is from a templating perspective, you will start to build out terminal unit templates, you will start to build out rooftop templates, you will start to build out chiller templates. And what will happen is that you can plug those in to your projects. The reality of terminal units, changing their IO requirements is pretty low. It's when you get to the custom air handlers and chilled water plants that you may have some nuances to your hardware and IO requirements. That being said, though, it's a lot easier to say Oh, we've got 100 or 1000 cooling only boxes. This is our standard points list. And if you do this right, if you followed us for any amount of time, you know that we believe in kind of synergistic processes. So if you're doing this right, your hardware templates should align with your software templates. So your hardware templates, your terminal unit templates, etc. Those should align with your system diagrams with your controller diagrams with your electrical details, all of which should be templated and repeatable. They should align with your programs which should be templated and repeatable. They should align with your graphics. Literally you should have standards for everything and then you make minor modifications. So we're really making superficial level modifications to things based on the nuances that are brought in. I really hope you all are following that because that is the key to increasing margin by several percentage points on your projects, and driving much more competitiveness and profitability in your business. So to recap, the five step process is step one released operations project review, we're going to focus in on our documentation, we're going to look through the three key documents, the scope, the specifications, and the mechanical plans, we're then going to transition to take offs, where we're going to understand what our systems are, or what systems exist in our project, and what little nuances they may have. From there, we transition into Step three, where we're going to address our physical IO. And we're going to go and design that, which is then going to transition to step four, which is the sizing of our controllers. We're going to focus in on why are we using controllers? What are our outcomes, and that will drive our selection. And then finally, that will bring us into the homestretch, which is Step five, handling the architecture, where we will go and figure out what kind of architecture we need, and how do we select it. If this is interesting to you at all, if you found this process valuable, and you would like to learn more about controls hardware engineering, you'd like a very defined course that covers everything about it, then I encourage you to check out our controls engineering boot camp, which shall be open for early access enrollment on December 18 2020. there will only be 50 spots available to sign up. You can find out more about that at podcast at smart buildings Academy comm forward slash 231. And like I said, in the future episodes, we are going to be diving through these five steps in greater detail. And then we're going to cap that off most likely don't know don't quote me because it's not guaranteed. But I'm pretty sure we're going to cap all that off with a webinar which will give a high level overview of these five steps. Also, we're going to be discussing this exact topic in our YouTube lives which happened Monday 8pm Central Daylight Time and Wednesdays 8am Central Daylight Time. You can find those by searching the smart buildings Academy, podcast, and or just our page on YouTube. And you can sign up for those. So thanks a ton. I look forward to your feedback and your questions in the comment section below wherever you're listening to this podcast. Thanks a ton and have a great rest of your week.

Phil Zito 27:35
Take care

Subscribe via iTunes

Subscribe via Stitcher

Show notes

Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito Episode 231. Hey folks, Phil Zito here and welcome to Episode 231 of the smart buildings Academy podcast. And in this episode we are going to be discussing the five step building controls hardware engineering process. So you're going to learn how to engineer building control systems at a high level. And then over the next couple podcast episodes, we're going to be diving a little bit deeper into each one of these five steps. This is going to parallel our controls engineering boot camp Early Access Program, which is opening up for enrollment on December 18. If you do hardware engineering, for building control systems, then you will definitely want to check out this course and the Early Access Program. You can find out more information about that as well as the show notes and links to other important pieces of information at podcast smart buildings academy.com forward slash 231 once again, that is podcasts smart buildings academy.com Ford slash 231. All right, so what is the building controls hardware engineering process? How does it work? Where do you get involved? And what are the key pieces of information you need to know about each step? Alright, so the five step building controls hardware engineering process is first step one release to operations project review. Step two is performing takeoffs. Step three is addressing all of the physical IO, and associated devices. Step four is going to be sizing your hardware, specifically your controllers. And then Step five is going to be handling your architecture. I've used these exact, exact five steps to do large projects to do small projects, they pretty much work for any project, you'll run into even integration projects where you really don't have that many physical IO or inputs and outputs. So step one, release to operations project review. Right here, you want to make sure, and this is critically important. I hammered this in all my project management podcasts. I hammer this in our technician courses and our project manager courses. But you need to ensure that there is a release to operations released operations is when the sales team goes to the operations team and says, Hey, we sold a project. Here it is, this is the scope of work. Here's the mechanical and specification documentation that we use to quote the scope of work. Here's the timeline, here's what's expected of you so that you can go and properly execute the project. Now we're going to take a brief segue here, talk about project execution, then we're going to tie this back into controls hardware engineering. One key point that I want you to understand is that control submittals, which are ultimately, a byproduct of the controls hardware engineering process, are usually the first thing that will be done on most controls projects. So whether it's a retrofit project or new construction project, when you're doing it, most of the time, you're creating control submittals first, so being able to properly engineer the hardware is going to be critical to getting those control submittals approved, and ultimately allowing you to make your first billing against the project so that you can get cash flow coming in the project. So I want to kind of tie that in. So what we're looking at the controls hardware engineering process is usually within percentage of completion 10 to 20% of the project. So that's usually by the time that rolls around, you want to be done with your controls hardware engineering process. My hope is that as we move through these next couple episodes, you will get some tidbits, some kind of ideas and strategies on how to really develop a process a repeatable process that can make this a little bit easier and more efficient for you. Because the reality is, if you do not have a defined process, you're not using templates you're not using is basically patterns and templates that you can plug into your engineering process, then you're doing things highly inefficient. Alright, so the first thing we need to know for step one is what required documents do we need? We need the scope of work. We need the actual specification and we need the mechanical, electrical and plumbing plans.

Phil Zito 4:59
So when we review these documents, the key points that we want to focus in on first off are the scope of work. Hopefully, your sales person did not give a device by device and point by point list of what will be provided in the scope of work. I really highly recommend unless it is required by the specification, I highly recommend against that level of detail that really pigeonholes you in to what you need to provide. And while there are a lot of really good sales people out there who are very technical in nature, who have mechanical engineering degrees and electrical engineering degrees, and maybe even came out of the field, the reality is, is that they don't necessarily engineer systems every day. And so for them to be engineering, the scope, getting to that level of granularity to where they define, we're going to provide these kinds of sensors unless it's required to bid the project, one that is costing them sales effort, but two, it's really pigeonholing you into providing a system design that may not be the right system design. There may be things that you learn as you have project meetings. And as you further review the specification and documentation that points out to you, hey, this really isn't the best architecture or I really shouldn't be using these four to 20 milliamp zone temp sensors, I should be just using regular resistive zone temp sensors. So the key focus points, I want you to dial in on our first the scope review of the scope letter. What you want to understand here is what systems are in scope. And this is going to become very important when we perform our takeoffs because we're going to align our takeoffs to the in scope system. So what systems are in scope, what is expected to be done with these systems, were there any hardware or software promises? software, however, is going to go more towards the software engineering, but you still need to be cognizant of it. And what timeline was promised what exclusions and what assumptions were made. All of this should help frame your template document, which is your scope or take off document I like to keep this in an Excel sheet. I like to normally share it on OneDrive, although you can do it on Google Docs as well. That way we have versioning. And multiple people can work off of it, especially if it's a very large project. And maybe you divide the hardware engineering one person is doing the plant one person's doing the air handlers, one person is doing the terminal units. I don't necessarily recommend doing that. I recommend typically one person doing the engineering because systems are interrelated. However, if you have to, you can do that if you use some of those collaboration tools that I mentioned. So we've done our initial look at the scope. Now we look at I it's it's a toss up whether you look at the spec or the MRP documentation first. So by looking at the specification first, where you want to dial in on is a couple things, first in the general category, and I'm going based off standard CSI spec format. So what you want to look at is in the general category, you want to dive into what are the required pieces of hardware manufacturers, what related divisions are quoted in this spec, because those related divisions could drive your hardware like if it's related to fire alarm or lighting, and you need to provide dry contact IO. That's important to understand because then that will go and dictate how you build out your hardware, how you build out your controller layouts, and potentially how you build out your panel layouts. So that's general section one. Now we move on to Section two, which is typically materials. And we're going to look at what parts and pieces are required. This is more of a familiarity glance, because we're going to be looking at this again in takeoffs. And then step three is execution. You want to understand how is this going to be executed? Now, you may ask yourself, why do I care how it's going to be executed for the hardware engineering process? Because let's say that you're expected to use IP enabled controls, and you're expected to execute those as part of the project and you know that it is gears not going to get there before the shell and core and everything is done and the building's conditioned, that may lead you to needing industrial switches to connect your systems. That may be an add alternate that you put in that may be something that you upsell. There's a variety of things that could influence your hardware engineering, then we move on that that MEP set, that MEP set is going to transition us into our takeoffs.

Phil Zito 9:58
So when we Look at the MRP set, I like to immediately go to the equipment schedule. I like to use that equipment schedule to build out my takeoff list. So we'll be starting to migrate to step two right now, which is takeoffs. So I take that equipment schedule and I start to build out my system count. I start to identify my system count, I document what ma p page, it's on, what type of system how many systems? Are there nuances? Do I need to submit any RFI or RFC s? Are these integrations, etc. And then I go, and I look at these system counts, and then I like to validate them against the floor plan. Why do I do that? Well, the reason why is let's say that we have a fan coil. And let's say that fan coils in the mechanical room with the chillers. And I know that now Now I have two hardware decisions I can make. I can say all right, I'm just going to use an IOM module off the chiller controller, and I'm going to use split programming if my controller allows it, if my software allows it. And I know this is a little crossing in the software engineering, but there's little software engineering in all hardware engineering. But I'm going to look at that and say, Okay, do I do a separate controller? So I have standalone for that fan coil? What is that fan coil serving? And then I make a decision standalone controller, or do I use the chiller controller, it's different choices based on cost based on system type building type. Now, let's say that same fan coils right next to that chiller mechanical room, but it's sitting in an IDF room, that would make something completely different now that IDF becomes its own critical asset, right? That's the data panel floor right there that has you know, switches and it gear for that floor. And that becomes Hey, we should probably have its own controller, we should have its own ups, potentially, etc. So we want to understand where things are laid out, because that is going to influence hardware selection, whether we share systems or divide systems. And then from there, once we've kind of made those rough decisions, we've said, okay, we believe we're going to go and use the chiller controller for both fan coils and chillers right in in that mechanical room. Now we go and we look at the specification. So if you followed me so far right, I start off with released operations. Step one, I review my scope, I start to build out my initial takeoff document, I review the specification, then I review the MEP set. Now in step two takeoffs, I've done the look at the equipment schedule. I've looked at the floor plans. I've looked at details. And I'm coming back to the specification again, to go and get a little bit more of a nuanced look at my systems. Is there anything in particular I need to be aware of? And you know, is there something in the specification that says I can't use the additional controller I need to have controller separated? Is there anything specific to my ups is or anything specific to my panel layouts, etc. Right now steps one and two, I'm just gathering information, I'm starting to get a sight

Phil Zito 13:33
picture of what my solution could look like. And this is naturally going to progress us to step three. Now step three, we're going to address the physical points. So we have our systems listed out right we have a full list of systems, maybe we have a chiller, or two maybe some fan coils, maybe some rooftops, maybe some terminal units, whatever. We have them listed on our takeoff document on tab one, then on tabs two through however many, we start to build our systems. And we want to build a system list for each specific system type, not for each specific system, but system types. So if you have a terminal unit with one stage reheat, and that terminal unit with two stage reheat and a cooling only terminal unit, you would have three system types. You may have 100 boxes, but you would have three system types. Now if you come along one of those cooling only boxes that has a alternate humidity sensor as well, then that becomes its own system type as well. So you kind of see. What we're looking to do here is we're looking to build kind of our kits. And it's at this point that I've got my system and I say my terminal unit and we're going to use a terminal unit with one stage reheat. That's super simple system, right. So what I would do is on that new tab on my Excel sheet, I would say Got my terminal unit, and it's gonna have these points. And I would say, okay, it's got a zone temp sensor, it's got, maybe, maybe for whatever reason, we are using a relay to drive the heat, instead of just directly connecting to the contactor. So we got an eye Dec relay or review one see really whatever, while we're starting to go now, and we're building out this points list, and then as we build out this points list, and we validate this points list against the mechanical plans, and ideally, the one line diagrams if they exist, we then go and compare it to the spec. And this is where we start to look at Value Engineering and alternates as well. So we look at the spec and we see what kind of devices what kind of IO, is it requiring us to have? Does it require us to have a specific zone sensor? What type? What functionality does that zone sensor require? And as we learn more about that, we then become better able to really understand

Phil Zito 16:03
what it is we're going to be picking for our inputs and outputs. So we figure out what zone sensor we're going to use. We figure out what's required, we pick that, we figure out what relay we're going to use for the heat we pick that we decide that we're going to use a basic VMA controller. We're not sizing it yet, though, we're not sizing it yet, that becomes really important. Now, let's say as we're reviewing the spec, there's some goofy requirement for a four to 20 milliamp sensor. I'm using this because the spec that we use in our courses, has goofy requirements that are purposely in there. Because I want people to go through the RFI RFC alternate value engineering process and discussions as part of the course exercises. I want them to become familiar with that. Because the reality is it's not always going to be cut and dry. Oftentimes, you're going to have to negotiate, you're going to have to say, Yeah, well, this is a school, does it really need this, and here's the additional cost and etc. Now, this also ties back to step one where I said, Did this salesperson give a very specific point by point description of what's provided, because if they did, that scope letter is now a legal document. And you're required to provide those unless you can get an alternate accepted as part of a request for change request for information requests for clarification, whatever process is part of your project vehicle, I hesitate to define a specific process because based on the project, that process may be different. It's not necessarily always called the exact same thing. So you need to be cognizant of that. Alright, so right now we've gone and we figured out our IO, we've listed out our IO, we started to figure out what parts and pieces we're going to put in. And we move on to Step four, which is sizing the controllers. Now we want to build out the controllers, we want to understand, what are we trying to do with them? Are we just looking at the lowest cost solution? Are we looking for potential capacity for growth? Is this a unfinished out space that needs flexibility? What are the outcomes we're looking for in these controllers? What are we trying to achieve? Do we want these controllers to be standalone functionality? Or do we care if they're dependent on a supervisory device, all of these questions we should be asking ourselves, and they will drive our selection of controllers, I almost never will select controllers or architecture. until I've built out the lower layer of the system. Some people like to start at the top and build their way down. I like to start at the bottom and build my way up. And here's my reasoning and logic behind that. You have one server, you let let's say for a building, you have one server, you may have a dozen supervisory devices, you may be have hundreds of controllers, and you may be have 1000s of sensors. If I make a cost impact decision on my sensors, that saves $10 per sensor, that's $10,000. That's a quick hit. And then that changed that selection, maybe I decided to use a network sensor instead of a wired sensor that has ramifications to all of the controllers. Now maybe I need to reduce my controller count. And that has ramifications to my bosses and to my supervisory devices. Maybe I need to reduce my supervisory count. And that has ramifications to my architecture. Maybe my supervisory count now is so low that I no longer need a server. And so you can see by starting at the lower level, I am then getting very crystal clear on what I need to size my system for and it is enables me to reduce costs by going and appropriately sizing from the bottom up. That's always been my approach. And it's worked for me rather well. So at this point, I've sized my controllers, I figured out what I want them to do. And it's at this point that I handle my architecture, which is step five. So here, I need to figure out what kind of architecture do I want? What am I trying to achieve with this project? Do I need remote access? Do I need it to be on a server? Does it tie into a greater, you know, company wide network?

Phil Zito 20:31
Is this a standalone low cost solution? Do I just simply want to display on the air handlers or on the chillers and have them stand alone with no supervisory control? What do I want from an architecture perspective, I first like to look at the supervisory devices. If this is, you know, a low cost standalone solution, then maybe I'm perfectly fine with just doing a supervisory device. And that's it, maybe I'm even perfectly fine with just doing an IP field controller for an air handler for a chiller, and then having downstream units like terminal units hooked up to the field bus of there and keeping the graphics in that actual IP controller. So that is an even more reduced cost architecture choice. So by taking this approach by thinking through, what do I actually want to achieve with my architecture, what are the end goals? What

Phil Zito 21:28
are the client expectations, and ultimately, what's the scope, the spec, the MEP requirements, that will then drive architecture design and architecture selection? In reality, controls engineering. I know this is a bold statement. But for most cases, it's not that difficult. There are some key concepts that we'll cover in a future episode, about valve sizing, about coil sizing about damper sizing. And most of those can be chalked up to equations and rules of thumb. And once you learn those, it's pretty easy to go and do proper sizing of valves and dampers and flow stations and pressure, transducers etc. So the reality is this pattern, or this five step process, while it has nuances when you get into the i o selection, other than that it's pretty plug and play. And so I want you to hear that. Because I find a lot of people really struggle with hardware engineering, they really struggle with, how do I pick the right controllers? How do I pick the architecture? They usually start at that point? How do I pick my supervisory devices? How do I pick my controllers? How do I do IP architecture? Or do I do field bus architecture? What am I doing? And that reason they have that much struggle on that is because one, oftentimes, they're not doing a full spec review, to they haven't started by addressing the physical points, and knowing what they actually have at the IO layer, which then will dictate their controllers, which then will dictate their supervisory and server layers. By starting with that you're going to find yourself in a much better spot, and it's going to guide different kinds of conversations. I know I know, it's easy for me to sit there and say that this is easy when I've done this time and time again, and I've taught it. But it really is just a set of repeatable processes, because what will happen is from a templating perspective, you will start to build out terminal unit templates, you will start to build out rooftop templates, you will start to build out chiller templates. And what will happen is that you can plug those in to your projects. The reality of terminal units, changing their IO requirements is pretty low. It's when you get to the custom air handlers and chilled water plants that you may have some nuances to your hardware and IO requirements. That being said, though, it's a lot easier to say Oh, we've got 100 or 1000 cooling only boxes. This is our standard points list. And if you do this right, if you followed us for any amount of time, you know that we believe in kind of synergistic processes. So if you're doing this right, your hardware templates should align with your software templates. So your hardware templates, your terminal unit templates, etc. Those should align with your system diagrams with your controller diagrams with your electrical details, all of which should be templated and repeatable. They should align with your programs which should be templated and repeatable. They should align with your graphics. Literally you should have standards for everything and then you make minor modifications. So we're really making superficial level modifications to things based on the nuances that are brought in. I really hope you all are following that because that is the key to increasing margin by several percentage points on your projects, and driving much more competitiveness and profitability in your business. So to recap, the five step process is step one released operations project review, we're going to focus in on our documentation, we're going to look through the three key documents, the scope, the specifications, and the mechanical plans, we're then going to transition to take offs, where we're going to understand what our systems are, or what systems exist in our project, and what little nuances they may have. From there, we transition into Step three, where we're going to address our physical IO. And we're going to go and design that, which is then going to transition to step four, which is the sizing of our controllers. We're going to focus in on why are we using controllers? What are our outcomes, and that will drive our selection. And then finally, that will bring us into the homestretch, which is Step five, handling the architecture, where we will go and figure out what kind of architecture we need, and how do we select it. If this is interesting to you at all, if you found this process valuable, and you would like to learn more about controls hardware engineering, you'd like a very defined course that covers everything about it, then I encourage you to check out our controls engineering boot camp, which shall be open for early access enrollment on December 18 2020. there will only be 50 spots available to sign up. You can find out more about that at podcast at smart buildings Academy comm forward slash 231. And like I said, in the future episodes, we are going to be diving through these five steps in greater detail. And then we're going to cap that off most likely don't know don't quote me because it's not guaranteed. But I'm pretty sure we're going to cap all that off with a webinar which will give a high level overview of these five steps. Also, we're going to be discussing this exact topic in our YouTube lives which happened Monday 8pm Central Daylight Time and Wednesdays 8am Central Daylight Time. You can find those by searching the smart buildings Academy, podcast, and or just our page on YouTube. And you can sign up for those. So thanks a ton. I look forward to your feedback and your questions in the comment section below wherever you're listening to this podcast. Thanks a ton and have a great rest of your week.

Phil Zito 27:35
Take care

Phil Zito

Written by Phil Zito

Previous Post

SBA 230: Cyber Security Basics for BAS

Next Post

SBA 232: Engineering BAS Inputs and Outputs