Conformance to BACnet (The Old Idea)
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
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.
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.