One of the most challenging decisions facing the controls industry today is what Building System Network should be the standard for future systems. The debate is heated between supporters of these networks, or communication protocols. Making the decision, BACnet™ or LonWorks™, is tough but is it really necessary to choose one over the other? The intent here is to answer that question with a simpler question "What are you trying to accomplish, and does one protocol, or more specifically control and network products based upon it, provide a better solution than the other?

The DDC industry has been inundated with information on communication protocols, and vendors are selling complete automation systems, as well as individual components, and recommending standardization on one Network or the other. Considering the impact of networks on a DDC system, it is becoming necessary to understand not only controls and HVAC, but computer networking and information technology. In spite of that added demand, real benefits are available, as the evolution of DDC Network standards presents the opportunity to achieve open systems, and to leverage off the shelf technology and the worldwide web.

[an error occurred while processing this directive]The basic requirement for making system communication protocol decisions is the same as ever: clearly define your expectations. By 1995 when ASHRAE (American Society of Heating, Refrigeration and Air Conditioning Engineer's) published BACnet®, there were 100 or more networks and communication protocols in use throughout the controls industry. Multiple DDC Manufacturers with multiple generations of products contributed a proliferation of system networks based on countless proprietary protocols, commonly referred to today as "legacy systems". System users had long voiced concerns about the complexity of DDC system management and expansion. This was due to the inability of systems to share data or communication networks. The industry became aware of the role that communication played in the long-term success of DDC systems and the importance of protocols and networking. The same challenges remain today, but with a tremendous simplification, rather than 100 protocols there are only two, and for now it is simpler to call them both standards. Both BACnet™ and LonWorks™ are standards of one type or another, but that doesn't make the choice easier. If one counts legacy systems still in use, there are more than two networks but it is easier to integrate them than ever before, and there's less resistance to making legacy source code available to simplify the task. In the final analysis, establishing system requirements and choosing between communication options comes down to defining one requirement; interoperability.

Focusing on interoperability may appear to sidestep numerous issues being debated in the Network "camps". The fervor that supporters of each Network demonstrate, and characteristics that are touted for each makes this issue seem immensely complicated. Set aside however, questions of who controls the standard, what type of standard it is and the level at which it operates? Certainly these are important questions, but the larger concern remains how will the control system be applied, and what level of interoperability is required? Interoperability in some respects is an overused and under-defined term. Therefore the focus here will be on defining interoperability and pointing out how it can be instrumental in determining system success or failure. Interoperability can be viewed as a continuum with levels as illustrated below.

At the most basic level, interoperability is about communication. The two issues that drove standard system communication were the ability to share data and the ability to replace or substitute control devices. Sharing data centered on the owners desire to use one interface (Personal Computer at the time) to access and share data between DDC systems in one or more buildings. Substitution was based on the desire of owners to mix and match various manufacturers components in the same system, sometimes called "plug and play". So the owner considering a new system must now carefully consider goals and objectives for the system and set requirements. This makes it possible to choose a network if needed gateways or other technology used to combine existing equipment with the new system.

The first and simplest level of interoperability is Connection, and it meets few requirements for most control systems. At this level controllers can "hang on the same bus", share the same medium (wire), but there is no interaction between them. It is like having two separate LANs on the same Ethernet using different application software that is incompatible. It may be possible to use such an approach to save wiring costs, but it does not address either of the key drivers that have been of concern in the control industry.

The second level of interoperability is Sharing, and it does meet one of the critical needs in the control industry. This communication level of Interoperability requires that different systems be connected on the same medium and share data. One of the key benefits of a network standard is to allow for this sharing of data. This is essential for many control sequences. BACnet™, in particular, provides more clarity by defining standard representations for data using object and service data definitions accepted by the controls industry. It is proposed that at a minimum the data sharing level of interoperability will be required by most control applications. This is especially valuable for multi-location users who do not have significant need for system expansion or "plug and play" change-outs. In many cases data sharing is at the core of today's meaning of interoperability. It may be as simple as sharing outdoor air temperature or as complicated as an OEM chiller controller interacting with a building level control system to achieve optimization.

The highest level of interoperability, substitution, has yet to be achieved in the controls industry. It is unlikely that this type of "plug and play" change-out will ever occur though there is a movement to standardize control sequences. The key issue here is that each control manufacturer implements sequences differently. After all this is the "control industry" and the key differentiator for companies, what makes them unique, is the quality, sophistication, optimization and effectiveness of their control sequences. As a result of this variability, it is not possible to take a VAV box controller from company A and replace it with one from company B to achieve seamless control. There could be a host of differences, for example one manufacturer may implement schedules at an air handler controller and send an occupied/unoccupied signal to the VAV box, while another may do scheduling at the box. Replacing a controller that has scheduling embedded with one that waits for an occupied/unoccupied signal will result in obvious problems. This same scenario can be identified for every aspect of the control operation, making controller substitution unworkable today. These issues can be solved on a building wide basis with explicit specifications by implementing BACnet™ gateways, and other similar devices, that interpret information and execute control sequences between dissimilar control architectures.

It appears that the most important trends in the automation industry revolve around communications and ultimately interoperability. Enterprise wide interoperability is also a goal, meaning fire, security, vertical transport, office automation, etc. The best advice for specifying systems is don't assume anything and be explicit in defining requirements. Take time to understand and ensure that both networking and control equipment is compatible, will interact in the manner desired and will provide data necessary to manage the facility. Remember that interoperability is a continuum, and don't loose sight of all the old familiar questions about commissioning, warranty, service and maintenance liability if there are problems. In spite of the challenges, commissioning with multiple manufacturers' devices is a reality. At ASHRAE 2000, a BACnet demonstration over hardwire and a wireless Ethernet backbone included thirty-seven manufacturers of HVAC, lighting and fire systems.

Standards for Network communication with automation equipment are here to stay, and of equal interest is that they also allow access to the worldwide web. Owners are already plugging laptops into a cell phone to dial up systems. Rapid growth in wireless technology, and the evolution of web browsers for automation interface is making it easier. At least three DDC companies have introduced web browser interface software this year. Owners must still choose the appropriate tool for the job, PC based or hand held. The old concept of a "person machine interface" or hand held is evolving, as BACnet® compliant hand helds are now being introduced. These of course require direct connection to the local network, but it is only a matter of time before they are wireless and the size of a pocket pager with multiple lines of display. Just as no one involved in the development of DDC standard communications could have foreseen how the web would evolve, it remains to be seem whether or if one of the rival networks will emerge as a dominant standard.

ABOUT THE AUTHOR

John J. "Jack" McGowan, CEM is Vice President of Marketing with Hydroscope Integrated Technologies, Inc. and author of 5 books including "Direct Digital Control" on Fairmont Press. He was named 1997 "International Energy Professional of the Year" by the Association of Energy Engineers.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]