Innovations in Comfort, Efficiency, and Safety Solutions.
August 22, 2003 7:48 AM
Subject: Re: XML
I have been reading with interest your articles regarding XML and its building automation usefulness, and would like to add some comments to the well thought out ideas proposed by yourself and others on the AutomatedBuildings.Com website:-
As proposed, XML can be, and is, used for management level connectivity between applications and systems, but it is also the perfect next generation 'interoperability' landmark for BMS/EMS hardware all the way down to the field level controller too. I say landmark, and not just another stepping stone, because XML gets us where we've been going for some time now.
As you know XML data packets are small, text only and both human and machine readable. It's a small leap of the imagination to propose then that even current open protocols could be superseded by XML exchanges between DDC controllers, LAN's and disparate building automation systems, whilst using robust technologies such as RS-485, LON and TCP/IP as the chosen network architecture as required; and why stop there? DDC controllers could be programmed with XML Strategy Algorithms that could be created by vendor independent applications, whether graphical or textual.
With regard to Web Services, I note an Internet Web Service function that accepts a US ZIP code and returns the current Air Temperature at that postal location, which demonstrates nicely the simplicity and usefulness of web services at the ground level for system engineers and owners too. Imagine building wide automatic control systems that collect information such as time, local air temperature & humidity, occupancy schedules, alarm routing, etc from a web service, and thereby ensure the use of unified and current information.
I can well appreciate your enthusiasm for the XML functionality offered for building management, energy control and plant and asset auditing. As an engineer I can see various applications of XML at the design and documentation end of our business that could simplify and clarify the engineering of automatic HVAC control systems, and believe that XML is the technology that can bring together all the best of all our various visions over recent years into a working reality with quite little effort.
It is early days yet but we could start thinking about ideas that include open XML DDC standards. I hope to be starting a Visual Basic.NET & XML project later this year with the very purpose of creating a graphical strategy engineering tool for programming DDC controllers in XML. Of course such controllers do not exist yet, but even Internet Explorer can parse XML documents, so embedded XML parsers that can fit into a 16 Bit micro-controller are not far away. To compliment the XML DDC tool could be a XHTML tool to generate web pages to view the same point data attached to pretty graphics too.
XML may have sneaked up on the most of us, but now we know its here and how easily it can be conformed to our needs, it's just a matter of finding the time to make these applications a reality, which is of course the tricky part!
November 19, 2002 8:17 AM
Subject: Web Services
Re: Information, its true worth
You have the knack in creating a spectacular debate upon emergent technologies!
My only concern is the apparent lack of concern, by the industry, over existing technologies.
In a nutshell; I have worked up through the HVAC and Building Services industry, and without any shadow of doubt, my experience is entirely this:-
Information at a management (web or otherwise) level, is entirely relative.
The manager, in actual day to day real life, is unaware of the operational activities of the plant engineer, therefore when he clicks on his web browser the information is not relative to the actual status of the plant. For example, the plant engineer may choose to isolate a particular plant item for maintenance and service, and this fact will not be reflected in the information presented in the Browser.
More commonly, regardless of the high level management intentions to improve performance and feedback, and this is only my personal experience, managers do not visit the front-line and communicate with the engineer, and so do not appreciate that plant is left to be pretty much operated on an ad-hoc basis.
When the management requirement for information is merged with a firm commitment, and understanding, by the plant engineer to ensure operational efficiency, then the relative value of advanced information services will become more useable.
I believe in Information Technology, but also believe that work needs to be done to bring together the managers and engineers to effectively co-ordinate the activity of getting plant and controls to perform correctly, and efficiently.
My two-penny’s worth!
Subject: "Dear Editor"
Date: July 18, 2002 9:16 AM
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:
"Finally, an open system must use an open communications protocol. Since the corporate spin doctors can't agree on what constitutes an open protocol, let's use a neutral definition, provided by a recognized authority on the telecommunications revolution. MIT Professor Nicholas Negroponte says "A truly open system is in the public domain and thoroughly available as a foundation on which everybody can build." BACnet, which was developed by ASHRAE, has been adopted by ANSI, and is being reviewed by ISO for adoption as an international standard, fits this definition to a "T." It's important this protocol be the "native" language used throughout the control system. "
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:
"The issue of including LonTalk as a LAN technology within BACnet was passed prior to the third public review of the standard in 1995."
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):
"It conforms to the standards-criteria of IP, ANSI, IEEE, AAR, IFSF, SEMI, BACnet, and others. The platform is complete from protocol, to ICs, to physical layer, to software installation and management, to operating system, to end-user applications."
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:
LonWorks®, a standard marketed by Echelon Corporation
BACnet®, a open standard developed under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)
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):
"A data communication protocol is a set of rules governing the exchange of data over a computer network. The rules take the form of a written specification (in BACnet's case they are also on compact disk) that spells out what is required to conform to the protocol.
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?
Robert J. Stokes, IDS, innovate develop solve
Thanks Rob, we will publish in our August issue.
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
Sent: Thursday, February 07, 2002
Subject: BACnet vs LonWorks
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.
Environmental Control Corp
I forwarded your request to both the BACnet and LonMark. AutomatedBuildings.com is extremely interested in publishing any information on examples of interoperability projects.
Thanks for your input
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"
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.
Automated Logic Corporation
Also comments on Jack McGowan's article "What's New and Hot in the Building Automation Market"
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.
All with a guaranteed savings over 25 years.
There is a tremendous opportunity for this type of work today.
Keep up the informative articles.
John M Schneider
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]