BACnet - A Data Communication Protocol for Building Automation and Control Networks. Developed under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), BACnet is an American national standard, a European standard, a national standard in more than 30 countries, and an ISO global standard. The protocol is supported and maintained by ASHRAE who ensures across the board standardization in testing and functionality.
ASHRAE has a long-standing tradition and policy of non-commercialism. However, BACnet's success depends on the implementation of BACnet in commercial products and ASHRAE works closely with all building controls manufacturers to ensure the reliability of this important universal communication standard.
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. The rules take the form of a written specification that spells out what is required to conform to the protocol.
What kinds of things are covered by BACnet's "rules"?
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 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.
But every manufacturer's system is different! How can BACnet possibly do all these things in a standard way?
The trick is that BACnet provides a standard way of representing the functions of any device, as long as it has these functions. Examples are analog and binary inputs and outputs, schedules, control loops, and alarms. This standardized model of a device represents these common functions as collections of related information called "objects," each of which has a set of "properties" that further describe 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 sort of 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's easy to envision messages that can manipulate this information in a standard way.
OK, so what kinds of messages does BACnet define?
Because BACnet is based on a "client-server" model of the world, BACnet messages are called "service requests." A client machine sends a service request to a server machine that then performs the service and reports the result to the client. BACnet currently defines 35 message types that are divided into 5 groups or 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.
Is BACnet limited only to HVAC equipment? Can it be used with fire/life safety, lighting control, and other building automation systems?
Absolutely. In fact, if you think about it, BACnet already contains most of the capabilities required for non-HVAC communications. These include the ability to read and write binary, analog, and text data; schedule control actions; send event and alarm notifications; and so on. 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 model that emerged from this consideration 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. This is not only expected, it is encouraged. 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.
I keep hearing about "interoperability" but I like the vendor I deal with now. Does BACnet require multi vendor installations?
Definitely not. BACnet is just a protocol. It makes possible the interconnection of different vendors' equipment that uses BACnet, but in no way requires it. Since many vendors will probably choose, sooner or later, to use BACnet as their "native" protocol, you could easily end up with a single-vendor BACnet system. Also, I agree with you. I would much prefer to deal with a single, or at most a couple of vendors. The issue is making sure their pencils stay sharp at bid time!
What about connecting BACnet systems together? What networking options are there for BACnet?
Good point! Up until now I have just been talking about the BACnet object-oriented model and the various services or message types. You 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. We 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. Both Ethernet and ARCNET can use a variety of physical media: coaxial cable, twisted pairs, even fiber optic cable. 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 LonTalk network can also be used on various media. All of these networks are examples of "local area networks" or 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 cost-effective to do so.
You mentioned that BACnet can use LonTalk. Does that mean that any equipment that uses LonTalk can automatically talk to BACnet systems?
Unfortunately not. 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 uses LonTalk to convey BACnet messages in an identical manner to the way BACnet messages are transported by Ethernet, ARCNET, and MS/TP. Confusion stems from the fact that Echelon has its own generic control language that is also transported by LonTalk. 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 Program which has working groups made up of people from each industry 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.
I like the idea of BACnet but what about all my existing DDC systems? Can BACnet help tie them together too?
Maybe, maybe not. In order for a BACnet device, say an operator workstation, to talk to non-BACnet devices like your existing DDC system from XYZ Controls, you 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 XYZ protocol of your legacy system. Naturally the most likely source for such a gateway would be the XYZ company and they may, or may not, choose to develop one.
What if some of my DDC systems are on Ethernet and some are on, say, MS/TP. Is there any way to connect them together?
Yes. Besides allowing the use of different LANs, the BACnet standard also specifies how to build routers. "Routers" are simply devices that connect multiple networks together. The networks may be of the same or different types.
Now I'm confused. What's the difference between a router and a gateway?
I don't blame you. A lot of people use the terms almost interchangeably. 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 U. S. Postal Service letter if you were going to send it further using FedEx or UPS. 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 are more complicated machines than routers.
Do BACnet routers really exist?
Sure. In fact, at the BACnet demonstration booth in Atlanta in February 1995 (sponsored by the National Institute of Standards and Technology's (NIST) BACnet Interoperability Testing Consortium), we had controllers running on all the BACnet network types, except PTP, and all interoperating. To interconnect them, we had an Ethernet-ARCNET router, an Ethernet-MS/TP router, and an Ethernet-LonTalk router.
|
