Hey folks, Phil Zito here and welcome back. In this post, we are going to be going through how BACnet really works. We're going to dive through what BACnet is, we're going to talk about BACnet objects, BACnet services, BACnet profiles, BTL listings BBMDs, BDTs, BACnet IP, and BACnet MSTP.
So, how does BACnet work? Well, BACnet is a protocol, right? What is a protocol? A protocol is a set of rules for communication between devices. Now, whenever I start to think about unpacking BACnet, it's just overwhelming.
First off, like why should you listen to me about BACnet? Well, I've written BACnet stacks. I've written BACnet integrations. I've worked with manufacturers like Cisco, Cree, and Molex, on writing their BACnet stacks. I've done a lot of critiques on things like BACnet SC. So, I'm really well versed in BACnet.
BACnet is the predominant protocol, despite what people may say. Things like KNX, LON, DALI, CAN bus, Modbus, CoApp, MQTT, while they are protocols that are used, they are not the primary protocol that is specified across the globe. They are more like regional protocols. So, it's important for us to understand.
BACnet is ASHRAE Standard 135, for those of you who don't know. You can actually purchase the standard and read through all, like, 1900 pages. I've actually read the standard. It's quite informative, but overwhelming.
It still amazes me that to this day, so many folks struggled to really understand what BACnet is. At its core, BACnet is an object-oriented protocol that enables you to establish objects, of which there's many. But we're going to focus on the four to five primary objects:
- Device Object
- Analog and Binary Input Objects
- Analog and Binary Output Objects
- Analog Variable Objects
- Binary Variable Objects
We're not going to focus in on the trend or alarming, or any of those objects, because they don't necessarily apply on a day-to-day basis.
So, in a nutshell, a BACnet object is a device, and a device is going to have sub-objects. A BACnet device could be something like a BACnet controller, a BACnet supervisory device, etc, and these BACnet devices, they're objects.
So, a controller is a device object, and the device object has sub-objects, which are like an analog input and analog output, an analog variable, binary input, binary output, binary variable. They also have services, and these services are things like read-property, write-property, read-property multiple, who is, who has. Some of these services are fire and forget services, some of these services are broadcast-oriented discovery services, etc.
So, now we have our BACnet services. In a nutshell, when you have a supervisory device, and you attach a bunch of BACnet devices to it, maybe in the form of like an MSTP bus or an IP connection, then what happens is there is this Who-Is/I-Am discovery. This discovery service is a broadcast service. In the case of MSTP, not a big deal, it just travels down the wire and the machines that get the service request are going to respond with an I-Am, so it's called Who-Is/I-Am. Who-Is gets sent, and I-Am gets responded.
Then, that master device that all these devices are responding to, it builds basically a list of BAC nodes, BAC nodes being BACnet nodes, because devices are called nodes in BACnet. So, it builds this list of BAC nodes with their associated address.
Now, that's awesome because what that allows to happen is, now the supervisory device knows where all the BACnet devices are, and their address, and it can route via the BACnet link layer. It can create this basically logical link and it can initiate services. So, for example, a service like read property, that would be a complex but non-acknowledged service. You’d read property, and then the property result would be sent back, whereas a write property is complex knowledge. Write property is where you write the property and then you get the acknowledgment back that the write is received.
Either way, you're getting acknowledgments back, right? These aren't fire and forget services.
But in a nutshell, what happens is you do the Who-Is/I-Am discovery that build touching BAC nodes, and then remember, BACnet devices are objects and they are objects that have objects. So, then you have this other discovery service, which is called the Who-Has/I-Have.
Who-Has/I-Have is a discovery, where now, the supervisory device is going to interrogate the device. And this is why, if you do like Niagara, you'll often see where you'll discover the BACnet devices, and then under each device, you'll discover the BACnet points. That's because you're doing a Who-Is/I-Am and then you're doing a Who-Has/I-Have, and the Who-Has/I-Have builds out a sub list under each Bac node of the object.
So, once you've built out that sub list, now all of your services can actually communicate. Now why do I go this deep with you? Well, it's important to understand this object-oriented structure, so that when we later discuss the actual protocols, the MSTP, the IP, that we understand how these protocols are functioning. We're going to get into things like BBMDs and BDTs with the IP-oriented architecture, and you're going to start to learn like that BBMDs and BDTs are important for those discovery services that use broadcasts. They're not necessarily important for those unicast or multicast messages, which we'll learn about in read property or read property multiple.
Unicast is a one-to-one message, that'd be the supervisory device sending that read property service request to the field controller, and then the field controller responding. Multicast would be like read property multiple you. Let's say you're in Niagara, and you highlight a bunch of controllers. You do a query for zone temp for all of these controllers. What happens is, that server communicates to the supervisory device, initiates a read property multiple service, and then that is a multicast. So, single point origination to multiple endpoints and those endpoints are pre-determined because we built out our BACnet nodes.
Alright, so we should, at this point, understand BACnet device objects and sub-objects, Who-Is and Who-Has services for discovery. Now, we're going to pivot BTL, BACnet Testing Laboratories. We're going to cover BTL listings, BTL profiles, BIBBS, Protocol Information Conformance Sheets (PICS), and then we're going to shift back to our actual forms of protocol communication, which are IP and MSTP.
BTL listing is where someone from the BTL testing lab will come to you. So, you can go to bacnetinternational.net/btl which will bring you to the BTL Listing of Tested Products.
From there, I can browse by Device Profile which shows me Operator Interfaces, Operator Workstations, Advanced Workstations, and then I’m going to see our controllers. I’m going to see the B-BC, which is most commonly associated with supervisory devices. It's a building controller.
Then I’m going to see the B-AAC which is most commonly associated with most of our controllers as the BACnet Advanced Application Controller. Most of our controllers are AACs. Then I see ASCs, and this is more closely associated with things like our BACnet VSDs. So, our BACnet VSDs, or BACnet ONICON Flow Meters, those tend to be application specific controllers, right? We have things like B-RTRs, BACnet routers, and we'll cover routing shortly.
So, I’ll go to B-AAC, I’ll just choose Alerton, the Alerton Advanced VLC, VLCA-1688. 0 advanced VLC.
I'm going to go to its BTL listing, and I'm going to see that is data sharing. It has ReadProperty A and B, and I don't remember off the top of my head if A is server and B is client, or B is server and A is client, but basically, it's really important for us to have with a lot of these controllers, both A and B functionality.
If I'm remembering correctly, server is ability to serve up the resource to respond, and client is the ability to initiate the resource request. So, if I only had an A capability, I would only be able to respond, and you'll see that in a lot of ASC’s profiles, you'll see that they have A but not B. That's because they have the capability to respond to ReadProperty requests, or WriteProperty requests, or COV requests, but they do not have the ability to initiate those requests like I could with an AAC where I could connect to another controller using a network link. I could initiate ReadProperty requests of another controller, like if I was doing a global outside air temperature share and I wanted to request that, so it's important to understand the BIBBS.
If you’re unsure of what BIBBS are, there’s a really good BACnet book on Amazon, and if you read it, you'll have a really solid understanding of BACnet. There's also the ASHRAE 135 standard, which is like 1900 pages. If you want to dive like super deep into how the protocol works, you can read that as well.
Alright, so this Alerton profile gives us our BIBBS, our BACnet Interoperability Building Blocks. This is how our device profiles are built and then the BTL folks come along, and they go into the product organization. They test and ask you to show them certain things, and they have a test for each BIBB. The profile needs to be able to conform to specific BIBBs for the profile.
Now a lot of folks will say to me, and I get this pushback quite often, that BACnet’s open. It's not really open because I still need Manufacturer ABCs programming tool to program the controller. Therein lies one of the rubs with like BACnet vs LON. LON had, at least with their application specific controllers, plugins where you'd have an LNS software, and you would use the plugin which would enable you to just simply modify the controllers. I can't think of a single software out there that does not have a specific programming tool for their field controllers, and I don't think that's going to change anytime soon.
That's not a limitation of the BACnet protocol because the BACnet protocol is not meant to implement a programming methodology. It's a communication and data organization methodology and protocol format. So, I don't see us getting an open programming tool that enables us to program everyone's software, ever. I don't ever see that happening. I mean, you'd have to have a universal firmware, and a universal programming software that every manufacturer would have to agree upon. So BACnet is not a proprietary protocol, in that that software is not able to be programmed. That is a limitation of the market, not of the BACnet protocol.
Alright, so now that we understand BTL listing, we understand how those things are created. So, if you ever show up on a job site, and you have a York rooftop unit or Trane rooftop unit, and you want to figure out what the unit can do, find out if it's been BTL tested. If it's been BTL tested, then you should have a BTL listing that tells you the BIBBs and tells you what aspects it should support.
Now, some BTL listings are better than others. I know that it really just depends on the tester you get. Some of them will really push you to create a points list. Some manufacturers will provide an entire points list in their detail listing. Other manufacturers will literally just provide a list of BIBBs. So, you need to understand what capabilities the unit has, but that would be the first thing I check.
If I had to work on like a chiller or a rooftop unit that had embedded controls, I would check if it had a BTL listing so I could understand what BIBBs, in theory, should support, then I would find its BACnet points list. I would understand the difference between AIs, AVs, and AOs, and BIs, BVs, and BOs, and I would understand like how all of that works.
In theory, if you have a V, that's a logical point. That's a variable. So that should be a set point. An O, in theory, that should be a physical output, and an I should be a physical input. So, inputs, they don't have this concept called a priority array, but outputs and variables have this concept called a priority array.
Priority arrays are one of the main things that differ in inputs vs variables and outputs. Variables and outputs, the thing with those is, in theory, if you're doing BACnet right, you should be using variables for your set points in logical, like network shares, etc. You should be using outputs for physical points. I see on a lot of embedded devices where they'll use outputs in lieu of variables.
Also, back when I was in the field, and I had techs working under me, I would get a lot of calls from my techs saying,
Tech: “I can't get this to work.”
Me: “Well, why can’t you get it to work?”
Tech: “Well, the set point’s not changing.”
Me: “Well, what point are you commanding?”
Tech: “Well, I'm commanding AI, whatever.”
Me: “Well, you're never going to be able to command that because it doesn't have a priority array, it only has a present value. So, you're never going to be able to command that point. You've mapped in this device, you've mapped in AIs, and you're bashing your head against the wall, and you're never going to be able to change anything.”
Let's move into kind of the communication methods for the protocol. So BACnet MSTP, master slave token passing, that is RS 485 standard. If you're adhering to the RS 485 standard, which I really encourage you to do, because I've yet to run into a network properly wired, following proper RS 485 standards, that doesn't work. The RS 485 standard is 3300 feet, across three segments, 32 devices per segment.
Now, you'll run into manufacturers that can say 5000 feet, 100 devices, and 3 segments. So you have 15,000 feet, which one is right? Well, in theory, their stuff can usually work, you will start to get some degradation after you pass those RS 485 standards, but if you increase the baud rate, baud rate is the rate at which communications communicate on serial networks, you're going to get faster flow. You can overcome length in some cases.
Now there are two agreed upon baud rates: 9600 and 38.4k. Those are the two default baud rates supported by BACnet that are required to be supported by any BACnet device. So, like if you have an ABB drive, or you have an ONICON Flow Meter, and they're MSTP, and you can't figure out which baud rate to work with, if you try 9600 or 38.4, one of them is going to work.
Then you have addressing for your devices. We use DIP switch Mac addressing, which is a layer two address, not to be confused with Ethernet frames. Our MAC addresses layer two communication on a serial network. Serial means device communicates one after the other in series, not in parallel, in series. No TTAP.
So, you started the supervisory device and you run this MSTP trunk. It’s typically a three-wire trunk, typically 18 or 22 gauge, stranded twisted pair. You're running this wire, typically you will have a positive, negative, and a calm or reference, and then a shield. The shield will get terminated on one side to ground. You don't terminate the shield on both sides; that creates an antenna.
From there, you run making sure you're doing polarity sensitive from device to device in what's called a daisy chain. Daisy chain is from one device to another, positive to positive, negative to negative, reference or calm to calm. You do that and you should have about three-ish volts DC.
Now you're going to communicate typically 3300 feet, 32 devices, and then what do you do after that network segment? Enter the repeater. The repeater cleans the noise off the electrical signal and repeats the signal moving forward that enables you to extend your network segments.
So, there are repeaters and routers. Routers are going to exist to enable you to typically take an MSTP network and convert it to an IP network to route. Then there are repeaters, and they are just repeating a serial bus network and extending the communication of the network.
Now when it comes to addressing, you have to have a unique address. It's usually 1-127, I believe, are master addresses, and then 128-255 are slave addresses. Slaves are typically of the ASC profile, meaning that they can respond, but they cannot initiate. Master devices are ones that can initiate and respond.
Now I say initiate and respond, so what do I mean? Well, here comes where the whole token comes into play. The token is essentially a little piece of software that gets passed, via the wires, from device to device. When the device is holding the token for a certain amount of time, and you can set how long devices can hold the token, but as long as it's holding the token, it can initiate the service requests. The client initiates the service requests, and the server responds. When it's holding the token, it can do that.
That's why it's also important on really long runs to sequentially number your MAC addresses, because the tokens typically will go sequential, it'll go 123456, and if you're like 1, 80, 70, 20, 30, not such a big deal on a short run, but on a longer run, it can introduce delay, especially if you're like 9600 baud, which is pretty slow communication. A lot of folks tend to be much higher baud rate, but those slower baud rates, just be cognizant that if you don't number your stuff in sequence, you're going to start to have communication issues.
Next, we have these concepts called end of line. End of line act as dampening. They basically dampen that electrical signal and keep it from reflecting back onto the network. The nice thing about MSTP vs like IP-BUS, and manufacturers are fixing this, but the MSTP is electrically bridged. So, if a controller loses power, it is going to continue on to the next controller along the wire. Whereas with a lot of IP controllers, even Bus and Ring, if the controller goes down, since their using network interface cards, things aren't electrically bridged, and you'll actually lose communication, and the whole bus will go down. Hence why we have Rapid Spanning Tree Protocol and Ring protocols on BACnet IP. They enable us to basically say, open up the blocking port, turn off the passthrough port, and allow the ring to communicate the other way to bypass the broken controller.
Okay, so we have our MSTP, we have them wired, we have our polarity done right, we're addressing our MAC addresses sequentially, not duplicating MAC addresses, we have baud rate, and then we have our device ID. So, there's several properties for the objects. If you really dig into BACnet objects, BACnet objects have several required properties, one of which is the device ID. The device ID plus the MAC address becomes the BAC node address. In the case of BACnet IP, the device ID plus the IP address becomes the BAC node address. That becomes your BACnet address.
That's why you can't have duplicate MAC addresses or duplicate IP addresses with BACnet. You will have issues with communication, because now you have duplicate BAC node addresses, and you'll have what are called blinking addresses. While this is not good, it's survivable on a BACnet MSTP or IP network as long as the supervisory device is not the duplicated address. If the supervisory device is the duplicated address, because that's the container of the BAC node, you're going to lose all of your devices. It's going to flicker on and off. If it's duplicate addresses device ID, or duplicate MAC addresses on the field controllers, not the supervisory device, then it's going to be bad, but it will only typically affect those two controls.
Things that will affect the entire network will be things like mismatch polarity in the wiring, mismatch baud rate, which is going to cause crazy amounts of collisions, especially as you get higher up in the baud rates in the mismatches. If you have a bunch of devices that are 9600, and you have one that's 114K, that’s going to cause a ton of collisions.
Alright, so that's BACnet MSTP. BACnet IP is where a lot of people lose their minds. As an industry, we have a pretty poor understanding of IT and IT knowledge. Then you combine that with things like routing, BBMDs, and BDTs and the fact that some manufacturers have self-propagating BDTs and self-discovery BDTs, and others have BDTs that you have to manually propagate. It can create a lot of confusion.
So, BACnet as a protocol, remember, it does these services called Who-Is/I-Am and Who-Has/I-Have, and these are broadcast-oriented services and they’re discovery-oriented services. You typically only have to run them when you're doing discovery. They're not continuously run, as long as you build out your list of your BAC nodes that allow for those unicast and multicast services of Who-Is/I-Am and Who-Has/I-Have continuously.
So with that, we introduce BACnet IP. The BACnet IP is internet protocol. It uses internet protocol to communicate. This could be over fiber, this could be over wireless, this could be over Ethernet. A common misunderstanding is that IP equals Ethernet. IP does not equal Ethernet; IP equals Internet Protocol, which is a logical protocol. It's a logical representation of an address. There is no physical IP that you can go touch. So, Ethernet is one of the methods for invoking that communication, Ethernet wiring, whether it's star pattern, bus pattern, or ring pattern, but there's also wireless, there's also 4 or 5g, there's also fiber.
The thing with BACnet IP is, it's not a limitation of BACnet IP as much as it's a limitation, which is not really a limitation. Here's the deal, how the internet works is we have all these IP addresses. Internet protocol consists of public and private IP addresses. Public IP addresses are routable. That means I can be on one network, and I can route myself to another network, because they’re routable IP addresses.
However, there's only 4 billion public IP addresses and you might think that’s a lot, but not really. When you think about your house, you have phones, you have a computer, TVs, maybe Alexa, all these things are using IP addresses. So, we run out of IP addresses really, really quick.
Enter the world of private addresses. You've probably logged onto your computer and run IPconfig some time. You saw 192168.1.X that is a private class C address. The thing is, I can have a 192.168.1-24 address subnet for my house and you can have the exact same address subnet for your house. How can that happen? It's through this concept called network address translation, or more appropriately, protocol address translation.
Network address translation enables you to take a public IP address and basically connect it to a bunch of private IP addresses. So, you route the traffic from the public IP address to the private address. That's what your router does.
Why do I tell you all this? Because BACnet is a broadcast service for Who-Is/I-Am. Who-Is/I-Am is a broadcast service. So, when I initiate that Who-Is, that goes out to every IP address on the subnet Well, that's all well and good unless I have BACnet devices on other subnets. How in the world is my supervisory device or my BACnet advanced workstation going to discover devices on a separate subnet? How's it going to find them? Well, without a BBMD or a BDT, it’s not.
A BBMD is a BACnet broadcast management device. It manages broadcasts. How does it do this? It uses a BDT, Broadcast Distribution Table. A BBMD uses a BDT, and a BDT has the address of every BBMD. A BBMD will be a device, typically a supervisory device sitting on a subnet, and it'll have an IP address. So, when I initiate a BACnet discovery, that BACnet discovery gets forwarded to all the BDTs and then the BDTs send that discovery out on their subnets, which enables that communication to come back and build my BAC node list.
Once I have my BAC node list, we're done with discoveries. Everything is unicast at that point, and as long as we have our route set up in our routers, we’re solid, right? I mean, we need our routes set up in our routers anyways, in order to communicate from a BBMD to all the associated BDTs and their BBMDs. But you know, I'm assuming you have routing set up.
Alright, so BACnet, we do our BBMDs and our BDTs, and that enables us to then forward our requests. That then enables us to create our BAC nodes. Remember, our address is a combination of the device ID and the IP address that makes our BAnet address for IP, and now we're able to do our unicast or multicast. And that's it.
BACnet and BBMDs and BDTs do not need to be that difficult. Now, I have ignored UDP port 47-808. BACnet IP is a UDP protocol. It's a connectionless protocol. Now you may wonder how it is a connectionless protocol, when you have complex acknowledged services. That's because we use this thing called the BACnet virtual link, which enables us to basically emulate a TCP which is a connection-oriented protocol.
Connection-oriented and connectionless protocols, so reliable and unreliable protocols, are layer four concepts in the TCP/UDP world. That's the transport portion of the OSI model layer four. So, the transport portion enables us to have UDP and TCP.
TCP is like if I go to http website, it's a session-oriented protocol, it creates a session in the session layer. That session, if I'm transferring data, if you ever want to see TCP in action, go download a big file and watch how your download gets faster, faster, faster, slows down, faster, faster, slows down. What’s happening is your length in which you're able to go without a confirmation grows bigger and bigger and allows data traffic packets to get bigger and bigger until you don't get a response. Then it realizes it's getting too big and needs to slow down. That's TCP in action.
UDP is when I send a message, and it shows up. It's like the difference between guaranteed mail with the Postal Service and just sending regular mail with a letter stamp. You don't get any confirmation. Well, BACnet messages are UDP. So, we have this link layer that enables us to have that acknowledgement and to execute those services.
Alright, pulling us back to BACnet IP. So, you have BBMDs and your BDTs, you have your addresses set up, everything's good. You have your port 47-808, which is our UDP port. Now, you can have multiple ports, you can do port routing and all sorts of stuff, but that is like way beyond the scope of this. Quite honestly, it's only important for like the largest of large campuses, and it's not even, in my humble opinion, important anymore because BACnet traffic is so lightweight. It's not like we're streaming 8k video, we're doing like tiny, 8 or 16 bit data points that we're transferring. To give you a perspective, 8 bits is eight ones and zeros.16 bits is 16 ones and zeros. Versus like 8k, which is a like gigabits of data.
So, we're not dealing with massive amounts of data and our networks are crazy fast. So, we don't really need to segment our BACnet ports anymore to try to keep traffic down. Really, the only thing I recommend is using nothing more than a slash 24. No slash 23, or slash 22 networks for BACnet IP. Use slash 24. That just makes it easy to troubleshoot.
Now with BACnet IP, we have three design patterns:
- Star
- Bus
- Ring
Star is our traditional pattern that we think of when we think of Ethernet, it runs from the switch, using an access link to the device; one-to-one. Great for system redundancy, because the only point of failure is the switch. If that network goes down, it goes down, but it doesn't take everything else down. Very expensive.
A managed layer two switch will cost you 2-3 grand. A managed layer three switch with POE will cost you upwards of almost 10 grand when you include your licensing fees. So, if you have a 48-port switch, and it's $10,000, you're talking $208 a port. That's crazy expensive.
Enter the bus architecture. The bus architecture, very much similar to a daisy chain architecture, is one Ethernet wire, to the next Ethernet wire, to the next one. That
allows you to go from controller to controller to controller. Now, I've seen so many mixed data points on what are the limitations of IP bus that I'm not going to talk to that definitively here.
I've seen folks say, in an appropriate environment, they can put 200 devices on an IP bus. I've seen folks say you really want to limit it to 32. I've seen all sorts of stuff in between. In my opinion, you wouldn't go more than 100 devices. That, in my opinion, would be very difficult to manage.
It's a bus architecture. So, there's some serious points of failure until every manufacturer gets out where their necks are electrically bridged, which means that if you lose power at the controller, it then electrically bridges the wires, and enables that signal to continue to the next controller. With a bus pattern, if you lose the second controller, and you have 100 controllers on the bus, you basically lose all 98 controllers afterwards, with a lot of manufacturers right now with their IP control lines.
That's why we have the ring architecture. The nice thing about the bus is it only uses one switch port. So, it really gives you some advantages there. Now on the the ring architecture we use Rapid Spanning Tree Protocol. Rapid Spanning Tree Protocol enables you to block one port because remember, we can't have a loop, because of that broadcast. We’ll create a broadcast storm; broadcast will continue to propagate and loop and loop and loop and never end because broadcasts never end until they hit the end of the network. That will take down our network, and it'll just basically be drowned out by noise of broadcasts. So that's why we have a Rapid Spanning Tree or Spanning Tree Protocol, depending on what version your manufacturer supports.
Essentially, you have an access port and a blocking port. The protocol monitors the access port. If it loses communication on the access port, it'll open up the blocking port and allow communication to go the other way. So, you get redundancy, but yet you're only using two ports. So that is one of the benefits. I do know manufacturers are rapidly working on electrically bridging their controllers. So that is something coming down the road.
So, my hope is that after this, you have a much better understanding of BACnet. If you have any questions or any comments about this topic, please leave that below and we’ll be sure to respond.
So, take care. Thanks so much.
