978-1-4673-5637-4/13/$31.00 ©2013 IEEE

Abstract. HMI graphical panels become more and more

common in control devices such as industrial PLC controllers.

The authors propose a multiplatform solution incorporating

HMI development tools and runtime environment which

takes into account specifics of such devices, including limited

resources. HMI visualization is oriented to graphic objects

and can be programmed in languages defined in IEC 61131-3

standard together with control algorithms. An architecture of

the mechanism, as well as details of development and runtime

components are presented.

Keywords: control systems, HMI, IEC 61131-3, operator

interface, visualization.

I. INTRODUCTION

MI interfaces have an important role in control

systems [1]. They are not only used in

high-performance supervisory workstations [2], but also in

smaller devices installed on site, in the vicinity of the

controlled plant. It is also more and more common to

integrate graphical panels in industrial controllers to

visualize parameters of a control algorithm and set

operation data. In previous years HMI panels employed

mainly small character-oriented displays. Currently it is

possible to use color LCD screens with high resolution,

some of them touchable. As a result, possibilities of

graphical visualization in process control have been

significantly increased [3].

IEC 61131-3 [4] is a worldwide well-known standard for

programming control systems, like PLCs (Programmable

Logic Controllers), PACs (Programmable Automation

Controllers), and DCSs (Distributed Control Systems). It

defines software structure and five dedicated programming

languages. ST (Structured Text) and IL (Instruction List)

are textual languages while FBD (Function Block

Diagram) and LD (Ladder Diagram) are graphical ones.

The last language, SFC (Sequential Function Chart) uses

mixed notation (graphical and textual). These languages are

used by developers to create POUs (Program Organization

Units) such as programs, functions, and function blocks.

Then, POUs compose control tasks.

The paper presents a multiplatform solution called

CPVis (Control Program Visualizer), for creating

Marcin Jamro, Department of Computer and Control Engineering,

Rzeszow University of Technology, al. Powsta!ców Warszawy 12, 35-959 Rzeszów, phone: +48 17 865-12-25, fax: +48 17 854-29-10, e-mail address: mjamro@kia.prz.edu.pl.

configurable graphical HMI interfaces for small- and

medium-scale control devices, especially controllers with

integrated graphical panels. Using IEC 61131-3

development process for both control algorithms and HMI

handling procedures is an important feature of the presented

solution. Most existing solutions use different procedures

for creating these two parts of the system. Contrary to this,

the authors propose common development tools as well as

programming methodology. Both parts are programmed

using any of IEC 61131-3 languages allowing the developer

to integrate control and HMI program units in the same

software structure.

The proposed solution is addressed mainly for devices

with limited resources where some performance issues are

at stake. In particular, this kind of problems can be caused

by the fact that controllers must process not only control

algorithms but also handle HMI operations at the same

time.

The paper is organized in the following way. Section II

presents a general architecture of development and runtime

environments, including software components of the

solution used in the engineering station and target

controller. The concept of visualization displays oriented

towards graphic objects is given in Section III with some

details of the object structure. The tool for display creation

is presented in Section IV. The runtime part of the system is

characterized in Section V. Section VI presents an example

of programming HMI interface using three IEC 61131-3

languages, namely ST, FBD and LD.

II. CPVIS ARCHITECTURE

CPVis has been prepared as a part of the CPDev

engineering environment (Control Program Developer)

[5]. CPDev is used to program PLCs, PACs, as well as

small and medium size DCSs according to IEC 61131-3

standard [6]. A development of the environment has been

ongoing for a few years in the Department of Computer and

Control Engineering at Rzeszów University of Technology

[7]. CPDev contains a few modules, including the

integrated development environment with compilers,

translators, textual and graphical editors of IEC 61131-3

languages [8], simulation, debugging and testing platform

supporting unit and table tests. CPDev programming will

be briefly demonstrated in Section VI by means of an

example.

The runtime part of CPDev is created as the virtual

machine (VM) which executes a universal code generated

IEC 61131-3 Programmable Human Machine Interfaces for Control Devices

Marcin Jamro1, Bartosz Trybus1 1Rzeszów University of Technology, Rzeszów, Poland,

mjamro@kia.prz.edu.pl, btrybus@kia.prz.edu.pl

H

48

by the compiler [9]. The machine can be adapted to various

