November 2011 |
[an error occurred while processing this directive] |
What "Open" might mean One piece of the larger open puzzle is the present restrictions around proprietary control languages. |
Ken
Sinclair, AutomatedBuildings.com |
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.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]