AutomatedBuildings.com Column

As CEO of Teletrol Systems, a supplier of BACnet products, and President of BACnet International, I frequently talk about BACnet with all kinds of people. What I consistently find is that BACnet is a little mysterious to outsiders – and by outsiders I mean people who are not intimately involved in BACnet-related activity. Most building owners, operators, system integrators, consultants, facilities management executives and regulators fall into this category. In my experience these outsiders view BACnet as something of a puzzle and they wind up either scratching their heads in confusion or making seriously inaccurate assumptions in an effort to decipher it. The sense of mystery and the potential for confusion are not intentional but they are obstacles to accelerating the pace of BACnet adoption. The good news is that they are obstacles we can probably overcome if we “insiders” are willing to put ourselves in the shoes of an “outsider” and make some changes in the way we communicate.

The sources of mystery and confusion around BACnet are numerous and largely understandable. They start with the specification itself. It’s a technical document written for technical people and the difficulties start right there. The terminology in the specification is incomprehensible to outsiders (e.g. PDU, BIBB, BBMD, MS/TP). But it gets even worse. In most cases, the essential content of the document is conveyed to outsiders by technical people who, in the interest of correctness, use the very language that was confusing in the first place. It’s sort of like asking an automotive enthusiast explain the difference between a five-speed transmission and a four-speed transmission to the average driver. They are likely to explain it in terms of torque, brake-horsepower and gear ratios when the average person just needs to know the five-speed will give the car more power at low speeds and better gas mileage at high speeds.

Another source of mystery and confusion for outsiders stems from the way insiders talk about the options for physical network types and their associated protocols. For example, when someone says a device implements BACnet MS/TP insiders know the device connects to a physical network made up of a twisted pair of wires. (I should point out here that outsiders do not automatically know this fact and finding it in the specification is … well, let’s come back to that issue later.) In any case, insiders know every MS/TP device connects to a twisted pair because the BACnet specification requires it. In fact, the specification even defines the nature of the twisted pair in great detail, and I quote:

The specification leaves no doubt about the nature of the physical network for BACnet MS/TP devices, ensuring that any two can be directly interconnected. On the other hand, when someone says a device implements BACnet/IP insiders know that the BACnet specification does not address the physical connection at all. While is commonly assumed BACnet/IP devices include a 100Mb/s Ethernet port with a CAT5 cable connection, nothing in the specification requires it. Other Ethernet physical connections are possible and in fact Ethernet is not required at all. A BACnet/IP device could just as well connect to the network via a Wi-Fi antenna. Thus it is not necessarily the case that two BACnet/IP devices can be directly interconnected. How is an outsider to know that two seemingly parallel device definitions are in fact, so different?

My point is not that the specification should handle the issue of physical interconnection the same way for every option. There are good reasons for the specification being constructed the way it is. The problem is that we use specification terminology and concepts when explaining BACnet to outsiders who do not have sufficient context. The result can be confusion and frustration.

Beyond the issue of physical interconnection, when insiders try to explain BACnet device functionality options to outsiders it gets even more interesting. The specification defines functionality at two levels of detail (BIBBs and Profiles for the outsiders in the audience) and neither one relates very well to the real world of devices. To most outsiders, devices are physical things they can touch (and buy). For example, outsiders think of devices as physical things like chillers, packaged roof top units, air handling units, elevators, lights, VAV boxes, refrigerated cases, etc. Outsiders would like to think (and often presume) BACnet specifies how those devices will communicate in a reasonable way with each other and with supervisory controllers. Of course, insiders know that BACnet only deals with devices at an abstract level, collecting functionality into profiles with names like “AC” (which stands for “Application Controller” and not Air Conditioning for outsiders in the audience). The functionality profiles in the specification are not mapped to real-world devices. To be fair, BACnet is only a communications protocol (at least according to Wikipedia … more about that in some future column). So, it is understandable that there is no direct mention of real-world devices in the specification itself. Here again, the real problem is not the specification. The real problem is that we have not fully translated BACnet language into the world where outsiders live, so if they want a useful understanding of what the term “BACnet device” does and does not mean they have to translate their world into BACnet language … and as we have seen, that is not simple.