hardware platforms, what makes the CPDev engineering

environment portable. In particular, it has been

implemented in ARM, AVR and x86-based systems.

Industrial applications of CPDev include ship control

and monitoring system from Praxis Automation

Technology B.V. (Leiderdorp, the Netherlands) [10]. The

system consists of several types of dedicated controllers

communicating over Ethernet. SMC controller from

LUMEL S.A. (Zielona Góra, Poland) is another application

[11]. SMC operates as a central unit in small distributed

control systems in measurements, control, monitoring and

diagnostics. Recently CPDev has been applied by Nauka

i Technika Sp. z o.o. [Ltd.] (Rzeszów, Poland) into

StTr-760-PLC controller used in pumping stations and

transportation. Fast FPGA-based CPDev controller has

been built as well [12].

The CPDev environment has been extended with CPVis

to allow a development of graphical HMIs for industrial

controllers. The following general assumptions has been

taken into account while designing the extension:

- Portability. The system supports multiple platforms,

such as x86 and ARM devices. It is independent from

visualization hardware (LCD/TFT panels, monitors, etc.)

and specific drawing libraries.

- Configurability. The system allows the user to replace or

modify HMI part of the system in a simple manner (no

low-level reprogramming should be necessary). In

particular, changing HMI has no effect on control

functions.

- Programmability. The developer can program behavior

of HMI graphics, such as display object attributes (color,

visibility, position on the screen, etc.) on user interaction or

when a control variable value changes. These programs can

be written in IEC 61131-3 languages.

- Low hardware requirements. CPVis is applicable for

devices with limited resources (memory or CPU clock).

This means that optimizations must be made in screen

update procedures. Limitations (such as no dynamic

overlapping ) are introduced to improve speed.

- Component-oriented graphics. Graphic displays are

composed from predefined visualization controls referred

as graphic objects (like bar graphs, process value box, touch

buttons). An object is defined by drawing procedure and a

set of parameters that determine its visual representation.

The objects are organized in libraries, either general

purpose or application-specific.

Fig. 1. An architecture of CPDev with HMI interface

Such assumptions, made during design, affect the

architecture of the system. The overall architecture is

presented in Fig. 1. It can be divided into two main parts:

development (engineering) and runtime environments. The

first one contains tools that allow the developer to create

control software (CPDev), simulate and monitor execution

(CPSim), perform tests of the software (CPTest), and

configure hardware parameters or communications

between devices involved in the project (CPCon). CPVis is

used at the engineering station to design the HMI panel.

Dedicated graphics editor of visualization displays is the

most important development application. The user

composes displays from graphic objects and stores data of

the project in XML file. A detailed description of the editor

is presented in Section IV. The project is then exported to

the CPVis binary file. The file is used in the runtime

environment of the target controller, where CPVis runtime

program and CPDev virtual machine cooperate to provide

control and HMI functions. The runtime part of the solution

is described in Section V.

Fig. 2. Multiplatform support in CPVis

As stated earlier, a portability is one of the general

requirements for CPVis. To handle different display

devices, CPVis is divided into platform-independent and

platform-depended parts (Fig. 2). A set of platform-specific

drawing primitives is defined and includes e.g. lines,

rectangles, triangles, and bitmaps. The graphic object

definitions are constructed using these primitives, thus the

objects are platform independent and may appear on

various display devices.

TAB. 1. DRAWING PRIMITIVES

Function Parameters

DrawRectangle position, size, border color and

size

FillRectangle position, size, fill color

DrawStraightLine starting and ending point, color,

line width

DrawString position, text, length, font, color

MeasureString text, length, font

DrawBitmap position, bitmap data, width,

height

FillPie position, width, height, starting

angle, angle, color

DrawArc position, width, height, starting

angle, angle, color, line width

FillTriangle point coordinates (3), fill color

FillEllipse position, width, height, color

49

The most important primitive functions (together with

their parameters) are presented in Tab. 1. They may be seen

as a kind of intermediate layer which hides details of

implementation specific to the target platform. From the

designer perspective this leads to several advantages, like

possibility of using the same visualization displays

(designed once) on different devices, e.g. PC (for

simulation), ARM-based controller with panel (as the target

HMI), mobile device (for a remote access to the

visualization), or a web browser. To handle a display

device, the developer should implement drawing primitives

using mechanisms specific to the device, including external

