- Facilities Management Director »
- AVP, Facilities Mgmt and Capital Planning »
- Facilities Director »
- Director, Finance & Administration »
- Facilities Maintenance Mechanic II »
Understanding BACnet Capabilities, Getting Past Obstacles
One thing that facility managers should be familiar with is the terms "true" and "native," which often are used in connection with systems running on the BACnet standard. Although industry experts admit there is no clear definition for these terms, they get at an important concept.
"The term 'native' typically refers to a device that uses BACnet as its standard communication language," says Chris Hollinger, senior product manager of integrated systems for Siemens Industry, Inc.'s Building Technologies Division. "The device does not typically use another protocol but still can use proprietary features and functions where necessary and appropriate."
Consider this example, says Todd Cowles, regional sales director, Trend Control Systems: "A VAV controller that speaks only BACnet, connected to an AHU controller that speaks only BACnet, would be considered a couple of 'native BACnet' controllers. It's not doing any translating between other protocols."
This ease of communication becomes more important higher up in a system.
"It's important to most installations to be able to connect 'up top' at the Ethernet or BACnet I/P level so a system can be connected to another system," Cowles says. "Down lower, amongst dozens or hundreds of unitary controllers, it matters very little how they communicate with each other."
The idea of a "true" BACnet system has important practical ramifications. "BACnet provides an integrator the ability to auto-discover devices on a network and all objects inside," says Peter Wilson, director and product specialist for Schneider Electric Buildings Business, partners division. "As long as the device is really BACnet, the integrator is able to fully work with that factory-installed controller without requiring any assistance from the equipment supplier."
The Role of Gateways
Gateways are important devices for the integration of legacy (non-BACnet) devices or systems into open and interoperable BACnet systems. Gateways usually are not capable of the same level of interoperability as systems that primarily communicate using BACnet objects and services.
"Gateways take data from one network type and route that data to another network," says Larry Haakenstad, Alerton's director of sales. "In the context of building automation systems, it's commonly used to move data from a proprietary format to BACnet."
Gateways have two big limitations: speed and labor, KMC's Dorsey says. "Gateways are not known to be extremely fast in transferring data," he says. "Also, there is a fair amount of engineering or programming of data that has to take place to get it to flow smoothly. Fairly sophisticated functions are required to translate one communication protocol to another. While the use of gateways is sometimes necessary, the more BACnet is used in a given system, the more these two issues can be avoided."
As Mike Olson, power and controls sales manager for ABB, says, "Native BACnet systems do not require gateways for protocol translation. You can connect BACnet-native devices directly to the BACnet system."
If "native" BACnet indicates a system that uses BACnet as its standard way of communicating, what about a system that has BACnet capabilities? Some BACnet experts say the term "BACnet capabilities" is ambiguous, as it leaves users to question what capabilities it supports and what it does not.
It's important to remember that specifying devices with "BACnet capabilities" doesn't guarantee interoperability. "There is a lot of flexibility in the specific methods for implementation of BACnet standards," says Roy Kolasa, open system integration manager at Honeywell Building Solutions.
Getting Past Obstacles
"BACnet does offer certain promises to the marketplace," Dorsey says. Such promises include freedom to use competitive products from different suppliers; the ability to integrate various building systems; and interoperability — the interconnection of different suppliers' equipment. But he says that a range of issues can thwart interoperability:
- Manufacturing issues. The manufacturer may not have properly implemented the BACnet standard.
- Training-related issues. The lack of properly trained controls technicians can cause numerous problems on a controls installation.
- Proprietary issues. The BACnet standard does allow manufacturers to implement their own special capabilities by incorporating proprietary objects and properties. Although the use of standard data types can promote interoperability, sometimes there is so much proprietary activity going on that it challenges true interoperability.
- Inefficiencies. Such things as network management or the failure of the BACnet provider to use higher BACnet functions also can create roadblocks to interoperability success.
One means to increase the chance for successful interoperability is to use devices certified and listed by the BACnet Testing Laboratories (BTL). BACnet International has established a set of testing criteria that a device must pass to be listed as a BACnet device. BTL ensures, through such testing, that these devices meet all requirements listed for that type of device, plus any additional capabilities that manufacturers claim exist for the device.
"Through BTL, customers can count on getting a tested interoperable product that conforms to a published ASHRAE standard," says Rocky Moore, OEM sales and marketing managerÊfor American Auto-Matrix. "This is not to say that non-BTL-listed product does not have the ability to be interoperable, but that with BTL you have a level of testing that has been done to a standard in an attempt to resolve issues that possibly could arise. Of course, it is always good to understand that even within this structure there is still a level of flexibility to allow competitive features to exist among vendors."
To get the most benefit from the information provided by BTL about a device, facility managers should do a little homework. "Customers and consulting engineers need to get up to speed on the nuances of the features tested and need to understand that gaps in functions supported or tested should be assumed to be non-interoperable," Hollinger says. "The assumption of 'it talks BACnet so it will work' needs to mature to 'it talks BACnet, and based on the device information, I see that I can read this property and write to that property, but it cannot read/write to this other proprietary property.' Typically, there are features and functions that will and will not interoperate between multiple vendor devices, and you must plan accordingly."