lon vs. bacnet

[brent]

I need some assistance from those more knowledgable than I am. I am having conversations with the head engineer for a 100,000 sq ft office building. It will have chillers, boilers, air handlers and served mainly by VAV's. We will be the leading mechanical contractor bidding the job when the dwgs are ready. He said his order of preference of ATC vendors is automated logic, siemens, and invensys. I don't really care who it is. I asked him if the system is going to be lon based. He said "no, it will be bacnet. I'm not sold on Lon."

My understanding is automated logic is native bacnet so I don't think I am too concerned about them. What about Siemens and invensys?

My main concern is we will most likely be taking care of this building after it is built. We don't want to be tied down to somebody. If in 8 years the owner want to change the space around we don't want to tell him we can't add controllers because they are obsolete or it will cost a fortune.

The engineer is also talking about controlling things like lights and maybe window shades (i'm serious).

I just want to know what to look out for.

Brent

[klrogers]

Obviously the head engineer does not fully understand the capabilities of LON. Perhaps some education might be in order to ensure the suitability for the in the long run.

Offer to take him to one of these seminars

http://www.buildingopensystems.com/us/index.php

all expenses paid of course!

[sysint]

Tell your engineer friend not to fall for all the propaganda of ASHRAE BACnetters.

We are going to retrofit a 5 building block that has ALC. The owner is done with all the supposed "BACnet" interoperability.

They went through 2 specification engineering firms who "weren't sold on Lonworks". (about the most ridiculous statement I've heard) Anyway, they are both gone as they simply couldn't answer simple LON questions and BACnet questions.

Both firms weren't smart enough to figure out that the system they had in place they weren't pleased with and why they weren't pleased with it.

Sheer ignorance propels BACnet. A little bit of knowledge goes a long way.

What does he say of all the Siemens and Invensys LON products in their lineup? IMO he has no clue about what he talks about.

Maybe he should go to http://www.lonmark.org and also take a look at oBIX.

[umd]

BACNET is pretty much a useless control specification that is sometimes mistakenly thought to mean inter-operability of different manufacturers control systems. On the other hand, Lonmark is an actual chip.

It is possible to have a system which meets BACNET and also is LONMARK compatable.

There's my "2 cents" worth on the subject.

[ps]

Doesn't sound like a BACnet v. Lon question (not yet, anyway). Interoperability, communications infrastructure, equipment manufacturers, owner preferences, equipment and service vendor knowledge, staff experience, etc - all play a role in determining "best" system.

Tell us more about the equipment and your company's background - this will allow those here to assist YOU w/o bias.

[nikko]

Posted below is the contents of a recent thread that was distributed through a public BACnet mailing list. The authors of the posts represent decision makers and official BACnet product testers however I have removed the names of the posters, companies, positions held and any other personal information that was associated to the original authors or participants.

There is no commitment for non-disclosure required to join the list and as such there is no requirments for content confidentiality for materials published on that list. To quote from the sign-up instructions for the list:

"The only restriction is that the list must not be used for advertising but questions concerning product features or capabilities are welcome".

As I've quoted material taken directly from the BACnet web site I've also attempted to assure that I comply with any copyright laws but finding none posted, I'll simply state that the above qoute should be attributed to http://www.bacnet.org

For purposes of clarification:
BTL = BACnet Testing Labratory
BMA = BACnet manufacturers Association

As for the content of the discussion, I'll let you draw your own conclusions.

nikko
************************************************** ****

From: <author’s name deleted>
Subject: BACnet interoperability of tested products

I am under the impression that controllers, tested at BTL and listed at
http://bacnetassociation.org/btl/default.htm comply with the BACnet protocol so that they can be plugged into one of the supported networks (Ethernet, Arcnet, MS/TP or PTP) and they will appear on a compliant front end GUI with all defined BACnet objects.

I'm aware that many controllers have not yet been tested, and that whatever their BMA listing shows may or may not work in practice.

However, in light of various comments I've recently received, I'm not clear if there are still connectivity problems even in the BTL tested and approved modules?

That would seem to defy the whole point of the exercise somewhat. Obviously, programming each controller would have to be done from a vendor-specific platform, but operational settings such as setpoints should all be accessible through a common user interface.

Does anyone have experience with connectivity problems specifically with fully tested and approved controllers?

Thanks,
<author’s name deleted>
************************************************** ******

From: <author’s name deleted>
Subject: RE: BACnet interoperability of tested products

The BTL tested building controllers (soon to be released) are not required to conform to the building controller profile and interoperability should not be assumed for the full range of B-BC functionality. I would refer you to the fine print however there is none. The BTL only makes public an overview of information that was tested and is not permitted to publicly display the many caveats a device may have which may hurt interoperability. Devices that pass through the BTL are forced to be fairly decent quality (functionally speaking) but the documentation provided to end users is not enough to decide whether a device is interoperable or not. There are pushes to make the BTL testing and listing more balanced however as it is there are no end users sitting in the BTL working group probably because manufacturers currently rule and pay for the BTL quality assurance lab.

If you are interested in the BACnet testing effort feel free to join. Based on the questions you asked you would be a fresh face in the BTL working group.

I am not sure how people join the BTL group and stay in the loop but you can probably contact <name deleted> or <name deleted> who are the <positions deleted> in the BTL. If you can not get in please let me know.

<author’s name deleted>
************************************************** ****

From: <author’s name deleted. Same author as above post>
Subject: RE: BACnet interoperability of tested products

Correction.

Instead of saying none I should better say there are not very ‘many’ end users in the BTL working group. Please feel free to disagree with my comments.

<author’s name deleted>
************************************************** ****

From: <author’s name deleted>
Subject: RE: BACnet interoperability of tested products

<previous posters name deleted>

Your comments are very accurate. There are only two BMA members who are not manufacturers reps and these are consultants who have different focuses but the true owner perspective.

You may recall that I represented <company name deleted> on the BACnet committee for a number of years. My background is more in tune with owners concerns however my participation since joining BMA has bee very limited (to my shame).

Your comments about conformance and particularly interoperability is very disconcerning. The main reason BACnet has atained the attention it has is due to the expectation that full interoperability would be what the BTL listing would stand for. If this is not the case then I don't want to even contemplate the potential outcome. It could be short and very bitter.

From my understanding BMA was formed to promote this very issue.

The time for action to be taken is now to get this and other interoperability issues resolved so that those who depend on standards being reliable and having meaning can continue to believe.

Should the BTL certified label turn into a "label of deceit" much may already be lost

<author’s name deleted>
************************************************** ***

From: <author’s name deleted>
Subject: RE: BACnet interoperability of tested products

All,

Vendors forming an organization to promote the 'open' protocol they use. What a novel idea.

The answer is really quite simple, completely separate the "fair and balanced" rating from those with even a perceived conflict of interest.

And then ... independently validate and audit the independent testing lab. Seems other industries have been able to effectively institute national testing labs. Sole sourcing could then be viewed as merely a stopgap measure.

<author’s name deleted>
************************************************** *

From: <author’s name deleted>
Subject: RE: BACnet interoperability of tested products

<Poster’s name deleted> et al,

I'm disturbed by the undercurrent of this thread, and particularly by <previous poster’s name deleted> "label of deceit" comment.

If BACnet, or more importantly a particular vendor's implementation of it, doesn't live up to one's desire about what it should be, that doesn't constitute a "deception."

There is a continuing hand-wringing about BACnet not being a "plug and play" standard, and about owners wanting a "guarantee of interoperability." I want to speak to those issues first.

BACnet is not, and has never been, intended to be a plug and play standard. There are way too many options and combinations for this to even be possible. Having said that, it doesn't mean that we can't get particular features to work well together in a vendor-independent manner. BACnet does a really good job in this regard, and there are MANY features defined in BACnet that in practice have the "feel" of plug and playness despite these caveats.

We would all prefer to not have to deal with these kinds of issues. I would like to have a universal motor, whose size, weight, power and coupling details work in every situation. Of course that's not possible, so we have to specify things like horsepower, shaft diameter, voltage etc. when we want to buy a motor. BACnet is no different in this regard. That 75HP fan motor won't work in my kitchen blender.

So, the idea of a "guarantee of interoperability" is flawed from the start, because it's based on the presumption that interoperability is a single scalar quantity. As we know too well, the kind of interoperability that BACnet is designed to address comes from a collection of specific types of "interoperation". BACnet defines how each of those interoperations should work. If two devices follow the standard, then they should be able to interoperate <<for that feature>>.

The test standard 135.1, and for that matter any testing agent such as the BTL, can only verify that each feature that a device claims to support, is in fact implemented in a manner consistent with the standard. If two devices have been verified, through BTL or some other means, to have sufficiently implemented a particular feature, then they should (and in most cases actually do) interoperate along the vector of that feature.

There are some subtle issues that relate to this though. Some features of BACnet are optional. So two devices can each have been tested and found to do exactly what they say they do, but one doesn't implement some options. If the other is designed to "depend on" those options then they may not interoperate as completely as one would like. That's not a failing in the standard, or the test standard, or the testing agency, or a deception on anyone's part. And yet, that optional feature doesn't interoperate, in this scenario.

How does the poor owner/specifier prevent this from happening? By asking for what they want. While the BACnet feature may be optional, the owner/specifier can still say "I want this feature."

This comes down to the ugly question, Why are there so many options? Well, that has to do with achieving consensus in the standards process, and some genuine disagreements about what things are vital vs. optional. If you feel strongly about the need to consolidate some of the optionality, you should join the consensus-building effort and defend those opinions.

I think it is unfair and counter-productive to suggest that any issues of supposed lack of interoperability are due to inadequate or deceitful testing. As various BTL participants have already described, there is an on-going evolution in the testing process that has dedicated a huge effort to continuous improvement and refinement. This is a very complex activity when you consider that many different players are involved. There is the on-going evolution of the BACnet standard, the evolution of the 135.1 test standard, the evolution of the BTL Working Groups trying to improve and set policy for testing procedure used by BTL, the evolution of actual testing performed by BTL, and a continuous shift in the designs and thinking in new and revised BACnet products. This is influenced by many strong peripheral factors like marketplace shift, changes in thinking and practice in specification, independent testing other than BTL, and the involvement of manufacturers, consultants, academics, end users and others in the BACnet evolution as well. The fact that any progress has been made, let alone the huge and continuous sustained advances that are BACnet, is nothing short of amazing.

But against all of this backdrop please keep in mind that there is a different dynamic to the open-to-the-public process of BACnet standards, and the BMA member-centric activities of the BTL Working Groups. BTL Working Group ideas and policies are not the same as the public standards, and in various regards the philosophies they bring to the standard and what specific types of interoperability mean are not the same. I don't mean to suggest that this is bad, but they are different and not equivalent.

I have to reiterate though, the testing process used by BTL (which is only one of several aspects of evaluating BACnet implementations) is not the problem, if in fact there even is a problem. The big issue is in being clear (to one's self as well as to one's vendors) what amount of interoperability you want and where you want it. The subtext of <name deleted>’s comments, and a flaw if you will in the whole notion of profiles, is that the depth of a given implementation of BACnet, and some of the optionality choices vendors make, also has an effect on the kind of interoperability two given devices may have. I'm not convinced that eliminating choice is the right solution, if we even agree that this is a problem.

I think the reality is that you have to specify what you want to buy. BACnet provides some of the tools for defining interoperable features and their options. Owners and specifiers must ask for the combination of these features that they are looking for. To pretend that a vague specification fully defines interoperability requirements when it doesn't is just a "label of deceit."

<author’s name deleted>
************************************************** **

From: <author’s name deleted>
Subject: RE: BACnet interoperability of tested products

To all

The point I wanted to make (in reference to my "label of deceit" comment) is that the owner consultant communities for the most part are not sufficiently informed about the reality of BACnet (strengths and limits - limits resulting from manufacturers selectively implementing services and
functions) to use it to their advantage. What some manufacturers fail to recognize is that by omitting certain BACnet services or features in their products weakens the whole BACnet environment (weak link syndrome) and any gain they might perceive will be short lived. Having said that, we live in a free society and everyone has the right to follow their own path.

It should be in the interests of BMA/BTL and SSPC 135 members to do what ever it takes to ensure the negative label never gains credence.

As has already been identified in this string there is an urgent need for owner/users and the design communities to become actively involved in the certification process and for the interoperability issues to become more prominent in the verification process.

Dispelling myths - Since the inception of BACnet in late 1980's there has been a building of expectations within the design and owner communities. As with many preconceived expectations many go beyond reality. The BACnet committee and those associated with the development process have always tried to refocus overstated comments to avoid confusion and reduce unrealistic expectations. Unfortunately there still remains a major potion of the owner user community who still hold high expectations, many, whose business activities focus on other aspects of the industry.

High expectations usually elevate the potential for failure of the final outcome. Interoperability is one of the issues where owners may be disappointed on. Owners expect total interoperability (the ones I have talked with), however reality is that only certain interoperability (partial) can be achieved with certain products and present BACnet definition.

Partial is good and can provide excellent services when products are selected which have the services and features which are compatible with the site requirements and the owner's needs. Partial also means that product and revenue can begin to flow for the major R&D that has been used to get product to market. The next generation of product will where demand is shown will increase interoperability and closer integration.

<Previous poster’s name deleted> and others have excellent course materials to spread the word about BACnet and are doing a good job, however more needs to be done. The potential audience is huge but the individuals who should be presented with the knowledge are often too busy to devote time to training sessions.

From my experience with BACnet and more specifically to the BIBBs and PIC statements is that there is a need for a spreadsheet type approach to enable the control system designer to not only list the services required for a specific project but also to compare the bidders products with the site requirements to determine compliance. Possibly the use of epics files could be read into the comparison process to expedite and reduce typing errors.

While the above suggestion is rather fundamental, I would suggest that very few practitioners will actually implement such a check during the tender review process.

I recognize that manufacturers and vendors may not be anxious for this type of review to be completed as it could result in products being disqualified at tender time. On the other hand members of the BACnet committee are probably thinking the opposite, that unless such a comparison is made, how will interoperability be achieved!

<Name deleted> invitation to join the BMA to represent owners views should be passed on to likely candidates so that the BTL procedures and processes will be scrutinized by those with various perspectives.

<author’s name deleted>



[Edited by nikko on 04-06-2005 at 05:10 PM]

[sysint]

LMA - I get it.... that's a ASHRAE BACnetter engineer way of saying "NO".

Thanks

[Freeze Stat]

brent, go to the Echelon website (echelon.com), check out the "online LonWorks demonstrations". One of the demos actually has a window shade you can "control".