These issues are magnified when we consider BACnet Web Services (abbreviated BACnet/WS per the specification). Note that BACnet/WS looks similar in form to BACnet/IP. So, we would have to forgive an outsider who supposes they are similar concepts with web services substituting for IP (and the implicit Ethernet cable that comes with IP). Insiders, of course know these two things are different in concept, capability and intended application. For example, at Teletrol we are currently working with another supplier to link their tenant billing application with our energy management application. Of course our application resides on a BACnet platform so BACnet/WS is the natural way to convey building information regarding override occurrences, rates and runtimes. (Incidentally, you can learn more about this application of BACnet/WS at a September conference presentation by Kurt Kavanaugh of Teletrol Systems). In another project we are looking at how to connect to an automated demand response server using BACnet/WS. In these kinds of applications there is no “device” in the usual sense on either end of the communications process. Both ends are merely software applications hosted wherever the user chooses to host them. Unfortunately, the specification terminology, BACnet/WS, does not alert outsiders to the distinction between that concept and real devices that directly connect to a network using other parts of the specification (e.g. BACnet/IP).

[an error occurred while processing this directive] In the best of all worlds some of the mystery about BACnet and potential confusion about what exactly key concepts mean would be cleared up by visiting the websites of the organizations at the center of the BACnet community. Unfortunately, you will find we do not live in that best of all worlds if you take a look at the ASHRAE BACnet Committee website and the BACnet International website. They both make perfect sense to insiders. However, if you put on an outsider’s hat and visit them with the goal of finding out whether or not you should care about BACnet they make less sense. It’s easy to find information about committees, organizations, history, current events and deep technical content. There is even some information about benefits and value. But most of it is written by insiders for insiders … or even worse, by insiders pushing outsiders to learn the insider language and worldview. Even the simple matter of how the two organizations relate to each other is not clear from their respective websites. As a result, it is not clear which one (if either) any particular outsider should engage with.

So, what can we do for outsiders? I suppose we could tell them to just read the specification. However, Bill Swan, chair of the ASHRAE BACnet Committee told me that when he first got involved with BACnet he read it from beginning to end several times and the process “gave him headaches for weeks” … which is probably not a good way to introduce outsiders to the wonders of BACnet. Realistically, it’s a challenge to lead outsiders to a point where they understand the things about BACnet that are important to them, without requiring them to learn BACnet technical jargon and abstract concepts. Is it a challenge important enough to warrant our attention? I think so. After all, these outsiders are the building owners, operators, system integrators, consulting engineers, facilities management executives, consultants and regulators who will make decisions regarding BACnet adoption and implementation. They are the ones who will set the pace for BACnet adoption going forward. Forcing them to learn the insider world is slow, painful and likely to lead to misunderstandings. We need something better.

So, what can we do? Can we develop an “outsider-focused” taxonomy of BACnet options? If so, what would it look like? What are the things outsiders actually care about and how can we cast BACnet options in those terms? Can the “usual cast of characters” accomplish such task or do we need “new thinkers” to do it? Can it be done within existing organizations and if so, which one(s)? These are questions I will reflect on in a future column and I invite your input. If you have thoughts on the issues discussed in this column or ideas about an “outsider-focused” taxonomy of BACnet options send me a note at andysview@arborcoast.com.

As this is the first column of an ongoing series I have agreed to write for automatedbuildings.com I should probably include the following disclaimer: The views expressed in this column are mine and do not necessarily reflect the position of BACnet International, Teletrol Systems, ASHRAE or any other organization.

Andy McMillan is president and CEO of Teletrol Systems Inc., a leading supplier of BACnet-based, IT-friendly building automation solutions. He is also the President of BACnet International, an industry organization serving the needs users and suppliers of BACnet. Andy’s background includes broad open systems marketing and industry development experience as well as strong technical knowledge of distributed automation and information management systems. Andy has been a featured speaker on open systems and automation-IT integration at conferences in North America, Europe, Japan and Australia. Andy has co-authored a book on open systems networking and holds a dozen patents in sensors, automation and software. He has MBA and BSEE degrees from the University of Michigan and is a member of ASHRAE, AEE, PRSM, and IEEE.

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources