Every complex topic or field needs a helpful naming system. Scientists name flora and fauna by genus and species. Even astronomers have their own planetary nomenclature. Standard naming conventions do just that—they standardize how we talk about things. They’re also a convenient way to condense large amounts of information into a short form. Hence, they function like acronyms. We needn’t sound out “self-contained underwater breathing apparatus” when we can simply utter S.C.U.B.A. right?  

In building automation, the same need for standards and compression applies, and BACnet gives us a convenient way to describe the functionality of devices using something called BIBBs.  

What are BIBBs? 

Definition: BIBBs stands for “BACnet Interoperability Building Blocks” and is a standard naming convention for representing specific device capabilities using simple acronyms. That is, it creates simple categories to describe how one device works with another.    

Without short-form descriptions, listing all the capabilities and services that a device offers would turn functional descriptions into a messy scrawl of technical jargon. By condensing these functions into acronyms, BIBBs makes it easier for FMs, system integrators, and building engineers to talk about the same things. BIBBs help buyers get the minimum number of services for the job without over-engineering and spending for extraneous functionality. 

man holding smartphone with words automation

BIBB Categories  

The BIBB naming system starts with five broad categories that list interoperability functions. These are high level functions that host specific capabilities within them. Categories include: 

Data Sharing (DS) 

The data sharing function describes how devices exchange data. Data sharing is essential for reading and writing data from one device to another. For example. If you wanted to regularly check the water temp of your boiler to monitor its performance, you would need the DS functionality.   

Alarm & Event Management (AE) 

The alarm and event management functionality is for detecting and notifying alarms and events. For example, if your boiler temps exceeded a specified setpoint, the AE function would allow you to receive an alert.  

Scheduling (SCHED) 

The scheduling functionality is for scheduling values based on date, time, and calendar. For example, if you wanted to schedule your boiler to provide after-hours heating for tenants.  

Trending (T) 

The trending functionality is for trend logging and historical data support. For example, if you wanted to store your boiler’s temp data to create a history for your engineer.  

Device Management/Network Management (DM/NM) 

The DM/NM is for setting up device and network management. It allows devices to discover each other, to synchronize clocks, and to reset a device to factory settings (reinitialize). For example, if you wanted to discover a newly installed boiler temp sensor.  

Specific Capabilities 

Specific capabilities, or sometimes called services, are distinct functions that exist within a BIBBs category. Capabilities also have acronyms. For example, the Read Property (RP) service is under the data sharing (DS) category. The service must exist for data sharing to occur. That is, a device (e.g., controller) must be able to read data, while another device (e.g., thermostat) must be able to send it. Many devices have both capabilities. Here are some examples of services for different BIBBs categories: 

Data Sharing (DS) 

  • Read Property Multiple (RPM) 
  • Write Property (WP) 
  • Change of Value (COV) 

Alarm & Event Management (AE) 

  • Notification (N) 
  • Alarm Summary (ASUM) 
  • View Notifications (VN) 

Device and Network Management 

  • Dynamic Device Binding (DDB) 
  • Text Message (TM) 
  • Reinitialize Device (RD) 

Find a more extensive list of device capabilities here

Clients and Servers 

BIBBs also distinguishes between clients and servers, assigning and A and B category to each respectively. Client devices (A) can initiate or call for data or service from a device that can respond to that request (B). An example of this would be a controller (A) requesting temp data from a thermostat (B), which responds with the requested data. You can remember this order by recalling that the letter “A” comes before “B” in the alphabet, just as a request must precede a response.  

Putting It All Together 

Now that we have all three parts of BIBBs, let’s look at a full interoperability description. The BIBBs naming syntax places the category first, specific capability second, and server/client designation third. Each acronym is separated by a dash. Consider a BACnet controller that has data sharing (DS), a read property service (RP), and client capability (A). It would be designated as DS-RP-A. Can you guess what functionality a thermostat would require to send temp data back to the controller? If you answered DS-RP-B, you’re correct!   

Conclusion 

As we’ve seen, BIBBs are the “building blocks” of the standardized system of naming devices and their interoperability functions. Devices can have many different functions, so there’s also a need to group them. For example, controllers, sensors, and actuators must all have a minimum number of specific functions to work. These groups of functions are called BACnet device profiles. Like BIBBs acronyms, profiles give us a shorthand way of quickly designating and describing a device. Read BACnet Basics: What are Device Profiles? to learn more or visit The BACnet Institute for free training.