by David G. Dickerson, P.E.
End users and building owners have been talking about standard protocols for the building automation industry for more than 20 years. Now that these standards are actually being implemented at some level by a majority of manufacturers, the question is, are they getting what they asked for?
First, what have they been asking for? Presumably, they wanted a standard communication protocol so systems from multiple manufacturers could easily communicate over a common building automation network.The next question is: Is this what they really want?
For the last two decades, the loudest and most frequent complaint from end-users has been, "I don't like being locked into a single vendor." The controls industry took this to mean that the end-user wanted multi-vendor solutions. This thinking led the controls industry to spend an inordinate amount of time and money chasing "standard" protocols that would allow the end-user to have multi-vendor solutions.
However, if you spend much time working with building managers, you'll find that multi-vendor systems aren’t really what they're looking for.
One reason: Servicing and supporting these installations creates a new set of headaches. It involves buying and stocking more parts, dealing with multiple vendors and service providers, and buying, learning, and supporting several software packages for user interfaces, programming, and diagnostics.
End-users want the simplicity, fewer headaches, and lower costs associated with a single-source provider.
On the other hand, end-users say they don't want to be locked in to just one vendor, because they feel trapped. This is a result of the business strategies used by some building automation system (BAS) manufacturers whose focus was to sell a long-term service contract.
So what’s the solution?
In one scenario, several contractors can sell the same product, allowing a customer to standardize on the basic control system with multiple choices for expansion and service. The problem: each contractor will have different ideas and styles for design, sequencing, and programming. Often one programmer can’t decipher, and therefore properly support, another’s software. This creates potential for finger-pointing and "I didn't write this code" excuses.
A second scenario looks to multiple products, where an end-user could still have all the above issues, plus their reliance on a single source has shifted from one manufacturer to a systems integrator (or contractor). The integrator alone understands all the intricacies of how the system fits together.
So maybe there is no perfect solution.
What the customer wants most of all is quality service and competitive pricing. In this manner, they can actually save money, and won't need to jump around between vendors.
As responsible contractors, our most important focus should be on providing the best service and fair pricing. But even that isn't always enough, because customers often see pricing as being too high, if they can’t shop around for it.
We need to acknowledge our customers' concern for fiscal responsibility is valid and demonstrate that our pricing is competitive and fair by showing them up-to-date comparison pricing for other projects from other vendors.
Skilled Integration Is Still Necessary. So, do standard protocols offer value? Actually they can, but for different reasons than for which they are being hyped and marketed.
The promise leads one to believe that once you adopt a standard protocol, you can "plug and play" products from multiple manufacturers.
The reality is that it takes a good system integration contractor to pull it all together and make the system appear to run seamlessly.
The most significant benefit of a standard protocol to the systems integrator is there are times when we need to integrate products from different manufacturers. Most notably, HVAC equipment is often supplied with factory-installed direct digital controls. Because of this, it’s not cost-effective and often impractical to field-install another manufacturer’s controllers in the HVAC equipment. In these cases, integration is a must.
On a typical construction project, you will often find chillers from one manufacturer, boilers from another, air handlers from a third, unitary devices from a fourth, with a fifth manufacturer providing the building automation system. Some HVAC equipment manufacturers will tell you (the promise) that the answer is to buy all the equipment and controls from them. The reality is that rarely does one manufacturer make the best and most cost-effective solution for all the various pieces of equipment and controls needed in a building. While manufacturers may do a good job controlling their own hardware, they have obvious challenges in controlling or integrating with other manufacturers' equipment.
As system integrators, we meld everything together through the use of open protocol gateways, black boxes, and software drivers. Now that most HVAC equipment manufacturers are adopting one or more of the standard protocols, the integration really is getting more efficient and cost-effective.
Fewer gateways and custom software drivers are needed, but it still takes a competent, experienced system integrator to make it work.
Having said that, we need to remember that just because two components talk the same standard protocol doesn't mean they understand each other (the promise). The reality is similar to two people who both speak English, but don't understand each other's questions or answers. As human beings, if we don't understand each other, we can repeat and reframe the question. Control systems can’t do that.
How Can Customization Be "Standard"? Both leading standard protocols, BACnet and LonWorks, are attempting to solve this issue. One thing that makes it difficult is the need for customization. By definition, standard and customization are mutually exclusive terms; however, the industry is trying to find ways to accommodate the level of customization that is often necessary.
The first thing both camps are promoting is standard profiles, which means all equipment meeting a standard profile will pass the same data, accept the same questions, and give the same answers.
While it might be conceivable that four or five unit ventilator manufacturers could get together and agree on a standard set of data, it’s inconceivable that manufacturers of more complex equipment, such as chillers, would agree on a complete set of data for exchange.
So, customization is necessary.
The LonWorks community is addressing this with a front-end software package that accepts "plug-ins" uploaded from products connected to the network. These plug-ins tell the system how to talk to the new product.
On the surface, this seems like a good answer (the promise); however, to make it work, you must purchase the system software from Echelon, either directly or indirectly (the reality). Also, while the plug-in tells the system how to talk to it and even gives the entry and display screens, it doesn’t facilitate any global strategies or functions such as scheduling, alarming, trending, etc.
BACnet allows equipment manufacturers to agree on a set of common data items they all need, plus additional data items that can be specific to each manufacturer's equipment type. The additional items must follow a certain format and be properly documented. It’s definitely not "plug and play," and a system integrator is still vital to make it work.
Overcoming Misconceptions. I believe end-users have several misconceptions about standard protocols, which probably have resulted from marketing hype. These include:
- Plug and Play. This says if you pick a standard protocol for your building, you can just plug in any manufacturer's products that follow that standard. Not true. It needs integration, which requires a contractor/integrator and some level of customization.
- Compatibility. If a product says it’s compatible with a standard, it works directly with other products also compatible with that standard. This is where many end-users get misled. There are many levels of compatibility or compliance with a standard. Even the LonMark or BTL (BACnet Testing Lab) certification doesn’t tell the whole story. The above statement just means the product met a specific set of requirements for a specific use.
- Gateways vs. native. The term native is typically used in reference to products using the standard protocol as the means to communicate and transmit data between the controllers. Gateway systems use proprietary protocols to communicate and provide a gateway device to translate to the standard protocol.
Careful attention should be paid to gateway systems. These may involve a physical device and/or software driver, and the gateway often limits the amount and types of data transmitted. The gateway usually needs to be configured for a specific application, use, and site. - Bait and switch. The possibility exists for vendors to market their "standards" projects and/or bid them on jobs specified to use the standard, and then offer a "value engineering" deduct to switch back to their less expensive, proprietary product, thereby defeating the end users' original intention to get a standards-based system.
Issues Remain. While standard protocols are useful and finally making headway in the building automation market, they’re far from the utopia promised by manufacturers and vendors. Choosing to follow a standard protocol in a building is a good idea; however, it doesn’t solve all problems. The old law of "buyer beware" still applies, and there are now other issues to be aware of.
As independent HVAC/controls contractors, you can be the key to turning the hype and promises of standard protocols into the reality of complete, cost-effective building management systems. n
David G. Dickerson, P.E. is founder and president of Control Engineering Corp. (CEC) in Oak Brook, IL, a systems integrator. He has 25 years experience in the building automation and controls industry. Dave is also a certified energy manager. He may be contacted at 630/954-1300 or [email protected].
