A new approach to specifying with BACnet
Updated standard ASHRAE 135-2016 makes specifying BACnet equipment easier.
It’s like a new birth in regards to how BACnet devices are specified with systems like lighting, access control, and life safety to communicate with building management systems (BMS). Effectively specifying BACnet for systems that are not traditionally HVAC-based, such as lighting, has been challenging. The effort to fundamentally assure the specification effectively communicates the owner’s intent of how systems like lighting work in a BACnet BMS environment has been a source of frustration and disappointment. Yet a fundamental shift is happening to make specifying easier, without the need for a PhD level of understanding in BACnet, because of a new “family” approach to BACnet device profiles. This new approach debuted in ASHRAE 135-2016: BACnet—A Data Communication Protocol for Building Automation and Control Networks.
In the 2001 through 2012 versions of ASHRAE 135, device profiles provided the fundamental relationship between how and which devices control and which devices obey. The device profiles for specifying BACnet equipment can be found in Annex L of the standard. Until now, very little was changed in the standard.
Keep in mind, ASHRAE created BACnet with HVAC systems in mind. The BACnet committee’s first official meeting dates back to 1987, although the BACnet standard did not have its first official publication until 1995. Other systems were not considered until much later—the Working Group for Lighting Applications did not have its first meeting until 2001. In regards to device profiles, systems like lighting, access control, or life safety adopted functionality to fit the original HVAC device profiles schema.
From the beginning, BACnet’s goal was to be the protocol for all building automation systems (BAS). To help accomplish that goal, objects have been developed in recent years for the specific need of systems like lighting, life safety, and access control. However, when it came to device profiles, there was a lot of debate about whether the current device profiles should encompass these industry-specific objects or make the new industry-specific objects optional. Optionality did not encourage the implementation of these industry-specific objects in BMS.
The concept of families was another option. The concept was put forth by an earlier proposal in ASHRAE 135-2012 to add special functionality in devices like BACnet gateways and BACnet routers. This way, a manufacturer could proclaim they are a BACnet controller and a BACnet router. The original proposal divided the known device profiles into two families: operator interfaces and controllers. A third family was added, called "miscellaneous," which included BACnet routers, gateways, and broadcast-management devices. This concept of families was new in regards to a physical device supporting multiple profiles, and that this application could be expanded to include device profiles designed for other building systems like lighting.
Keeping the traditional families of operator interfaces and controllers intact, other proposals soon added a family of access-control operator interfaces and controllers and life safety operator interfaces and controllers. Currently in public review an addendum for lighting is also being added to include new families of lighting operator interfaces, lighting controllers, and lighting control stations. The new landscape of device profiles categorized into families are:
- Traditional operator interfaces
- Lighting operator interfaces
- Life safety operator interfaces
- Access-control operator interfaces
- Lighting control stations
- Traditional controllers
- Lighting controllers
- Life safety controllers
- Access-control controllers
A manufacturer of a workstation can concentrate solely on a traditional HVAC-based device profile and that would be perfectly acceptable, but if a manufacturer of a workstation wants to be identified as working with every system—lighting, access control, life safety—it can also do just that by including family profiles from each group.
This family concept in lighting is expected to relieve much of the burden of understanding compatibility and functionality when integrating a BMS and lighting system which was based on a different industry perspective. To work with a BMS traditional operator, HVAC-based interface lighting systems had to adopt the traditional HVAC-based BACnet objects and services. Using traditional HVAC-based BACnet objects and services gave no clue in determining what functionality for lighting was available through integration. It took an in-depth discovery about the integration capabilities of each manufacturer for a specifier to know if that manufacturer could meet their intent. This was the source of a lot of frustration for specifiers resulting in unsatisfied end users. The family concept takes basic lighting functionally from being manufacturer-specific to being profile-specific and thus easier to understand.
Another major benefit is that the family concept makes it easier for a BAS, like lighting and access control, to use BACnet as its primary protocol regardless if it is connecting to a BMS.
New proposals to the ANSI/ASHRAE BACnet standard are adding objects specific to elevators. History tells us that once the industry-specific objects and services are established, the device profiles for that system will come soon after.
This new family approach will help BACnet to become the predominant protocol for all building systems. Allowing the specification of BACnet in each system and between systems leads to seamless machine-to-machine (M2M) communication, which is the ultimate goal.
Scott Ziegenfus is the manager of government and industry relations at Hubbell Lighting and a member of ASHRAE SSPC 135 BACnet Committee and Chair of ASHRAE SSPC 135 BACnet Data Modeling Working Group.