Open Programming Language for Building Automation If you buy-in to systems that are proprietary, you also buy-in to a restricted source of humans with the expertise to provide those services. This means that owners and consultants are locked-out of making on-going changes and improvements, not to mention future vendors.

David Fisher, President, PolarSoft® Member ASHRAE, BACnet Lecturer,Co-chair, BACnet International Education Committee

Articles

Interviews

Releases

New Products

Reviews

Editorial

Events

Sponsors

Site Search

Newsletters

Archives

Past Issues

Home

Editors

eDucation

Training

Links

Software

Subscribe

The time has come to enable explosive growth in Building Automation by standardizing the way that BAS control programming is done. There, we’ve said it. It no longer has to be the shameful secret. Let’s take this idea out in the open and talk about how to do it, what’s important, what concerns we may have and really see if this makes sense.

The last two decades have seen monumental changes in the way that we look at Building Automation, and indeed in its best practices. In what is arguably one of the most proprietary industries, there has been a long, and in some cases bitter, battle between proprietary approaches to BAS communications and so-called “open communications.” Today that issue is mostly settled in that there are now International Standards, very widely implemented, with millions of devices that successfully interoperate every day. By any measure, the worldwide market for BAS is growing, as are the number and types of devices, and areas of application. Owners and specifiers want more selection and capabilities, vendors are responding with innovative products. Prices have not collapsed. Despite the generally depressed economy, development and investment in new BAS products is at an all-time high. This is all good.

But there are some things holding us back, preventing the growth that is possible. This isn’t new. History is full of clear lessons that are often ignored (and therefore repeated again and again). Fear, Uncertainty and Doubt (FUD) remain strong, but look at the evidence. People fought against decentralized automation for decades and yet today, nearly every BAS is mostly decentralized. People fought against direct digital control (DDC) claiming it couldn’t work and would cost too much, and yet today virtually every BAS control system is DDC-based. People fought against the idea of using a standardized and open communication between BAS devices and the concept of inter-vendor and inter-discipline interoperability, and yet today most systems have abandoned proprietary communications in favor of a very small number of standardized technologies, such as BACnet. Why not make a concerted effort to standardize the way that BAS is programmed and controlled?

Standard control programming methods are going to occur, and must for simple economic reasons. Cost and maintainability is the driving factor. It takes human labor to do automation programming. If you buy-in to systems that are proprietary, you also buy-in to a restricted source of humans with the expertise to provide those services. This means that owners and consultants are locked-out of making on-going changes and improvements, not to mention future vendors. This also means that vendors must take on support and training of customers, technicians and developers with no leverage from standardization. This increases their costs, and those costs are passed on to customers.

If history is any indicator, it’s likely that people will fight this idea due to FUD and other factors. That's too bad because there is a lot of benefit and money to be made and enormous benefits to all concerned, available much sooner, if they agree rather than fight.

How Do We Make This Happen?
Obviously there are many details to be discussed and agreed upon. But what I’m talking about here is what the process should be for having discussions and moving forward. Recently we’ve had a lively set of discussions in several online forums about these topics. One of the things that’s abundantly clear is that there is a lot of interest, especially on the consuming side, in having standardization for programming. What that really means is itself a valid discussion topic. Many consumers and at least some vendors have been vocal about timeframe. It seems a little premature to talk about how long something will take before we have agreed on what that thing is, but the sentiment and concern is that we have watched a number of standards-making processes proceed at a very slow pace. Indeed, one seasoned participant described these as “multi-decade, career-consuming hurdle(s)”.

What I’d like to see is a voluntary, totally open and transparent process. Anyone who wants to participate should be able to. No fees to join, no fees to make use of the intellectual work product. A consensus based organization to prevent mob rule with a democratic (one vote per organization) super majority process. Rotating leadership with one year limits. This would preserve a lot of the good features of an ASHRAE SPC-like process without the limitations of delay-producing review and comment response cycles that are frequently abused. It would be a free organization unlike OASIS-style pay-for-play which is dominated by large companies.

What Ideas and Requirements are Important?
The devil is in the details and even if there is general agreement that programming should be open, how it becomes open, and what form it takes and many other questions may not be easy to agree on.  Just to get the melee started, here are a few topics that come to mind:

