For many years now, the building automation industry has talked about the need for — and the ability to deliver — interoperability; that is, the ability to tie all building systems together with a building automation system (bas), making it easier for building owners-operators to manage every system in a building at the touch of a button.

Building owners and operators find this option appealing, and manufacturers have advertised that it as a very real possibility.

Some contractors, however, have found a different reality. Instead of seamless integration of all systems in a building (e.g., hvac, elevator, security, lighting, etc.), they’ve found a potpourri of systems that sometimes will and sometimes won’t talk to one another.

Those who haven’t jumped into building automation systems may also be hesitant, given the stories they’ve heard about trying to get systems to talk to one another — the expense, the trouble, and the confusion.

While there’s no doubt that great strides have been made in the world of interoperability, there is still a way to go before contractors — and customers —find this option readily achievable in all applications.

It Can’t Do Everything — Yet

It would be false to say that interoperability isn’t possible to achieve. It can be done, especially where new construction is concerned, or if the application revolves around a single vendor.

The problem usually arises where legacy systems are concerned, or if a number of different vendors are involved who each use a different type of protocol to communicate with the bas.

Whether or not interoperability is achievable may also depend on your definition of the word. Some think that it means “plug and play,” similar to being able to attach just about any VCR to any TV and have it work. While the industry is working hard to get there, it isn’t at this point yet. Unfortunately the industry, either intentionally or unintentionally, seems to have led many end users to believe that interoperability really does mean plug and play. This can lead to high expectations, which the industry (including contractors) just can’t deliver on.

One controls contractor from Pennsylvania, who wished to remain anonymous, says he’s frustrated with the industry, because manufacturers are misrepresenting the ability to achieve interoperability. He says if a building has a LonMark system, he can hook up the LonMark controller to the system and there are no problems. “But it’s sold on a bit of a farce there, and the same is true with BACnet,” says this contractor.

It’s true, he says, that if he has, say, a LonMark-based Honeywell controller for an air-handling unit, and an Invensys LonMark controller, it’s possible to swap either one of them out and it doesn’t matter. But customers believe that if they have a LonMark controller, they can go in and program the LonMark controller.

“For example, they think if I put a Honeywell in there, the Invensys software will go in there and program that Honeywell LonMark controller. That’s totally untrue. Once that Honeywell controller is in there, I can’t see what’s under the shell — inside. But I can access the information, because it has a LonMark compliancy to it.”

Then there are LonWorks controllers, which are totally programmable. However, this anonymous contractor says that creates even more confusion, because the information being put out on the wire can be anything the contractor or the building owner wants it to be.

“Let’s say the information that goes out on the wire with a LonWorks controller is space temperature,” says this contractor. “I can make that space temperature mean anything. So if I have a LonWorks controller that’s on a boiler, my space temperature could actually be reading hot water supply temperature — especially if I don’t have that documented and somebody else comes in and says, ‘Hey, I don’t like my Invensys system anymore, and I’m going to switch it over to Honeywell.’ They can do that, but they’ll have to reprogram everything, and if they don’t have my information, that space temperature could be going somewhere that they don’t want it to be.”

Therefore, this contractor stresses that extensive documentation is needed on these types of controllers. The same is true with BACnet controllers.

“If you don’t have the documentation, it hurts,” says this contractor. “Everybody says, ‘Well, I’ve got a BACnet controller; I’ll just throw in another BACnet controller that can talk to it, and there you are.’ Well, there I am where? I don’t know what that stuff is, I’m looking at it blind, especially if you don’t have the paperwork. The way the economy is right now, a lot of companies are failing on getting the documentation corrected.”



Improved Flexibility

There are definitely still problems with a single direct digital control (ddc) system taking over control of other components of another ddc system, says Alan Barnes Jr., chief operating officer, Aircond Corp., a subsidiary of Consolidated Engineering Serv-ices, Washington, DC.

“Most manufacturers are starting to loosen the reins a little with their proprietary information,” Barnes says, “but there is still a long way to go.”

Barnes has found that the more flexible ddc systems (those that can work with a wide variety of other systems or types of equipment) come from companies that are only in the ddc business. Barnes says he has found Andover Controls systems to work very well.

“Systems that are made by the equipment manufacturers like Carrier and Trane are more ‘canned’ and tend to not work as well with other systems,” he says.

Barnes adds that he has found the Andover system to be “infinitely flexible,” and his programmers are able to do very complex control work as a result. “We have a large amount of work in the industrial market, where tight building controls are extremely important. The Andover systems we install in these sites work extremely well.”

What Barnes says he would like to see from other bas manufacturers is more training for contractors — and lower prices for customers.



Sidebar: Aeris.net, Notifact Provide Wireless Messaging

SAN DIEGO, CA — Aeris.net, a provider of web-to-wireless, machine-to-machine communications services, has partnered with Notifact Corp. to provide fast, low-cost wireless messaging to rooftop hvac systems manufactured by Lennox Industries, a subsidiary of Lennox International.

Through a recent agreement with Lennox, Notifact’s “plug-and-play” monitoring transceivers, which are embedded with Aeris.net’s MicroBurst® technology, are now available with Lennox’s L Series® rooftop hvac systems, enabling customers to receive real-time warning and diagnostic information via e-mail, fax, cell phone, pager, or Internet connection.

Notifact’s transceivers work to monitor activity in the systems, while the MicroBurst utility routes data from the transceivers over the MicroBurst network, which acts as a transparent overlay on the control channel of the cellular system. The messages are sent to technicians and facility managers almost instantly, helping them prevent, identify, or diagnose problems.

“Leading hvac manufacturers…recognize the importance of providing the best service possible to their customers and end users,” said Wade Vesey, vice president of marketing at Aeris.net. “Because the MicroBurst network transmits immediate notification and diagnostic information within a matter of seconds, Lennox customers can identify and repair a minor maintenance problem before it can turn into a larger, more-expensive equipment failure.”

Publication date: 11/20/2000