BACnet Unraveled

Publication of ASHRAE and ANSI’s BACnet communication protocol in 1995 ushered in a new era for building automation and control systems, making it possible to integrate building control products designed by different manufacturers. This change has proved to be as profound for consulting engineers as it has been for building owners and manufacturers of building automation system (BAS) products. Despite this breakthrough, and the fact that there are hundreds of thousands of installed BACnet system control products, consulting engineers have had difficulty understanding how to write quality BACnet specifications. It has been difficult because, in many instances, specifiers have no background in computer communications and the tools provided in the 1995 standard to bridge this gap have not worked well in practice.

ASHRAE has recognized this and at its annual meeting in late June, the board of directors approved final publication of three new addenda to ANSI/ASHRAE Standard 135-1995. These addenda added many new capabilities to the standard, including features specifically designed to make it easier to integrate fire and life-safety systems with other building automation systems. It is also a mechanism for making nonstandard extensions to BACnet network visible. For consulting engineers, Addendum d stands out because it was designed specifically to make the job of specifying BACnet systems easier.

Addendum d replaces Clause 22, Conformance and Specification, and introduces a new concept called BACnet Interoperability Building Blocks (BIBBs). As the name suggests, each BIBB defines a small portion of BACnet functionality needed to perform a particular task. BIBBs are combined to build the BACnet functional requirements for a device in a specification. In developing BIBBs, ASHRAE SSPC 135, the committee charged with maintaining the standard, turned to a work in progress for inspiration. At the time, a separate ASHRAE committee had been developing a tutorial on BAS, now published as ASHRAE Guideline 13-2000, Specifying Direct Digital Control Systems. This guideline recommends specifying direct-digital control (DDC) systems by describing the requirements in five functional areas:

• Data sharing.

• Alarm and event management.

• Scheduling.

• Trending.

• Device management.

The committee decided that it made sense to define components of BACnet functionality within these broad categories. It was decided to use small building blocks so that, for each functional area, a specifier could select from a range of capabilities that best meet the intended application of the device. Thus, the idea for BIBBs was born.

BIBBs come in pairs—designated A and B—that reflect the client/server nature of control system communication. The A BIBB represents the client or the device that is trying to obtain information or command an action. The B BIBB represents the server or the device that provides the data or carries out the commanded action. If two devices support the complimentary BACnet capabilities (the A and B side of the same BIBB), then they are interoperable from the standpoint of that function (see Table 1 page 53).

The basic idea is that for each kind of device—workstation, building controller, application-specific controller—the functional areas they need to support are selected, and then BIBBs that apply to that functional area are chosen to match the level of sophistication desired. For example, the data-sharing (DS) BIBBs contain, among others, ReadProperty (RP) , ReadPropertyMultiple (RPM) , WriteProperty (WP) and WritePropertyMultiple (WPM). The ReadProperty service provides a way to read a single property of a single object. The WriteProperty service provides a way to write to a single property of a single object. ReadPropertyMultiple and WritePropertyMultiple are more complicated in that they can read or write to multiple properties, possibly from multiple objects, in a single message. Reading or writing multiple values at one time can improve communication efficiency, but it requires more memory and processor resources and, thus, is more expensive. Using a Bibb

To select a BIBB, the specifier must decide which level of capability is most appropriate. Consider a very simple application-specific controller. Does it have data that needs to be shared with some other device in the system? The answer is almost certainly yes. This means that it must support the B side of one of the ReadProperty BIBBs; some other device can read the properties of its objects. Does it have the resources to answer requests for more than one data value at a time? Let’s assume the answer is no. That means DS-RP-B is the appropriate choice. Does it need to provide a way for another device to change the value of one or more of its properties (e.g. a setpoint)? If yes, then it should also support DS-WP-B. Does it need to get data from or change values in another device? It probably doesn’t, which means that it does not need any of the A side BIBBs.

The end result is a specification where these controllers must support DS-RP-A and DS-WP-B. This kind of reasoning for each application area can be used to select the building blocks that define the communication capabilities for any BACnet device. Standard Device Profiles

Although the process has been simplified, it still requires considerable expertise to select all of the appropriate BIBBs. To help make this even easier, Addendum d defines a standardized version of several typical control system components:

• BACnet operator workstation.

• BACnet building controller.

• BACnet advanced application controller (B-AAC).

• BACnet application-specific controller (B-ASC).

• BACnet smart actuator.

• BACnet smart sensor.

The set of BIBBs for each of these devices is already selected and listed in a table. In order for a vendor to claim to meet the communication requirements for one of these standard BACnet devices, all of the listed BIBBs must be supported.

