What Is BACnet?

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 of a complete, site-wide system nor the demand for a non-proprietary structure.

The industry needed a leader to step forward and set a standard. In 1987, the BACnet Committee was formed and began to develop a standard that the industry could adopt. There were several important goals to be achieved. Primarily, the standard had to be technically sound and truly non-proprietary. It also had to be easy to implement. These were not easy goals to achieve; however, in June 1995, after years of industry input and reviews, ASHRAE adopted BACnet as a new standard for the industry.

What does BACnet do?
BACnet ends the frustration of proprietary systems, increases competitiveness and increases consumer choices. The vision throughout the BACnet development process has been to generate a system that permits complete "interoperability" between different manufacturer's building automation control products. In reaching this goal, the BACnet Committee produced definition standards for BACnet data, control and communication functions. In part, this was accomplished by defining a number of Local Area Networks (LANS) through which BACnet messages can be transmitted.

This variety of LANs defines a range of options for any given project. Briefly, they are as follows:

 

PTP (point-to-point)	PTP is unique to BACnet and provides for internetworked communications over modems and voice grade phone lines. PTP accommodates modern modem protocols (V.32bis and V.42) and also supports direct cable connections using the EIA-232 signaling standard. Speed is limited to from 9.6Kbps to 56.0Kbps.
MS/TP (master slave/token passing)	MS/TP is also unique to BACnet and is implemented using the EIA-485 signaling standard. This is a shielded twisted-pair (STP) LAN operating at speeds from 9.6Kbps to 76.0Kbps. This LAN type is low cost and particularly suitable for unitary controller communications.
ARCNET (ANSI/ATA 878.1)	ARCNET® is a token bus standard, and devices typically support it using single-source chips that handle network communications. ARCNET can run on a variety of media at different speeds-from 150Kbps on EIA-485 (STP) up to 7.5Mbps over coaxial cable, STP, or fiber optics. Typically, ARCNET runs at 2.5Mbps over twisted pair.
Ethernet (ISO 8802-3)	Ethernet is a popular international LAN standard widely deployed in commercial applications. Ethernet is fast, running from 10Mbps to 100Mbps (fast Ethernet), and runs on a variety of media-STP, coaxial cable, or fiber optics. Like ARCNET, Ethernet requires a special chip to handle network communications.
LONtalk	LONtalk is a proprietary technology developed by the Echelon Corporation and is the only LAN type that requires special development tools and a proprietary chip set to implement. For more information about LONtalk, see LonWorks to BACnet - A Difficult Upgrade and/or BACnet vs. LonWorks White Paper.

BACnet's Method of Exchanging Messages
In defining the format for BACnet communications, the Standards Committee chose a flexible, object-oriented approach. All data in a BACnet system is represented in terms of "objects," "properties" and "services." This standard method of representing data and actions is what enables BACnet devices from different manufacturers to interoperate. Understanding this object-oriented approach and its terms is essential to understanding BACnet.

Objects
All information in a BACnet system is represented in terms of objects. An object might represent information about a physical input or output, or it may represent a logical grouping of points that perform some function, such as a setpoint. Every object has an identifier (such as AI-1) that allows the BACnet system to identify it. In this regard, an object is much like what is now commonly known as a "data point" in the HVAC community. Where an object differs from a data point is that a data point would typically have a single value associated with it, whereas an object consists of a number of prescribed properties, only one of which is the present value. It is only through its properties that an object is monitored and controlled.

To help clarify this difference, compare the room temperature as a data point to an analog input (AI) object that reports room temperature in a BACnet system. Both are associated with the space temperature read from a physical input. When you reference the data point, however, typically the only thing that it indicated was the room temperature, perhaps 72. The AI object also reports the room temperature as 72. The key difference is that 72 is the Present-value property of the AI-1 object. Other properties of the object convey more information: the Units property tells the system that the value is in º, the Device-type property that the hardware is a 10kohms thermistor, and the Description property that it is a space temperature. As you can see, the AI object is much more robust than the data point. All objects have some required properties and some that are optional.

Properties
As indicated in the discussion of objects above, objects are monitored and controlled only through their properties. BACnet specifies 123 properties of objects. Three properties-Object-identifier, Object-name, and Object-type-must be present in every object. BACnet also may require that certain objects support specific additional properties. The type of object and the type of device in which that object resides determine which properties are present. Some properties can accept writes, and others can only be read.

Services
When a property is read or written to, that act is known as a service. Services are how one BACnet device gets information from another device, commands a device to perform certain actions (through its objects and properties, of course), or lets other devices know that something has happened. The only service that is required to be supported by all devices is the Read-property service. There are a total of 32 standard services.

As a system developer or user, you don't need to be concerned with the execution or processing of service requests, which will be transparent and automatic. As a specifier or engineer, however, you will need to know what objects and services are supported by which devices. This information is found in the device's protocol implementation conformance statement (PICS).

Conformance Classes and the Device PICS
Because not all devices need to have the same level of functionality, BACnet defines conformance classes that categorize the capabilities and functionality of devices. All devices of a certain conformance class will have a minimum set of required features (in the form of objects and services). Some other features can be optional. BACnet insists that this information is made public in a protocol implementation conformance statement (PICS)-basically a list of features that the device supports. The PICS lists what objects are present in the device and whether the device initiates a service request (asks or commands) or executes the request (responds or acts). The PICS also provides you with the conformance class of the device. By comparing a device's PICS with project requirements or with another vendor's PICS, you can determine how well a BACnet product "fits" a given application.

Summary
The BACnet protocol is comprehensive in scope and complex in detail. Built upon an international standards base, it has undergone extensive revisions to accommodate solicited and unsolicited structural ideas from all sectors of our industry. As intricate as it is, however, BACnet's design readily permits future modifications by ASHRAE as building automation requirements change. As our industry, and Alerton in particular, embraces this significant and positive development in building automation, we look forward to serving our customers with even better choices and higher levels of quality facility management. BACnet opens the door to true systems integration.

Thanks to Alerton for use of this article.

Visit their web site at  www.alerton.com