BACnet has been a core element of the building automation business for years, yet many lighting professionals are unaware of exactly what it is. BACnet is a universal communication protocol for Building Automation and Controls that unifies various systems and vendors into one network and control interface. The globally accepted standard allows intelligent devices in buildings to interconnect and interoperate by defining communications rules and networked equipment mechanisms to exchange data, commands, and status information.
The key to making a building successfully “smart” is the interoperability of discrete systems and equipment supplied by numerous vendors. Integration across multiple systems and vendor solutions through an open standard achieves cost savings and streamlined operations for building owners. It also provides flexibility for future use cases. BACnet is the link that connects multiple systems, enabling sophisticated energy management, occupant comfort, and building security applications. BACnet also enables information and controls from all building systems to be combined into one single graphical control interface, which can also be accessed remotely. It simplifies operations, reduces user training, streamlines maintenance, provides alerts, and allows room for expansion and cross-functional add-ons. That is why BACnet has grown to become the predominant worldwide building integration protocol. According to a 2018 market study, BACnet is being specified in nearly 65% of projects globally and in over 80% of US projects.
The smart building is a large, interconnected puzzle where each component is a piece of a much bigger picture. A smart building shares data across multiple systems to respond to real-time needs and conditions or to learn and optimize building operations. When the building automatically knows how to react to the data and changes in its external environment, all within the parameters of its design intent and equipment requirements, it then becomes smart.
Building automation and its associated technologies are gaining more relevance and momentum, especially during the current coronavirus pandemic. It is an evolving landscape with new requirements and applications under constant development. Although individual equipment technology is often in place, if the correct infrastructure has not been set up, enabling various systems to communicate with each other becomes complicated and expensive. BACnet addresses integration of all aspects of building systems including HVAC (heating, ventilation, and air conditioning), security, shade controls, fire detection, sprinkler systems, energy and air quality monitoring, access controls, power distribution, and lighting. All these systems can operate and work independently, but they become unified and provide new value propositions with BACnet as the network’s protocol backbone.
Use cases
The use cases are extensive, and it is up to the building owner and the designers to define them. One office use case could be automatic dimming of conference room lights when a meeting is scheduled to end as a means to signal occupants to wrap up. Another scenario could entail the HVAC system adjusting to occupants’ actual locations within the space rather than having the entire space heated or cooled to a certain temperature despite vacancy.
Initial use cases of building system connectivity revolved around energy savings to cut building operational costs, such as connecting access systems with occupancy to turn lights off when no one is in the space. Another functional use case is load shedding to take advantage of utility rebate programs through power-utility credits.
Getting employees safely back to work during the pandemic opens up the possibility of new use cases. For example, how can you manage density reduction if you cannot measure real-time occupancy? Or how can you ensure a clean workstation when you do not know where someone has been sitting?
Some of these scenarios can be managed internally with a standalone lighting system via sensors, but others require integration across systems or vendors. For example, a more advanced use case is wayfinding, where an employee enters the office by swiping their access keycard and the hallway lights turn on all the way to the employee’s assigned office. Automated notifications to maintenance workers when lights fail or are about to reach end-of-life are other common use cases.
Unfortunately, many lighting controls manufacturers focus on their ecosystem and an isolated silo of hardware and software with little consideration of its integration into the larger ecosystem. As a result, they do not offer or embrace integration with BACnet. It frequently requires a special request by the building owner/operator early in the specification process. Typically, lighting controls are self-sufficient proprietary systems with limited open interfaces or application programming interfaces (APIs). While HVAC and other applications have adopted and integrated BACnet natively, the lighting industry has not. This limits potential applications for building owners and increases costs when the network control technology is not addressed and specified early enough. Building owners/operators need to understand that identifying the overall integration needs and protocol early in the process is crucial. They also need to define relevant use cases so the technical requirements can be outlined and established to specify which systems need to communicate and in what ways.
Lighting integration
Some control systems manufacturers claim they offer BACnet support or compatibility, but they often support only a small subset of functionalities and address specific use cases. In BACnet, device communications capabilities are specified in functional building blocks called BIBBs (BACnet Interoperability Building Blocks). The extent to which a particular manufacturer’s lighting controls support robust integration with other building systems is dependent on which BIBBs the company supports. This means an owner/operator or system specifier must look more deeply than just BACnet when evaluating their options and choosing the right manufacturer to work with. They need to evaluate suppliers on the fit between a supplier’s BACnet integration functionality and the requirements of the defined and future use cases.
There are three different ways a provider can integrate lighting controls with BACnet systems.
The most common and traditional integration is a gateway approach, in which lighting controls companies have a BACnet interface to their products via a gateway. The BACnet protocol stack sits inside a piece of hardware or gateway between the different systems. The lighting subsystem is on its own communication layer, but it has the gateway to connect to the building network.
There are different ways to define what a gateway is. It could be hardware, perhaps a third-party device translating signals to room or area controllers or virtual BACnet devices (preferred by Hubbell and Lutron). Any gateway acts as a translator between different protocols, so there can be issues with latency and translation.
Another approach is device-level integration, in which the BACnet stack is integrated directly into the fixture. Every fixture or end device speaks BACnet directly and is considered BACnet compatible. Therefore, the actual lighting control moves into the BACnet realm. Some consider this to be ideal as the whole system speaks one consistent protocol and data exchange format and is therefore natively integrated. Meanwhile, others argue that it requires additional device-level programming, which demands extra time. Many BACnet integrators get paid by the point, and some buildings have thousands of light fixtures, making programming expensive. For a long time, this approach had some limitations. The BACnet protocol did not support enough specific lighting capabilities to make this easy — for instance, color changing or color temperature setting. These capabilities are now available and directly supported in BACnet.
The third approach is a little controversial as different integration philosophies and programmer generations clash. It is the cloud-level approach, in which the vendors provide APIs, generally in the form of web services. While web service APIs are generally quite common in Internet of Things (IoT) software integrations today, the practice is far less common in the building automation community. Web service APIs are open in the sense that they are public and anyone can use them, but they are not standardized like BACnet. Instead, every supplier has its own API. So, while web service APIs provide flexibility for connecting to new outside services, integration costs increase rapidly with the number of vendors that need to be integrated.
Another concern with integrating systems through web service APIs is the potential security risk inherent in having multiple web services accessing the building network. Again, this issue becomes more significant as the number of vendors involved increases.
Cloud-level integration works best when BACnet integrates all controls in the building (including lighting). The building automation system provides a web service API to integrate with cloud-based building operations platforms for tenant management, analytics, diagnostics, optimization, and other services. This creates a single-point cloud connection to the building, which is more secure, simpler, and cheaper to manage, providing great benefit to the building owner.
Functionality of BACnet
The BACnet protocol provides for all essential lighting functionalities with developed BIBBs or programming elements, including the recently added color-changing capabilities. Lighting controls vendors generally deliver access only to selected functionalities regardless of which integration approach they adopt. Which functionalities each individual vendor integrates into their control interfaces is up to them. Some vendors focus merely on power management, while others incorporate more sophisticated light scene control and/or color-changing capabilities. This situation is currently not very transparent for the specifiers. This makes it difficult to compare vendors and their capabilities. They can have the required functionality already integrated, or they may be required to custom-build functionalities for a specific project, increasing integration cost. For owners/operators, the essential part is that the BACnet protocol provides the functionalities allowing the owner/operator to operate the building as one unified system. This means the lighting system is operated through BACnet and can be connected to other systems so functions can be streamlined and automated. Meanwhile, commissioning is always handled by the controls vendor through its own interface. The vendor provides the methodology on the front end and manages the programming in the back end.
From a building owner/operator’s point of view, the goal is maximizing the integration functionality to enable current and future applications at a reasonable cost. The key element is that they can operate the lighting through BACnet. Determining the integration functionality provided by specific vendors is not always easy, because they are not the same. That is why it is critical for building system specifiers to detail their requirements with more specificity than just requiring the lighting system to have a BACnet interface.
Lighting user interfaces
Currently, one of the lighting industry's big topics of discussion is the quality of user interfaces and how intuitive they are. Traditionally they are developed by engineers and programmers and provide overly technical, non-intuitive interfaces for end users.
One of BACnet’s value propositions is the ability to implement a unified control system across multiple subsystems (lighting, HVAC, and so on). However, BACnet only provides interoperability among devices and systems; it does not control the look and layout of user interfaces. Instead, user interfaces are designed and delivered by controls system vendors or system integrators.
BACnet ensures those user interfaces can access data and control points in all the connected equipment, but the interface design defines the use cases it enables and supports. So even if a system uses BACnet, that does not mean user interfaces from different vendors or integrators are equivalent. Moreover, it also suggests that lighting programming still needs to happen on two different levels: the product or device level (BACnet) and the end-user application, e.g., the lighting scenes provided by the lighting designer.
Conclusion
Progressive building owners/operators fully understand the value proposition of smart and connected buildings. To fully realize the benefits, it is essential to put the correct infrastructure in place. The infrastructure should be efficient, vendor agnostic, open to future enhancements, sustainable, and affordable. Lighting is a key element of many building control solutions, so lighting controls must be effectively integrated with other building automation systems. The best way to achieve that is to detail the requirements for substantive BACnet integration capability in lighting control systems early in the design process and for lighting controls vendors to be more transparent about their level of BACnet integration.
Get to know our experts
BEATRICE WITZGALL is the principal at interdisciplinary design consultancy I3D, Inc., which strives to create dynamic physical environments. Witzgall is an award-winning designer and architect with 20 years of experience, and has authored several articles on lighting controls and the Internet of Things for LEDs Magazine. She is a frequent speaker on smart buildings, lighting control systems, user experience, and systems integration.
ANDY MCMILLAN is president and managing director of BACnet International, the organization dedicated to promulgating successful implementation of BACnet protocol in building automation and control systems. He has led several controls companies and has been an invited speaker at conferences around the world. His recent presentations have focused on rapid change in the building automation business driven by connected lighting, cybersecurity, and the Internet of Things. McMillan holds a dozen patents in sensors, systems, and software as well as engineering and business degrees from the University of Michigan.
