<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

In this episode, we discuss how to deploy IP controls devices in new construction projects.

Click here to download or listen to this episode now.

Resources mentioned in this episode

Training Video


itunes-button-300x109
Subscribe via iTunes

stitcher
Subscribe via Stitcher

Transcript
Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito episode 326. Hey folks, Phil Zito here and welcome to episode 326 of the smart buildings Academy podcast. In this episode, we are going to tackle the topic of the chicken and the egg deploying IP devices to new builds. Now you may be like, Okay, that makes no sense to me. Well, if you've ever shown up on a job site to install IP controls, you've probably experienced what I'm about to describe to you. You show up, you go, you install your IP control devices, which every manufacturer out there is promoting right now. They're all telling you, you need to go and buy these products. And I mean, they're good. There's a reason why you'd want them. But you go, and you have these IP devices with you install them. And you're like, Alright, where do I connect them to? And you start looking? And crickets, because the IDF is not in so the data closet is not in the MDF, the main data closet, you know, that's not in yet. No switches, no servers, no IT support? How in the world are you going to go and commission all of these IP devices on new builds? Now, those of you have done new build projects, you've probably ran into this from time to time.

Phil Zito 1:31
So the first thing we need to do, in order to make sure we're all on the same page is talk about the three primary IP device architectures. So we're gonna talk about the three primary IP architectures, then we're going to talk about what actually happens when you deploy an IP device, like what do you need? And what do you do? And then we're going to talk about, ultimately, how do you deploy these devices in a situation where there's no IT infrastructure. So first off, in regards to IP devices, there are three primary architectures. And those are the ring architecture, the bus architecture, and the star architecture. So ring is probably the least familiar to you. But you can probably figure out what it is, it's a ring architecture, the devices are in a daisy chain. So it's Ethernet cable to Ethernet cable to Ethernet cable, and in between each Ethernet cable segment is a controller at the end of the left side of the segment. And the right side of the segment is a switching device. And then you have this fancy thing called Spanning Tree Protocol. Or for some of you who are maybe using Cisco switches or switches that support this technology, rapid Spanning Tree Protocol. And what Spanning Tree Protocol does is it eliminates this nasty little thing called a broadcast storm. So basically IP devices, they communicate via broadcast, that's how they discover themselves. That's how they go back to the switch. And they say, Here's my MAC address, and here's my IP address Paris up and build out your ARP table, your address resolution protocol table. The problem is using broadcasts broadcasts go everywhere. Well, if you had a ring broadcasts would go in circles and more broadcasts and they would just never ever stop. And you would have what is called a broadcast storm and the network would eventually crash. So how do we deal with that? Well, with Spanning Tree Protocol, you have what is called a blocking port. And this blocking port is one of the physical ports either on the right or left side. So one of the switch ports that this ring is plugged into, and that blocking port blocks traffic. Now as soon as that blocking port and switch detect that the other side of the trunk is down, so the open port. I'm not going to get into too many technical details on rapid spanning tree. But if y'all want me to talk through that on a future episode, let me know in the comments. And I will definitely do an episode on spanning tree and rapid Spanning Tree Protocol. But simplicity, or as a simple explanation is the blocking port goes and blocks. The open port is open communicating that port that switch detects that the port is down for whatever reason, power, connectivity etc. And that port then is closed and the blocked port opens and it allows for communication. So you get kind of the best of both worlds, right? You get the cost benefits of a bus architecture, which I'm going to talk about in just a second or a daisy chain architecture. But you also get the redundancy of a ring so you get two ports instead of one. And what I've seen a lot of folks do is connect to to disk different switches. So they even have physical redundancy, we're going to talk about how that can definitely be a problem in the fact that there's no IP infrastructure and no IT infrastructure. Alright, so let's continue along. So you've got this rapid spanning tree, ring protocol, great architecture. Great. Now you've got the bus or daisy chain architecture, as you can imagine, it's simply starts off at a switch, and daisy chains along. Now, some supervisory devices enable you to run the daisy chain from the supervisory device, as do some advanced application controllers. They allow you to run the daisy chain, or the ring from those controllers. But you know, it's kind of hit or miss if that's your controller line. So you need to research that

Phil Zito 5:52
the final architecture is the star architecture or the one to one architecture. So by the way, the bus architecture or daisy chain architecture is the lowest cost architecture. But it also has a single point of failure at any of those switches, or any of those controllers to bring down the chain. Because what we have to realize, and this is still the case with a lot of manufacturers, is in a BAS controller, your MSTP bus, your BACnet MSTP serial bus, it is electrically isolated. So it doesn't matter if the power goes are electrically bridged, sorry, doesn't matter if the power goes down on your field controller, the RS 45, BACnet, MSTP, or ft 10. Whatever signal is going to continue along on its merry way from controller to controller, so you lose power the controller with how a lot of the IP controllers were built, they were built with individual network interface cards, and software based switching. So as soon as that controllers power goes down, that IP signal does not continue along. So that's one of the downsides 5g controllers. Now, manufacturers are aware of this. And they're starting to bridge those network interface cards to allow those signals to continue in the case of power loss. But that is something to be aware of with both ring and bus architecture. Now star architecture is one to one. So it's one switch port to one device. This is what we most closely associate our supervisory device networks with. So right we have a supervisory device that has an IP drop, and we do a one to one from one switch port to that device. Now, the nice thing is, if that network were to go down, we only lose one device, right? So we only have one device that goes out. That being said, it's extremely expensive. Because we are using switch ports on some switches on the you know, commercial it side can cost 1000s of dollars. So you're talking hundreds of dollars per port. That can be quite pricey if you're doing a star pattern to everyone. Plus, there's a lot of waste in having to run cables throughout the building to get to these end devices instead of like doing a ring or daisy chain. Okay, so now that we're familiar with architectures, let's talk about how we deploy these things. Standard deployment practices, right, we go we create a network riser, we figure out what of the three architectures we're going to use. And we figure out where we're gonna make our runs to so are we going to run to this IDF closet this MDF closet? How are we going to make our runs, then we need to decide on a IP addressing schema. Now usually we would turn to the IT group for this IP address and schema but the reality is it switchgear is the last thing that is typically put in a building. So their switches, the routers are usually not put in the building till the very end. So and then it has to configure them. So getting an IP address schema is something that we're probably not going to have. So we need to figure out our schema we need to understand how to subnet, we need to say like, okay, are we doing a slash 24? How many devices do we have? How big do we want this broadcast and collision domain to be? Things like that? Do we want to implement VLANs separate subnets per building per floor? What do we want to do? This used to never be an issue, right? You have maybe one sub net for an entire building because you had just supervisory devices and maybe a plant controller. Now when you have terminal unit IP controllers, and everything has an IP address, we start to run into some concerns. I've seen people doing like slash 23 slash 22 networks, which that's 5012 hosts or 1024 hosts on those networks. Now, granted, it's not that many hosts because you have broadcast address and all that default gateway and all that stuff. But you're talking about huge collision domains and huge broadcast domains that could be a nightmare to manage. So my first kind of coaching point here is like, don't go beyond slash 24. Like no slash 23, IP networks, those are bad. They're a, they're not impossible to troubleshoot. They're very difficult to troubleshoot. So right, so now we've laid out our architecture, we built our network riser, our electricians are starting to pull the Ethernet cable, they're starting to connect up our devices. We're starting to deploy our IP addresses. Let's go connect them to the it switch. Oh, wait,

Phil Zito 10:44
there's no it switches. Wow. Well, that sucks. So what are you to do? Well, this used to be quite a difficult conundrum, because the answer would have been, alright, let's grab a 16 port, Netgear switch, let's just let the IP addresses do their thing. And they're not going to be interconnected. And so we'll commission segments at a time, right? We'll do you know, floor one floor to floor three. The problem with that was twofold. One was if you had any logic that like plant the pendant or air handler dependent, and you needed to enter network between switches, it became quite a nightmare. And you found yourself having to use like managed switches to do this, enter the industrial switch, I actually have one kind of sitting over there, I'm not going to pull it out. But the industrial switch allows you to have level layer three and layer two. So layer three is what we really need is that routing capability to go between subnets. Because remember, we don't want to have multiple 512 or 1024, subnets, that's gonna be a problem. So if we have to have multiple slash 24 subnets, and we want the devices to communicate once another, we have to have some form of routing. So layer three industrial switch kind of fits the bill and they're not terribly expensive. Now granted, if you're using a star pattern, that can become a major issue, because you're going to eat up those switches, the industrials usually have eight to 16, ports, tops. And so you're going to eat up your switch ports like crazy fast, if you go and try to do star pattern. So usually you're going to do daisy chain, maybe ring pattern. The problem with those industrial switches and ring pattern is setting up rapid spanning tree or Spanning Tree Protocol. On those switches. If you don't know what you're doing, that's usually something that's done by the IT folks, or it's built into your controller product line kind of hit or miss either way. Now the thing is, okay, we've got these devices laid out, we've put in either our net gear switches, which I don't necessarily recommend, because they're unmanaged, which means they're typically layer two, they have no command line interface, they have no way for you to manage them, no way for you to set up VLANs no way for you to set up routes, no way for you to manage your network, hence the term managed switch or unmanaged switch. Additionally, there layer two. So while IP traffic can go across layer two, it's actually going across in the form of Ethernet frames. So it's not IP packets, it's Ethernet frames, and it's on that local physical LAN and subnets. Okay has to be a physical land unless you're using VLANs, in which case, you need layer three switches, and it just becomes a nightmare, right? So here's the thing, though, you have your physical lab, you have your switches set up, you've got all that communicating. And that's all well and good. But you have to go and find a way to connect, as I mentioned, the industrial switch allows you to do that, because it's a managed switch. It's layer three, but you have to go and understand how do I go about actually commissioning and or setting up the routes? How do I do all this? So you need to get a product, I'm not going to make product recommendations. But you need to get a product that is easy to use, ideally has a graphical command line interface instead of a textual command line interface. Okay, so we've got that done. We've got our IP devices deployed, we've got everything communicating to a point probably not ideally how we want it to be on the production network production meaning the final network, but for you know, a deployment network, it's okay. Now the IT group comes in. This is where things get a little difficult. Now you need to have a cut over strategy. So you have to have a strategy now One physical cutover How are you going to rewire these switches? Ideally, these industrial switches or neck gear switches are in the same data closet as the it switches. So it's just a matter of having a coiled up extension of the wire and just disconnecting and running. Now this will take your network down temporarily, so you need to be cognizant of that and you need to plan accordingly. Additionally, what we also have to account for is okay, what if the IT group comes in and says, you know, used one, nine 2.16 8.1. But

Phil Zito 15:34
we want 192 dot 168 dot 10 for your slash 24. subnet. Now you need to re address everything. Now a lot of controls manufacturers support bulk readdressing. But that still is a problem. So these are things you need to start to think about, like how am I going to stage these things down? How am I going to re address? Do I need to reroute things? from a logical standpoint? Do I need to set up new routes? These are all things that you need to consider when deploying IP devices. So in a nutshell, deploying IP devices to building automation, it's not near as difficult as it used to be. That being said, there's a lot that you need to think of when you're going about deploying these things. And you need to be cognizant of them. If you have any questions do not hesitate to reach out in the discussion section. Wherever you're watching this, maybe it's comments, maybe it's discussion. Maybe you're watching this on our site. And if you're listening to this, then definitely go to podcast smart buildings academy.com For slash 326 Once again, this podcast at smart buildings academy.com Ford slash 326. And I'd love to hear or see read your comments and questions. Thanks so much for listening and watching the podcast. I appreciate you all being here. And I look forward to seeing you in Friday's episode. Thanks a ton and take care

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?

 

BE A GUEST