These days, when building owners, facility managers or consultants want to specify a new Building Management System (BMS), they invariably say they want an “open system”. This comes from a fear of becoming locked into a single service provider with the perceived risk (although not always the reality) that this may result in high service prices and poor service levels.
It’s not always clear what is meant by the term “open”, and some people use the description “open protocol” which describes the technical interoperability of the system when really they are looking for service flexibility. This paper explores the pros and cons of three potentially overlapping system types:
Where the BMS head-end can communicate with fi eld controllers using openly-available, industry-standard protocols, which allow users to select system components from a wide range of suppliers.
Where the system developer/manufacturer certifi es selected vendors as System Integrators (SI’s) for their products, who are then able to supply, commission and service the system using specially licensed software tools giving building managers a choice of suppliers.
Where the system contains the software tools such that, with appropriate training, a licensed end user or their nominated service providers can service and maintain the system.
These concepts are largely independent. It is possible to have an open-protocol system which may or may not be multi-vendor, or it is possible to have a user-managed system which may or may not support open protocols. For building owners, operators and consultants, a clear understanding of the difference in these concepts and how this affects the success of the system and the facility, is crucial to choosing the right solution.
This document clarifies the realities associated with the ‘open’ concept and sets the context within which building operators and users should select the system that provides them with the most benefits, most cost-effectively, across its lifetime.
What is an Open Protocol?
A Building Management System generally is made up of the following parts:
a.) Field Controllers, which are hardware devices installed across a site and used to sense and control equipment or building areas e.g. thermostats, room controllers etc, and a
b.) Software Head-End, that consolidates and presents all data from the fi eld devices to the system operator for them to view and change the operation of the system and building.
A communications protocol is the set of rules that devices use to communicate over a network and an “open protocol” is an industry standard for communication which enables the software head-end of one manufacturer to communicate with fi eld controllers of any manufacturer that supports the same standard. This provides the building manager with freedom of choice in selecting and matching the software systems and fi eld devices, which create the total building management system.
Open protocols have been a good thing for building managers and the supply industry, but there are limitations. Because all devices have to look the same to the software head-end any unique, often advanced, features may not be supported by the protocol, which reduces system functionality to the lowest common denominator. Some manufacturers therefore support both open protocols and proprietary or extended protocols for field devices, allowing building managers to access additional functionality not supported by the base standard.
Also, the open systems protocols normally apply only to the real-time day-to-day running of the systems. Set-up, programming and commissioning of devices is usually still done with manufacturer-specifi c tools. This means that the promise of infi nite choice is impractical as facility managers often don’t want the hassle of multiple different confi guration systems to maintain