AutomatedBuildings.com Letters to Editor

I've been noticing more and more of late a leaning towards BACnet based content on your web site. I'm sure this is not your intent but the trend is annoyingly obvious and concerning. I'm also aware that the "leaning" I'm picking up on is most likely a function of the people who contribute to the site. Perhaps it's a simple as this. What bothers me is not so much the information that's presented but rather the misinformation and in particular the way certain terms and phrases are presented or in some cases omitted. Again, this is a function of the various authors but a couple of cases in point:

Steve Tom in the article entitled "Browsers BACnet and Building controls" writes:

I don't wish to dispute articles on a point by point basis however Steve failed to mention that BACnet recognizes LonWorks as an approved carrier. I quote from an excerpt taken from www.bacnet.org:

Further, BACnet was not "adopted" by ANSI but rather was "accepted" after an application process initiated by BACnet. This process was no different for BACnet than it was for any other organization wishing to make their protocol a "standard". To continue setting the record straight, LonTalk is already an ANSI Standard (709.1). Quoting Kevin Lynch from the interview titled "How are corporations currently using control networks to automate buildings", published on your site (as he speaks to LonWorks):

To clarify; LonTalk IS a protocol whereby BACnet is a specification FOR a protocol. This is a key difference that several of the BACnet proponents seem to omit. Another example of "absence of information" can be found in Jonathon Buckley's article from your site titled "Overcoming BMS shortfalls by managing facilities as a unified network". In the article he references BACnet and LonWorks in the following format:

Once again, through the choice of flowery wording, the "newbie" reader is led to believe BACnet is in fact an open standard and LonWorks is simply "a" standard. Again, BACnet is a specification to which product can be built. To quote www.bacnet.org (FAQ section):

BACnet is a "standard" only in as much as it is interpreted as such on a per-vendor basis. LonWorks is a "thing" which can be purchased negating the requirement for interpretation of a specification. You and I can be sent away to draw a blue circle and when we return to compare completed product, it's highly improbable your circle and my circle are the same size, the same shade or drawn on the same type of paper. Interestingly enough, upon review of the completed product both submissions will be deemed acceptable and both can claim compliance. Thus is the case with BACnet. With LonWorks, we both have the opportunity to purchase an identical blue circle where the size, shade and media have been determined by consensus of the people who know and understand blue circles. From there, we can build that circle into a product we can call our own but it will always be based on the identical blue circle; a circle that we can interchange at will, with no detrimental effects to the finished product.

I'd also like to point out that in the majority of BACnet installations, there is rarely one single "native" control language used throughout the system as your readers are led to believe. Rather, there is usually a proprietary language used at the device level and a gateway somewhere on the network converting specific variables to the BACnet specification. This combination enables the vendor to claim "compliance" when in fact nothing special has really taken place and the system is nothing more than a "standard" proprietary system that's given the customer no more value, yet has cost more money. This is not to say that BACnet doesn't have a valuable and earned place in Building Automation, it does. BACnet was designed and functions well as an upper level communications path that allows proprietary controls vendors to convert their protocol via a gateway to a common format, and to share specific and discreet pieces of information. In rare instances, when different manufacturers have placed their R&D teams together, devices have been manufactured that allow for the calculated flow of information between them without a black box. This however, is the exception, and not the norm many BACnet proponents would have your readers believe.

The BACnet/LonWorks discussion will continue over the next few (many) years and as long as ASHRAE is in a conflicting position and is involved with the production of product for resale, BACnet will always have it's share of proponents regardless of their level of application knowledge. The result is often mis-information and inflated claims and the unfortunate recipient of this information is often the very client doing their best to wade through the rhetoric. To pit BACnet against LonWorks is to ignore the fact that both have their place, both have similar goals in mind, yet one can never truly be directly compared against the other. BACnet has made several moves of late in the right direction, towards creating a platform equal to the inherent interoperability offered by the team of LonWorks/LonMark but by the very nature of the specification, will never reach the same ease of success and it was not intended to. The fact remains BACnet is a specification and while it's very well written, it will always be open to interpretation. It was always intended to allow proprietary vendors to bring their unique products up to a level of communication through the exchange of their data to a common format. BACnet was never intended to be a device level communication mechanism where-as LonWorks has been designed to facilitate all levels of communication without interpretation or dedicated R&D discussions between competing vendors. This is not a statement of competition, but a statement of simple fact, one that seems to have been lost within much of the verbiage that's trending on your site.

I understand one of your functions as an editor is to solicit information but as Editor, you have a responsibility to present neutral informative material to your readers. Of late, your site has been missing this balance. Granted I'm not quoting any "LonWorks friendly" articles but frankly, there haven't been a lot of them. When AutomatedBuildings.com was first launched I encouraged all of my customers and potential customers to visit your site, as I knew they would get a fair and detailed set of discussions pertaining to all facets of Building Automation. I do not do this anymore due to the level of content I've discussed.

How do we change this trend? How do we ensure a fair and un-biased field of information is presented so I can once again encourage my customers to lean on your site to capitalize on the rest of the (non-protocol based) quality information submitted by reputable professionals?

