The implementation of BACnet is under-the-hood. It is invisible to most of us users. We don’t know what services are supported and nor do we know when each service is used. If we don’t know then how can we tell, for example, whether a controller and field device such as a thermostat can interact.
The question is: How do you match requirements of a project to the capabilities of the devices being installed?
The Answer – in BACnet – is BIBBS. A BIBB is a Bacnet Interoperability Building Block.
Continuing with our example: Say your controller needs to read the set point on a thermostat to perform its control. Then the controller needs to support a BIBB called DS-RP-A. This isn’t enough. The thermostat must be able to respond so it needs to support a BIBB called DS-RP-B. DS stands for Data Sharing. RP stands for Read Property. The A and the B stand for Client (A) and Server (B).
The outdoor temperature on a HVAC controller could come from two places. A local sensor connected to the unit or a remote value sent via BACnet. In this case you would want to match the BAS controller and HVAC controller with BIBBS DS-WP-A and DS-WP-B (DataSharing-WriteProperty-A or B for Client and Server).
Thus, if you buy a great controller that supports Conditional and Range Reads you would want to buy field devices that support these services. DS-RPC-A/B for DataSharing-ReadPropertyConditional-Client/Server.
Abbreviation BIBB Category
DS Data Sharing
AE Alarm and Event Management
DM Device Management (DM and NM are part of the same category)
NM Network Management
TIP : Device A and Device B. All the BIBBs end in ‘-A’ or ‘-B’. BACnet refers to the A device and the B device. The A device in this context is a device acting as a client. The B device means a device acting as a server. In BACnet devices can be both clients and servers since almost all devices can read data from each other.
A complete table of BIIB’s is available at: http://www.chipkin.com/articles/bacnet-bibbs-table-bacnet-interoperability-building-blocks