By Steve Tom
An airport manager uses his building automation system to check the temperatures and schedules in multiple concourses. A physical plant employee at a university enters a “winter storm – no classes” schedule into buildings throughout the campus. An energy manager uses trends and reports to compare the performance of government facilities throughout the southwestern United States and Hawaii, activating emergency measures when required.
Nothing you haven’t heard before? Maybe, but in each of these examples the data is coming from multiple building automation systems made by competing vendors, and is being integrated into a single user interface by a web-based front end. The interoperability promises of standard communication protocols have come true, and the new web-based control systems extend this interoperability across the globe.
The concept of interoperability is not new, but getting proprietary control systems to talk to one another used to be so difficult that it was usually confined to retrieving a few nuggets of information from major pieces of equipment like chillers or boilers. The emergence of standard point-level protocols like LonWorks® and Modbus made this job much easier, but the exchange was still primarily limited to individual data points. BACnet™ raised the ante by including higher-level building automation functions like scheduling, alarming, and trending. This greatly simplified the process of making the entire system interoperable; that is, using a front end made by one manufacturer on a system made by another.
To generate a trend graph using point-by-point interoperability, for example, the front-end computer must be connected to the system for the entire time period being trended so it can read each value as it occurs. Alternatively, a special piece of hardware must be installed on the system to gather and store the trend values in a format that can be read by the front-end computer. With BACnet, the original vendor’s hardware stores the trend data in an interoperable format to begin with. Now, any other vendor’s BACnet front-end can connect to the system, retrieve the BACnet trend file, and display it. Similarly, turning a piece of equipment “on” at a predetermined time can be handled by point-by-point interoperability if the front-end computer is connected at the time the change needs to be made. If, however, you want to schedule it to turn “on” at 6:00 a.m. next Tuesday, you need to use an interoperable schedule like BACnet’s.
BACnet is a logical choice for wide-area interoperability because it is impractical to keep the front-end computer connected to every building in the system 24-hours-a-day. The choice then becomes one of using an interoperable protocol for the high-level functions or installing a proprietary piece of hardware in every building. In a web-based system, a web server replaces the front-end computer but the choice is the same: Either the server uses BACnet to communicate with each building as required, or a proprietary piece of equipment needs to be installed in every building. Both approaches provide interoperability, but BACnet provides a cleaner solution.Steve Tom, PE, PhD, is the director of technical information at Automated Logic Corp. (www.automatedlogic.com), Kennesaw, GA.