The article "Become a Bas Master" (Engineered Systems, February 2000) described a pathway for the migration to an interoperable, open protocol building automation system (bas). Since the writing of the original article, many new interoperable systems have been brought into operation. Also, many of those systems have included Internet hardware and software to provide the consistency and convenience of Internet access.
The shared experiences of implementing and operating these interoperable systems have generated a valuable body of knowledge for those embarking on interoperability and Web access.
Interoperability Defined
Interoperability refers to the ability of a bas system to utilize components of different manufacturers at the system level. Interoperability allows the complete monitoring, and control of a distributed, multivendor EMCS from a central workstation with uniform commands, monitoring, and graphics. This quality allows the operation and maintenance (O&M) staff to operate the bas with the same unchanging mode of operation even as systems of new manufacturers are added.Interoperable systems also communicate with each other as well as with a common workstation. This allows the different systems to share information and increases the control and effectiveness of the overall installation without increasing the number of control points. For example, an outside air temperature sensor from one system could also serve different systems in different buildings on a campus.
Interoperable bas systems generally employ either the BACnet or LonWorks protocols. To provide some perspective there have been many interoperable protocols in the past and there will be new ones in the future. But BACnet and LonWorks are specifically tailored to applications in buildings and are dominating today's market. Both of these communication and control languages provide interoperability with certified peer devices and controllers but the protocols themselves are not inherently interoperable.
Interoperability between BACnet and LonWorks systems is achieved with the use of bridges and gateways that translate between the two. Alternatively, an integrating controller can be used to combine several BACnet buildings with a group of LonWorks buildings. This controller might serve a local area network (LAN) providing access from any workstation on the network. If the LAN is equipped with an Internet server, then all of the control points in all of the buildings are available on the Internet as well as the LAN.
Figure 1 shows an example of an interoperable system combining BACnet devices and controllers with LonTalk equipment. This is a model of an actual system installed in a community college in Montana. The LonTalk equipment was ordered directly from the Echelon factory in California. The BACnet equipment came with Trane packaged rooftop air conditioning units (ACUs). The three ACUs were daisy-chained to a local control panel (LCP) that served as a BACnet bridge as well as a system controller.
The entire system in Figure 1 is not only interoperable, but is accessed through a standard Web browser. The bridge from the LonTalk equipment to the campus LAN is also an Internet translator that packages the data in the format required by standard Web browsers.
The result is that the entire system is made interoperable through the standard Web browser interface. It is accessible from the campus LAN or from anywhere in the world. The author routinely accesses this system from about 300 miles away and the monitoring appears to work flawlessly (see below for caveats!).
Goals of the Interoperable Building Control System
Interoperable building control systems bring modern technology to bear on the issues of communications and control of physically separate facilities. The improvements expected from such a system include:
- The replacement of several LANs with a single LAN. This should result in fewer buried utilities and fewer incidents of accidental damage. The single LAN can be multiple, redundant fiberoptic conductors in separate conduits encased in a concrete duct bank. This installation can be accomplished for about the same cost as several direct-buried networks and offers significant improvements in reliability and flexibility for future expansion.
- A single operator workstation (OWS) display with a single "look and feel" for the monitoring, control, and programming of all building systems, regardless of manufacturer. This reduces the training required for proficiency on several different systems.
- The ability to access the OWS display and have complete control capabilities from any workstation on the LAN and the ability to extend this access to the Internet through standard Internet servers without purchasing additional site licenses. This allows improved flexibility for the O&M staff in monitoring building operation and diagnosing problems in off-hours.
- Access to building energy consumption patterns for the purpose of energy purchasing. Includes demand limiting by the coordinated shutdown of equipment in different buildings and the verification of demand (or even direct control) by the energy provider.
- The sharing of information between buildings so as to minimize the needs for sensors and other common instrumentation.
- The preservation of a competitive bidding environment for future buildings on the network. This allows controls for future buildings to be provided by any vendor while still maintaining universal access and the same look and feel at the OWS.
While the value of these combined advances can be considerable, it will only be realized through the careful planning, design, and installation of the interoperable control system. Consider the information below while laying the foundation for your new control network.
Hidden Points and Interoperability
Specifying control point interoperability between building systems is made easier by the clarity and distinctness of building control points. Building control points are generally pressure or temperature sensors, modulating actuators, or dry contacts that can be identified and assembled into a list. When the design team specifies that those points are to be interoperable with a control system of a different manufacturer, that specification is clear.Unfortunately, specifying interoperability for control points on proprietary equipment is not so clear. The engineer's idea of interoperability may differ from that of the equipment vendor. When that is the case, the customer probably will not get what he/she expects.
Figure 2 is an example of how this might affect the monitoring and control of a packaged chiller. The chiller is specified with controls that are interoperable with a LonTalk system. The chiller is, indeed, equipped with the required computer chip that constitutes the hardware side of LonTalk and therefore will meet all of the usual specifications for interoperability.
Unfortunately, the owner will not find out until the very end of the project (when everything is installed and being tested) that most of the safety/protection controls are hidden from connection to the network. In the event of a chiller trip, maintenance personnel remotely accessing the chiller will only be able to see the general alarm and will not be able to see the cause of the trip. The low suction temperature, high head pressure, high motor current, and other safeties are wired internally to the machine and are not connectable to the control network.
The author recently managed a project that was supposed to be fully interoperable, only to find out that the minimum outside air damper position was hidden by the controls on a packaged air conditioning unit. This meant that the outside air damper position could be neither seen nor controlled from the central workstation. The manufacturer at first said that the control was hidden because the damper operation was crucial to the safe operation of the direct expansion air conditioning compressor. The company felt the damper had to be operated locally to ensure that it would not fail and expose the evaporator to a sudden, extreme high or low temperature.
The real problem turned out to be political rather than technical. When a few phone calls were made, the hidden points were magically revealed. In this case, the commissioning was handled by the owner, who knew that control of the outside air mixture was vital to the functional testing of the economizer cycle. From the commissioning authority's (CA's) point of view, it wasn't a territorial issue but simply one of being able to test and maintain the machine. In the absence of a commissioning mindset, this control function might still be hidden (and others as well)!
Figure 3 shows a typical boiler control diagram in which the safety controls are hidden from connectibility to the control network. The burner manufacturer may claim that insurance companies and code officials require the local wiring of safeties such as water level, flame monitoring, and steam pressure. Since the controls are wired locally on the boiler, they are not available for connection to the network.
Nonetheless, the owner's O&M staff will need to see these parameters if the staff is going to remotely diagnose problems. Some owners may decide that boilers present enough of an inherent danger that they don't want operators to remotely correct the problem and restart the boiler.
However, operations staff will want all the information available, as soon as possible, in order to correct the problem. For example, the status of these safety points might determine whether an outside contractor is needed for the fix. If so, in the event of an off-hour failure, the repairman could be on the way to the plant at the same time as the maintenance supervisor, saving valuable time.
Although many "BACnet compatible" boilers will not come with complete packaged BACnet controls, most are available with auxiliary packages that allow the remote monitoring of all points, including safeties.
Is Interoperability Sustainable?
Although interoperability provides substantial improvements in convenience and utility for the O&M staff, these improvements have limitations. For example, even if the staff is able to monitor and control the systems from the OWS, they may not be able to edit programming from the workstation.The ability to remotely monitor building control systems is a valuable tool for the diagnosis and optimization of building environmental control. This is especially true for owners of distributed properties such as school districts, property management firms, and franchise operators. Remote monitoring from the local controls network is a feature that is inherent in interoperability and the owner will always get it (subject to the "hidden points" caution above). Remote monitoring from the Internet is usually available if the customer wants it.
The ability to remotely override and change setpoints, to exercise damper and control valve actuators, and to turn equipment on and off is also expected of the interoperable system. This should be possible from either the local controls network or the worldwide web (WWW). Remote control from either the local controls network or the WWW is usually available from the interoperable system, with the exception of hidden points as described above.
Unfortunately, the ability to add control points and add and modify control logic from the OWS for all of the interoperable systems will probably not be there. It will most likely be necessary to program some local building controllers "on site" with a laptop or handheld computer. Even worse, such editing may require proprietary software tools that have nothing to do with the interoperable BACnet or LonTalk protocols. In other words, the owner may have interoperability, but has not gained independence from proprietary software vendors.
The inability to program from the OWS may be a significant roadblock in many owners' dreams of installing a single OWS, training staff one time, while still providing a competitive bidding environment for future buildings. As new buildings are built, they may have complete "interoperability" with the overall system, but programming may still have to done at the building control panel with proprietary software.
But, this doesn't mean that interoperability isn't worth it, as many owners will be no more dependent on vendors than they are now. Plus, they will have the monitoring and control advantages of the interoperable system and will not have to retrain for monitoring and control skills with each new system.
However, if the owner is serious about complete interoperability, including monitoring, control, and programming, this must be specified in the bid documents and tested and enforced by a thorough commissioning process at acceptance. The owner is also advised to make a brief survey of the local vendors during the design stage of the project and determine where they stand on this issue. If a demand for programming from the OWS restricts the field to a single bidder, the owner will probably think twice. This is especially true if all of the buildings are in the same area and it's easy to visit each one for occasional reprogramming.
If the owner's properties are scattered across the nation and remote programming is a definite plus, some extra planning may be required to ensure competitive procurement.
Has IT Been Included?
As the new world of LAN-based control evolves, there's a new player in town: The information technology (IT) group. IT personnel consist of software programmers, network managers, software reviewers and buyers, design engineers, and installation and maintenance technicians. The modern, integrated building controls system will be going onto their network and they want to be involved.In the best of all possible worlds for the facility manager, the building control network would be completely separate from the enterprise LAN. This provides a clear separation of O&M responsibilities, but at a significantly increased cost. Indeed, some college campuses have several building control networks, one for each vendor that allows new vendors to simply hook up to their network.
But at some point these arrangements become unworkable. As corporate and campus underground utilities become more crowded, accidental damage becomes a frequent occurrence. Multiple networks are impossible if the buildings are widely separated. All roads lead to a single network that is expected to convey all enterprise data, building control systems included. The IT group will manage and control this network.
When the facilities office decides they want to move towards an interoperable building control system, the first thing they should do is establish contact with the IT group. It is naïve to think that the IT group is any less busy or any more generously staffed than the facilities office. So involve these folks early and keep them involved through the entire process. Asking their advice at the start of construction is like asking a lawyer for advice after the contract is signed: It's too late.
The IT group is going to be concerned about anticipated hardware and software that will be installed as part of the new system. The protocols and engineering used by the new systems can cause the existing systems to crash. Only trained network professionals are in a position to evaluate the options for preventing future problems.
The IT group will be responsible for assigning LAN addresses for all of the new devices that will be connected to the network. If new hubs are required, this may be a cost that the facilities group will have to bear and it's better to know early rather than late.
Finally, the IT group will be concerned about the security of the overall LAN. If the dream of the O&M staff is to have remote access via the Internet, security is a significant issue. A plan of passwords and firewalls will have to be developed that satisfies the needs of both the IT group and O&M personnel.
All Things Considered...
The interoperable building controls network provides a streamlined operating environment by reducing redundant training and providing for flexibility in building monitoring and control. It also prepares the building owner for the deregulated energy market by allowing the coordination of many remote properties and, eventually, the direct control of demand limiting strategies by the energy provider.However, these benefits will only be fully realized in conjunction with a thorough planning, construction, and commissioning process that includes the following:
- An accurate and complete list of interoperable points that is to be satisfied by the vendor/contractor. This list of points must be coordinated with the O&M staff's intended use of the system, whether for monitoring, control, and/or programming and should take into account "hidden" control points.
- The owner's intent with regard to remote programming and editing of control logic. If remote programming is required this should be researched with vendors during the design and specified accordingly. Many interoperable systems require programming on site.
- The inclusion of the IT group in the planning process at the earliest possible stage in the project. This department should approve all hardware and software planned for the LAN.
Although migrating to interoperability means more work and planning, the benefits of a better work environment at a lower cost make the commitment worthwhile. ES
