As detailed in this month's cover story, in many instances process and building automation systems are separate, but need to be connected to each other. Data to be exchanged between the two systems can be as simple as a single temperature point or as complex as real-time energy consumption values. Integrating process and building automation can be done in one of two basic ways depending on the degree of connectivity required.
For process plants with little interaction between the process and building automation systems, hard-wired connections between the two systems are often the best approach due to low cost and simplicity. With this approach, I/O is simply hard-wired between the two systems, with the building automation system typically sending discrete and analog output signals to the process automation system indicating status, temperatures and other relevant information.
But for plants requiring extensive interaction and interconnections between process and building automation systems, the hard-wired approach quickly becomes cumbersome. Not only is it expensive, it's also inflexible as a new hard-wired connection must be made every time additional information needs to be exchanged.
In these instances, a digital data link between the two systems is the better solution since a large amount of data can be transferred as easily as a single value. The digital link can be implemented in a variety of ways: controller to controller, controller to HMI, or HMI to HMI. In any case, a method of connection must be selected, not always an easy choice, because process and building automation systems typically don't use the same communication protocols.
Realizing this, process automation software suppliers are moving to accommodate BACnet, the most widely used protocol in building automation. BACnet supports five different networking technologies, but this article will focus on the Ethernet-based protocol, referred to as BACnet/IP, which is the fastest of the five protocols at a speed of 100 Mbps.
Most every building automation system supports BACnet/IP, so the first step to establishing communications is to pick a process automation system component that also supports BACnet/IP.
At the HMI level, some suppliers support BACnet natively, while others provide support through OPC plug-ins. For example, InduSoft provides native support for BACnet, allowing its Web Studio software to communicate to a building automation system via BACnet/IP. InduSoft's BACnet driver contains the tools required to translate BACnet information to a format recognizable by its HMI software.
If the OPC option is used, a method of further translating BACnet information to a format recognizable by the HMI is required. This can be done with some HMI software configuration and programming, but to simplify and standardize communications, the OPC Foundation is actively working on an OPC UA for BACnet initiative.
The aim of this initiative is to facilitate the flow of information between process and building automaton systems by establishing a common language for communication. BACnet will be mapped to OPC UA by linking BACnet Objects/Properties to OPC UA Object Types, BACnet Events to OPC UA Alarms & Conditions, BACnet Logging to OPC UA Historical Access, BACnet Data Structures to OPC UA Structure Data Types, and BACnet Units to OPC UA Engineering Units.
The BACnet OPC UA Mapping Working Group was started at the end of 2012, produced a final draft in April 2014, has started prototyping, and hopes to release a standard by the end of 2014.
Connecting the building automation system to the process automation system at the HMI level allows the HMI to act as a gateway, communicating information up to ERP and other higher-level computing systems, and down to controllers.
Another way to establish BACnet communications is at the controller level. For example, ProSoft offers a ControlLogix to BACnet communication interface module which plugs into a Rockwell Automation chassis to pass data between a ControlLogix PAC and BACnet devices and networks. The module can be configured as a BACnet slave or master, and in either case communications are via BACnet/IP. In addition to plug-in interface modules, standalone gateways are also available.
This method of communication may not be as powerful or flexible as using a PC-based HMI, but it's simpler and can be sufficient for many applications. To the extent that the controller is more reliable than the PC-based HMI, this method of communication will also be more robust.