BTL Mark: Resolve interoperability issues & increase buyer confidence
“The Past and Future of Control Languages”
A call to the industry to speed their evolution to
Comments by Ken Sinclair
This article is not done and may
never be. I invite the industry
to interact and give me their take on the future of control languages
with articles, emailed comments and interactions with our Linkedin
group and other on line blogs. We are an industry in
transition and must all do our part to speed our evolution.
When the industry tells me of my errors and omissions and general
misconceptions I will rewrite this article with linkage to their input, but in the
meantime, I will see if I can do what I do well, be a catalysis
for change in the industry.
I do not bring change to the industry, but I have been successful over the years at increasing the rate of change in our industry, which is sadly needed. Good thing I am the publisher because a half written article requesting input like this would never get published.
One of the advantages of being in the large Automated Building Direct Digital Control industry for five decades is you get to see a lot of change. But sometimes such as in the area of control languages I have seen very little change.
Why do we need change?
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
This creates a problem when global strategies are implemented such as DR Demand Response. These global implementations not only involves all of the vendors' proprietary control languages but all of their installing partners who have written the strategies. In the example of a large university or other 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 talking at this year's ConnectivityWeek about that in the light of open ADR standards, there is need for an online control language generator for an online generic control language for all vendors. In that 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 langauge information and linkage 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
detail drill down the hyperlinks for years of evolution and
A linked overview and table of contents of the subject matter covered in this article.
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 Markup 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
Who provides a control language at the device and the network system level?
Today and future Control Language deployment
Progress to date
Roadmap for Control Programming Language
Quick history on the development of control languages
I worked with British Columbia Building Corporation and Tom Hartman to help develop an Operator Control Language "OCL" specification back in the early 1980s This is the OCL section of the original BCBC online manual still online:
Tom got it documented in 1989 and it is still online
Tom's OCL Manual
It was fashioned after control basic if, then, else, structure.
The concepts started to evolve in the mid 1970 out of the University of Alberta's first DDC Remote Monitoring and Control System "RMCS" system that I worked on which used on DEC computers and Modcom DDC panels borrowed from the cement plants of the day,
MCC Powers who eventually became Siemens after several buy outs used a lot of what we developed at U OF A on the DEC PDP 11s and introduced Powers Process Control Language (PPCL) This was the language we used as a model in the beginning except originally it ran only on DEC PDP11 and had to be compiled but then they modified and made it interpretive instead of compiled for their first ever Stand Alone Control unit the SCU using new microprocessor technology.
The SCU was one of the first DDC Stand Alone Panels SAP.
We generally liked the structure and at the time Andover was giving us drum programing while others provided menu driven control language programs and some new graphical program abortions. Everyone was learning it was a mess. The battle was on between compiled and interpretive.
Note: Definition for interpretive language: In computer programming, an interpreted language is a programming language in which programs are 'indirectly' executed ("interpreted") by an interpreter program. This can be contrasted with a compiled language which is converted into machine code and then 'directly' executed by the host CPU.
We determined that the control langrage OCL must be interpretive not complied, because if it was compiled incorrectly no one knew. This was a common problem of early DDC systems.
Although we did not convince the complete industry that OCL was the way to go we did split the industry into two camps. The If then else OCL camp and the graphic programming camp. The graphic programming was an easier sell to those who did not program but had difficulties documenting the complex relationships that we were developing in our dynamic control strategies.
Echelon has its own generic control language that is also transported by LonTalk. For LonTalk devices to be interoperable, even using Echelon's language, there has to be agreement among implementers as to what the generic messages mean in a particular context. To obtain such agreements, Echelon has set up the LonMark Program, which has working groups, made up of people from each industry, trying to reach implementers' agreements on how to use Echelon's proprietary control language in a common way for their applications.
The point is that the BACnet language and the Echelon language are fundamentally different, and devices using one of the languages can never interoperate directly with devices using the other.
Ok I have said too much, but have a lot more useless information about the development of control languages should anyone be interested.
John Petze now of Skyfoundry adds this;
wrote this (with Sajaad) after looking at what Tom Hartman had done and
seeing a need for a control system to be based on a commercially
available programming language from the computer industry:
"An Industry Standard Language for DDC Systems: A Look at the "C" Language". ASHRAE Transactions, Volume 95, Part 1, 1989. Co-author Sajaad Chaudry. Here's a link to download a scanned copy
An Industry Standard Language for DDC Systems.pdf
We implemented this at Teletrol and it was very successful (our whole startegy was to base a BAS on IT industry standards and we created a very powerful system). It resulted in the first BAS system where independent software engineers could actually write extensions to the product (not just custom control sequences). For example, we had people writing communication drivers to other systems in 1989 with an open SDK we provided all based on the standard C Language. 1989 -- wow.
Discussing the evolution of control languages on our web site
This from Jim Butler of Cimetrics
I encourage you to reread our article published 11 years ago in your on-line publication: Java and other Internet technologies have the potential to greatly impact control and monitoring systems
that time we thought that Java could become the open programming
language for building controls, but Tridium was the only company to go
in that direction.
My impression is that the incumbent controls manufacturers have little interest in abandoning their proprietary programming languages. The cost of switching would be very high. As with BACnet, change is likely to start with the small companies and new market entrants who have little to lose and something to gain by being more “open”.
article is out of date in a number of ways. For example, if I
were to write such an article today, it would be necessary to consider
alternatives to Java such as Python. But it is interesting that
Android, which is Google’s open platform for smart phones, has an SDK
for Java (see
Any open programming language would need to have some libraries for common building control tasks and access to hardware resources (e.g. I/O). Those libraries could be provided by the controls manufacturer, or they could be supplied by third parties.
Regards, - Jim Butler
Richard Desmarais VP Engineering Teletrol Systems Inc. wrote this in May 2000
XML (extensible Markup Language) is emerging as the standard language for data exchange in many business sectors, including building automation.
Bits of Evolution to date
Most kids today under 30, or even 40 do not know what control basic is or even was and cannot imagine why those old guys still use an obsolete language like OCL. They work with web based languages that are quick to build and are very easy to develop complex applications because they have libraries of functional pieces.
The reason for the original OCL no longer exists. The operators do not write the control code now and have not for the last five to ten years, but the industry has just forgotten to change because our industry never changes. OCL was a transition from the days when operators got to plug pneumatic lines together so they were the programmer of how the HVAC system worked. Also enabling and empowering the operators was a large part philosophy in early days at BCBC so it got reflected in the product they requested the industry to produce.
DDC is now often supplied as an integral part of HVAC equipment and comes
with self-learning and rule based logic. Equipment integral controls must be
self-healing, while protecting and report the performance of equipment.
In 2002 Eric Craton of ALC, well before Carrier took over, told us that web services would change everything. How did he know that back then? ALC was early into how this may all play out. What's needed is a unified system model, in XML, that can be used by any building automation protocol.
The Marriage of the Web Services Architecture with Building Automation Information Models
Since BACnet and EIB objects and LonMark functional profiles are
information models, and XML is a modeling language, we could express
these high level information models in XML and in so doing make them
compatible with the emerging Web services architecture. Because of the
flexibility of XML and the web services architecture, these high level
models could be expanded to include other types of facility-related
(but not necessarily building automation-related) information. If each
building automation protocol developed its own XML model, however, we
would have similar but incompatible system models. Today's problems of
translating from one protocol to another at the building controller
level would become tomorrow's translation problems at the Web services
level. What's needed is a unified system model, in XML, that can be
used by any building automation protocol.
It should also be mentioned that this push toward Web services architecture should not be interpreted as an end to standard protocols. Web Services are useful as a computer-to-computer or software-application-to-software-application interface, but they are "overkill" as a device-to-device interface. While it might be possible to expose information as XML at a building-controller level, it would not be practical to do so at a zone or unitary-controller level. Web services should be viewed more as a successor to OPC than a replacement for BACnet, EIB, or LON.
At the ASHRAE/AHR Expo show 2003 in Chicago there was unified
acceptance of web-based solutions in addition to a strong acceptance
and connection to the evolving digital office standards, by all
automation hardware and software vendors. From my article
"Identifying the Complex Components of Convergence"
In 2003 Hartman wrote this
Convergence: What Is It, What Will It Mean, And When Will It Happen?" Tom Hartman, Principal, The Hartman Company
So more and more of the industry devices and major equipment is
smarter. We must connect their networks and orchestrate control of
intelligent equipment. Only control, safety and protection of
equipment will occur in the field, optimization will come from the cloud or
enterprise server and it will be web based with self-learning, continuous
commissioning, smart grid, interactions and the “Yet To Be Imagined”
(YTBI – pronounced yittbee) solutions.
From this column by Toby Considine Clouds and Rain comes this wisdom:
For Brandl, nearly everything is a cloud; only the core control processes are on the ground. I think this is right; for buildings, only the core processes, those elements on the traditional low voltage protocols such as BACnet and LON, are on the ground.
Therefore the core control language must be on the ground and closely couple
with DDC control. The optimization of this language will come from web
services in the cloud.
Optimization will no longer be contained in the DDC control language. Optimization and the necessary Interaction will come from complete web services solutions and smart grid interaction from the cloud
The complex dynamic optimizing control coding of the past will be part of actual major equipment control and part web services.
Optimization and the necessary Interaction cannot exist with our existing proprietary control languages but only exist in a mash up of dynamic web services that will provide the results we are looking for.
In this 2009 article from Alper Uzmezler about the new comes these thoughts:
Pure object oriented programming for Building Controls
Since every object is a real life device, programming methodologies will completely change. Every equipment manufacturer will store and build essential algorithms into their devices which will give them an edge over their competitors. For example, a VFD manufacturer will essentially create algorithms that will optimize their PID loops inside their equipment. Damper actuators will have more optimized PID loops based on their communication skills to the cloud.
In this article the security industry struggles with similar issues:
Open Source Physical Security Software Open source software would automatically have built into it open protocols such as SAML (Secure Assertion Markup Language), SPML (Service Provisioning Markup Language), XACML (eXtensible Access Control Markup Language), LDAP (Lightweight Directory Access Protocol) and many other emerging privacy, identity and network standards. - Guy Huntington, Huntington Ventures Ltd
In 2007 we had this interview
Lydon: IEC 61131-3 defines a control software suite of five languages that all work together to meet the needs of any control application. The five languages are Instruction List, Ladder Logic, Function Block, Structured Text, and Sequential Function Chart.
Part 3 of IEC 61131 deals with
programming languages and defines two graphical and two textual PLC
programming language standards
New Tools & Ideas for Buildings 2.0
Bill Lydon, Director PLCopen
Major activities of PLCopen are further developing open controls programming standards, extensions, and certifying products.
In this article
From the Silo to Open Collaborative Facility Internetworks Today we have to anticipate a new kind of network in the facility - The Facility Network. That particular network has to be developed before the building automation subsystem details.
Nino Kurtalj, President, Elma Kurtalj Ltd provides this wisdom:
We see that the key battlefield is in who provides a control language
at the device and the network system level? If the control language is
left exclusively to the single vendor the middleware could just be used
by an existing manufacturer to migrate from a competitor's product to
their platform and the owner will not see a real benefit from an open
We can imagine the differences of the application languages as differences between human languages. For example, most readers will not understand this: "Bunu anlayamıyorum eminim ". In this example, we can read the letters but not understand the meaning of the information! This is usage presentation of the same communication media "written letters", but not the usage of the same application language. More or less the same we see in the automation. The devices could talk over the same media but usage of different application languages is not allowing exchange of the information content between speakers. In most cases the dominant application language will be used as the main language and the other languages will be translated to one common language, these translators are called gateways.
Therefore, after a move from proprietary vendor solutions to the
standard application language solution, the mix and match of the
different vendor devices is possible if they are compliant with the
particular used standard. In the most cases LonWorks, BACnet, and
Modbus from different manufacturers will coexist on the same network
without any problem talking to the same peers: Modbus to Modbus,
LonWorks to LonWorks, BACnet to BACnet. To exchange information between
for example Modbus and BACnet a translator will be needed.
Alper Uzmezler of BAS Services & Graphics, LLC. writes:
We have a lot to learn from the industrial world as far as inter-programmability (a new word I guess) goes. There will be huge demand for it as we move into the smart-grid and demand and response.
From: George Thomas - Actually, I have this book. IEC 1131 is still
not as popular in the US as it is in Europe. US PLC vendors still
promote their proprietary solutions (primarily ladder logic). One
advantage of ladder logic is that in general an electrician or system
integrator can view someone else’s logic and make sense of it.
The same could be said of Control BASIC.
It has always surprised me that industrial automation folks and building automation folks create an artificial barrier between the two industries when selecting equipment and languages. About 80% of the languages can do each industry’s job but the crossover work is minimal.
My problem with 1131 is that it would be difficult to develop and support because of the number of different views of the logic. If you purchase a 1131 stack, there is usually a runtime license. The other problem is that I do not believe there is a common tool. I think Control BASIC is easier to implement and you can develop custom functions to suit your application. I agree you can do the same with 1131 but the custom blocks are not portable.
More from John Petze
You are taking on a big subject! You and I have discussed this very briefly in the past. I agree it is an important subject. It is a bit esoteric though. So here are some thoughts:
First it is essential to separate the tool that a user will use to define control programming logic from the underlying language that is executed by the controller. We want the industry to have the opportunity to advance usability and come up with interesting new ways to streamline the process of "writing" control sequences. We want competition in this area. We want people to create a better mousetrap. BUT the most value will be derived if these tools act on a standard foundation.
Take web page development as an analogy -- there are some really cool software packages out there to author html pages and web sites. But under the covers these tools are all generating standard html that can read by standard web browsers. Pretty simple and effective.
What we need is a similar model for control sequence programming. So if we agree that we want the benefit of competitive development of GUI tools to provide users with choice in the user experience, the real question is what is the underlying control framework/application layer.
At this point taking a look at IEC 1131 is very useful. It has been mentioned briefly in the discussion but I think people may benefit from a more complete overview. Here is my quick summary and demonstrates the strong analogy. Here's a brief description from Rockwell:
"Developed with the input of vendors, end-users and academics, IEC 1131 is the international standard for programmable controller programming languages. As such, it specifies the syntax, semantics and display for the following suite of PLC programming languages:
• Ladder diagram (LD)
• Sequential Function Charts (SFC)
• Function Block Diagram (FBD)
• Structured Text (ST)
• Instruction List (IL)
One of the primary benefits of the
standard is that it allows multiple languages to be used within the
same programmable controller. This allows the program developer to
select the language best suited to each particular task. An analogy is
that a mechanic wouldn't attempt to repair an automobile using only a
screwdriver. The mechanic has a variety of tools available and chooses
the best one for each task."
The concept was that if controller products support IEC-1131, then multiple tools could be used to define control sequences. So if I am more comfortable with block programming I can use that, and you can use ladder logic. Programming tools are open to competitive development so the field can continue to advance and people can choose their favorite. The comparison to 1131 is helpful, but 1131 doesn't actually specify any implementation -- it is a paper standard which a number of manufacturers have adopted. You would need to get an expert on 1131 to comment on far it has moved the industry towards a true standard language that supports portability of control sequences and programming via different toolsets.
So now for a connection to the BAS world. The BAS industry has a similar standard control language layer available for use. It is called Sedona. The Sedona Framework is designed to make it easy to build smart, networked embedded devices and it includes a general purpose component oriented programming language very similar to Java or C#. The Sedona language is used to write control sequences and it includes a base library of standard control elements that can be used to build virtually any control sequence desired. The language is decoupled from the tools used to actually create the program. This means that a Sedona-based device could be programmed with a variety of tools allows for reusable, interchangeable programs because under the hood those sequences are built up from standard program elements.
Sedona on the other hand is actual real code available as open source which is designed to be shared, reused and is ready to use. You might want to take a look at the Sedona website: http://sedonadev.org/.
In addition to being openly available software its worth point out that a number of companies are shipping products based on Sedona today. Some I am aware of include infocon: www.infocon-technology.com and Contemporary Controls: http://www.ccontrols.com/basautomation/sedona.htm. Currently Tridium offers a graphical programming tool for Sedona devices, but I believe others are developing similar tools and we will see them available in the market soon.
Like your draft article this information is not the end of the story, but shows that there is a viable path to achieve the goal you are describing and it is based on open source software platform available to all manufacturers at no cost. I believe that Sedona will continue to grow in its impact in the market going forward.
Today and future Control Language deployment
Much of the article talks about what has been done and how we should likely move forward but I think we need to learn from all this history and use
the new tools of web services to build the control language of our
lowest level controllers in several languages.
My shot from the hip; Since we are moving towards tight integration with the web let us follow how the web would solve this problem with their languages and not use the control languages of the commercial or industry control industry. Several of the early articles suggest this.
We need to build a new virtual DDC web appliance that has an online control language that can be programmed by the masses from anywhere with no proprietary software. A truly open DDC appliance that we could add some open standards of connectivity; ie BACnet, Lon. These could be purchased as APPs for controllers as well as other protocols and enhanced functions.
A "Web appliance," is a device specialized for Web browsing. Today's Internet appliances are smartphones and handheld wireless devices such as the iPod touch or android devices.
The direction of control language development includes the ability to program any device without special tools. The web browser is the programming tool of choice. As long as it builds with a web browser who cares how? Even complied or interpretive is not as big an issue as it was. Networks now work, back then they did not. Maybe it is even time to revisit block text programming as the browser would present us with various scenarios and we would simply choose and the funny code generated would be sent to the low level controller.
All smart equipment must have a networkable smartphone like a DDC device with an operating system and control language that can be created and downloaded from a browser. Web mash ups will be able to access the control language and optimize and even replace low level controller programming. For openADR and other smart grid and smart community relationships automation network will be connected to internet. In the future major equipment will be automatically connected via cell network so manufacturer can start up, set up, and protect their equipment remotely independent of community network. Large devices will check with factory profile to insure correct operation and performance. Smart equipment in the future will work like a Kindle with 3G and 4G internet connection independent of the community network. If a battery is supplied as part of a half a million dollar chiller the factory will not only know where the chiller is during delivery, but if it has been exposed to low or high temperatures, voltages, or otherwise tampered with the factory will know. They would likely have a vibration monitor to see if it has been dropped, when and by whom.
Progress to date
Look at how this works. A wall plug becomes a web appliance.
To get started, simply plug the modlet into an existing electric outlet and plug your appliances into it. Then use your web browser to wirelessly monitor and manage your power consumption.
What is hardware is little and what is software/webware is big and who cares how it works as long as it does http://www.automatedbuildings.com/news/jul11/articles/thinkeco/110627025707thinkeco.html
ecobee, http://www.ecobee.com/ the award-winning green technology company, has released a new iPhone and iPod touch app for the ecobee Smart Thermostat. The new application, which is free of charge, further distinguishes the ecobee Smart Thermostat from other programmable thermostats on the market.
This article is not done and may
never be. I invite the industry to interact and give me their
take on the future of control languages with their articles, emailed
comments, and interactions with our Linkedin group and other on line
blogs. We have all fallen on an industry in transition and must do our
part to speed our own evolution.
[Home Page] [The
Automator] [About] [Subscribe
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]