By Stephen R. Ferree
Building automation systems have evolved over the past 25 years from the mixture of pneumatic controls, relays, sensors, and actuators of the past to the direct digital controls of the present. Many manufacturers had developed their own protocol to enable their devices to communicate with each other. Even unique systems within a building, such as boiler controls, chillers, variable speed drives, fire panels, and security systems, developed their own protocols until the typical building became a tower of babble. In many buildings interoperability means that the front-end controls for the various systems in the building all terminate in the same room.
While protocols such as LonWorks® and BACnet™ have come a long way toward the goal of interoperability, many of the devices and systems desired by today’s building operators and integrators do not utilize these open system protocols to interface to building automation systems.
The various control systems in a plant or building can no longer afford to operate independently. Reduced manpower, increased energy costs, increased security needs, and enhanced personnel demands mean that building systems must work together to provide the optimum environment for the people and equipment within the structure.
There are many reasons for interoperability of building control systems, including:
Reduced installation costs.
Enhanced energy management.
Improvement of safety and security of plant, personnel, and equipment.
Plant-wide access to building operation information.
Use of existing Ethernet backbone for building operation.
Single-seat user interface.
How does the integrator get these various devices to be interoperable? It would be nice if all devices used a common communication protocol, but reality is that with the large number of legacy devices worldwide, plus the many different protocols available today, a single common protocol is not usually a choice. Also, for most devices, there is usually only one protocol output available. Thus, even if the integrator does select BACnet as the primary protocol, there will be many individual devices that will use a proprietary protocol – LonWorks, Metasys, Modbus, or something else. The only practical way to bring information from these other devices is via a protocol gateway.
A gateway system can seamlessly integrate systems together. For instance, when interfacing a fire panel using a proprietary protocol to a control system using Modbus TCP, the gateway should appear like a fire panel node to any device on the fire network and appear as a Modbus node to any Modbus system. A gateway can link a serial device to other serial systems or to Ethernet.
Interoperability is no longer a dream of the future; it is here today. While it is not simply plug and play, it will meet an integrator’s need to share data between devices and enjoy unified control. Using gateways enables the integrator to bring in legacy devices and enable interoperability between diverse systems.
Stephen R. Ferree (email@example.com) is vice president of marketing at FieldServer Technologies (www.fieldserver.com), Milpitas, CA.