Observing Protocol: What’s in Store for BAS? – Part 2

By Barbara Horwitz-Bennett, Contributing Editor May 16, 2005

Integration of BACnet and LON protocols has become easier, say the experts, but the focus has shifted to the convergence of BAS with IT networks, XML and web services. The CSE M/E Roundtable on BAS continues. Click here for part 1.

CSE: Do you personally think one system is better than the other, or does it matter?

EHRLICH: I don’t think one or the other is better. Trying to say that they are is like arguing about one printer protocol over another. No one really cares about the protocol—they care about what you can accomplish in the end—which is a functional building and both solutions do that.

HUSTON: The best system is the one that meets our client’s requirements for functionality, life-cycle cost and performance. We do not design a system based on preconceived ideas or the selection of one technology over the other. Our role is to use our unbiased expertise to present the features and benefits of all the options and help them decide what is right for them. That being said, our experience has been that our client’s definition of an “open system” requires device-level integration; therefore, LonWorks has been and continues to be our clients’ primary system of choice.

HOFFMANN: I have seen good to great systems of each, and likewise I have seen hybrid systems using both that meet the needs of the owner better than either could alone. But when it comes to taking information to the enterprise level, it’s XML Web services that do the best job.

TENNEFOSS: I believe LonWorks is the better solution based on cost, robustness, flexibility and vendor independence. Free topology, twisted-pair networking is less expensive to install than RS-485 because it allows an installer to run the wiring in a manner that is most expeditious, instead of requiring a doubly terminated bus like RS-485. In addition, the free topology channel allows both power and data to be sent down a wire pair, whereas RS-485 can’t do this.

In addition, the same common tool can be used to diagnose the entire network and serve as the platform for the HMI. However, with a BACnet system, the customer must purchase a different tool for each device manufacturer, so the installation and maintenance personnel have to learn and support multiple installation tools.

LonWorks also allows the integrator or end-user to select products—from the device level on up—from different manufacturers and make them interoperate. This gives integrators and end-users the freedom to select from among a wide range of different vendors on the basis of costs, features and design, instead of being stuck with sole sourced vendors for devices and controllers, as is the case with BACnet.

WICHENKO: I used to believe that LON’s strength was at the device level, but I now question this belief. Originally only LON offered device level profiles, so it could be used for various devices as a starting point for building BACnet device profiles. However, the BACnet committee is now working on device level profiles, so this advantage will not exist in future.

Another point is that device manufacturers used to offer LON devices only, but with the reduced costs of implementing the BACnet protocol stack at the device level, vendors at the recent AHR show were offering BACnet, as well as LON in devices like chillers, humidifiers, VSDs and duct heaters.

Further, BACnet support is growing among DDC system vendors. Companies like KMC, Siemens, Invensys and Andover now offer—or, in the case of Johnson Controls, are about to offer—native BACnet MS/TP devices, in addition to their proprietary or LON offering.

Frankly, I now prefer another device level protocol: Modbus. It is widely used in the PLC industry, in electrical meters and in boiler burner management controllers. Most BACnet DDC vendors make their own Modbus/BACnet gateways, so there is no third-party involvement required.

CSE: Is there a perception in the consulting community that BACnet is “safer,” or that engineers might be more comfortable with it because it was developed through ASHRAE? Is this a negative in any way?

EHRLICH: I have heard the perception that it is “our standard” as ASHRAE members.In reality, that really doesn’t hold much ground. What really matters more is what is going to work for building owners—they are the people who pay the bills in the end! We need to use solutions that meet building owners’ needs—regardless of where they come from.

HUSTON: Neither BACnet nor LonWorks is right for all situations. Many engineers blindly specify BACnet and/or LonWorks without understanding the features and benefits of both technologies. In fact, most control system specifications are written by mechanical engineers who have had no formal BACnet/LonWorks training. Worse yet, their lack of knowledge precludes them from enforcement of their own specifications and design, if any. Open standards provide the ability for 100% upfront design and specification while maintaining a competitive market. Vague performance specifications with minimal enforcement, if any, leads to underperformance and higher costs. Engineers are paid for their expertise, therefore they should be educated before making recommendations or attempting to design and specify an “open system.”

