October 2011

[an error occurred while processing this directive]
(Click Message to Learn More)

Criteria for BAS Open Programming

Forget about what you do now, and think about what you should be able to do. What is our wish list, or maybe our “must have” list, for BAS programming?

David FisherDavid Fisher,

Member ASHRAE, BACnet Lecturer,Co-chair, BACnet International Education Committee

New Products
[an error occurred while processing this directive]
Site Search
[an error occurred while processing this directive]
Past Issues
[an error occurred while processing this directive]
[an error occurred while processing this directive]

(This is the second part in a series of articles that intend to expose issues and topics for discussion centering on the idea of creating an open standard for programming of BAS applications.)

Last month I introduced the idea of creating an open standard for programming of BAS applications. As expected, we’ve received a lot of (mostly positive) feedback about these ideas. At least one industry expert has suggested that this problem has already been solved by IEC standards 61311-3, and now IEC 61499. Before we get into any debate about the merits of any one solution, I think it’s important to first reach some consensus about what the important criteria for BAS programming are, what’s done well by today’s tools and what isn’t. The overwhelming view, based on feedback we’ve received is that this is the right approach.

Although there are many great questions to explore, one person recently asked “If we work towards an open programming language, what then sets different manufacturers product offerings apart?”  That’s an excellent question. For starters, how about: price, performance, features, support, understandability, reliability and flexibility?
The fact that every car has a steering wheel, brakes, accelerator, rearview mirror, turn signals etc. hasn't stopped car companies from making thousands of other points of distinction. And yet as a driver I can get into virtually any car and drive it, perhaps with a little fumbling. No one would assert that all cars are the same, yet they have a great deal of common and open elements.
In the beginning, cars had a lot of quirks and differences so it was difficult to go from one brand to another without special training. It wasn't until commonality in cars stabilized on an accepted set of features and reasonable costs that the market exploded in size.
This same explosion is waiting to happen for building automation programming.

Is there really anyone interested?
You bet. We’ve asked this question repeatedly in various BAS forums and there has been a resounding cry of “it’s about time” and lots of interesting feedback. Sure there are concerns, and a healthy dose of cynicism. That’s why there needs to be a lot more discussion.

Before letting concerns about outcomes dominate the agenda though, we should first have some serious discussion about what it means to create BAS programs today, what is good and bad about that, and what features any new approach should consider.

[an error occurred while processing this directive] What forum is this discussion taking place in?
Right now there are several Linked-In groups, as well as AutomatedBuilding.com, that are actively having discussions. There has been some talk about creating a new centralized venue for debate. Once the issues have been more exposed and set the tone for direction, we can move the discussions there. Some have asked why not create an “official” venue like an ASHRAE SPC? Perhaps that will become appropriate at some future time, but for now there is a lot of reluctance to dampen enthusiasm by introducing too much structure.

What ideas and requirements are important?
This is a central and critical issue. Forget about what you do now, and think about what you should be able to do. What is our wish list, or maybe our “must have” list, for BAS programming? To get the thought process started I’ve made a strawman list. For each item you could say “yes that’s important to have” or “no that doesn’t matter to me” or add your own items to the list. The more input we have, the better as this will become more representative of needs and wants. In no particular order:

That’s enough to get started! Let’s see just how many of these get nods and how many produce anxiety.

Keep those emails coming.

About the Author

David Fisher (dfisher@polarsoft.biz) is president of PolarSoft® Inc., Pittsburgh, PA. He was a charter voting member of ASHRAE’s Standards Project Committee 135P and has been active in the development of the BACnet standard (ANSI/ASHRAE 135-1995, 2001, 2004, 2008 and 2010) since its inception. He served as a voting member on the Standing Standards Project Committee-135 until July 2000 where he is an active participant and contributing author. He has taught many courses about BACnet, networking and communications, and direct digital controls, including ASHRAE PDS and Short Courses.

The opinions expressed here are those of the author and do not necessarily represent the position of AutomatedBuildings.com, or any of the organizations with which the author is affiliated.


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

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]


Want Ads

Our Sponsors