September 2011 |
[an error occurred while processing this directive] |
Embracing Change
Are we embracing the necessary changes enthusiastically and fast enough to keep control of our industry? |
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] |
Column
- August 9, 2011 - I am using
embracing in its second sense to
“accept or support (a belief, theory, or change) willingly and
enthusiastically”. As they say the only “constant is change” and this
has never been truer than now in our industry. Our Building Automation
industry has become very visible anywhere and a very large part of
today's web services and smart grid.
But are we embracing the necessary changes enthusiastically and fast
enough to keep control of our industry? If we do not evolve and morph
fast enough others will take our opportunities because they better
understand the tools of change and not because they better understand
our industry.
In this article I attempted to hurry the industry “The Past and Future
of Control Languages” with a call to speed the evolution to open
protocol for control languages. One advantage of being in the large
Automated Building Direct Digital Control industry for five decades is
you get to see a lot of change. But in other areas, such as control
languages, I have seen very little change in the last five decades.
Why do we need change?
The problem as I see it is that all large 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 creates a problem when global strategies are implemented, such as
DR Demand Response. These global implementations not only involve all
of the vendors’ proprietary control languages but all of their
installing partners who have written the strategies as well. In the
example of a large university or another campus this could be many. The
problem is reduced when an owner takes over control of all his vendors'
systems with his own or contracted super operators but this person now
has to manage the myriad of various control languages which can be a
mixture of if then else logic and graphical programming.
We were discussing that at this year's ConnectivityWeek in the light of
open ADR standards and how there is a need for an online control
language generator for an online generic control language for all
vendors. In this scenario, the language would interact with
standardized ADR commands which would cross over many vendors' control
languages. New interactions required by smart grid and web services are
rapidly changing what is expected of a DDC system control language.
What is old is now new again, and web protocol has to be an integral
part of the control language and the language must be able to be built
generically with a web browser.
This article quickly got very large, but I am pleased to have the start
of the assembly of several views on control language information and
links to many articles, all in one spot. I hope the table of contents
below will allow you to quickly review the large amount of information.
If you do not have time to read the complete article, just read the
table of contents and you will have the gist of the issues involved.
For more information drill down the hyperlinks for years of evolution
and knowledge.
Table of contents of the subject matter covered in this article “The Past and Future
of Control Languages”:
• Quick history on the development of control languages
• An Industry Standard Language for DDC Systems: A Look at the "C"
Language
• Java could become the open programming language for building controls
• XML (extensible Mark-up Language) is emerging as the standard
language
• Web Services Architecture with Building Automation Information Models
• Every control system manufacturer has its own control language
• Optimization will no longer be contained in the DDC control language
• Pure object oriented programming for Building Controls
• IEC 61131-3 defines a control software suite of five languages
• Who provides a control language at the device and the network system
level?
• Today and future Control Language deployment
• Progress to date
A great response in this article, Roadmap for Control Programming
Language Evolution - Nirosha Munasinghe, product development
manager of
Open General:
“Standards
have evolved and driven the BAS industry over the last
decade. They have provided a path for interoperability, multivendor
integration and more importantly, a plethora of choices to the end
user. The days of a BAS manufacturer implementing proprietary systems
are gone. Vendors with a legacy system have at least a gateway to
translate the proprietary protocol to an open protocol to compete in
the market. The key component missing in the open standard evolution
has been the control programming language. At present every vendor has
its own programming language for its BAS products and uses private
services in open protocol to communicate to the end devices. This
article examines what is a control programming language, the use of it
in the present markets and a roadmap for the future.”
[an error occurred while processing this directive]
In this article Embracing
Change - Bob Wallace, president of Building Clouds, LLC:
The system
enables open selection while extending typical localized
user control and management to the Internet and devices we use daily to
manage our business operations. Some of the benefits are listed below:
• Anywhere
anytime access, Extending system software life
• Helpdesk
support, Allows for budgeted migrations
• Provides
options for upgrade paths, Minimize “End of life” risk
• Portfolio
Wide Energy Management, Historical data reporting
• Provides a
common user interface, Constant Commissioning
• 3rd Party M
& V services, Cost recovery services
• Advanced
alarms management, Automated email and SMS Alerts
This interview; Energy Monitoring and Management also embraces
significant change. Richard Theron, national sales manager of
FieldServer Technologies:
EnergyWise is
an innovative architecture built into Cisco switches and
routers enabling access for monitoring, reporting and reducing energy
consumption across an entire corporate or institution infrastructure.
Cisco EnergyWise enables the utilization of the network as the platform
for energy command and control. IT networks using Cisco switches and
routers are able to discover Cisco EnergyWise manageable devices,
enabling energy management systems to monitor their power consumption
and take action based on business rules to reduce power consumption
while ensuring continued business productivity. Many devices including
IP phones, computers, laptops, VDI terminals and PDU’s have access to
the Cisco EnergyWise domain and are part of the network.”
As you can see
change is here to stay so let us all get involved and Embrace it.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]