Interoperability between different devices from separate manufacturers once was the luxury of the elite. Today, even the smallest facility needs to run efficiently to be competitive. So a certain level of functionality between building systems is essential.
But how far should a facility executive go and how should interoperability be accomplished? These are tough questions with no easy answers.
“Before you begin addressing communication between devices, you need to determine functional requirements,” says J. Alberto Rios, chief controls and automation engineer for Kling, an architecture and engineering firm. “Do you need to be monitoring data for control purposes? Do you need real-time alarms? Do you need to keep track of information as historical data? Once you have defined the functionality required for systems in your facilities, then you can assess the options for interfacing those systems.”
Interoperability can be accomplished by hard-wiring two components together, by using drivers and gateways, by relying on proprietary solutions and by employing open systems, such as those built around BACnet or LonMark.
The simplest, most direct route to interoperability is hard-wiring two components, such as an alarm or controller to a chiller. In response time, hard-wiring is faster than other options because there are no devices to translate, no protocols to follow. So, if the function is simply to start a chiller when the temperature reaches a preset parameter, then a hard-wired solution will be adequate. The costs of hard-wiring add up quickly, however, when the number of devices to be connected increases or the functions needed become more complex.
Cost isn’t the only potential stumbling block. “In many buildings, another issue is one of limited space,” says Rios. “It can become difficult and costly to connect beyond a small, defined number of points, particularly in larger facilities.”
“The advantages of hard-wiring are simplicity and the reliability of contact closures,” says Dave Fisher, president of PolarSoft. “But they don’t work well when there is even a modest number of points to connect or when a broader range of information is needed.”
Despite these drawbacks, hard-wiring sometimes is the only solution acceptable to meet building safety and fire code requirements. For example, many locations require the fire alarm system to operate on its own network, independent of the building-automation system (BAS). If a fan is to be stopped or a damper opened or closed in a fire situation, it’s beneficial to have a hard-wired interface between the alarming system and the fan or damper to eliminate the possibility of software failure.
When it comes to automation, everything other than direct-wiring point A to point B requires one or more drivers. Basically, drivers are software programs that permit a computer system to communicate with devices.
The term “gateways” refers to both hardware and software (generally in the form of drivers) that connect devices using different protocols — rules enabling different devices to communicate with one another — or that reformat data from the computer to the receiving device or application. According to Microsoft Encarta, “The term is frequently used to describe any computer that transfers data from one network to another, but such usage is not technically correct.”
Gateways frequently are used to connect a building-automation system’s network to the network operating the chiller plant, for example. There are many types available on the market today and gateways can be a good solution for connecting both legacy and new equipment — such as chillers, variable-speed drives and lighting control systems — to a building automation system. For instance, if a proprietary BAS system is working well and there’s no reason to revise it for the new chiller, then a gateway connecting the new chiller to the existing BAS may be the optimum solution.
There are several sources for gateways. Some are written by equipment manufacturers to allow their units to connect to the facility’s building-automation system; many of these are developed under a partnership between the equipment manufacturer and the automation vendor. Other gateways and drivers are written by third parties to connect equipment from manufacturers to building-automation systems. Finally, some gateways are custom-programmed by system integrators.
Gateways and drivers can make interoperability solutions effective today, providing monitoring and sometimes control capability to the automation system. Although gateways have limitations, some of today’s gateways offer more power at lower cost than older generations of products.
Gateways can meet needs other solutions do not offer. “If you are installing a BACnet building-automation system and you need to have a variable-frequency drive tied to the BAS, a gateway may meet your needs,” says Steve Bushby, leader of mechanical systems and controls group of the Building and Fire Research Laboratory of the National Institute of Science and Technology (NIST).
When local fire codes permit, gateways can be used to link building automation to proprietary fire and security technology. Gateways also allow legacy equipment to be linked into newer building automation systems, saving considerable costs for their replacement.
The problem with gateways is not today’s issues as much as those of tomorrow. “The benefit of a gateway — that it best addresses a specific product — is also its drawback, because that solution is equipment-specific,” says Rios. “So, when you upgrade the building automation system, you probably will need to buy a new gateway from the equipment manufacturer. Chances are good that the previous gateway will not work with the new automation system.” That makes it important to look down the road to determine if the automation system will be upgraded or expanded.
Drivers and gateways are necessary because of the number of proprietary automation systems in existing buildings. “The systems integrator often uses software from the proprietary company and puts it in a format that the system handling the integration can recognize,” says Tom Lohner, vice president of Teng Solutions. “Computers have lots of drivers to translate information from one proprietary system to the next.”
If a gateway is not already written, a systems integrator needs to develop the software for a custom installation. In addition to a much higher price tag, such gateways present a potential hazard to interoperability.
Jay Pitcher, technology manager for Althoff Industries, says that gateways can lead to finger pointing when things don’t function as planned. “When gateways don’t perform as expected, whose problem is it?” he asks. “In other words, let’s say there are gateways between a chiller from one manufacturer to a chiller from another manufacturer. If they are supposed to be sharing information and somehow that exchange doesn’t occur, chances are the facility executive will think it’s a problem with one or the other chiller. Truth is, it could be the gateway manufactured by someone else.”
There are a variety of gateways available, with varying levels of power and sophistication, so it’s important to find the best gateway for the application. “Gateways can be straightforward or complicated, depending on the level of functionality required,” says Fisher of PolarSoft. For example, many gateways are one-directional; that is, they accept an input from a building-automation system and provide an output to the device. In other words, they have an A side and a B side. The A side takes requests and the B side gets answers. “It’s also possible to have gateways that are bidirectional,” says Fisher. A bidirectional gateway allows input and output from both the building-automation system and the device.
Some gateways are limited in capacity. “Many gateways have a fixed expansion level, so it may be literally impossible to expand them to meet future needs,” says Fisher. “You need to recognize their limits.”
“Gateways are only as good as the guy who wrote them,” says John Huston, director of technology integration for Teng Solutions.
When using drivers, Pitcher wants only those that are field tested and proven. “Otherwise, the data may not be reflective of what’s actually going on.”
All automation systems use networks that are based on some network protocol, which is then modified to meet specific systems’ needs. Though open-system solutions such as BACnet and LonMark products have entered the marketplace, the lion’s share of automation still belongs to proprietary building-automation systems.
A proprietary solution may be the best solution when the customer has a good relationship with the supplier, say industry sources. “There are many large facilities that have gone through several generations of control systems that have been upgraded and they continue to work well together so the facility executive is content with his or her supplier,” says Rios. “If the supplier is readily available when problems surface and continues to put together the right combination of automated solutions that satisfies your needs for real-time data, then you are fine.”
“If you have a small building and really good service from a proprietary building-automation system, the benefits of an open system are less important,” says Bushby. “Your facility’s needs are met.”
Proprietary solutions also make sense for commercial developers, who are interested in limited functionality over a short time span. “When you are not interested in life-cycle costing or future performance, a proprietary solution makes sense,” says Huston.
Then, too, there’s the issue of training. “If your staff is all trained and comfortable on a proprietary building-automation system, it can be cost ineffective to throw something new into that mix,” says Pitcher. “The problem with proprietary systems is that when customers want to add a new controller or new functionality, they need to go back to the proprietary company because only that company can really support them.”
For those whose needs are not met by proprietary systems, open systems and protocols, such as those supported by the BACnet and LonMark organizations, offer flexibility and the ability to be more compatible with future technological advances.
“When you want to mix and match equipment from other companies or integrate stand-alone systems with each other for real-time energy pricing and load management, for instance, then you require the solutions offered by standard and open systems for the interconnection,” says Bushby.
Many facilities do not have the immediate financial resources to move as far as they want in terms of interoperability. Sometimes there are operational hurdles to doing so as well. As a result, transforming a facility’s building-automation system into a fully interoperational unit may need to be accomplished over a period of years.
Pitcher admits moving toward open systems and standards is not easy. “There will be a level of pain to endure as the transition takes place,” he says. But the advantage is the potential information the product can yield. “There’s so much more data, it’s like changing from a typewriter to the Internet.”
Whatever option facility executives use should be based on functionality. “Define your functional requirements for the system you want and build in intended functions and future expansion needs,” says Rios. “Specify the precise level of interoperability. Is it for control? Monitoring? Data storage and retrieval?”
Ron Caffrey, partner in BCS Partners, advises facility executives and building owners not to get locked into one solution. “Work with your systems integrator or consulting engineer and determine what functions you need. Then let the market make the decision. You may be thinking of one vendor or approach but keep your mind open. Most vendors have some interoperable solution.”
As long as suppliers can work with various protocols and provide BACnet or LonWorks where needed, Caffrey says today’s building owner benefits by getting more functionality for the dollar. “The harder part is who is going to do it,” he says. “Remember, you are buying total expertise — someone has to have the experience, ability and requirements to make these different components play together.”
Total interoperability is a wonderful but generally elusive goal. There are issues that need to be addressed to keep buildings running optimally through emergency situations. Some segments in mission-critical or sensitive areas may need to be separated because they need a higher level of backup power than many Ethernet-based systems can supply. Another major issue is network security. There may be reasons to segregate some functions through routers so that firewalls can be erected and encryption applied to sensitive areas.
No two facilities are created equal, even though they may look similar. Data centers have different functional needs for interoperability than do commercial buildings. Issues for patient safety in medical centers are quite different than security issues at primary and secondary schools. Finally, interoperability must be related to cost constraints and completion timeframes. It’s up to the facility executive to become knowledgeable enough about interoperability options to assure that the approach selected provides the best solution for a particular facility’s needs today and tomorrow.
Contributing editor Rita Tatum has covered facility technology and management issues for over 25 years.
