Innovations in Comfort, Efficiency, and Safety Solutions.
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,
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
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:
1: Text base programming environment
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
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:
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
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
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
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
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.
4: Proposed programming language architecture
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
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.
5: Multiple user
interface, open architecture
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
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.
[Home Page] [The
Automator] [About] [Subscribe
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]