November 2011
Column
AutomatedBuildings.com

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


What "Open" might mean
One piece of the larger open puzzle is the present restrictions around proprietary control languages.

Ken Sinclair, AutomatedBuildings.com
Publisher

Published
Energy Management Canada


Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

Several discussions by many in the building automation industry on what “Open” might mean have created a lot of new interest.

Our online magazine AutomatedBuildings.com is definitely open and we invite you to share your thoughts on what open means to you and how we might best achieve an open industry.

We have provided links to several months of discussions on several LinkedIn groups plus articles on our web site in Our Open Control Language Discussions tab.

Many vendors of automation systems may think that they can ignore these and other open discussions but the problem with that is our present place in time and technology allows others to make a business out of opening up their systems. Experienced enabled Owner Operators of these non-open systems are literally taking control to open these systems to provide the required anywhereness with access to online analytics and continuous optimizing web services. Old style proprietary systems with restrictive access find themselves running on virtual machines to increase their anywhereness and accessibility. This of course is a band aid but provides a guerrilla warfare solution to bringing legacy systems forward when vendor does not. Protocol convertors and other approaches provided by several solution providers provide work arounds vendor restrictions opening their information to all. If vendor does not provide a solution others will. Another trend in the industry is for vendors to provide solutions for other vendors systems that have become islands in the stream of openness. Openness touches and exposes everyone.

One piece of the larger open puzzle is the present restrictions around proprietary control languages.

The problem is that building automation vendors only allow changes to their internal control languages using their proprietary software. Just because they all use BACnet or Lon has no effect on the access to the control language which controls the relationship of how the open standards interact.

This article starts a call to define what the Open Programing piece might look like.
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.

“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.”

The open explosion is waiting to happen for building automation programming.

This article touches on the reasons for open.
Compelling Reasons for Common Programming Language (CPL)
Do you have any? - Winston Hetherington, owner, B.A.S.S. Consulting Services.

[an error occurred while processing this directive] “What would make you think seriously about going to a Common Programming Language (CPL). As an Owner Operator Representative (OOR) responsible for maintaining multiple buildings or campus, would you be enthused by the thought of having all of your building automation systems (BAS) controllers use the same control application logic? Or graphic programming that is easier to use? No more dealing with legacy scripting or unintelligible code, presently in various products. Fantasy or reality?

For those who may presently be burdened by a similar responsibility but also facing issues of obtaining and retaining the additional technology and knowledge skills to maintain five or more different BAS products, each with their own proprietary implementation of Control Application Logic (CAL), CPL might seem like wishful thinking.

Obviously technologists/technicians working as OORs require a different skill set from those working for contractors or manufacturers. The OOR personnel have the added responsibility of meeting owner’s expectations and the overall performance of the facility they work in. Often they are behind in their training for new products and technologies as owners often find training a burdensome cost.”

This article talks about how do we decide which existing open standards to use and why?
Open Systems – Is an Open Protocol Enough?

I do not believe that any one protocol is the secret to success in a building; my personal thoughts are that the secret to success lies in choosing the right protocol for the right part of a building. - Andy Davis, product manager, Siemens Building Technologies.

“Firstly, I do not believe that any one protocol is the secret to success in a building; my personal thoughts are that the secret to success lies in choosing the right protocol for the right part of a building. For example the building management system should be a BACnet client and the main plant systems could utilise BACnet controls, at room level a combination of KNX and DALI (Digital addressable Lighting Interface) would give a flexible and efficient solution. In this solution there may well be MOBDUS or M-Bus integrations for field devices. All these elements should be connected and coordinated to provide a single seamless system to the user.”

***

This is just a sampling of some of opening discussions. None of this is going to change the existing systems we have or even those under installation now, but as new products are created and new players come to the industry they will better understand from our discussions, what we need while embracing our existing standards or replacing them with existing IT standards. As we watch the open anywhere information interaction and control explosion in smart phone and tablet development we know that some of that will fall on us.

Ken Sinclair is the publisher of AutomatedBuildings.com and can be reached at sinclair@automatedbuildings.com.


footer

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

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

Events

Want Ads

Our Sponsors

Resources