Take a simple idea. Add complex technology required to turn that idea into reality. Then throw in the need to establish competitive positions in the marketplace. The result is a recipe for at least a small helping of confusion. And when the subject is as tricky as interoperability, even a little confusion goes a long way.
A daunting word for a fairly straightforward idea, interoperability has been gradually reshaping the building controls market since BACnet and LonWorks first held out the promise of systems and devices that would communicate directly with one another, no matter which company made them. Today, a wide range of manufacturers offers products based on BACnet or the LonWorks protocol known as LonTalk. Those protocols enable the products to share information and commands so they will work together — to interoperate. Put two products that use the same protocol together and viola, interoperability. Right?
Not really.
It’s a fact that both BACnet and LonWorks offer proven ways to achieve interoperability. It’s also a fact that many products use those protocols. But neither of those facts means it’s a snap to create an interoperable building control system using BACnet or LonWorks products.
Indeed, the idea that interoperability is by definition easy is where linguistic confusion starts to creep in. For facility executives, the word to keep in mind isn’t “easy,” it’s “easier.” Progress toward interoperability is measured by the extent to which a product makes interoperability easier to achieve.
Easier than what? Easier than the other choices available.
Facility executives who don’t understand that easier doesn’t necessarily mean easy will find the process of obtaining an interoperable system more frustrating than those who accept the distinction. And they’re likely to overlook real gains that have been made toward the goal of interoperability.
The entire subject of systems integration is marked by gaps like the one between easy and easier. The first article in this series described gaps between facility executives and control system vendors that have complicated the task of getting the best system for a given building. This article will explore a second kind of gap — the differences between what terms mean and what they seem to mean. The third article will examine ways that — by choosing the right approach to systems integration — facility executives can close the gap between in-house capabilities and organizational needs.
The word interoperability is a prime example of a term that doesn’t mean what it might seem to mean. If two devices are interoperable, they can share information and commands without the need for a gateway or other special hardware or software to translate from one protocol to another.
But that doesn’t mean the devices are interchangeable. In other words, just because thermostats from two different manufacturers are interoperable, facility executives cannot simply replace one with another and expect the second to work exactly the way the first did.
For devices to be interchangeable, both the way protocols are implemented and the capabilities of devices would need to be standardized to a far greater extent than is currently the case.
If devices were interchangeable, facility executives would have far more freedom to mix and match devices from different manufacturers. But there would be fewer choices about features and the way those features are implemented. Some in the industry argue that the more devices are standardized, the less innovation there will be among manufacturers.
The idea that interoperable equals interchangeable has given rise to another misconception: If two devices are interoperable, then it’s relatively straightforward to get those devices to share information.
That isn’t the case. It may sound strange, but just because two devices are interoperable doesn’t mean it’s necessarily easy to get them to interoperate.
Here is where words really start to get in the way.
Consider the difficulties that can arise if a facility executive mistakenly thinks that the “Lon” in LonTalk, LonWorks, and LonMark indicates that all three terms mean roughly the same thing.
LonTalk is the protocol developed by Echelon Corp. Any device that uses the protocol — and related technologies developed by Echelon — is a LonWorks device.
LonWorks devices are interoperable. But that is not to say it will be equally easy to get any two LonWorks devices to interoperate The protocol itself doesn’t spell out the details of how devices will interoperate. So getting up some LonWorks devices to interoperate may be a far more time-consuming process than linking others on a network.
Enter LonMark. The LonMark Interoperability Association is a group of manufacturers and others in the industry formed to lay out standard ways of implementing LonWorks technology.
A discussion of the difference between LonWorks and LonMark can move quickly into a morass of technical terms. But the essential difference is this: Using LonWorks devices makes it possible to achieve interoperability; using LonMark-certified devices makes it easier — often much easier — to reach that goal.
Consider a simple device like a temperature sensor. A LonMark-certified temperature sensor will follow a set of rules — what’s known as a LonMark functional profile. Each functional profile contains both mandatory and optional elements. Specifically, a profile defines mandatory and optional data points and configuration for a particular function of a device. Manufacturers can’t change the mandatory parts of a functional profile. But manufacturers can add usefulness to functions, says LonMark, or create additional task-specific functional profiles to implement on devices.
The profile isn’t absolutely necessary to achieve interoperability with a LonWorks system, but it helps enormously. The reason is that it gives the system integrator more control. For example, the profile provides the integrator with the ability to configure the temperature sensor to define what information is to be put on the network and when.
A LonWorks temperature sensor that doesn’t adhere to that profile might also provide the integrator with the ability to configure the device, but that configuration might not be accomplished in a standardized way — or the device might not allow the integrator to configure those parameters at all.
It may also be more expensive to put together an interoperable system using LonWorks devices that haven’t been certified by LonMark. For example, a router may be required to limit the amount of information put onto the network; with a LonMark device, that bandwidth-allocation goal can be achieved with a setting on the device.
Changes in profiles have made installing devices easier than in the past. The latest revision of the guidelines — version 3.3 — is best. Vendors aren’t supposed to be selling any devices based on guidelines prior to 3.0. The LonMark logo indicates which revision of the guidelines the device adheres to.
It’s also important to learn to talk the talk when it comes to BACnet. Take “BACnet-compatible.” That solid-sounding term is in fact so general that some vendors consider it a sort of smoke-screen. Although there’s no formal definition, the phrase is generally used to mean a system that can be connected to a BACnet network. But one way to make a system “BACnet-compatible” is with a gateway. In that case, the vendor’s system remains based on a protocol other than BACnet; the gateway translates from that protocol to BACnet. For many facility executives, the essence of interoperability is that it frees them from having to go back to a vendor for a “black box.” And a “compatible” system doesn’t offer any assurance on that score.
The phrase “native BACnet” is a step up from “BACnet-compatible.” Native BACnet devices communicate directly with one another using the BACnet protocol. More to the point, the term implies that gateways will not be needed to connect the devices to a BACnet network.
So far, so good. But if a vendor says that a device is native BACnet, that doesn’t mean all of its products communicate directly over BACnet. Some may and some may not.
There’s nothing nefarious about a manufacturer that has some devices communicating over BACnet, while others are still using a proprietary protocol. In fact, that’s generally what happens when a manufacturer introduces BACnet or LonWorks products. The new devices adhere to the protocol, while the manufacturer continues selling the previous generation of products until it has had a chance to update those parts of its product line. But a facility executive can’t assume that all of a manufacturer’s products are native BACnet just because some are.
There’s another limitation to the phrase native BACnet: Different manufacturers implement the protocol in different ways. And the extent of those differences will determine how difficult it is for a pair of native BACnet devices from two manufacturers to communicate.
One reason for the differences is that BACnet is intended to be comprehensive. It describes features for all BAS applications. No single device implements all those features; it is up to the manufacturer to select appropriate features for a device. As a result, VAV controllers from two different manufacturers may have two different sets of BACnet features.
That fact has given rise to the idea — or accusation — that there are different “flavors” of BACnet. The implication is that the different “flavors” are incompatible — that BACnet devices aren’t really interoperable. That isn’t true. “There really is only one BACnet,” an industry observer says.
To promote the use of BACnet, an industry group known as the BACnet Manufacturers Association has created the BACnet Testing Laboratory (BTL). BTL tests are designed to assure that a device has the features claimed by the manufacturer and that — for those features — BACnet requirements have been implemented in a generally accepted way. BTL tests are based on a recent American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) standard that specifies how conformance testing is to be conducted.
BTL listing is available only for certain devices at the moment. “The testing process is complicated,” says one industry observer. “BTL doesn’t have the capability to test for all functions. They started with the more simple functions, and they’re increasing their capabilities in stages. In a real system, simple devices vastly outnumber more complicated ones. ”
It’s important to realize that BTL listing doesn’t mean that two devices have implemented the same BACnet features. And the more that devices differ in the sets of features they implement, the more work may be required to get them to interoperate and to be sure that all required capabilities are available. To that end, ASHRAE recently approved a new section of BACnet that describes features recommended for common devices. More jargon: The new section is known as Annex L, and the features are defined in BIBBs, or BACnet Interoperability Building Blocks.
Annex L constitutes an industry consensus. But manufacturers are not required to adhere to the Annex L recommendations when designing devices. What’s more, a listing by BTL does not, in and of itself, indicate that a device provides the industry-consensus features listed in Annex L. The decision about which features to include in any device is up to the manufacturer.
Despite the similarities between the LonMark certification process and the BTL listing process, there are also important differences.
To earn the LonMark logo for a device, a manufacturer must submit documentation and software known as interfacing files to demonstrate that the device follows the correct functional profile and that the mandatory features are implemented properly. Because what is being tested is the network interface — which is represented in the interfacing files — the physical device itself need not be tested, says LonMark.
The BTL logo means that a device has been tested to demonstrate that it has the features its manufacturer claims it has and that those features are implemented in a generally accepted way.
Although they signify different things, the BTL and LonMark logos have one thing in common. Both provide an indication to facility executives that interoperability will be easier to achieve.
How easy is “easier”? Linking interoperable systems from different vendors still isn’t as easy as integrating systems — even proprietary systems — from a single vendor. That should come as no surprise, since elements of single-vendor systems have been designed to work together.
Even with those systems, the process is far from simple. For example, it’s still essential to begin with a good specification based on the needs of a facility and a detailed listing of exactly what the integrated system is supposed to do — an enumeration of points to be trended, alarmed and scheduled.
But interoperability adds a layer of complication to the job of getting a good specification. For example, it is not nearly enough for the specification to say simply that the system will be based on this or that standard protocol; the specification writer will have to understand items like BIBBs or LonMark’s standard network variable types, say facility executives familiar with interoperable systems.
“There is complexity to get the functionality you want,” says one facility executive.
Do the benefits of an interoperable system justify the complexity involved? To answer that question, facility executives must understand their needs, then take a hard look at the benefits offered by different approaches. The final installment of this series will look at the sometimes surprising ways that real-world issues shape facility choices.
BACnet is a standard protocol developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers and approved by the American National Standards Institute; its formal name is ANSI/ASHRAE Standard 135. It has also been approved by the International Organization for Standardization as ISO 16484-5.
A voluminous document, the BACnet standard lays out the details of how data is to be communicated over a building automation network. The standard is intended to cover all building automation system applications.
The LonTalk standard protocol was developed by Echelon Corp. It is embedded on the Neuron chip, which was designed by Echelon Corp. and is currently manufactured by Cypress Semiconductor and Toshiba. Although the protocol can be embedded on other chips, the Neuron chip is used in all LonWorks devices on the market today. The LonWorks technology platform also includes transceivers, network management tools and databases needed to enable devices to interoperate on a control network. LonWorks devices are used in a wide range of applications, including building products.
Because it is owned by Echelon Corp., LonTalk is a proprietary protocol. But LonTalk is widely seen as being different from other proprietary protocols. It was developed specifically to provide a way for devices to interoperate, not as the foundation for a specific company’s building automation system. Since being introduced, it has been approved as a part of a national standard, ANSI/EIA709.1-B. More importantly, it has been adopted by a wide range of device manufacturers. The first article in this series, “Systems Integration: Getting from Good to Best No Easy Task,” appeared in the August issue of Building Operating Management.
The third installment of the series will appear in the October issue.
Mark Behar, Brian Stowell Alerton • Jay Pitcher Althoff Industries • Steve Gavlek American Auto-Matrix • Rick Focke, Don Lemenanger, Jon Williamson, Rainer Wischinski Andover • Steve Tom Automated Logic • Ron Caffrey BCS Partners • Jonathan Fulton Building Control Integrators • Kirk McElwain CABA • Mark Tozzi Carrier • James Lee Cimetrics • Mike DeNamur Comfort Systems • Brian Crimmins Crozer Keystone Health System • Raymond Rae, Brian Dutt Delta • Steve Nguyen Echelon • Jim Shulkin Essention • Marty Emmick, Bill True Fidelity • Stephen Ferree FieldServer Technologies • Sanjiv Bhaskar Frost & Sullivan • Dean McCauley, Steve White GSA • Robert de Grasse Grubb & Ellis • Tom Gormley, Byron Hall HCA • John Hatcher HMA Consulting • David Robinson, Thomas Bay Hines • Simon James Honeywell • Ralph Box, David Gill, Kevin Strohman Invensys • Terry Hoffman Johnson Controls • Thomas Plating Jones Lang LaSalle • Don King Kaiser Permanente • Barry Haaser, Jeremy Roberts LonMark Interoperability Association • Jonathan Buckley McData • Mark Bergman McQuay • Lenny Jachimowicz Marriott • Steven Bushby NIST • Ron Sharpe The Ohio State University • Jim Damico Osceola District Schools • Jay Hendrix, Christopher Hollinger Siemens • Mark Rehwald Staefa • Dean Meyer TAC • Pat Jastroch T. Wall Properties Management • Roger Schenck Technical Solutions & Services • Charles Beach Team Engineering • Andy McMillen Teletrol • Jay Althof, Randy Amborn Trane • Dennis Tuft Tridium • Carl Ruther University of Cincinnati • Victor Atherton University of Miami • John Vucci University of Maryland • Kurtis Johnson University of Wisconsin • Hank Marier Wells Fargo • Jack Gornik York