The standard provides guidance about what kind of functionality can be specified for each of the standard device types, knowing that the underlying communication details are supported. This allows the engineer to focus on the application requirements instead of the communication requirements.

Now let’s examine the tools themselves. A B-ASC is a device with limited resources and limited or no programmability that is intended for use in a specific application (see Table 2 on page 54 for communication requirements). A specification that uses this profile should state that the controllers provided shall meet the requirements of a B-ASC. The specifier then adds specific functional requirements that fall within the range of those indicated for the device. In this case, the specification would indicate which values are to be shared and how they are to be used. It would also indicate which values are to be modifiable and by whom.

A somewhat more complicated device is the B-AAC. This is a device that may be intended for a specific application, but it supports some degree of programmability and has a more rich set of features than B-ASC (see Table 3 on page 58 for the communication requirements). For a B-AAC, it is possible to specify more complicated application functions such as alarm generation, schedule definition and clock synchronization. The overall idea is to keep work focused on subjects for which the specifier has expertise—the requirements of building control application.

Keep in mind these standard devices are intended to be a guide. If they meet the needs of a project, use them and make life easy. But if a project has special needs for one or more devices, then go back to the complete set of BIBBs and select the ones that are most appropriate. Specification to this level of detail requires a more complete understanding of the communication details. To do it well will require more work and expertise than just relying on the standard device types. Other key issues

All of the discussion in this article applies to the application functionality of BACnet devices. But there are other issues that must be carefully specified to make a project successful over time: e.g., which network technologies to use, a naming convention for BACnet objects and a numbering convention for BACnet networks. These issues are discussed in detail in the NIST Inter-agency Report (NISTIR) 6392, which is available online under the bibliography section of www.BACnet.org . This document was prepared for the General Services Administration to help them develop high quality BACnet specifications. It includes a checklist that can be used to determine whether or not a BACnet specification is complete. NISTIR 6392 predates the final version of Addendum d. It was based on a draft version of the BIBBs that differ from the version adopted as part of the standard. The BACnet communication protocol standard makes it possible to integrate a wide variety of building automation and control products. The fact is, however, that engineers still struggle with the question of how to properly specify these integrated systems. Newly approved Addendum d is an attempt to improve the situation by defining a set of interoperability building blocks that can be used to clearly define the communication requirements of a BACnet system.

The addendum also includes several standardized building control devices for which the BIBBs have already been selected. Guidance is provided regarding the kind of application functionality that can be specified for each of these devices. The intent is to provide a reliable communication framework from which the specifying engineer can build using what they know best: the functional requirements of the application.

Table 1 – BIBBs Sampling

• Directly link the communication capabilities to application needs that are well understood.

• Provide the needed capabilities, but no more.

• Provide a path for innovation by not locking into today’s approach to distributing control functionality.

The end result was a set of hierarchical conformance classes and an orthogonal grouping concept based on particular applications such as alarm initiation or serving as a time master.

These collections of communication capabilities were called functional groups. The idea was to select an appropriate conformance class and then add functional groups until the desired functionality was represented.

But for several reasons, it did not work. The simultaneous use of two fundamentally different approaches to dividing features was confusing. The attempt to avoid stifling innovation by locking particular features into specific devices resulted in categories that specifiers could neither recognize nor map to control hardware that they understood. The inherent asymmetry of the communication process was not well represented. And, perhaps most importantly, the granularity of the choices turned out to be too coarse.

Table 2 – B-ASC Requirements

Table 3 – B-AAC Requirements

What Happened To Gateways?

The list of standard BACnet devices does not include a gateway. This may seem strange since many projects will need a gateway in order to connect to previously installed non-BACnet systems. Inclusion of a gateway profile was a topic of considerable debate. It was eventually decided that a gateway could be made to have the same functionality as any of the standard devices. The needs and cost constraints of a particular project should dictate how much functionality is required in the gateway. For this reason, no standard gateway was included. This is a reasonable argument, but it leaves the individual who needs to specify gateway requirements with very little guidance. BIBB requirements for a gateway, as well as recommendations for other functional requirements that should be specified, can be found under NISTIR 6397.

Why BACnet Was So Difficult

Developing a good BACnet specification is not difficult—if you are an expert in computer communication. Here’s where the 1995 standard missed the mark.

The 1995 standard did contain tools to make it easier for people with no computer communication background to select the BACnet features, but it didn’t make sense to combine all of the features into a single product. There was a need to divide the feature set into useable parts that could be selected to meet the requirements of various components of a BACnet system.

But because one size does not fit all, there was a need for options and a way to combine it into a working system. This flexibility is one of BACnet’s biggest strengths

and the primary reason why it will stand the test of time. At the same time, it also makes specifying systems harder.

In attempting to come up with a better solution, several guiding principles were considered:

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.