What Kind Of Language is Best?
Procedural programming, graphical programming, ladder logic, function block, etc. There are advocates on all sides. The existing standard IEC 61311-3, and now IEC 61499, concept of having multiple creation styles and a common intermediate object code is a strong idea. However, this standard has had limited traction in BAS. I think the reason for this is that it’s too complicated. If we look at existing proprietary approaches that are popular and common in BAS, they really fall into two camps: procedural programming and graphic programming. In my view the best approach would allow you to use either technique, which is compiled into an intermediate form and can be decompiled back into either source form. So if I write a procedural program, you can look at it graphically and vice versa.

The idea of having a common intermediate form is critical to the bidirectionality for program sources and also to having a common machine-independent execution environment.

Execution Platform
In order to be successful and portable across many products, the language needs to be based on a virtual machine model that is implemented for each specific kind of controller or device. So it needs to provide a base set of capabilities that must be supported in every implementation, as well as abstraction of device-specific resources like timing, memory, local I/O etc. There are some existing virtual machine approaches such as Java and Sedona that work this way. One of the big debates is going to be that advocates of these approaches will want them to be used as the standard. In my view, this may be problematic. There are several criteria that any approach has to provide:

1. The footprint in terms of RAM and FLASH memory must be small, or at least small for the base requirements version. Current 1-2MB and larger requirements are simply too much for small controllers that represent the majority of target devices for programmability
2. The virtual machine must be free of licensing restrictions and cost. If I design my own VM, it should be free (except for my time of course). It would be nice to see an Open Source implementation available that is free for commercial use. Of course I can license a VM from someone for a fee.
3. The standard should specifically prohibit proprietary encoding so that the same intermediate binary code will run on any platform with similar I/O capabilities.
4. The VM should natively understand BACnet as the fundamental model for objects and actions. Vendors that want to continue to use LonTalk-based devices could offer built-in gateway style mapping.

Some vendors won’t like these ideas. They’ll want to be able to compile into a “faster/smaller” encoding that only their platforms can run (thus locking-in the customer). They’ll want to do this also to “protect” the intellectual property of their control algorithms. This will be a key point in the debate since they’ll want to have some method where they can encapsulate proprietary control features into some function block that can be used in the control programs, but whose contents are not visible to the end user (or competitor). I don’t think that consumers will be happy with coffee cups that can be used with any kind of coffee but only take proprietary cream or sugar. Vendors that are invested in LonTalk in its various forms won’t like a BACnet-centric model.

Toolset
It’s been suggested that not only should the language be standardized, but also the toolset. This is going to generate a fierce debate again because of existing investments. I’ll admit to being partly on the fence about this. On the one hand, the syntax of the procedural language component should be exactly the same, even if there are multiple sources for “compilers”. Again it would be nice if there were Open Source implementations of compiler/decompiler tools for the procedural language.

On the graphic language side, I think it would defeat the purpose if there was a different look to glyphs representing standard functions from one tool to the next. Having said that, like playing cards it should be obvious looking at a glyph which standard function it represents, even if there are stylistic or artistic differences from tool to tool. I could live with that. Again 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. An Open Source implementation of a graphic tool would be nice.

One often overlooked aspect of BAS programming is program documentation. It should be possible to fully document code in-place and carry that along with the source, though obviously not with the binary intermediate form.

Open vs Open Source
In this discussion, open means defined 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.

As I’ve said, the selfish part of me would like there to be Open Source programs available, for example as Source Forge projects, that would provide tools for compiling, decompiling, graphic editing and maybe even debugging. Whether there is motivation to invest time in making such programs remains to be seen, but some may be interested in undertaking those tasks for various reasons.

I can imagine a hearty market for third party implementations that are available in binary executable form for free or for a fee.

Verification and Testing
Although we could create a testing agency similar to BTL, it may be faster and more productive to invest that time into test suites that verify tool performance based on a known test program that should produce a known intermediate form.

Training, Learning, Simulation
One of the best suggestions that have come from private discussions is that whatever language and tools are developed, it would be extremely helpful to have a training/learning sandbox tool that can simulate the execution and debugging of these programs. This would serve to familiarize new users with the language as well as providing a common and standard method of testing programs in isolation.

Parting Thoughts
There is a lot more to say on these topics of course. For now, I just want to start the conversation and see what it leads to.

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.