BTL Mark: Resolve interoperability issues & increase buyer confidence
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.
Member ASHRAE, BACnet Lecturer,Co-chair, BACnet International Education Committee
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.
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:
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
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.
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 (firstname.lastname@example.org) 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.
[Home Page] [The
Automator] [About] [Subscribe
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]