Obviously a proprietary bas is one that utilizes a company's proprietary protocol, but unlike older proprietary systems, today's systems can typically be linked, through gateways, routers, or portals, to other manufacturers' systems that may utilize BACnet, LonTalk, or other communication protocols.

In Part One, manufacturers pointed out the benefits of proprietary systems, including simplicity and commonality. Another benefit described is that proprietary systems are usually less expensive to manufacture and support than systems using an open communication protocol.

This second and final part of this series will look at manufacturers who believe the advantages of bas that use open communication protocols far outweigh those using proprietary protocols. Manufacturers say open systems allow endusers to buy from various sources, and they allow different systems to be tied together to perform seamlessly. Other benefits, they note, include increased speed, power, and flexibility. For these reasons, many say that proprietary bas are no longer needed.

Some Disadvantages

As Andy McMillan, president, Teletrol Systems (Manchester, NH) noted, "The disadvantages of proprietary systems are legendary. Lack of multivendor interoperability is the most obvious issue but not the only one. True standards-based open systems (such as BACnet) not only provide multivendor interoperability, they also provide a degree of stability from one generation of products to the next."

McMillan added that because standards-based open systems are developed and enhanced in open public forums, they rarely go through incompatible changes. As a result, they typically provide better migration and extension capabilities than proprietary systems. "Proprietary systems will be around for some time to come. However, in the long run, open-systems solutions will dominate the market and proprietary systems will be limited to highly specialized applications and legacy system extensions," he noted.

Bill Lyndon, product manager electronic products, WAGO Corp. (Germantown, WI) said, "There is no advantage to using proprietary systems. This is brought into focus by reviewing the history of the industrial controls market where proprietary systems are no longer viable; customers will simply not accept them. The benefits of using products from multiple vendors to better solve problems and optimize controls is far superior to proprietary systems."

When users commit to a proprietary system rather than an open system, Lyndon noted, they pay a huge opportunity cost by limiting the scope of possible solutions. "Proprietary systems are closed to innovative products from a wide range of companies that support open systems. With open systems you take advantage of the innovations, now and in the future, from a wide range of companies. In addition, buying proprietary systems puts the customer at a disadvantage when negotiating add-ons," he says.

Steven Gavlak, product manager, American Auto-Matrix (Export, PA), said, "Proprietary systems have long been thought of as a means to 'lock in' a customer to one specific manufacturer."

William May, vice president of marketing and product development, Circon Systems Corp. (Richmond, BC, Canada), said the bottomline is there is absolutely no need for proprietary systems at all, "unless there is a customer out there who says, 'I want to pay more for upgrades, I want to be locked into one vendor for all service and support, I want to pay through the nose for everything from this point on.'"

Open Advantages

Gerry Hull, president/ceo, Automated Logic (Atlanta), said emphatically that BACnet is an open protocol that works. "It is tremendously powerful and flexible and allows manufacturers to add functionality to the protocol as required to support any special features of that manufacturer's control system, while still maintaining interoperability with other BACnet systems."

He believes that BACnet is unmatched for speed, power, and flexibility. "Keep in mind, BACnet provides the capability for a manufacturer to add special features and enhancements that go beyond the BACnet basics, so there are no fundamental limitations. Being software-based rather than chipset-based, it can easily be updated to keep pace with improvements in technology," adds Hull.

An open system is definitely more appropriate when there is a need to integrate products from multiple products into one system, said Mark Rehwald, marketing manager, Staefa Control System brand, Siemens Building Technologies Inc. (Buffalo Grove, IL). "This gives the user a common interface for monitoring and scheduling system functions for all devices."

In addition, noted Rehwald, engineers are realizing that open systems allow them to have the flexibility to design a system using the best components from virtually any compatible open-systems manufacturer. Building owners, too, he said, realize the operational efficiencies and long-term maintenance cost and labor-saving benefits of open protocol systems.

Rick Focke, director of marketing controls, Andover Controls (Andover, MA), said that a system that supports an open protocol can set up the framework for a totally integrated bms. "This would allow the consultant to specify 'best-of-breed' devices and subsystems, as long as these devices support the open protocol selected.

Focke is not necessarily a fan of either BACnet or Lon, noting that ModBus is actually becoming more of a standard on lighting control systems, vsd's, and fire/smoke alarm systems. "And Web standards are fast surpassing BACnet and Lon in importance and excitement. The power of xml to share data not only between building management systems but between building management systems and billing systems, between access control systems and payroll systems, is simple and amazing. Our industry must follow the IT world and leverage the tremendous development resources that go into their products and standards," he said.

What About The Engineer?

Paul Oswald, director, Midwest region, Tridium, Inc. (Milwaukee), agreed, noting, "I think it is far more challenging to specify open systems. With proprietary systems, you find a manufacturer who can provide the functionality required for the client and whom the engineer is comfortable with from a performance standpoint. You then define the sequences and everything is covered."

With open systems, Oswald stated, the engineer must define the functionality required and the sequences, and they must define the interface between the systems or components. This includes defining division of responsibilities, commissioning, programming, etc. "It is usually more technical and, unless the engineer is getting paid for the extra work, it is difficult to justify. This is one of the great trade-offs in proprietary vs. open: Open is good for the client, and possibly the engineer, because it promotes choice. But with choice and flexibility comes a certain degree of complexity and additional effort."

Simon James, marketing leader, building automation, Honeywell Automation and Control Solutions Service (Golden Valley, MN), also believes that engineers find open systems to be more challenging because in some ways it may come back to haunt them if different aspects of a system do not work together as intended.

"With proprietary systems it was very clear who was responsible for what. The onus is now on the specifying/designing engineer to define the open protocols to such a degree that successful integration can be achieved. For many specifiers and design engineers, there is a learning curve they need to get over before they can do this effectively. Both ASHRAE and Echelon are aware of this and are working to improve the knowledge in this community," said James.

But that extra effort is worth it, says Automated Logic's Hull, because specifying engineers should want to provide their clients with future options, and he says it is vastly easier to do with an open protocol than with a proprietary protocol. "There is a misconception that specifying an open system means specifying every possible detail of the communication protocol and control hardware. This is a little like trying to buy a car by specifying every possible detail of the engine, transmission, suspension, electronics, etc. Unless you're planning on buying these parts separately and assembling your own car, which is not a recommended procedure for cars or control systems, this is not the best way to specify interoperability."

Hull noted, for example, that BACnet offers "BIBBs," or BACnet Interoperability Building Blocks, which is a method of specifying interoperability. BIBBs allow engineers to specify the interoperable functions they need (e.g., read/write point values, trends, schedules) from any component in a system. They also provide a quick way to check the products offered by a particular vendor and to make certain that needed functions are supported.

There is no doubt that specifying/designing engineers sometimes have trouble wading through all the information available about open protocol bas. And as Chris Hollinger, SBT product manager, Siemens Building Technologies (Buffalo Grove, IL), pointed out, an open protocol system is still somewhat vendor dependent. "No matter what protocol is used for communication - whether standard or proprietary - the incumbent bas vendor must be involved in integration to other systems. If a competitive vendor is chosen for subsequent work, a loss of functionality and greater expense will occur during integration, whether the system uses LonWorks, BACnet, or a proprietary protocol."

So what's an engineer to do - choose a proprietary or open bas for customers? Hollinger simply advises choosing the best vendor with the best support system in place and best product and service offering. "Not the vendor with the particular protocol that fits the hype." ES