dedicated graphic libraries (such as GLCD, RamTex, or

GDI+). This feature also allows the developer to add

support for another display device in a relatively easy way.

III. GRAPHIC OBJECTS

The CPVis visualization mechanism is oriented towards

graphic objects. The HMI developer creates a project by

designing one or more displays (pages) that may be

switched during runtime. Each of the displays is composed

from graphic objects selected from libraries. CPVis

contains the default library with basic controls that are not

related to any specific application, e.g.:

- Bar Graph – a simple visual presentation of a value

- Image – a bitmap

- Image Part – a specified part of a bitmap

- Text Box – a placeholder for any text

- Process Value – a text-based control for presenting

process variable in various colors depending on the

value (real number)

- Counter Value – a text-based control showing integer

numbers in specific format, e.g. with or without

leading zeros

- Line – a straight line in particular color

- Box – a rectangle with or without a border

- Rounded box – a rectangle with rounded corners

- Circle – an ellipse with or without a border.

Some objects from basic library (like Circle) act as simple

wrappers to drawing primitives.

Fig. 3. Placing graphic objects on the display

Graphic objects can be placed on the display in any

location (Fig. 3). The designer can customize them by

changing position, size, or even aspect ratio. This feature

allows the graphic objects to appear on the display in a

convenient way and indicate visually their importance

using size and location. Particular objects (such as bar

graph or line) can be used on the display multiple times,

thus its instances are maintained by CPVis mechanisms.

Every graphic object has a set of parameters that are used

to adjust its appearance, like a background color (Bar

Graph) or a displayed text (Text Box). The parameters are

set either during development or runtime. Each of them has

a default value, which can be overridden by setting a new

fixed value for the specific graphic object instance placed

on the display. It can also be bound to a global variable

declared in the CPDev environment. In this case, the

parameter can change during runtime. Therefore, its value

is obtained from the CPDev virtual machine (see

Section V) and has an impact on appearance of the object.

Since the object may have several parameters, they are

grouped into subsets (like Basic, Advanced, or Design) to

improve readiness and easiness of use.

CPVis supports two kinds of parameter types – basic and

specific to CPVis. The first group contains IEC 61131-3

data types: BOOL (logical), BYTE and INT (integer

numbers), REAL (a real number), STRING (a character

string). The others are CPVis-specific – COLOR (an index

from a color palette), RANGE (a structure with given

minimum and maximum value), FONT (an index of a font

style), IMAGE (a bitmap) or COMPLEX (contains other

types, excluding COMPLEX). A declaration of CPDev

variables that will be bound to graphic object parameters

should match their types. However, COLOR and FONT

parameters can also be mapped to integer variables holding

index values.

A particular control application may require specialized

objects not available in the basic library. In such a case

CPVis allows to create application-specific controls and

place them in a custom library. More sophisticated objects

(like pie graphs, dial graphs, list boxes, etc.) can be created

in this way.

A new graphic object is created by declaring it in XML

library file and preparing the drawing code in C (using the

drawing primitives from Tab. 1). As an example, a

declaration of the Bar Graph object from the basic library is

presented in Fig. 4.

<?xml version="1.0" encoding="utf-8"?> <Library Name="CPVis.Objects.Basic" Wrapper="CPVis.Objects.Basic.Managed.dll"> (...)

<Object Name="BarGraph" FunctionName="DrawBarGraph" Width="20" Height="100" Identifier="0x01" IsUpdatable="True"> <Parameters> <Group Name="Basic"> <Parameter Variable="minValue" Name="Minimum Range" Type="REAL" Default="0" Description="" /> <Parameter Variable="maxValue" Name="Maximum Range" Type="REAL" Default="100" Description="" /> <Parameter Variable="currentValue" Name="Current Value" Type="REAL" Default="50" Description="" /> </Group> <Group Name="Design"> <Parameter Variable="alignment" Name="Alignment" Type="INT" Default="0" Description="To top (0), to bottom (1), to right (2), to left (3)" /> <Parameter Variable="indicatorsNumber" Name="Indicators Number" Type="INT"

50

Default="5" Description="" /> (...)