TENNEFOSS: LonWorks was developed as a control networking platform that can be used across a wide range of trade specialties—HVAC, security, access control, fire and life safety, lighting, elevators, sun blinds, weather station, sub-metering, generator control and IT integration. As such, LonWorks was and is ideal for single-function systems, as well as integrated systems in which all building control devices need to be seamlessly networked, managed, monitored and controlled. The focus on IT integration is especially important because it means that LAN and WAN IT infrastructure can be treated as an extension of the control network—whether for the purpose of connecting floors of a building or allowing a remote operations center to supervise, update, troubleshoot and optimize buildings from across a city or a continent.

WICHENKO: BACnet’s open-standards process gives me a comfort level that does not exist with LON. The committee process can be slow at times, but the quality of the output is excellent. The controls industry, save for a few players, now sees BACnet as the future for DDC. The effort that has been put into BACnet, both in the protocol standard and the testing standard, the plug fests that have been conducted and my experience in integrating different vendors’ systems together over a WAN, gives me a high degree of confidence in the standard.

CSE: How about on the other side? Is the use of the proprietary Neuron chip in LON products a pro or con?

EHRLICH: It is a non-issue. The bigger issue with LonTalk is the need to use certain other components in a system that are not part of the standard. For example, the commonly used communications transceivers and network management tools are only available from Echelon.

HUSTON: First of all, one should refrain from inferring that LonWorks technology is proprietary because of the use of the Neuron. The Neuron chip is provided as a convenience, but is not required. The LonTalk protocol is available in the same written format as the BACnet protocol and can be embedded in the processor of one’s choice. Additionally, there are several companies in Asia, Europe and North America that offer non-Neuron processors with the protocol. Echelon Corporation wisely determined early on that in order to obtain device level integration, consistent implementation of the LonTalk protocol was required. They also realized that if you put 10 programmers in a room and have them interpret a “standard,” you will get 10 different implementations. Sound familiar? BACnet.

By embedding the LonTalk protocol 100% in the Neuron, Echelon has short circuited the path to interoperability. Manufacturers can purchase the Neuron and spend their engineering dollars on the development of their product, instead of the implementation of the protocol.

TENNEFOSS: First, let’s finally dispel the myth that LonWorks in proprietary. The protocol, twisted-pair technology, power-line technology and IP routing technology used in LonWorks are all open standards.

At the same time, the advantage of using a Neuron chip or core is that it offers the most cost-effective implementation of the protocol, and the protocol embedded within these ICs is unalterable by the user. This means that every device has an identical instance of the protocol.

Second, let’s turn around the question. Is a BACnet product considered open if the manufacturer uses the BACnet protocol, but eliminates or modifies certain BACnet services or features to make the product non-interoperable with BACnet devices from other manufacturers? One could argue that the owner/specifying engineering communities are not well informed about the reality of the limitations of BACnet resulting from the selective implementation of services and functions by manufacturers who make these changes for their own advantage. These products pass BACnet certification, and are marketed under the auspices of open BACnet, but are in every way proprietary in operation.

CSE: How important is it that BACnet is an ISO standard? What about LonTalk as an ANSI standard (EIA 709.1)?

HUSTON: Standards are important to validate the technologies and expand acceptance of open systems, but they are not required. The bottom line is functionality, life cycle cost and performance. At the same time, standards acceptance continues throughout the world. For example, LonTalk is a preliminary European building automation standard known as prEN 14908, and work is well underway to make it both an IEC and ISO standard.

WICHENKO: BACnet has proven itself as a solid protocol across the world and has become an ISO standard because it works very well. ISO standardization is particularly important in the area of government procurement as some countries mandate the use of ISO standards where one is available. The fact that BACnet is also a CEN standard requires its adoption as a national standard by all 28 of the countries of the European Union.

TENNEFOSS: LonWorks is an ANSI, IEEE, CEN, SEMI, AAR and KS standard, and at some point, it will also be an ISO standard. The LonWorks protocol is also included as part of BACnet.

That being said, the important point is not the number of standards in which a technology is included, but rather the popularity, solidity and completeness of the solution.

Click

here

for part 1.