September 2011
Column
AutomatedBuildings.com

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


Embracing Change

Are we embracing the necessary changes enthusiastically and fast enough to keep control of our industry?

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]

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.

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