<Parameter Variable="positiveColor" Name="Positive Bar Color" Type="COLOR" Default="102" Description="" /> <Parameter Variable="positiveRange" Name="Positive Bar Range" Type="RANGE" Default="50;100" Description="" /> <Parameter Variable="backgroundColor" Name="Background Color" Type="COLOR" Default="0" Description="" /> </Group> </Parameters> </Object> (...)

</Library>

Fig. 4. XML declaration of a library with bar graph graphic object

The library name (CPVis.Objects.Basic) is specified first

together with the file (.dll) which holds an implementation

of drawing functions (written in C) of all objects in the

library. Then, declarations of objects are given (only the

Bar Graph is shown in Fig. 4).

Each object declaration should contain:

- a name of the object (Name)

- a name of its drawing function (FunctionName)

- a default width and height (Width, Height)

- a unique identifier (Identifier)

- a value indicating whether the object should be

updated during runtime (IsUpdatable).

The Parameters node (Fig. 4) contains a set of Group

elements with nested Parameter declarations. Each

parameter has a name (Name), a variable which holds its

value (Variable), a type (REAL, INT, RANGE, and COLOR

in this case), a default value (Default), and – optionally –

a Description.

Apart from the declaration, the graphic object requires its

drawing function created in C language. A part of code for

the Bar Graph is presented in Fig. 5. void DrawBarGraph(CPBitmap *bitmap, int width, int height, float minValue, (...), unsigned char backgroundColor) {

StartDrawing(bitmap); FillRectangle(1, 1, width - 2, height - 2,

backgroundColor); DrawRectangle(0, 0, width - 1, height - 1,

borderColor, 1); (...)

EndDrawing(); }

Fig. 5. A part of bar graph drawing code

The drawing definition has a form of C function

(DrawBarGraph) with parameters corresponding to the

XML declaration (some of them are skipped for simplicity).

In the function body there are calls of the primitive drawing

functions (FillRectangle and DrawRectangle, see Tab. 1)

which create visual representation of the object. The

concept of graphic objects in CPVis recommends to draw

them in a way that makes possible a free adjustment of their

size and scale. There are two additional calls at the

beginning and at the end of the function body.

StartDrawing function initializes visualization mechanism

before drawing, while EndDrawing finishes drawing the

object. As seen, the definition of graphic object does not

depend on display platform and can be used on different

devices if the drawing primitives are applied.

IV. CPVIS EDITOR

Visualization displays can be designed and managed

using the dedicated CPVis editor. The XML format is

applied to store all display data, such as display

arrangement, object instances with design-time parameter

values etc. The editor is equipped with a set of features,

including:

- display management

- adding, moving, or deleting graphic objects

- changing location, size, and scale of graphic objects

- setting values for parameters of graphic objects

- adjusting display (e.g. choosing a suitable grid size)

- graphic object library support.

The main CPVis window is shown in Fig. 6. It consists of

two parts. The left one contains CPVis project tree with two

defined displays, namely Main display and Auxiliary

display. Lower part of the tree contains the library branch.

Fig. 6. The main window of the CPVis editor with two simple displays

51

CPVis.Object.Basic library is expanded showing all

available objects (Bar Graph, Image, etc.). The main part of

the CPVis editor window is a workspace where displays are

shown and maintained. Display creation is done by

dragging graphic objects from the library tree and placing

them on the display. The two simple displays shown in Fig.

6 in the design mode contain bar graphs, process values,

circles, boxes and text boxes. After placing an object on the

display, the user can adjust its location, size, and

dimensions. Suitable values for these and other parameters

can be set, either as fixed values or by binding them to

variables processed by CPDev control program. The editor

helps the user to set correct values of parameters and

perform basic validation, based on types.

The final stage of development involves an export of the

visualization data to the CPVis binary file (Fig. 7). It holds

information needed at runtime in a compact form suitable

for transferring to the target controller. Data of all displays,

graphic objects, and parameters used in the visualization

are included.

Fig. 7. A structure of the CPVis binary format

Each section of the CPVis binary begins with a header

that stores a length of the section (in bytes). In addition, the

header can hold other specific information (like display

width and height). Display section nests data of included

