BACnet - The New Standard Protocol
In this article, which originally appeared in the September 1997 issue of Electrical Contractor magazine, H. Michael Newman, Manager of Cornell University's Utilities Department Computer Section and Chairman of ASHRAE's BACnet committee since its inception in 1987, discusses the new BACnet standard for building automation and control system networks, ANSI/ASHRAE 135-1995.
Introduction to BACnet
If you are involved in the installation of building automation equipment of any kind - direct digital controllers for HVAC, lighting control systems, fire alarm systems, security systems - chances are that you have at least heard of the new standard protocol called BACnet. Since BACnet relies to a great extent on the use of common local area network (LAN) technologies such as Ethernet and ARCNET, the need for electrical contractors to learn new wiring techniques will be minimal. Nonetheless, a knowledge of BACnet's basic principles may come in handy when commissioning is taking place or troubleshooting is required.
What is BACnet?
BACnet is "a data communication protocol for building automation and control networks." A data communication protocol is a set of rules governing the exchange of data over a computer network that covers everything from what kind of cable to use to how to form a particular request or command in a standard way. What makes BACnet special is that the rules relate specifically to the needs of building automation and control (BAC) equipment, i.e., they cover things like how to ask for the value of a temperature, define a fan operating schedule, or send a pump status alarm.
BACnet was developed by a committee formed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). The committee's main objective was to create a protocol that would allow building systems from different manufacturers to interoperate, that is to work together in a harmonious way. Prior to the advent of BACnet there was simply no practical way to achieve this goal.
To achieve interoperability across a wide spectrum of equipment, the BACnet specification consists of three major parts. The first part describes a method for representing any type of building automation equipment in a standard way. The second part defines messages that can be sent across a computer network to monitor and control such equipment. And the third part defines a set of acceptable LANs that can be used to convey BACnet communications. Let's look at each of these components of the BACnet spec in a bit more detail
Representing BAC equipment in a standard way - BACnet objects
To pull off this seemingly impossible trick, BACnet provides a standard way of representing the functions of any device, such as analog and binary inputs and outputs, schedules, control loops, and alarms, by defining collections of related information called "objects," each of which has a set of "properties" that further characterize it. Each analog input, for instance, is represented by a BACnet "analog input object" which has a set of standard properties like present value, sensor type, location, alarm limits, and so on. Some of these properties are required while others are optional. One of the object's most important properties is its identifier, a numerical name that allows BACnet to unambiguously access it. Once devices have common "appearances" on the network in terms of their objects and properties, it is then possible to define messages that can manipulate this information in a standard way.
Providing standard messages for monitoring and control - BACnet services
BACnet currently defines 35 message types, or "services," that are divided into 5 classes. For example, one class contains messages for accessing and manipulating the properties of the objects described above. A common one is the "ReadProperty" service request. This message causes the server machine to locate the requested property of the requested object and send its value back to the client. Other classes of services deal with alarms and events; file uploading and downloading; managing the operation of remote devices; and virtual terminal functions (accessing equipment across the network as if you were using a directly-connected terminal or laptop).
Note that the ability to read and write binary, analog, and text data; schedule control actions; send event and alarm notifications; and similar functions are required by all kinds of BAC equipment, not just HVAC gear. Nonetheless, the committee realized that these capabilities might not cover all situations and developed the standard with an eye toward accommodating future, unknown building automation and control applications. As a result, one of the real strengths of the BACnet object and services model is that it can be easily extended. If a vendor comes up with some new functionality for which communication is required, the vendor can add new properties to existing object types or create new object types that are accessed in exactly the same way as the eighteen defined in the standard. Moreover, a vendor could even dream up new services that go beyond the standard ones. Of course, proprietary features may not be interoperable without vendor cooperation.
This is probably a good time to point out that while BACnet makes multi-vendor installations possible, it in no way requires the use of multiple suppliers. Since many vendors will probably choose, and some have already chosen, to use BACnet as their "native" protocol, you could easily end up with a single-vendor BACnet system.
Leveraging standard network technologies - BACnet LANs
Up until now I have just been talking about the BACnet object-oriented model and the various message types. The system designer will still need to pick an appropriate network technology to connect everything together. The BACnet committee spent a lot of time on this part of the standard and ended up with 5 different options, each of which fills a particular niche in terms of the price/performance tradeoff. The first is Ethernet, the fastest at 10 Mbps with 100 Mbps also recently available. ("Mbps" stands for "millions of bits per second.") Ethernet is also likely to be the most expensive in terms of cost per device. Next comes ARCNET at 2.5 Mbps. For devices with lower requirements in terms of speed, BACnet defines the MS/TP (master-slave/token-passing) network designed to run at speeds of 1 Mbps or less over twisted pair wiring. Echelon's proprietary LonTalk network can also be used on various media. All of these networks are LANs. BACnet also defines a dial-up or "point-to-point" protocol called PTP for use over phone lines or hardwired EIA-232 connections. A key point is that BACnet messages can, in principle, be transported by any network technology, if and when it becomes desirable to do so. See Figure 1.
Figure 1. "Native speaking" BACnet devices can all share a common LAN selected from the four approved BACnet choices. Because of the way BACnet messages are packaged, other types of computers, for example office PCs and servers, can coexist on the same LAN without interference.
From the electrical contractor's perspective, these networks all use standard, hopefully familiar, wiring technology. Both Ethernet and ARCNET can use a variety of physical media – coaxial cable, twisted pairs, as well as fiber optic cable. Although the types of coax are different - RG-58 for "thinwire" Ethernet and RG-62 for ARCNET - the types of connectors and tools are essentially identical. Contractors should also be knowledgeable about recent standards from the Electronic Industries Association / Telecommunications Industry Association such as EIA/TIA 568 which defines wiring practices for telecommunications in commercial buildings such as the CAT-5 specification for high-speed LANs.
Comparing BACnet with LON
Given the tremendous amount of advertising and promotion that has been dedicated to Echelon Corporation's Local Operating Network (LON), LonTalk (the LAN technology it uses), and LonMark (the Echelon certification program), it is not surprising that there is some confusion in the marketplace as to just what this technology is and how it relates to BACnet. For example, there is the myth that any equipment that uses LonTalk can automatically talk to BACnet systems. This is unfortunately not true.
Let me give you a little background. LonTalk is Echelon's specification for a recently developed LAN technology that many people thought would be a useful addition to the BACnet standard. BACnet in fact specifies the optional use of LonTalk to convey BACnet messages in an identical manner to the way BACnet messages are transported by Ethernet, ARCNET, MS/TP, and PTP. Confusion stems from the fact that Echelon has its own generic control language that is also transported by LonTalk LANs. In order for LonTalk devices to be interoperable, even using Echelon's language, there has to be agreement between implementers as to what the generic messages mean in a particular context. To obtain such agreements, Echelon has set up the LonMark Interoperability Association which has working groups made up of people from a variety of industries, including building controls, that are trying to reach implementers' agreements on how to use Echelon's proprietary control language in a common way for their applications. The point is that the BACnet language and the Echelon language are fundamentally different and devices using one of the languages can never interoperate directly with devices using the other, even though they might possibly share a common LonTalk LAN.
Other points of comparison are these. BACnet is an American National Standard, LON is proprietary. This doesn't make BACnet "good" and LON "bad." The point is that the public has been involved with BACnet from the outset but not with LON. The BACnet committee has had representation from all segments of the industry and the BACnet standard was subjected to extensive public review with 741 comments from commenters in 12 countries. Anyone can participate in the future enhancement of BACnet but only those willing to join the LonMark program, for a fee, have any say in LON.
BACnet was designed specifically for building automation and control applications while LON was designed to be a general purpose control network solution. The consequence is that some of the functions intimately associated with building controls, and central to BACnet, such as time-of-day scheduling, alarm generation, and control prioritization, are simply not present in LON. Moreover, BACnet is designed to be scalable, i.e., it can be applied to very small or very large systems with equal effect. LON, as it exists today, is most suitable for systems with a small number of nodes.
Finally, there are commercial issues. Unlike LON, there are no fees for using BACnet and no license is required. The people promoting BACnet, unlike those promoting LON, have no direct financial stake in its success. BACnet is not a product. Rather it is a specification for making products that can work together for the purpose of achieving better building automation and control.
Again, all of this doesn't make BACnet "good" and LON "bad." It simply means that it is important to understand the differences and, if a decision is made to use LON, either with or without BACnet, it should be done in manner that suits the intended application.
BACnet in the near term
While devices that speak BACnet as their "native" language are beginning to appear in the marketplace, the question arises what to do with existing systems. Can they be tied-in to new BACnet equipment? Maybe, maybe not. In order for a BACnet device, say an operator workstation, to talk to non-BACnet devices like an existing DDC system from "ABC Controls," you will need an intervening gateway. A "gateway" is like a United Nations translator that can speak two languages. On one side it speaks BACnet, on the other side the ABC protocol of the legacy system. Naturally the most likely source for such a gateway would be the ABC company and they may, or may not, choose to develop one. See Figure 2.
Figure 2. Legacy, non-BACnet devices can be linked to a BACnet network through an appropriate "gateway." The most likely source for such a device is the manufacturer of the existing equipment.
Another issue is the use of different LAN technologies. This is not a real problem since BACnet specifies how to build "routers" to interconnect them. In BACnet a router is a device that passes a message from one network to another without changing the form or content of the message. If the networks are of different types, the addresses, error checking, in short, the "packaging," of the message may get changed, much as you would repackage an ordinary Post Office letter if you were going to send it further using FedEx or UPS. See Figure 3. A gateway, on the other hand, opens the letter, translates it into a second language if possible, puts it back into some type of envelope or another, then sends it on. Obviously, it can take more time and energy to do a translation than to simply forward a message so gateways tend to be more complicated machines than routers.
Figure 3. This is an example of three different BACnet LANs linked together by "routers." There are also routers from Ethernet to LonTalk, ARCNET to MS/TP, and so on, thereby facilitating a wide variety of interconnection possibilities.
Next steps within ASHRAE
In January of 1997 a follow-on committee to the committee that originally drafted BACnet was formed within ASHRAE. Called Standing Standard Project Committee (SSPC) 135, it is this new committee's task to maintain, interpret, and enhance the BACnet standard. One of the SSPC's top priorities is to finalize a conformance testing addendum that can serve as the basis for a BACnet certification program. Another high priority is to enhance the use of BACnet with the internet protocols (TCP/IP, UDP, HTTP, etc.) so that building owners with facilities linked via the Internet can send BACnet messages back and forth. This refinement, BACnet/IP, was in fact approved by the SSPC for public review in May and is now wending its way through ASHRAE channels. Another SSPC working group is trying to bridge the gap between specifiers and manufacturers by defining "interoperability specifications" that will deal with the areas of data sharing, alarming, scheduling, logging and trending, and device management. The idea is to give specifiers an easy way to indicate the functionality they need on a job while defining for the manufacturers what BACnet capabilities must be provided in each type or class of control device. Finally, a working group is looking at specifying the definitions of some new "macro objects" whose properties would be the parameters required for the monitoring and control of some large-scale device like a heat pump, chiller, or packaged rooftop air conditioner.
Other BACnet activities
Besides the SSPC activities, there are several BACnet demonstration projects underway. One that has been in the news quite a bit is the General Services Administration's rehab of the Phillip Burton Federal Building in San Francisco. The impressive thing about this project is its scale and complexity. It will involve more than a thousand controllers, four (possibly five) different vendors, several applications including lighting control and end use energy monitoring, and an interface to the local electric utility. It is on track to be completed by the end of this year.
There is also activity on the international standards front. BACnet has been selected by the European Community's standards committee CEN TC247 as a European "pre-standard" meaning that it will undergo an evaluation process over the next couple of years to see whether it should become a full-fledged EC standard. The International Organization for Standardization's committee TC205 is also considering whether BACnet should be designated as an ISO standard. All of this is quite remarkable, considering that BACnet was only published in January of 1996.
The future of BACnet
The big question, of course, is how real is BACnet? Although it is hard to get a precise tally, the number of BACnet sites up and running at this moment was estimated by various BACnet manufacturers at the July ASHRAE meeting in Boston to be around 2500. Of these, perhaps one-third are multivendor installations. About one-third of these sites are in the United States. Other jobs have been reported in Canada, Mexico, Brazil, Germany, Switzerland, UK, Hong Kong, Singapore, Australia, and Taiwan. It wouldn't surprise me if there were more installations that I haven't heard about.
Another key question is when will more BACnet products be available? There is a bit of chicken and egg here: the vendors will probably accelerate their product development if they see a growing user demand and users will probably increase their demand if they see more BACnet products in the marketplace. If you consider that most controls companies have product development cycles on the order of 5 years, it is amazing how many products are already on the market, a mere 18 months after the standard was approved. Talking with the manufacturers it is clear that there is a tremendous amount of development activity taking place right now, much of which will bear fruit in the next 12 to 18 months. Stay tuned!