Hey folks, Phil Zito here and welcome back! Today, we are going to be discussing BACnet IP versus BACnet MS/TP.
You know, I was in our BAS Sales Bootcamp recently and one of the students asked about BACnet IP versus MS/TP, what are the pros and cons? I realized that we haven't really done a post about that. So that's what this post is going to be about.
If you're interested in getting a no BS assessment of why you would use BACnet IP or why you would use BACnet MS/TP, then stay tuned because that’s what we'll be discussing.
So, as I started to dig into this topic, and I started to kind of just do the initial Google search, I started to come across some really goofy advice. I found “reduced programming time BACnet MS/TP or LON can take hours to communicate between controllers, whereas BACnet IP only takes minutes and BACnet MS/TP can take seconds. Well, BACnet IP could take seconds, in some cases, it can take minutes. I've yet to run into a functioning BACnet MS/TP network that takes hours.
So, there's this goofy advice out there like,
“Common scripting languages can be used.”
What does that even mean?
Then you get into things like,
“BACnet MS/TP can be more difficult to troubleshoot.”
Maybe, but I would argue BACnet IP can be very difficult to troubleshoot, if you don't know what you're doing, or you don't understand IP.
Then you'll have things like,
“BACnet IP devices aren't susceptible to communication issues, with only one device affecting multiple devices.”
Well, not really. Not if you are running a Bus architecture, or potentially a ring architecture, and both Spanning Tree Ports goes down.
Before we really dive into this, because I know some of you need a breather, before we dive into any of that, let's do a quick primer on MS/TP and IP. Then, let's walk through the benefits and the cons of both, and kind of what I would deploy If I were you sitting there figuring out, what to implement.
At the end of the day, I'm not selling you controllers. I'm not selling you services for installations. I have no need to convince you either way to go MS/TP or IP. I'm pretty unbiased when it comes to this topic.
So, MS/TP, our tried and true rs485 wire standard, three to four wires. It hops from supervisory device to controller, to controller, to controller. It uses layer-two communication using a token to communicate between the controllers. The controller gets the token and it can send messages or receive messages.
That's how BACnet MS/TP works. Because of that, we're typically limited to some slower communication rates, which are baud rates. You would say, similar to modem speed baud rates, right? 56k? But, as I say, in all my podcasts, I'm not going to memorize something that I can Google. I'm not going to put it into my brain when I can just Google BACnet MS/TP baud rates and get a table. There’s no reason for you to memorize that. There’s no reason for you to memorize that.
So, MS/TP, it communicates across the controllers, and they can have a run. Some of the sites are going to say 128 nodes. No, it could be 96 if you're following the rs485 standard across three segments at 3300 feet or more. Anything more than that, you're not guaranteed to get the results, no matter what your OEM tells you, because you're violating the rs485 standard on which MS/TP is dependent upon. So just be cognizant of that.
Also, polarity comes into play if you cross wires because it is volts DC communicating, so if you cross wires that could be bad. If you don't punch down properly, that could be bad on the controllers.
At the end of the day, it's pretty simple to set up. You just run the wires, you connect the controllers. Ideally, you address the controllers using MAC addresses that are in series. So, that's what you would do.
Once you've done that, once you've addressed the controllers, you turn them on, and they should all communicate. Pretty simple. And simplicity is king, especially in today's market where we have a lot of unskilled labor because we have a labor shortage. We have so much backlog that we're putting people out there to do work, and we need that simplicity.
Then on the other side, BACnet IP, it uses IP addressing to communicate, and you discover using a Who is/I am discovery message, map them in. As long as everything is on the same subnet, pretty good. When things get off on to different subnets, you need things like BBMDs and BDTs. I'll put some links into my BACnet resources in case you don't know what a BBMD and BBDT are.
But suffice to say, BACnet IP, it's going to be a little faster and have some better communication. It can, in some cases, be more reliable. In other cases, it can be less reliable. Some cases it can be easier to troubleshoot. In other cases, it can be harder to troubleshoot. In some cases, it can be faster. In other cases, it can be slower, and you’re probably thinking, “What? I've never heard slower.” In some cases, it can cost more, but in some cases, it can cost less. So therein lies the rub.
Most of what you see about IP is going to be pushing you to IP controllers. Why? Because that's what they're selling. They're selling IP controllers, they want you to buy IP controllers, they need you to pay off their R&D costs associated with IP controllers.
Now, that's not to say that IP controllers are not better. There are many ways that they are better, but it comes to a point of diminishing returns. If you are getting a contractor, or someone who's advising you, to do all of your VAV boxes with IP-enabled controllers, I’d be like, “What? Really, why?”
Is it because I can download programs faster? How many times am I downloading programs? Is it because I can have IP supervisory device enabled capabilities like graphics and all sorts of stuff in my controllers? They’re VAV box controllers, people. They don't need to be that fancy.
So, let's start to list out the pros and cons, and this is in no particular order. We're going to go IP first, pros first, then cons, and then we're going to do MS/TP pros, and then cons. Finally, I’ll give my closing thoughts.
IP Controllers - Pros
IP controllers are definitely faster. The average IP controller is anywhere from 10 megabit to 100 megabit, typically. That is significantly faster than MS/TP controllers, which are going to be anywhere from 36,000 to 76,000 baud. Baud is different than bits, just be cognizant of that. Baud is the state change of a bit, and when we're talking about Ethernet, we're talking about bit transfers, whereas baud is state change, signal change.
So, it's not a direct comparison. Anyone who tells you 76k is a direct comparison to the megabit, or kilobit, on an Ethernet side doesn't know what they're talking about. Suffice to say, Ethernet IP is significantly faster. It means that you're going to be able to send data faster, you're going to be able to download programs faster, but you will also be able to send more data, which means that you can send graphics, alarm data, and all sorts of stuff.
I'll talk about data packets and data sizes, and why this isn't that big of a deal. But the real thing about IP is it enables you to use higher level protocols like HTTP or HTTPS. So, you can do web services, you could do things like use SNMP, you could do trapping. You can do all sorts of stuff that you really can't do over MS/TP.
It’s not because of the baud rate, but rather because of how it works, how it's a serial communication using tokens. It's not meant to support IP traffic, which is layer-three, TCP traffic, which we need for HTTP, which is layer-four, and HTTP traffic, which is a layer-seven protocol. So, we can't support those things with the serial networks.
Now, some folks will argue that IP is more scalable because you can put 256 controllers on a slash 24 network. You could potentially, and I don’t know why you would do this, but you could do like 509 controllers on a slash 23 network, I don't know why you would do that. That would be a very unwieldy subnet and be very difficult to troubleshoot all that traffic, but you could.
So, in theory, you can have these ginormous subnets, filled with controllers, and these IP addresses DHCP, and everything can be working really well. It's scalable and you can just keep expanding it. You're not tied necessarily to an MS/TP trunk and its 96, not 128, 96 node limit.
Next, we come to troubleshooting. Now, I will agree that troubleshooting IP is simpler than troubleshooting MS/TP, to a point. If you're running a star pattern, which is an end run from a switch to a host device, it's a single run. It's pretty easy to troubleshoot as it's either up or it's down. Troubleshooting your IP packets, they're either malformed or they are not. It becomes simpler to troubleshoot. So, from that perspective, there is a benefit.
Supervisory capabilities. A lot of when you hear me advocate for IP controllers, it's going to be on air handlers and central utility plants. Because of the supervisory standalone capabilities that come with most IP controllers, where they have graphics built into them, they have trending, alarming, all sorts of more advanced capabilities. This is so that it could run as a standalone controller, if your connection to your supervisory device were to go down for whatever reason, you could effectively run that air handler, and its sub-devices off that advanced application controller.
IP Controllers - Cons
Alright, so then what are the cons of IP controls? Well, price, they do cost more. That cost is coming more to parity with non-IP controllers, and eventually, you're going to be forced to use IP because they're going to phase out MS/TP, at least at the central utility and major air handling unit controller level. So, your large capacity controllers eventually will be IP only, it's just a matter of time.
So cost, the actual cost of the wires, it does cost more. You will be told that you can run IP controllers and you can run the cat 5 cable, cat 6 cable for less, because it's extra low voltage, but that's not true. You're going to have to, in a lot of unionized cities and metropolitans, pay the same sparky the same rate to run that wire.
Now you're going to probably have to put it in an actual cable tray versus j-hooking. You can run Ethernet over j-hooks, but it's not preferred. Some people will say that it's easier to terminate, right because you have to terminate the rj45 heads. I would argue that it is the same level of difficulty whether you're terminating three to four wires onto a terminal strip or you're putting eight wires into an rj45 head and crimping it down. Either way, you're terminating and either way, you can mess it up, and I would argue that terminating rj45 heads is going to be more difficult.
Do not buy pre-terminated cables, just do yourself a favor. It's going to be more difficult, because there's eight wires you can mess up versus three to four wires that you can mix up, and you're doing this in the plenum, and it's going to be confusing, and you're going to potentially mess it up.
Now cost, also, you have a switch that you have to pay for. If you're doing star pattern, you could be paying tens to hundreds of dollars a switch port, per year, to have access to that switch port. Now, granted, there are things like the bus pattern and the ring pattern, and they enable you to have wires. Basically, the bus pattern is a daisy chain pattern that enables you to run a series of controllers and daisy chain from one to another.
The problem is that unlike with MS/TP, where things are electrically, signals going across the wire, and if the controller loses power, the signal will continue across the wire. With a lot of IP controllers, they use network interface cards inside them that are not electrically bridged. So, if one of those controllers powers down, everything downstream from it dies.
For this reason, we came out with the ring architecture where you have one port that is open and the other port that is closed, also known as a blocking port, rapid spanning tree, or Spanning Tree Protocol. When it senses that the open port is down, it opens the blocked port, and that enables you to have communication up to the point of the dead controller, but you still will have a dead controller potentially blocking your ability to communicate.
Now, a lot of manufacturers are working through this. They're solving the electrical issue. But be cognizant that it is something that still occurs.
Let me briefly touch on IP security. How do I address, this because if you’ve read these blogs or listened to my podcasts for any amount of time, you know my feelings about BACnet Secure Connect. You know my feelings about security when it comes to controllers and the overkill that is,
“The Government DOD or major pharmaceutical said we're not secure. We lost one job and our top salesperson complained about it to the products group and now the products group has implemented this secure connect and is going to force it on everyone. We’re going to solve this small problem with a giant mallet and not with a precise needle point hammer. We're going to apply security to everything, regardless of whether there's even a threat. That basically means that we should have that level of security, and now we're going to put this new depreciated form of security on top of everyone.”
Now, this isn't me railing against BACnet/SC. You don’t have to agree with me though. You can take your own stance. I just think it's a bad idea. It's coming, whether I like it or not, everyone's going to have to learn it, everyone's going to have to do it, because it is being forced into specs by people who don't know better. In my opinion, once again, that's my opinion. But IP does enable a better layer of security because you can do Point to Point VPN, you can do IPSEC, VPN, stuff like that already.
MS/TP - Pros
Now let's talk about MS/TP tried and true. Most people know how to use it. Pretty straightforward, it's got a lot going for it right? Controllers are a little cheaper, the wire is pretty cheap, you just connect it to a supervisory device, you don't need a switch. So, it's got some definite price benefits.
It is reliable when properly set up. I've went to sites that had 10-20 year installs, and they were running good because people actually numbered their MAC addresses sequentially, kept their wires clean, weren't doing crazy things just follow the rs485 standard, and it ran fast enough. Yes, it is a little slower when downloading initial firmware or downloading your programs, but when we're talking about read and write properties, which is pretty much the only services we run with BACnet, except for maybe a COV service, then it's plenty fast. Considering our poll times are normally a minute anyways, plenty fast update graphics. Speed of data reporting should not be your primary reason for going to BACnet IP.
MS/TP also has the ability to be troubleshot, in my opinion, pretty easily. There's only a handful of things that can go wrong, and they're all usually electrical. Meaning that, you can go and troubleshoot them with your meter and figure out most of what's going on, without having to go into Wireshark, without having to know how to read packet captures, all sorts of stuff. You don't have to deal with it.
That is a definite benefit, you don't have to deal with the IT group, you don't have to size switches, you don't have to wait for the FF and E budget to actually put switches in the building so that you can commission. You don't have to be carrying around industrial switches for temp switches, that way, you have a temporary switch, so you can commission the system. A lot of benefits there.
MS/TP - Cons
Now, let's get into the negatives. BACnet MS/TP is slower, and because it's MS/TP, because it's a layer-two communication, it cannot communicate HTTP traffic. So, you're not getting graphics over MS/TP, not going to be running SNMP traps over MS/TP, not going to be doing the analytics, typically direct from the controller, across MS/TP.
You still collect the points in the supervisory device and run analytics, but you're not going to be doing it at the edge. Honestly, doing analytics at the edge in the controller, and then saying, “Well, there's so much traffic that we're going to do the analytics in the edge, in the controller, prior to sending it up,” because that's like some big deal. Because somehow, we haven't built computers that can process our miniscule amount of data that a building automation system produces.
Let me be clear, even on the largest of large sites, BAS systems are miniscule in their data production, compared to other sites. Let's just be real, we're talking about seconds where we have change of value, to minutes where we have change of value. We're not talking nanoseconds, like stuff in the industrial world.
Okay, another thing that we need to be clear about with negatives is going to be the fact that you do actually have to wire this stuff up right. It has points of failure, right? You can wire them up wrong, you can reverse polarity, you can mis-address stuff. It's kind of hard to do all of that with IP. You can mis-wire with IP, but you're not really going to mis-address, and you're not going to do t-taps and things like that.
Finally, we are losing the ability for security. Now, once again, I will argue that with MS/TP, if someone is up in your ceiling, hacking into your serial network with a rogue device, what is your real issue? Is it the lack of security at the MS/TP system, or is it the lack of physical security that someone is literally in your ceiling, or in your mechanical room breaking into your network?
I would argue that you have a PHY-SEC problem, not a product problem, but it's easier to point the fingers and say that you have a product problem. It's just easier to do that, plus it creates a problem to solve which means you have to sell new hardware to fix that problem.
You have to say, “Hey, do you want BACnet Secure Connect? Well guess what, your controllers that are running it, they either are going to need this overlay gateway that we're going to sell you because your controllers can't be updated, or you're going to have to update all your controllers so that they can support the firmware that runs at Secure Connect.” That's the only way you're going to do it.
Can anyone say product sales? Yes. Repeat that with me, “PRODUCT SALES.” Can you tell I'm a bit disappointed with BACnet S/C? Yes, I am.
Alright. That being said, let's talk about my thoughts and my scenarios, because this is getting a little bit longer than our normal posts, and I want to kind of close it up for you.
My thoughts:
BACnet IP, definitely use it for central utility plants and major air handlers, especially if your controller line on the major air handlers has secondary MS/TP trunks and you can run that to the associated VAV boxes that are served by that air handler. That's a beautiful installation. It's kind of best of both worlds.
Then you just pull those IP controllers from the air handlers. Ideally, those would be like a ring or a bus. I wouldn't do a star pattern on those. I would do a ring or a bus. Unless it's critical, then I would do a star pattern. Then, bring those to a switch, and then I would connect the supervisory device to the switch, and we'd map everything in IP and then we would call it a day.
Then for the central utility plant, I would do a star pattern. So, direct end-to-end run from the switch to the central utility plant controller. That would be my approach. I would avoid terminal units, I would avoid fan coil units for IP controllers. It does not make sense to me to do those.
Also, if you ever want to add someone else's controllers, everyone has an MS/TP line, not everyone has an IP line. So, you can easily add MS/TP controllers, especially if you find some legacy controller somewhere.
So that's my two cents. You don't have to agree with me, and I encourage you not to agree with me. I'd like to know your thoughts. Why do you want to use BACnet IP over MS/TP? What did I miss? What am I all wet on? So, leave your thoughts at the end, and let me know about what you think in regard to BACnet IP versus MS/TP.
There you'll also find a link to our BACnet Bootcamp. If you want to get up to speed on BACnet, this is the best way for you to do that completely online, completely fast, and completely good.
Thanks a ton! Take care.
