Roadmap for Control Programming Language Evolution A roadmap towards an open control programming language is to define an open instruction set for a  control device to interpret.

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

Standards have evolved and driven the BAS industry over the last decade. They have provided a path for interoperability, multi vendor 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.

The control programming language is the key feature which allows the flexibility to the run sequence of instructions in a device. It allows the system integrator or the end user to control the behaviour of each device. An air handling unit is operated generally the same but there is always a variance from project to project. The control programming language is used to differentiate the operation. Therefore the programming language is a key component in a BAS system and should be a key consideration when choosing a BAS vendor.

The history of the control programming language has evolved from computer programming languages such as BASIC. The fundamental criteria of the language has been to keep it simple as there are various stakeholders in the BAS value chain. Consultants, engineers, service technicians, electricians etc... are all part the value chain, hence large discrepancies in the knowledge pool. Therefore control languages are implemented using logic statements. For example a typical syntax of the language follows:

In the example, if the schedule is active, the fan turns on, otherwise the fan is off. The programming jumps between lines using the Goto statements. More importantly it is very simple to understand. Any person who can understand English can interpret the piece of code to make logical operation of the mechanical device.

The next evolution in the BAS industry has been to add another graphical layer to hide the coding abstraction level. Therefore instead of the operator coding with text syntax, they can use graphical symbols to form the same logic. It is visual to the operator and psychologically it seems easier for the operator to program the device. The chances of syntax errors in a text based programming environment are eliminated and for some, it makes it easier to visualise what they are trying to achieve.

Figure 2: Graphical programming environment

[an error occurred while processing this directive]Is graphical programming language better than a text based programming language or vice versa? This is the million dollar question asked by many at AHR tradeshows from BAS vendors; Do you support graphical or a text based programming environment? There is no correct answer to this. The type of programming environment depends on the knowledge of the person, the computer programming languages they are familiar with and what they are trying to achieve.  Generally, if the operator is programming simple mechanical devices such as fan coil units, roof top units and variable air volume units with simple logic, it is easier to use the graphical environment.  When programming devices such as complex chiller logic, the text based language is better as the operator has more flexibility and control of the language. Also, it is noted that people with computer programming languages prefer to use text based language and people who are new to programming or do not have a programming language background prefer the graphical programming environment.  The visual sense is perceived to be easier to program, however this is not always the case.

How is the control language implemented in the device? Control language is an interpretive language where the device executes instruction set command actions. The general hierarchy of the  programming language in a BAS system is as follows:

1. The operator defines the required logic in either a text or graphical programming environment.
   
2. The BAS vendor defines the syntax for the programming language and checks, if there are syntax errors, they are reported back to the operator.
3. If there are no syntax errors, the piece of code is parsed into an instruction set defined by the BAS vendor.
4. The instruction set is communicated via the protocol to the end device, which is required to interpret and execute the logic.  The current open protocols do not define a particular service for programming language communication, therefore use a private service.
5. The end device has a engine which interprets the instruction set to execute the actions.

The key point in the above procedure is that the BAS vendor defines the instruction set. Therefore, for each vendor the programming language execution is different. Every vendor can have the IF .... THEN .. ELSE type of language but if the parsed instruction set is closed, then the end device from one vendor cannot understand another vendor's programming language. It is one of the few areas in the BAS industry that we have failed to make major improvements and a key feature which differentiates the current open protocol vendors.  It is also a key misunderstanding of the end users of the open protocol evolution. Many still have the perception that  a BAS vendor supporting an open protocol implies the programming language component is open as well.

A roadmap towards an open control programming language is to define an open instruction set for a  control device to interpret. The instruction set uses short mnemonics to represent the fundamental operations. It contains the bit definitions for conditional and unconditional branches, operation codes, function calls and returns etc... All typical operations required in a typical BAS environment should be defined. Then the open instruction set is downloaded to the control device and it has the engine to interpret the instructions.

How about the user interface to the control programming language? “Text based programming is too complex, I like graphical programming”. “Graphical programming is too limited, I don’t have control”. “What’s BASIC, I wasn’t even born when it was introduced, it’s too old”. “I don’t like writing code, I like calling libraries”. These are the typical comments in the BAS industry about control language. As it can be seen the industry has to cater to diverse demographics. The older generation that has grown up with BASIC type languages to the new generation of programmers that just use sets of libraries to program software.  The answer is simple; you can have your preferred user interface. The BAS vendors can develop any user interface, text based, graphical, XML, libraries etc... and then parse the output to the open instruction set.

The above architecture will further open up the industry. It allows a control device from a vendor to be programmed from another vendor. For example, at present a BACnet system which consists of five  vendors with one single user interface can monitor and modify parameters of all devices from all vendors. However, to modify a program vendor dependent software is required.  In an open instruction set architecture, the vendor dependent software is eliminated and the main user interface can be used to modify the program. Also, the main user interface can support multiple program development environments to cater to the capabilities of different users.

The challenge to the BAS vendor in the proposed architecture is to develop the different user interfaces for programming environment and output to the open instruction set. The BAS vendor with the most flexible and easy to use interface can gain significant competitive advantage.

It is time for the control programming language paradigm to evolve to open and more flexible programming environments to cater to the diverse audience in the BAS industry.