This audio was created using Microsoft Azure Speech Services
As societal and business pressures continue to push building owners and operators to improve the efficiency, sustainability, productivity, and tenant experience of their buildings, the role of the BMS is growing beyond its traditional role of building heating, ventilation, & air conditioning (HVAC). The term “open” is often used to describe desired functionality of a Building Management System (BMS). It is thought to be essential in achieving the ambition of a smart building. But interestingly, that term itself, while used often by building owners/operators as requirements for their system, as well as by vendors to describe attributes of their systems, generally creates much confusion and ambiguity, since the industry lacks a standard definition.
I collaborated over the last several months with two very smart experts within Schneider Electric – Jeff Bowman and Chris Megede – to create a white paper to help clear up the confusion. In this paper, we propose a logical industry framework (shown below) for discussing the topic of open BMSs, so that decision makers can better assess the capabilities of a system, have informed discussions with providers and partners about where a system falls on the spectrum of “openness”, and understand the complexities and implications of being open. The hopeful outcome is that decision makers can make a more informed system selection based on the desired outcome(s) of the building.
Criteria for assessing openness
Every building is unique. And open is a complex topic. (It is much more than a discussion of open protocols although that’s commonly where the conversations go). The framework introduces three distinct layers defining criteria to assess open. Each layer has its own expectations and challenges, and each layer builds from the previous layer. This means the capabilities from layer 1 are pre-requisites for achieving the capabilities of layer 2, and layer 2 are pre-requisites for achieving layer 3.
For each of the three layers in the framework, we have defined three criteria for assessing how open the system is: (1) Interoperability, (2) Engineering complexity, and (3) Who performs the work.
- Interoperability – assesses the ability for one part of the system to work with another part, or one system to work with another system
- Engineering complexity – assesses how difficult it is to achieve the interoperability; i.e. how much customization and programming is a key consideration
- Who performs the work – assesses whether specialized skills and individuals are necessary to achieve the objectives; i.e. does work require certified, specialized skillsets?
There are often tradeoffs with these criteria. For instance, you might be able to achieve a highly open system in terms of interoperability by sacrificing engineering simplicity; or work can be done without engineering complexity, but only by a vendor’s certified technician. Having this construct for discussing a BMS’s degree of “openness” brings these important topics and tradeoffs into the picture.
Layer 1 – Data acquisition and sharing
Data acquisition and sharing is the critical foundation for BMSs. Within the conventional scope of controlling the HVAC of a building, the system must be capable of sending and receiving data to and from sensors and actuators and other building controllers. Sensors/actuators are easiest to integrate as they are one-way devices that share or receive data to/from a controller. Examples are simple sensors for pressure, temperature, etc.
Controllers require protocols to communicate. More and more, controllers use open protocols, and to consider a BMS open, it should be interoperable across multiple OT protocols (i.e. BACnet, LonWorks). But just because it uses an open protocol, doesn’t mean it is interoperable. The needed data must be exposed by the vendor. The system should also support the extension of native protocols, in order to limit the number of gateways required to serve as “translators” to the sensors, actuators, and controllers. The BMS should not depend on calling in “experts” for day-to-day operations like modifying a room temperature set point or updating schedules.
Layer 2 – System integration
As the BMS scope expands beyond HVAC control, it must integrate with other systems within the building, such as the lighting system. The BMS must now be able to consume data in a different way. It must be able to push data to other systems and query data from those systems. It may also need to tie in with analytics services that may communicate to a proprietary cloud. One key topic here is the use of APIs vs files/databases vs OT protocols. APIs are a means of a vendor exposing the data for another system’s use. Semantic tagging (labeling) and ontologies (relationships of things) are critical for interoperability. Without the right context of the data, it becomes difficult to use it. Brick and Haystack are two examples of semantic standards that help expose data in a standard way.
During system integration, another important consideration is authentication mechanisms. These can be a limiting factor and increase the complexity of integrating the systems together. Its helpful to look for a system that supports non-obscure authentication types like OAuth, as well as allows custom development of middleware to access 3rd parties that use proprietary authentication. An open system minimizes the time required to integrate systems together and simplifies integration with teams of experts.
Layer 3 – Building orchestration
Building orchestration is complete coordination across all building systems. Think of this as Layer 2 at scale. It’s what gets us to the ambition of a smart building where everything is tied together. It helps achieve optimized energy efficiency, tenant well-being, and productivity by streamlining and automating complex building tasks. These integrations are generally bi-directional, so it’s likely to include complicated object types and data structures like time schedules. This increases the likelihood of semantic differences between systems and a need for custom rules and workflows to fill in the gaps. A more open BMS would have a toolset that supports these custom rules and workflows.
In the paper, we discuss how presentation, point discovery/mapping, programming, and APIs can determine how much complexity is needed here. The paper also discusses common integration activities that can occur that require varying skills and expertise. For instance, setting up workflows in most cases can be accomplished using a tool with minimal amount of training. However, complex workflows may require the help of a software developer.
The paper goes much more in depth on each of the layers. It also provides use cases and explanations for how a BMS may be more or less open. Check out the paper here (White Paper 501), “Smart Buildings: A Framework for Assessing the “Openness” of a Building Management System (BMS)”
