AutomatedBuildings.com Article - “The Past and Future of Control Languages”

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.

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 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 knowledge.

A linked overview and table of contents of the subject matter covered in this article.

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:
http://www.accommodationandrealestate.gov.bc.ca/Doing_Business_With_Us/Technical_Manuals/files/ccs/2_3/3_0.html#3_9

Tom got it documented in 1989 and it is still online

Tom's OCL Manual
http://www.hartmanco.com/innovate/ddc/ocl.htm
http://www.hartmanco.com/pdf/ocl2_2.pdf

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.

I 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.

Hello Ken,

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

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

Our 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 http://developer.android.com/guide/basics/what-is-android.html).

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

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.

[an error occurred while processing this directive] 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.

As an example, consider how controls are now programmed. Every control system manufacturer has its own method of programming control sequences into their product - it's the product's control language. Some are better than others, and some manufacturers are rightly proud of the functionality and ease of use of their control language. But one huge drawback is associated with every single one of them. They are all proprietary! In order to make any changes, either a specially trained technician from the local representative must be hired, or the user must try to train his own staff. All of this is enormously expensive compared to the cost to use more standard languages, even though such languages may not contain the same features as these proprietary languages. So clients want my firm to select products that employ standard programming languages that may be more flexible than what is available in building control systems today, and are based on standard languages. This way they can hire individuals or firms that have knowledge in this language (as well as others they employ for their network) such that as much as possible of the integration of the building controls into their overall business network can be accomplished by firms other than the controls subcontractor who tends to be rather narrowly focused on building controls. This is a reasonable request that is very difficult to satisfy at present, but the demand will only grow in time.

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:

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.

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 system.

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.

At the device level, we can assume there are two types of devices - programmable and pre-programmed. Common programming environment (language) for programming of programmable devices is an additional request at the network level to the application language. The existing (International Electrotechnical Commission) IEC 61131-3 programming environment is used by a lot of vendors as a control language within the device. Pre-programmed devices are the ones which will be just commissioned to the network. The commissioning process is basically the creation of the automation M2M ECO system. It is a process of building the system scope and environment. As commissioned all devices are aware with whom they have to exchange information.

Check IEC 1131-3 and IEC 61499 but in the industrial controls world, they agreed on a standard where they can convert the code to any type. Basic, Ladder Logic, Block logic giving the flexibility for programmer to change at will.

http://books.google.com/books/about/Programming_industrial_control_systems_u.html?id=sc-g9k6dPzMC

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.

Hi Ken,

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.

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.

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.

Events	Want Ads
Our Sponsors	Resources