• Articles about BACnet
• FAQs
• History of BACnet
• Fundamentals of BACnet

• How does BACnet work?
  
• BACnet's Collapsed Architecture
  
• BACnet Transport Options
  
• Internetworking
  
• Gateways
  
• Objects
  
• Services
  
• Conformance to BACnet
  
• Testing and Certification
  

The original BACnet standard from 1995 defined six classes of conformance. Each class specified a set of application services that must be supported and indicates for each service whether the device must be able to initiate the service (client) or execute the service request (server). Some conformance classes also required the support of specific BACnet standard objects. The conformance classes were numbered 1-6 and are hierarchical. Conformance to a class greater than one requires support of all of the requirements of the lower-numbered classes.

BACnet conformance classes were a statement about the number of BACnet features that a given device chose to implement. A Class 1 device, for example, only needed to be able to receive and execute a ReadProperty BACnet service. A Class 2 device also had to be able to receive and execute a WriteProperty BACnet service etc. The problem with these classes is that they do not reflect how deeply a given device implements BACnet, and which of the hundreds of BACnet options are available. So conformance classes were basically of little value.

In addition to conformance classes, the original standard specified a concept called functional groups. A functional group was a set of BACnet services and/or objects that presumably would be needed if a device was to support a certain function. For example, a device that understands time and date, and can receive and execute the TimeSynchronization service, and provides the local time and date as properties of its Device object, as said to provide the "Clock Functional Group."

Conformance to BACnet (The New Idea)
Regrettably, the combination of standard object types, conformance classes and functional groups proved to be too obscure and unwieldy for specifiers and owners. As a result, one of the first projects undertaken after the release of the BACnet standard was to revamp the whole idea of how conformance to BACnet should be described and tested. The breakthrough concept was developed by Mike Newman from Cornell University. He proposed the definitions for what he called "BACnet Interoperability Building Blocks" (BIBBs). The idea was to break the problem of interoperability down into common types of functions, intuitive to specifiers and owners, and then to define a name and a set of simple BACnet requirements for each of these. BIBBs were incorporated into BACnet in Addendum D which has become Annex K of the standard.

The BIBBs fall into five principal areas: data sharing, alarms and events, scheduling, trending and device management. In each of these areas there are a number of kinds of interoperable function one might need to perform. Each function always has two entities involved, normally an "asking device" and an "answering device", although you might prefer to think of these as "client" and "server", or "user" and "provider."

In the simplest example, say that one device has a temperature sensor whose temperature is accessible as a property of a BACnet object. Another device would like to find out this temperature. The device that has the sensor we'll call the "server." In order to interoperate in this manner, the server device must be able to receive a ReadProperty service request and execute it and return a result. The BIBB for this kind of capability is called "DS-RP-B" (DS meaning Data Sharing, RP meaning ReadProperty, B meaning the server device). The device that wants to know the temperature we'll call the "client." The client device must be able to initiate the ReadProperty service request and accept the response when it arrives. The BIBB for this capability is called "DS-RP-A" (DS meaning Data Sharing, RP meaning ReadProperty, A meaning the client or asking device).

So to have an interaction like this, two BIBBs are defined, one for the asking and one for the answering role in the interaction. Of course, other kinds of interoperations are possible and desirable. Let's say the same client has a need to turn on a light. The light is physically controlled by another BACnet device. In this example, the device which controls the light is also a BACnet server. But rather than asking for information our client now wants to request the execution of some action (turn on a light). The client wants to know as a reply simply the the request succeeded or failed. In BACnet this kind of request would usually be performed by writing to or changing the value of a property of an object that represents the light, for example a Binary Output object Present_Value property. The client turns on the light using a WriteProperty service to change the Present_Value to "on." In this case the DS-WP-A and DS-WP-B BIBBs would be required by the client and server respectively.

You can see that each of these operations is clearly defined by a BIBB. In general every interoperation in BACnet has a pair of BIBBs that define the client and server components of the interoperation.

BIBBs have been defined for a large number of interoperable features. Specification of BACnet in large part is accomplished by identifying the BIBBs that are required for each kind of interoperability that is required for a given situation.

Device Profiles

While it is possible, and in many cases desirable, to always use a detailed specification of BIBBs, there are many common kinds of interactions that traditionally go together, or are commonly found in certain types of devices. Addendum D also proposed the concept of a Device Profile, which is basically a named collection of particular BIBBs. The profile names are intended to convey the typical kind of device for which a given profile is or may be useful. This concept is now Annex L of the standard.

Annex L defines six standard profiles that describe typical collections of BACnet capability in terms of the BIBBs that might be supported by each profile. It's important to keep in mind that profiles are a tool for succinctly describing a collection of interoperability features, not a judgement about which features are more or less important. Some specifiers or owners have made the mistake of thinking of profiles as some kind of minimum recommendation. In fact, in many instances it would be highly undesirable to limit ones choices to only devices that provide the features outlined by standard profiles. In general, specifications should be written around specific BIBBs that define the interoperability desired.