BACnet lock-in and the program object (16)

The BACnet marketing

You are in the HVAC business and trying to sell some BACnet devices. How will you market your product? Well, you’ll probably talk about how this protocol protect the user from being victim of a vendor lock-in.

Switching manufacturer

How wonderful! You can tell the customer how easy it will be for him to switch to another company if you ever let him down! But will it be so easy? Besides the various BACnet variants that might be a compatibility problem, what could be a kick in the teeth? Let’s make a quick check list of what you need in order to perform a vendor transfer:

  • Access to the controller I/Os? Yes;
  • Access the trend logs? Yes;
  • Access to alarms? Yes;
  • Access to the programs? NO!

Wait what? So the user can access every I/Os in the building, but can’t change his system behaviour. So, besides monitoring, what can he do?

“Sure, you can reprogram your controllers, but you’ll need to use our closed source interface application in order to change anything in your programs. We will gladly let you buy one for the modest amount of <insert stupid locked-in price>$ and your soul for eternity.”

This, my friends, is a lock-in.

It is also the moral fight that the Free Software Foundation and the open source projects under the GNU licence are trying to win. You should not be a slave of your programs (nor should your clients).

Priority is power

Not only can’t the user change the programs, he is most likely to be unable to change the programs priorities. This means that even if the user were to try to do a tug of war with the existing controllers by adding a new one with a whole new program in it, the new commands could be completely ignored! If the old devices have higher priorities than your the new one, it’s game over!

Towards a BACnet language standard?

The obvious solution (but less obvious to implement) is to have a language standard which could be read and edited by everyone. Obviously I would go for a lisp-like language, because I think it’s easier to grasp for the everyman. Anyone who have done primary school mathematics can understand how the parentheses are evaluated.

A language standard, while possible, is highly unlikely. The amount of work and cooperation between the many manufacturers would be non-trivial to say the least. In addition, if the program standard was ill-designed, it could drag down the entire BACnet standard with it.

Plain text program

There is however one little change in the standard that could help greatly. What if the programs were plain text and accessible through the BACnet network? Then every workstation would be able to at least open the program and let the user study it. Bonus point if they can also modify it.

The Program object type defines a standardized object whose properties represent the externally visible characteristics of an application program. In this context, an application program is an abstract representation of a process within a BACnet Device, which is executing a particular body of instructions that act upon a particular collection of data structures. The logic that is embodied in these instructions and the form and content of these data structures are local matters. – BACnet Standard 135-2004

Instead of making the content of the programs “local matters”, it could be a property, such as the description.

I can understand how, when the BACnet draft was elaborated, the controllers couldn’t have hold the plain text version of their programs, but today there’s no excuse.

Towards a truly open solution!

One response to “BACnet lock-in and the program object (16)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: