Roadmap to Open Programming Language Continued…. This article continues to develop a road map to an open control programming language standard by examining the difference between IEC 61131-3 standard and the proposed open instruction set architecture.

Nirosha Munasinghe MBusIT BSc BE (Hons) (Melb) Product Development Manager, Open General  Contributing Editor

Articles

Interviews

Releases

New Products

Reviews

Editorial

Events

Sponsors

Site Search

Newsletters

Archives

Past Issues

Home

Editors

eDucation

Training

Links

Software

Subscribe

Embracing change in control programming languages created a plethora of discussions among the who’s who of the BAS industry last month. The discussions indicated the resistance against change in the BAS industry and the past attempts to open up the control programming paradigm by the  IEC 61131-3 standard. This article continues to develop a road map to an open control programming language standard by examining the difference between IEC 61131-3 standard and the proposed open instruction set architecture. It also outlines the socio cultural issues behind the open control language in the BAS industry.

The articles referenced above:
The Past and Future of Control Languages
Roadmap for Control Programming Language Evolution   Part 1

IEC-61131-3 is the first vendor independent standard programming language for industrial automation. It provides multiple language support for control programming, allowing the user to select the best language that is best suited to a particular task or user preference. The standard is also hardware independent increasing level of software reusability. IEC-61131-3 as defined suits the following five PLC programming languages:

The user selects the language and the hardware supports the interpretation of the language. Building automation supports similar languages but the implementation is closed to each vendor. For example many BAS vendors support structured text languages. Although the syntax may look similar at a user level, the interpretation of the complied output is different from vendor to vendor.  Therefore the BAS industry requires a similar standard to IEC-61131-3 to further open up the industry.

How different is the “Open Instruction Set” road map suggested in last month article to IEC-61131-3? The primary difference is that IEC-61131-3 defines the five different programming languages and its syntax and taxonomies. The manufacturers user interface must fit to these languages and its respective rules to comply with the standard. The open instruction set proposal does not define the programming language. It only defines a standard for the output of the programming language, which is transferred to the devices to interpret. Therefore the BAS manufacturers can choose any programming language style to match their customer preference, but once the program is parsed and compiled, it must be converted to the open instruction set. The following diagram illustrates the general flow of the BAS program from the time user programs using a user interface to final interpretation from the device.

In open instruction architecture the program is parsed to open instruction set and every device which supports the standard, has an interpreting engine to execute the program.

How do we implement such architecture? Not a simple task. The BAS industry is evolving significantly with energy management paradigms and the requirements to develop complex programs are required. Ten years ago, a BAS system contained simple programs for fan coil unit, air handling unit, chiller and boiler. Now, there is a requirement for many energy saving strategies, which means the standard program from ten years ago must be re-written to implement the changes. More complex algorithms need to be implemented via the programming language. Therefore greater thought and research must be conducted as to what exactly is required in a BAS programming language. It needs to be simple as possible but needs the flexibility to cover the current requirements and evolve in the future.

How do we move forward? An existing BAS manufacturer or a body formed with representatives from many BAS manufacturers neesd to initiate the removal of barriers to form the architecture. The following is an example of a road map the body can follow to develop an open architecture for a control programming language.

What are the barriers? The fundamental barrier is the resistance to change. Currently, the only method a BAS vendor can lock them self into a large site is via the programming language. The BAS vendor’s proprietary software is required to change any program. An open control language environment will truly open up the BAS industry. Many BAS vendors prefer the perception of truly being open, while maintaining some kind of proprietary components to maintain a barrier of entry of other vendors to the site. In the suggested open instruction set architecture, the BAS vendor still can maintain a sound competitive advantage. The architecture does not have a set user interface for the programming language as long as the output of the language is converted to the instruction set. Therefore, it will be up to the BAS vendor to define the actual user interface for the programming language, whether it will be graphical, structured, text, XML, C, JAVA or multiple combinations.  Every BAS vendor will have a different user interface. It will be up to the BAS vendor to complete the market research and develop the user interface to capture the market. The open instruction set will be hidden on an abstract layer from the user interface. Therefore the user interface will be the key feature to winning the market. The BAS vendor with an easy to use, yet flexible programming user interface, can capture the market to gain a competitive advantage.