BACnetTM, the standard communications protocol for the HVAC controls industry, is clearly becoming the accepted alternative to the proprietary communications solutions that to-date have dominated most HVAC controls installations. What Is BACnet? BACnet is the term commonly used to refer to the ANSI/ASHRAE Standard 135-1995, adopted and supported by the American National Standards Institute (ANSI) and the American Society of Heating Refrigeration and Air-Conditioning Engineers (ASHRAE). BACnet stands for Building Automation and Control network. BACnet is a true, non-proprietary open protocol communication standard conceived by a consortium of building management, system users and manufacturers. The 500-page protocol specification is a detailed description of how a BACnet system is to function. It identifies all the rules for system components to share data with each other, how this is to be done, the communications media that can be used, which functions can be available, and how this information is to be interpreted. In short, it sets the ground rules for various systems to openly communicate with each other regardless of the manufacturer. BACnet is an entirely non-proprietary system. This means that there are no proprietary chip sets or protocols used. This differs from other systems, such as LonWorks™, which requires a proprietary Neuron® chip to reside in each controller. Additional information regarding the comparison of BACnet and LonWorks is contained in a online white paper. There is often considerable confusion and misunderstanding regarding BACnet, other systems and their compatibility with BACnet. The industry is in the process of learning this technology, so it is important to understand the various levels and options available when interfacing a system with BACnet. The Development of BACnet For many years, as building automation systems became popular, more and more users were demanding alternatives to proprietary systems, which prevented competitive bidding or serviceability. They objected to being "locked in" to one particular manufacturer. A consensus and industry attitude has been developing to respond to this need. Most solutions to providing interoperability are proprietary gateways or converters. For instance, one particular manufacturer may have found a way to read the code of another manufacturer and produce a device that lets the two systems communicate. Sometimes the development is a cooperative effort; other times it is not. The end result, however, is that one manufacturer could provide either a new or different operator"s terminal or global controller for a different manufacturer"s existing system. This type of approach has specific restrictions. First, gateways and converters are expensive and difficult to develop, even with the cooperative effort of another manufacturer and more so when there is no cooperation. Second, these devices tend to have a very short life. Systems change generations quickly, and the gateway often has to be redeveloped and upgraded for each generation in order to remain effective. Third, these gateways can often be limited compared to what a single manufacturer"s system can provide. The seamless integration of full system features is often not a reality. Support and documentation can be nearly impossible to keep up with under the best of circumstances. Lastly, until BACnet, there was no industry standard by which manufacturers could design a system to describe how it communicates, including the message structures, communications mediums and processes that enable systems to interoperate. Potential solutions other than BACnet also emerged. One is LonWorks, which is based on a proprietary communications chip manufactured by the Echelon Corporation. LonWorks provides for a method of communicating between devices, as long as the device employs the proprietary LonWorks chip. This approach does not fully answer the technical requirements o