Building Management System (BMS) Protocols Explained

WHAT YOU SHOULD KNOW ABOUT PROTOCOLS WHILE SELECTING A BUILDING MANAGEMENT SYSTEM (BMS)?

Protocols are languages by which two devices communicate and exchange data.  These devices are microprocessor-based products, such as an input/output board, roof top unit controller (RTU), Chiller controller, user’s laptop/desktop computer or even central enterprise servers.

The picture below shows that the master building management system (device) communicates with devices, such as RTU, refrigeration controllers, energy meters and other input/output boards within a building.  Similarly, the Building controller communicates with remote users and enterprise servers via the internet to display temperature, operating parameters or energy data.

Protocols are defined by the data structures that
explain the format and meaning of each data (almost like a dictionary that explains a word’s spelling and meaning).  Both devices have to know the data structure in order to facilitate the exchange of data.  The data exchange usually happens over some physical wire (such as on a twisted pair RS485 or Ethernet CAT5 cable).  It can also happen wirelessly over wifi network.

In order for 2 people to have a meaningful exchange they need to speak the same language and have a medium to communicate (e.g. phone). This language is equivalent to a protocol in the BMS world and the phone is equivalent to a physical wire.  Hence, the term BACNet over IP means that the protocol is BACNet and the physical layer is an IP network.

The four key aspects to protocol are:
1. Open
2. Standard
3. Inter-operable
4. Proprietary.

A protocol is “open” when the creator of the protocol makes it readily available to everyone (e.g. through their web-site).  “Standard” protocol requires all parties to agree on a data structure that can be implemented on their respective devices.   If there is consistency across an industry,  then the protocol becomes an industry standard e.g. BACnet, modbus.

“Inter-operable” is the characteristic of a protocol that makes it vendor agnostic  e.g. a controller from one vendor can be replaced with a controller from a different vendor.  ”Proprietary” protocols are those that make the protocols restricted to the creator of the device by not sharing the data structure.

It is not difficult to imagine why proprietary protocol is not considered best practice. One of the key criteria in selecting BMS is to make sure that the language/data structure is not proprietary.

In order to identify whether or not a protocol is open, you need to ask the following questions to the BMS vendor:
a)      Can your competitor exchange data with your BMS?
b)      Is your protocol published in such a way that it is easily accessible to everyone (including the competitor)?

A proprietary protocol is not good for the client because once bought, they are locked with that vendor for all of their BMS needs. This means that one cannot remotely access the BMS, for example, to manipulate the set points without the vendor’s software.

On the other hand, an “open” and “standard” speaking device will not lock you with a vendor and will enable you to shop freely for enterprise solution providers.

What is the best protocol for BMS?

When a master controller is exchanging data with devices and meters within a building, the standard BACNet or Modbus or any other standard protocol should be preferred.  Otherwise, make sure it is at least “open” for anyone to read and write information.

For enterprise access (protocol B in picture), people have used BACnet over IP.  However, the current trend is to use internet technology for data exchange.  Companies like Honeywell Tridium (Niagara framework), Resource Data Management (Data Manager), Echelon Corps (iLon) and many others have used standard internet XML data with web-services to exchange data.

Even the ASHRAE BACNet committee has a XML working group that is defining applications of the eXtensible Markup Language (XML) relevant to BACnet systems.  They are also working on Web service definitions that will allow data exchange between building automation and control systems and various enterprise management systems.

To Summarize, when selecting devices ensure the following:

• Devices like RTU, refrigeration controller should use “open” protocols like BACnet or modbus.
• Make sure these devices give you both “read” and “write” capabilities so that you can even change set points.
• The BMS should have web-services capabilities with data exchange using XML for enterprise access.
• Again, the BMS web-services should allow both read and write capabilities.
• The BMS supplier should provide the XML dictionary (structure of data format) and web-services definitions  to anyone (including their own competitor to be “open”)

About the Author

Dr. Abtar Singh is the founder & CEO of Singh360 Inc (www.singh360.com), a facility management consulting firm.   He specializes in facility-management systems, design, engineering, performance monitoring, predictive analytics, and optimization of energy and maintenance systems.  He can  be reached by contacting Singh360 .