AutomatedBuildings.com Letters to Editor

mentions ZigBee as an Open Standard.

FYI : ZigBee Is NOT an open standard. Specifications are only available to ZigBee members.

Kind regards,
Ivo Noorhoff

From: William Burns
Sent: Fri 01/10/04 8:05 AM
Subject: Control Spec Builder

I use it as a tool in the building operator certification class I teach because the building engineers can quickly assemble a control system diagram, points list and sequence of operation. With out this level of detail on the control system it allows the building engineer to provide constructive comments when new control systems are being installed. It is also useful when they are trying to understand an existing control system with no documentation.

I have also found it very helpful in the commissioning control systems in the design phase. Many designers provide very weak sequences and often the control diagram and points list are nonexistent. When I show the designers what the owner could get for free, they become very interested in incorporating the sequence, points list and drawings on their documents.

Control Spec Builder provides both a benchmark for the minimum level of detail that should be provide provided when specifying controls systems and the ease of use makes it impossible for designers to argue that the benchmark is too expensive to create and implement.

From: Len Damiano
Sent: 12:13 PM July 9, 2004
Subject: Ventilation Needs And The Requirements - Rebuttal to following letter from Gene DeJoannis

This is in response to the email comments you received from Mr. DeJoannis of West Hartford.

I am very happy that someone is reading the articles and thinking about what they say. However, the purpose of the “Ventilation Needs And The Requirements of the IMC…….” article was to inform and educate. To sell a concept – not to sell product. It was unequivocally non-commercial. His final “shot” attempted to align your publications’ credibility with defects he perceived in the article. He needs to be made aware that automatedbuildings.com has always tried to give equal time to opposing views - the hallmark of really good journalists, better publications and one of the best ways for us to learn from one another.

CO₂ sensor supporters and packaged equipment manufacturers have more than sufficiently promoted CO₂–based DCV over the past 15 years, creating much confusion and misunderstanding in the process from their unsubstantiated methodologies and loose interpretations of standards. They have been so successful, that few understand how or when to use it. They also thereby relieve me of any responsibility to give their claims “equal time”. But none of this addresses the main point of the article – the IMC 2000 & 2003 versions have no provision to allow CO₂ monitoring for compliance with the intake rate requirements in ventilation section 403. The only tenuous justifications presented to me are the very general allowances for code exception requirements and very qualified references to the control method in the IMC 2000 Commentary, which is not part of the IMC development process and should be read very carefully.

If bias was seen, it could only have been in regard to technology and method. If bias is needed to communicate an appropriate opposing perspective – so be it. Providing logical arguments to support a particular position are normally more successful when biased to that position. I appreciate the writer’s comments, but I think Mr. DeJoannis of West Hartford also needs to keep an open mind and not believe everything that equipment vendors say when promoting CO₂ control options. They may have their own self-serving interests involved. It would not be the first time that control strategies or sequences supplied by equipment makers have been found to be less than that advertised – at least some of the time or for certain applications. I believe that to be the case now.

From: Gene DeJoannis
Sent: 11:30 AM July 8, 2004
Subject: Ventilation Needs and the Requirements

I found your July ventilation article to be a rather one-sided opinion piece, which is not too surprising since the author works for a maker of air flow measuring stations, which he insists are a necessary part of any ventilation system. You did not point our the author's connection to the manufacturer. Is this an info-mercial or an unbiased article? I imagine makers of CO2 sensors might have a different opinion. One factor the author does not mention is that even if you can measure the OA rate accurately, no one can tell the designer or the control tech what the setpoint should be (other than the maximum design space occupancy). But this leads to a school with 500 occupants being ventilated to serve 2000, even when the gym, auditorium and cafeteria are empty. I don't think we want to do that.

Certainly when CO2 is used to control ventilation for people-generated contaminants, we should clearly specify the minimum ventilation rate to be always supplied when occupied (exhaust + pressurization). The CO2 control forces the economizer to open beyond that point. But I think it is possible with current actuators and digital controls to set those minimum rates during commissioning at several different supply fan speeds (such as 35%, 70% & 100% of full speed) and operate with open loop control of the minimum damper position between these points.

I agree this is not the best method, and that a flow station would be desirable, and if there are local user-controlled exhausts in the space it is indispensable. However, not every job can afford a flow station, and if the local exhausts do not vary under the control of users, a static minimum ventilation rate should be satisfactory. That is not to say that it should be left alone for 20 years without rechecking, but outdoor air flow stations may add a little too much complexity for many owners and they have the disadvantage of needing a flow setpoint from another source (such as a human being who estimates the population or a CO2 sensor that detects it).

Gene DeJoannis
vanZelm Heywood & Shadford
Mechanical & Electrical Engineers
29 South Main Street
West Hartford, CT 06107

From: Craven,Dave
Sent: 10-Jun-04 5:41 AM
To: sinclair@automatedbuildings.com
Subject: Engineered Systems Article

I enjoyed reading your piece on the impending wireless explosion. You are absolutely correct on one point, and that is that the overall impact on the Building Automation will be staggering. We started working with Ember about two years ago when most of the technology was at smoke stage, getting serious about a year ago when we actually found a home for sufficient numbers of the devices to drive manufacturing costs to the point where there is a significant enough delta over wiring and commissioning costs. That same reception hasn't quite found enough legs in the traditional BAS marketplace as opposed to equipment manufacturers.

I said I agreed with your article's major point but you may have overlooked a larger one. Being able to lower the bar on installation costs while simultaneously being able to embed a whole new layer of applications will eventually make it possible to bring automation to virtually every component in every electro-mechanical system in any building. The driver for doing so will be energy. Utilities / Energy Service Providers have been unable to do anything other than scratch the surface with near real time control with all 4 million of the small C&I customers in this country, those folks whose electrical demand is typically less than 100 KW. Collectively we have a national crisis on the front burner with regard to our nations' energy supply and its aging distribution system.

I think it may be realistic to look down the road a very few years and see complete connectivity and control capability being delivered to the small C&I customer to all levels of their energy consuming systems, not to mention other appliances or processes to costly to consider extending automation to today. The gap between end user and manufacturer will narrow considerably and in less than 5 years there will be many more things on the internet than there will be people using the infrastructure.

Mr. Sinclair:

On the heels of your Feb 2004 article in ES, and after a meeting I had yesterday, I'm going to repeat a message that I wrote some time ago about the industry's technology needing to "de-volve" rather than evolve......

Yesterday, I did a pre-bid walk through with an engineer from a major New Jersey city. The projects were very straightforward and not very complex. However, as we discussed the scope and possible components, I was told repeatedly not to use any new technology. No high efficiency condensing boilers. No CO2 detectors. The simplest control schemes, and so forth.

It wasn't they did not see the value of these newer technologies. The problem was that budgets and skill levels would not allow the owners to take advantage of them. This is a public entity. My years of experience have shown me time and time again that we are laying these new technologies in front of this sector of people who are ill prepared to use them. We use too much "wow factor" on upper management or boards of directors, forgetting, or not caring, who will be the actual users of the systems.

The result is that the users send their comments up the ladder about how "the system doesn't work" or "It's a piece of junk" or "Savings weren't realized". If you look at maintenance staffs in the public and private sectors, they are increasingly being staffed by new Americans with limited language skills and even more limited technical skills making the issue even more complex and difficult.

We cannot keep selling our products and systems in this environment without "co-evolving" proper training, tech support and extended service contracts.

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!

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:-

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.

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