I receive calls from clients who want connect to their older building’s HVAC energy management system (EMS) via more modern tools. There are many reasons for wanting to connect to an older system. Some clients simply want to create a browser interface to enable easier control of their building. Some need to replace failed components and hope that they can modernize their system in pieces. Others want to take advantage of utility company programs to implement Demand Response (DR) or Peak Load Management (PLM). Also, more owners today are trying to apply data analysis tools to monitor their building performance. Finally, some clients hate their controls vendor and want to get them out. Whatever the reason, there is an increasing demand to connect existing control systems via newer tools.
Informed clients are aware that the Niagara Framework was designed to facilitate the connection between dissimilar control networks. When these clients call, they eagerly state the manufacturer’s name of their existing controls and ask for a price to connect their building. Unfortunately, the manufacturer’s name alone isn’t all that’s needed to determine if it’s possible. Very specific details about the model and age of the system are needed. Even after we’ve got all the data, the answer comes down to the availability, capability and cost of a driver.
The “driver” in question isn’t a chauffeur, a golf club or a tool used to tighten screws. Instead it’s a piece of software that’s needed to translate the control signals from the existing EMS into a format that another system can understand. Think of it like Google Translate – you enter Italian and the translator outputs English. Ideally, like Google Translate, a driver understands both languages perfectly well and can instantly communicate a message from one language to the other. Unfortunately like language translation, it’s never that easy.
Just as the word “driver” can have multiple meanings in English, controls communications signals in one system may not have an exact parallel in another system. Worse yet, controls manufacturers historically designed their systems so that they could not be accessed without proprietary tools of their own making. The thinking was to lock up a building system so that the incumbent company could create a recurring stream of purchases for any future needs. (It’s a very profitable model for the service department too!)
Building owners found proprietary systems to be very expensive to maintain. This was one of the principal reasons behind the creation of universal building network protocols such as BACNET and LONworks. These protocols were developed to create standards for communications between systems. In theory, all manufacturers’ devices could interconnect via these systems. If only it were that simple. Not all control system communication signals have a parallel in other systems; some manufactures have developed unique features for their control system. Others only partially adopted the standard protocol, which means that the connections aren’t that simple. (Note that LON generally works much better due to the fact that LON implementation is tightly controlled by Echelon, the company that makes the chip set used in every LON card.)
Some drivers work very well and easily translate information into a format that’s immediately useful on the other system. Other drivers don’t work well at all, and some drivers don’t exist. In many cases a hardware bridging device may be needed to complete the connection. These devices may be made by the original equipment manufacturer or others, but none of them are cheap.
Unfortunately, some drivers and bridges don’t work well. It may be the quality of the software, but often this is due to the limitations of the older system being connected to. For example, if the communication trunk of the existing BMS has a top speed of 4,800 baud (=0.0006 megabits per second), no driver can quickly deliver the data needed for the functions discussed at the beginning of this post. Other drivers are badly hampered by the unwillingness of the BMS vendor to allow access to their system. For older systems a driver may not exist at all. Worse yet, some of the ones that work the worst are quite expensive.
Another option is to create a custom driver. There are several companies who are in the business of creating custom drivers. I’m not a big believer in custom drivers unless there’s a huge payback for the project. Custom drivers can be costly to acquire, possibly difficult to maintain and may deliver unacceptable performance.
No one wants to hear that they’ll have to replace their control system to get the functionality that they want. Even in a small building, this can be quite costly. I hate having to tell clients that we can’t connect to their system – especially when other vendors say that they can – but if the “upgraded” system won’t meet their needs or won’t deliver an acceptable payback, well, it is what it is. Before spending big $’s on a driver, make sure that it can deliver the goods.