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 Fisher, President, PolarSoft® Member ASHRAE, BACnet Lecturer,Co-chair, BACnet International Education Committee

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

• Must provide both procedural programming and graphic programming of source code
• Must “compile” into the same intermediate “bytecode” which is platform-independent
• Bytecode design must support decompiling into either procedural or graphic form
• Must provide inherent multi-threading between executing programs
• Must provide intrinsic support for BACnet objects and property values and datatypes as well as compartmentalized client and server functionality
• Must support multiple datatypes based on BACnet primitives
• Must provide abstraction for access to local I/O values and local (proprietary) “functions”
• Must provide a common machine-independent execution environment
• Must allow for scalable resource requirements (small machines with limited resources,scalable to huge machines with lots of resources)
• Must be free of licensing costs for basic intellectual property
• The syntax of the procedural language component should be exactly the same, even if there are   multiple sources for “compilers”.
• There should be standardized ideal glyph definitions in the language, as well as  positional/workflow rules for layout and display and printing of graphic programs.
• It should be possible to fully document code in-place and carry that along with the source
• Core features must be in Open Documents, meaning in a public domain document that is freely accessible, and free of licensing and usage fees. Presumably the language forms, syntax, and rules, as well as the intermediate code encoding, as well as virtual machine environment definition, would all be open documents.
• Must have a Test Reference that verifies tool performance based on a known test program that should produce a known intermediate form.
  

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.