Myths of LonWorks™ and BACnet™

Building owners and facility managers have long awaited the means to break the proprietary lock of the building control manufacturers. BACnet and LonWorks are two protocols that are competing to be the key that unlocks the lock.

Not everyone is enthusiastic about LonWorks and BACnet. There are some who want one to win at the expense of the other, and there are a few who are still hoping against hope that both will somehow disappear. So, amidst the hype and the claims there is also accusation and confusion.

 “First they ignore you, then they ridicule you, then they fight you, then you win.”

  —  Mahatma Gandh

This article represents a view of what is real and what is not.

Myth #1: It’s a duel to the death - only one will be left standing.

Not so. This myth often cites as supporting evidence the Betamax vs VHS knockout that occurred. But the comparison is flawed because Betamax and VHS were mutually exclusive products, whereas BACnet and LonWorks products can interoperate in the same system.

LonWorks and BACnet are competitors, yes; but they both have a place in the industry, and they both have a critical mass of customers.

There are even some building control manufacturers who are purposefully designing their product lines with a hybrid of BACnet and LonWorks as their standard offering.

Consider the four configurations below.

A. The legacy proprietary system
This is a design from yesterday with an attempt to adapt to the industry standard, but not adopt it.
This system is still proprietary, and over time will fade from the scene, or will be relegated to speciality niche market applications where interoperability is not an issue.

B. Lonworks system with gateway to LAN networks to PC workstation to the BACNet link

Configuration B is maybe better, maybe worse. It seems to have been dreamed up by a marketing department.

It allows the marketeers to claim “we have adopted LonWorks to allow you, the customer, to mix and match different manufacturer’s components.”

Sounds good, but what is left unsaid is that the customer is still not free to mix and match different manufacturer’s systems. In other words, if the customer wants to contract for an addition to an existing system, he can only entertain a bid from a competitor if he agrees to use the original supplier’s proprietary workstation, and agrees to pay the original supplier’s price to reconfigure it for the new addition.

Lets consider this arrangement, with the original supplier’s proprietary grip still in place …thanks a lot!

C. Lonworks network, LON conponents controlled via  LON controllers, talking through a gateway direct to a BACNets network and components.

Configuration C begins to address the needs of the customer. The customer can now interoperate different manufacturer’s systems without being locked into a particular supplier, and can mix and match different supplier’s components (although at the component level, it may not be as cost effective as it sounds).

D. Lonworks network, LON conponents controlled via  LON controllers, talking through a gateway direct to a BACNets network and controllers and components.

Configuration D also addresses the needs of the customer. The customer can interoperate different systems, and can mix and match components (again, it may not be cost effective at the component level).

Why would some manufacturers choose configuration C, while others choose D?
There are as many reasons as there are engineers designing them, but from the customer’s point of view, it probably matters little.

So, LonWorks is not going away because some manufacturers are designing LonWorks components into their product line, and it is very costly to change later on. BACnet is not going away because it is the protocol of choice at the system level - A number of top building control manufacturers have chosen LonWorks for this purpose, but they don’t want to you to know that its based on Lonwork system. If they are embracing interoperability, as in configurations C or D, they are choosing BACnet to do it.

Myth #2: It’s a lovefest - they are working together in perfect harmony.
No, it is not a lovefest - they are competitors, remember? Yes, they are both chasing the same goal, interoperability.
But within each group there are a few who still believe in Myth #1, and want their side to win. Pointed jabs in the ads and hype are not uncommon.

The vast majority of the members of the LonMark and BACnet groups, however, see the fallacy of Myth #1, and understand the need for both groups to work together. A working relationship exists today between the two groups, and it is getting better as the reality sets in.

Myth #3: One is expensive, the other is affordable.
Claims for cost effectiveness abound, but the bottom line is there is no significant difference in the cost of manufacturing controls based on a proprietary protocol, the LonWorks protocol, or the BACnet protocol. If
there is a difference, it will be lost as a rounding error on bid day.

If cost is the primary criterion, compare the life cycle cost of configurations C and D versus configurations A and B. That’s where the big bucks are.

Myth #4: One is complicated, the other is simple.
Here we go again. Some folks spend their time on this type of argument because they still believe in Myth #1.
LonWorks and BACnet are both like an Internet browser - they are complicated if you want to know how they work; they are simple if you want to know how to use them.

Myth #5: Specifying either one is a nightmare.
Sure, if you are trying to force a controls manufacturer to interoperate with a competitor through the specification process, when the manufacturer is not committed (or when they are covertly opposed to it), then it is indeed very, very difficult and will likely result in a nightmare. On the other hand, if a controls manufacturer is committed to interoperability, and some are, then the specification process is simpler than it has ever been.

If you want interoperability, first spend your time determining which controls manufacturers are committed and which ones are not. Then, use the specification process to spell out your performance and functional requirements.

It works.

This entry was posted on 13/06/2009 at 09:58 pm and is filed under BACnet, Lonworks. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or trackback from your own site.