object instances (e.g. Object#1, Object#2). Similarly, the

object section contains data of parameters. The parameter

section represents either a fixed value (default or set at

design time) or an address reference to the CPDev variable

that is bound to the parameter. Bitmap data (pixel values)

are stored directly in the binary file, however one byte per

pixel color depth should be used to keep the binary size

suitable for control devices.

V. CPVIS RUNTIME ENVIRONMENT

CPVis runtime is used on the target device, such as

a controller with graphical touchable LCD panel, to draw

and update visualization displays. The runtime has been

prepared as C/C++ program which processes the CPVis

binary file and draws displays according to data obtained

from the file. A single iteration of the runtime program

consists of an interpretation of the binary file and getting

data of displays, objects, and parameters.

The runtime runs on the device in parallel with the

CPDev virtual machine (Fig. 1) [9]. In fact, dynamic

changes of the HMI graphics are caused by programs

executed by the machine. Two scenarios are available here.

First, when a value of the CPDev process variable bound to

an object is changed. In such a situation, the object should

be updated to reflect the new value. This happens for

example if Current Value of a bar graph has changed. To

achieve this the bar graph drawing function contains

necessary logic to update the visual representation of the

value. Another scenario involves a direct modification of

some visual aspects of the object (color, position etc.) from

CPDev program using IEC 61131-3 language, as in the

example discussed further in Section VI. This gives the

developer more flexibility and allows to adjust the display

without changing object definitions.

The CPDev program can also contain logic for switching

the displays. CPVis runtime program monitors particular

CPDev variable (of integer type) which contains an index

of the currently active display. Any change of this variable

causes the screen refresh to present the newly selected

display.

One of the most important optimizations of CPVis

runtime involves updating only those graphic objects that

require so. The runtime checks whether the currently

processed object needs to be refreshed (Fig. 8). In such

a case, the object is drawn by the function indicated in the

graphic object declaration. If no refresh is required, the

CPVis runtime proceeds to analyzing the next graphic

object from the current display.

The refresh is done only for those objects which are

marked as updatable (see Fig. 4). If IsUpdatable flag is set,

the object can be refreshed multiple times. If the flag is not

set, the object will be drawn only once, when the display is

selected. This reduces time needed to process static parts of

the display (background images, borders, logos, etc.).

Fig. 8. The CPVis binary interpretation and object drawing

Another mechanism is used to reduce redrawing of

updatable objects. Such objects may change visual state

during runtime according to CPDev variables. The change

detection algorithm compares values of parameters and

determines whether the value has changed. If so, the

graphic object needs to be refreshed and current parameter

values are stored for reference. If values have not been

changed, the update is not required.

The update logic significantly increases the performance.

CPVis can be applied for devices with limited resources, so

reducing as many operations as possible has a vital impact

on efficiency of the whole system. Other optimizations

involve a shadow buffer to eliminate undesirable flickering

effect while graphic objects are redrawn or the active

display is switched.

The process of drawing and updating a display is

controlled by the drawScreen function, which is the main

52

entry point to the CPVis runtime. Its calls should be

synchronized with the cycle time of the virtual machine. In

such a case, modifications of variable values done by the

CPDev program will be reflected immediately on the

display. Additional calls may be required to give instant

feedback when the operator interacts with the controller,

e.g. presses a button or touch panel.

VI. EXAMPLE OF HMI PROGRAMMING IN IEC 61131-3

As stated earlier, the presented solution allows to use

languages defined in IEC 61131-3 standard to handle HMI

graphics. In case of the industrial controller programming,

the concept assumes that the developer creates both control

program and visualization program in the same manner.

One can use any IEC 61131-3 language, textual or

graphical. The developer can select a suitable language

depending on skills and taking into account the project

characteristics.

As an example, a project for controlling an engine

(motor) and a pump is described below together with a

simple HMI corresponding to Fig. 6. The control part of

the project contains ST program which starts the engine

immediately after pressing a starting button, and launches

the pump 10 seconds afterwards. Similarly, stopping the

engine is done immediately after setting STOP or ALARM,

however the pump is stopped 10 seconds later. Fig. 9.

shows the ST code used in the control part of the project.

VAR DELAY_ON : TON; (* TON function block *) DELAY_OFF: TOF; (* TOF function block *) END_VAR VAR_EXTERNAL START : BOOL; STOP : BOOL; ALARM : BOOL; ENGINE : BOOL; PUMP : BOOL; END_VAR ENGINE := (START OR ENGINE) AND NOT STOP

AND NOT ALARM; DELAY_ON(IN:=ENGINE, PT:=t#10s); DELAY_OFF(IN:= DELAY_ON.Q, PT:=t#10s); PUMP := DELAY_OFF.Q;

Fig. 9. ST code for controlling an engine and pump

Two function block instances are declared first

(DELAY_ON and DELAY_OFF) using TON (delayed on)

and TOF (delayed off) function block types. Then, five

Boolean variables are declared. The first three (START,

STOP, ALARM) are inputs and may correspond to

pushbuttons on an operator panel. ENGINE and PUMP are

outputs calculated by the program and can be used to

activate the devices. ENGINE is on if START has been

pressed and until STOP or ALARM is triggered by the user.

The two delay function blocks are then called in a sequence

using the time value of 10 seconds as the input argument

PT. Finally, PUMP is set according to the Q output of

DELAY_OFF.

CPDev main window with the project is shown in Fig.

10. The project tree on the left contains several global

variables, starting with the five variables used in the ST

control program. Other global variables include

ENGINE_RPM and PUMP_RPM. There are integer inputs

coming from sensors that calculate revolutions per minute

(RPMs) of the engine and pump. Such values monitor

whether the devices still rotate. ALARM_USER,

ALARM_ENGINE, ALARM_PUMP are Boolean variables

indicating whether alarms are active. The first alarm is

“manual”, activated by the operator with the ALARM

button. The other two alarms are raised by the engine and

pump hardware. They are set when a hardware failure

occurs.

Since global variables are shared between IEC 61131-3

tasks, the variables calculated by the control task can be

used by the visualization task to adjust the graphics shown

earlier (Fig. 6). The developer can create some dedicated

variables for handling visualization using CPVis data types

described in Section III. In the sample project, a set of

global variables with prefix VC_ is dedicated to handle

visualization colors. The first two, VC_ENGINE and

VC_PUMP define colors of rectangles representing the

engine and pump (Fig. 6, center). If the engine or the pump

is rotating, the appropriate rectangle is drawn in green,

otherwise red color is used. To get it, an additional program

has to be created in CPDev to prepare suitable values of

global variables VC_ENGINE and VC_PUMP. The

program can be written in any IEC 61131-3 language. Two

versions of such a program will be presented, one written in

ST and second in FBD.

Fig. 10. CPDev with ST program for engine and pump visualization

The program V_ENGINEPUMP in ST is presented in

Fig. 10. The IF expression is used to check whether the

engine is running (ENGINE_RPM>0). Either 102 or 180

value is assigned to the variable VC_ENGINE. It is

important to assign correct indices of colors from the

palette. In the example, 102 is an index of green, and 180 of

red. Another IF expression is used later to select the color of

the pump rectangle.

Fig. 11 shows a graphical FBD diagram to demonstrate

ability to create HMI programs in a visual manner, i.e. by

manipulating program elements graphically rather than by

53

specifying them textually. The diagram uses GT and SEL

functions represented by rectangles with inputs and outputs.

GT returns a logical value indicating whether the first input

is greater than the second one. SEL function chooses the

second or the third input as an output value, depending on

the first input. The numbers in the function rectangles

represent processing order. Other rectangles in the diagram

denote input and output global variables (such as

ENGINE_RPM or VC_ENGINE) and numeric constants

with color indices 102 and 180. VC_ENGINE and

VC_PUMP are outputs of the two SEL functions. It can be

seen that the FBD diagram provides the same functionality

as the ST program presented above.

Fig. 11. FBD program setting colors for engine and pump visualization

The three remaining global variables with VC_ prefix in

the tree on the left of Fig. 10 (VC_ALARM_USER,

VC_ALARM_ENGINE, and VC_ALARM_PUMP) store

indices of colors used to select correct background for the

ellipses on the auxiliary display (Fig. 6, on the right). The

colors can be set in a similar way as presented above, but

instead of “greater than” comparison, Boolean variables

indicating occurrence of alarms should be checked. For

example, if ALARM_USER equals to TRUE,

VC_ALARM_USER is set to 180 (red color indicates the

alarm), otherwise it equals to 102 (green color indicates

normal action).

The LD diagram is presented in Fig. 12 as another

example of IEC 61131-3 language which can be used to

handle HMI graphics. LD is a visual language, quite

popular among designers of electromechanical

applications. It shows logical relationships between input

and output variables as they were contacts and coils in a

hard-wired electromechanical relay circuit.

Fig. 12 contains three horizontal rows (rungs) between

two vertical rails on the sides of the diagram (power rails).

The verticals contain a virtual power (only the left one is

used). The upper rung starts with a symbol of a contact

denoted ALARM_USER. This represents the Boolean

variable which is set when the operator presses the

ALARM button. In such a situation, the virtual contact is

closed allowing the virtual power to flow to the SEL

function block instance. This block is used in the same way

as in the FBD diagram of Fig. 11, thus it produces an output

of either 102 or 180. The output is then passed to the

variable VC_ALARM_USER which holds the color for the

top indicator in the auxiliary display. Similarly, the colors

for engine and pump alarm indicators are set in the middle

and bottom rungs in Fig. 12.

Fig. 12. LD program setting colors for alarms indicators

As said before, the CPVis runtime monitors a particular

integer variable representing the currently active display. In

the presented example, such a variable is named

V_DISPLAY (the last one in the project tree in Fig. 10).

Assuming a default value of 0, it indicates that after starting

the system the first display will be shown (Main display).

CPDev program can set the variable to the value of one, for

example upon a button press.

IF ALARM_USER OR ALARM_ENGINE OR ALARM_PUMP

THEN V_DISPLAY := 0; ELSE V_DISPLAY := 1;

END_IF

Fig. 13. ST code for switching displays depending on an alarm

Another possibility is implemented in the ST code

(Fig. 13) which switches between the two displays

depending on the values indicating whether an alarm is

active. In case of an alarm, the second display (Auxiliary

display) is processed and presented to the user.

VII. SUMMARY

IEC 61131-3 is a common industry standard for

programming controllers using textual and graphical

languages like ST, FBD or LD. A creation of HMI

graphical interface is currently an important part of

development of many control systems, regardless of their

size.

The authors have proposed a multiplatform visualization

mechanism CPVis provided with IEC 61131-3

programmability. The designer can create displays by

choosing graphic objects from libraries, customizing them

by setting parameters and binding to control program

variables. CPVis can be used on various display devices

including those with limited processing resources.

The combination of development tools for visualization

(CPVis) and for process control programming (CPDev)

creates a complete solution for engineers in the field of

industrial control and allows to design and implement

control and HMI processing logic in a unique way by using

standardized programming techniques.

54

REFERENCES

[1] Zhang P.: Chapter 13 – Human-machine interfaces, Advanced Industrial Control Technology, Oxford, 2010, pp. 527-555.

[2] Wittenberg C.: A pictorial human-computer interface concept for supervisory control, Control Engineering Practice, Vol. 12, Issue 7, 2004, pp. 865-878.

[3] Nachreiner F., Nickel P., Meyer I.: Human factors in process control systems: The design of human-machine interfaces, Safety Science, Vol. 44, Issue 1, January 2005, pp. 5-26.

[4] International Electrotechnical Commission, IEC 61131-3, Programmable controllers - Part 3: Programming languages, 2013.

[5] CPDev website [Online], http://cpdev.kia.prz.edu.pl, accessed: January 2013.

[6] Rzonca D. et al: Mini-DCS System Programming in IEC 61131-3 Structured Text, Journal of Automation, Mobile Robotics & Intelligent Systems, Vol. 2 No. 3, 2008, pp. 48-54.

[7] Rzonca D., Sadolewski J., Trybus B.: Prototype environment for controller programming in IEC 61131-3 ST language. Computer Science and Information Systems, Vol. 4, No. 2, 2007, pp. 131-146.

[8] Jamro M.: Graphics editors in CPDev environment, Journal of Theoretical and Applied Computer Science, Vol. 6, No. 1, 2012, pp. 13-24.

[9] Trybus B.: Development and Implementation of IEC 61131-3 Virtual Machine, Theoretical and Applied Informatics, Vol. 23 No. 1, 2011, pp. 21-35.

[10] PRAXIS Automation Technology website [Online], http://www.praxis-automation.nl, accessed: January 2013.

[11] LUMEL S.A. website [Online], http://www.lumel.com.pl, accessed: January 2013.

[12] Hajduk Z., Sadolewski J., and Trybus B.: FPGA-based Execution Platform for IEC 61131-3 Control Software, Przegl"d Elektrotechniczny (Electrical Review), R. 87, No. 8/2011, pp. 187-191.

55