BACnet’s BIBBs Up Close

It was two year ago this June that ASHRAE's board of directors approved final publication of three new addenda to ANSI/ASHRAE Standard 135—the BACnet communications protocol. One goal of these changes to the protocol was to make the specifying of BACnet easier. To this purpose, Addendum d to the standard introduced the concept of BACnet Interoperability Building Blocks (BIBBs).

It was two year ago this June that ASHRAE’s board of directors approved final publication of three new addenda to ANSI/ASHRAE Standard 135—the BACnet communications protocol. One goal of these changes to the protocol was to make the specifying of BACnet easier. To this purpose, Addendum d to the standard introduced the concept of BACnet Interoperability Building Blocks (BIBBs).

At the time, CSE published two articles (see “BACnet Unraveled,” 08/02 p. 50, and “BACnet 1 2 3,” 09/02 p.34) discussing the BIBBs and other efforts to make BACnet easier for engineers to understand. In reviewing the effectiveness of this revision, the findings are mixed—and predictable. Some engineers have taken the time to learn the BACnet BIBBs and actually use them. Others, however, have found it possible to write specs for BACnet systems without using the BIBBs.

BIBBs Today

The standard is under continuing maintenance, and 135-2001 includes a number of substantial addenda. In fact, certain revisions in Addendum d have led to its successful adoption as an international standard (see “BACnet Goes Global, p. 48). Closer to home, the general consensus would appear to be that the BIBBs may be difficult to grasp but are infinitely better than what came before.

“There were problems in the past with trying to implement PICs [protocol implementation conformance statements],” says Steve Tom, director of technical information at Automated Logic, Kennesaw, Ga., explaining the problem with the BIBB forerunner. “They got so specific; it was a way for manufacturers to define what equipment does, but it doesn’t matter if one device has 128k more memory as long as they both support trending.”

This issue was at the heart of the problem. Published in 1995, BACnet was always of greater use to equipment manufacturers than for specifiers of building automation systems, according to most engineers. Its use of data structures and object-oriented programming were for the makers of interoperable controllers, making it difficult to understand for those without a background in IT or programming.

According to Gene DeJoannis, P.E., technical associate with van Zelm Heywood & Shadford, West Hartford, Conn., the question of BIBBs impact on the industry is indeed better suited for manufacturers. Specifically, the real issues, he says, is how it is affecting them in terms of upgrading their products to conform with BIBBs.

According to Bill Swan with Alerton Technologies, Redmond, Wash., one of the four major makers of native BACnet systems, “The BIBBs did put some burden on the controls manufacturers. Our software developers had much work to do as a result.”

But Swan believes strongly in the BIBBs as a logical way to specify. “BIBBs is a tool that consulting engineers can use and need to know,” he says.

But what about engineers? How do they feel about BIBBS, and are they using them?

Hooked on BIBBs

One very active proponent of BIBBs is Grant Wichenko, P. Eng., president of Appin Associates, Winnipeg, Manitoba. “I’m all for BIBBs, because I’ve made the effort to understand them,” says the engineer.

Of course, Wichenko is admittedly biased, as a member of the ASHRAE SSPC 135 BACnet committee, the standing committee that oversees the BACnet protocol.

“For me, personally, the BIBBs have been very successful in specifying what I want and giving owners what they want,” says Wichenko. “It explains controls the way engineers would understand the systems.”

For example, he compares controls specification with buying a valve: There is always another valve that is its equal. In other words, the contractor can go to both vendor A and B. Unfortunately, he says, controls don’t work like that.

“The problem is that it’s like having a valve with 400 options. One of the functions of the consultant, besides understanding what he wants [in a product],” says Wichenko, “is understanding what vendors can offer for what product. So, you have to look at the BIBBs as a set of features. When I do a specification, I award on value instead of price.”

Not the only game in town

But BIBBs isn’t the only effort toward making BACnet simpler, and BACnet specifications easier to write. The ASHRAE Guideline 13-2000, Specifying Direct Digital Control Systems, is also dedicated to the task. In fact, BIBBs is partly based on recommendations from Guideline 13-2000, explains Steven Bushby, with the National Institute of Standards and Technology, Gaithersburg, Md., and current chair of the SPCC 135 committee. The guideline was developed as a tutorial on building automation systems by a separate ASHRAE committee. For the BIBBs, the BACnet committee borrowed the five areas of functionality described in Guideline 13: data sharing, alarm and event management, scheduling, trending, and device management.

One consulting engineer with considerable BACnet design experience who was interviewed for this article reports that he relies on the current Guideline 13 language for his BACnet specs. “I, personally, find it difficult to use the BIBBs in a specification,” he says. “But this is more due to my failings as an engineer than to any failings with the BIBBs approach to specification.”

Deferring to the systems integrator

In general, a number of engineers still report that they are not getting too much into the specifics of the native BACnet systems. That, they feel, is the realm of the controls integrator.

“We don’t get into the object identifiers,” says Randy Taylor, P.E., Affiliated Engineers, Madison, Wis. “We might say ‘fully compatible’ or ‘level one’ or ‘level four’ compatible; the rest is up to the systems integrators.”

Taylor gives the example of a BACnet system that the firm specified for the University of Illinois at Chicago: “The job boiled down to the top native BACnet vendors. The university told us what they wanted, and we put it in the spec. The rest was up to the systems integrators.”

Wichenko counters by saying it still behooves consulting engineers to use and implement the BIBBs in their specs. “BIBBs represent a simple way to specify the features that owners and their staff want. BACnet can do more than the five BIBBs but it is a good start. The consultant has to understand what products he wants and what he wants them to do.”

The jury is still out on BACnet BIBBs. Some engineers are using the language of BIBBs in their specs. Others find satisfying results without them. It appears to be a matter of whether specifiers take the time to learn them.

BACnet Goes Global

International interest in BACnet is on the rise. It was announced at the ASHRAE 2003 Winter Meeting in Chicago that ANSI/ASHRAE Standard 135-2001, better known as BACnet, has been approved as an International Organization for Standardization (ISO) and as a European Committee for Standardization (CEN) standard. Standard 135 will be published as international standard ISO 16484-5 and as European standard EN/ISO 16484-5.

Several ASHRAE standards are referenced as part of international standards, but Standard 135 is only the second in some 10 years to be adopted in its entirety.

One of the main reasons that BACnet was adopted as an ISO standard was the inclusion of European protocols—European Installation Bus/KNX—in Addendum d of the BACnet standard, the same addendum that describes the BACnet Interoperability Building Blocks.

The EIB/KNX communications protocol is widely used in Europe for field-level residential and non-residential controls in lighting, shading, HVAC, energy management and security applications.

CEN approval is significant, because in Europe, public projects are required to follow CEN standards, according to Steve Bushby, chair of the 135 committee. In addition, ISO standard status is particularly important in Asian markets. China and Japan are both growth areas for BACnet technology.