I will also add my comments to your comment "I understand one of your functions as an editor is to solicit information but as Editor, you have a responsibility to present neutral informative material to your readers."

As editor I believe in the freedom of speech of each contributor. They are totally responsible for their words. We provide an email address for each contributor so that they can be contacted directly. We will do the same with your letter to editor. Had the sections you cited been authored by me, I would then be responsible for them and could respond to your comments. We simply provide a conduit for industry views.

As to providing a "fair and unbiased" field of information; we only report the information we receive and what we don't receive we cannot publish. If the Lon community needs to correct information of any author all of our communication vehicles are open for use.

Subject: Web Services
Date: March 24, 2002 7:20 AM

Dear Mr. Sinclair:

I read your recent article in ES on Web Services and I think this a great and necessary area for BAS to evolve into. However, BAS in general while evolving, needs to "de-volve" a little. By that I mean the industry needs to help end users develop the proper staffing and training to use these rapidly changing technologies.

I was the BAS manager for Trane in New Jersey and one "constant" that was always with us was that the features and benefits of Window based systems, clever control routines, etc. was often lost on the end user. The owner of the building, the architect or engineer, in their efforts to create a gee-whiz system forgot the end user: the boiler room mechanic. Not only that, they had some boiler-plate training time in the 'specs for "not less than 16 (or 24, or 40) hours of classroom training......". This training usually begins at the end of the job and has to compete with a myriad of other new-building complaints. The result is poor training which leads to poor understanding, which leads to poor use of the system which leads to "this system is a piece of junk".

The acceptance and use of new technology for BAS is a battle that will be won in the classroom. Training, personnel and products all need to evolve together.

John J. Christiano, P.E., CEM Criterium Engineers

AutomatedBuildings.com has published some excellent articles that are both educational and useful. I especially appreciate it as a source of unbiased information regarding the BACnet vs LonWorks debate. As some of your authors have indicated, and I agree, it is unlikely that one will "push" the other out of the marketplace.

An article I would really like to see is a study, or a report, of the currently interoperating projects using the BACnet protocol, as well as the currently interoperating projects using the LonWorks (LonMark) protocol. Both technologies have a series of control vendors and equipment vendors using their respective protocols. The utility of these protocols is of benefit both in interoperability of control vendor to control vendor and in interoperability of control vendor to equipment vendor. Some case studies would be of great interest.

I forwarded your request to both the BACnet and LonMark. AutomatedBuildings.com is extremely interested in publishing any information on examples of interoperability projects.

I write the Building Automation Column for Engineered Systems Magazine a few months ahead to allow for publishing time. We run the same column on our site the following month, so in this case we have comments before you may have read the column "The Indispensable Internet"

[an error occurred while processing this directive]I enjoyed your article on "The Indispensable Internet" in the October issue of Engineered Systems and agree wholeheartedly with your conclusion that TCP/IP will be the primary data pipe of the future. I also agree that XML will be very useful for creating systems that are truly interoperable; however, I am concerned by the fact that many people in the HVAC industry don't really understand what these standards include, as well as what they don't include. Terms like "protocol" and "language" are thrown about so freely that some engineers see these Internet standards as competing with existing HVAC standards like BACnet, and they begin wondering which standard is "better." That's a little like asking "which is better - BACnet or English?" XML and TCP/IP are very powerful tools for exchanging information over the Internet, but companies who have tried to use them by themselves to automate business to business (BTB) transactions quickly discovered they needed more than just universal communications tools. They needed a standard way of modeling the information they were trying to exchange. If company A defined a "Customer" and provided data fields for street address, city, state, zip, and account balance in dollars, while company B defined a "Purchaser" and provided data fields for an e-mail address, FAX number, and amount owed in Deutschemarks, they couldn't automate transactions between the two companies without creating a custom interface, even if the information was written in XML and sent over a TCP/IP network. Creating interoperable building automation systems is very similar. Having universal communication tools doesn't eliminate the need for a standard way to model the data being exchanged. The power of BACnet is that it provides a standard way of modeling all aspects of a building automation system, from a simple poin value to a complex scheduling hierarchy, and it can do this in any language. (The BACnet committee is currently working on an XML extension to the BACnet standard.) You may want to consider devoting a future column t how Internet standards may apply to existing building automation systems, as it's a cinch your readers will run into these issues in the field.

Steve Tom
Automated Logic Corporation

Jack:
[an error occurred while processing this directive]Excellent article "What's New and Hot in the Building Automation Market".
I whole heartedly agree with the opportunities in the Performance Contract Market.

I have recently completed a "Super Energy Services Performance Contract" at a Federal Government campus here in the Salt Lake City area. We retrofitted the chilled water distribution system with de-coupling loops and variable speed pumping, added a plate and frame exchanger to be staged with the central chillers, retrofitted a solar assisted domestic hot water heating system, installed a new 10MW substation to take advantage of a different utility rate structure, installed a new medical waste handling system, upgrade of 11,500 lighting fixtures and finally upgraded the Metasys building automation system.

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

Events	Want Ads
Our Sponsors	Resources