ADVANCED CONTROL ALGORITHMS + SIMULINKCOMPATIBILITY + REAL-TIME OS = REX

Pavel Balda, Milos Schlegel, MilanStetina

University of West Bohemia in Pilsen,Department of Cybernetics,

Univerzitnı 8, 306 14 Plzen, Czech Republic.e-mail: pbalda@kky.zcu.cz

Abstract: This paper describes the structure and features of a new industrial control systemcalledREX. During the system design, special attention was paid to the simulation facilityof the control algorithms. The equivalent behavior of simulation and real-time control isguaranteed by a large function blocks library which is implemented for both Simulink andeach target platform.REX is suitable for building real-time control systems of real, virtualand remote laboratories.REX does not utilize Real Time Workshop by The Mathworks.Copyright c© 2005 IFAC.

Keywords: industrial control system, embedded control, Simulink, OPC, real-timecontrol system.

1. INTRODUCTION

There is a rather wide gap between control engineer-ing theory and practice. The way from the develop-ment of a new algorithm to its practical implementa-tion is usually very long and laborious because bothareas use different tools. Currently, Matlab-Simulink(The Mathworks, 2001) is perhaps the most widelyspread program system used for the development andtesting of new algorithms in industrial process control.Simulink is more frequently used not only in academicinstitutions but also in engineering practice. Practi-cal use of standard Simulink blocks is, however, notwithout obstacles, because these blocks have not beendeveloped for industrial applications.

To bridge the above mentioned gap, a new controlsystem,REX, has been developed. The main designrequirements have been as follows:

• Compatibility with Matlab-Simulink• Development of industrial control block library

(blockset)• Openness of the system, easy creation of new

algorithms

• Suitability for the teaching of control engineer-ing

• Support of industrial standards and internet tech-nologies

The objective of the paper is to describe briefly thecreation of aREX application and to emphasize thepossibility of simulating it in Simulink before puttingit into operation. TheREX control system is an openand scalable system, which is suitable for embed-ded control.REX can be easily ported to differentplatforms with C and C++ language compilers, fromdedicated control cards and simple real-time execu-tives to process stations equipped with standard op-erating systems. At present,REX supports WindowsNT/2000/XP, Windows CE .NET and a hard real-timeoperating system Phar Lap ETS (Embedded ToolsSuite).

REX has been used for the building of the remoteand virtual laboratory in the department of cybernetics(lab.fav.zcu.cz ). Below is the list of sectionsfollowing this Introduction:

2 Structure ofREX

Configuration Visualization OPC clients

Diagnostics

Communication

Development, visualizationHost

Target

RexView

Process

EfaDrv AdvDrvIODrv1 IODrvN

File.rex

RexCore

File.mdl

RexComp

RexDraw Simulink

RexOPCsv

RexAutSv

TCP/IP

TCP/IP

Indusoft WS

Excel

Genesis 32

In Touch

IExplorer

Automation

OPCDCOM

OPCDrv

OPCSvr1

OPCSvrM

OPCMbDrv

Real-time control

…

…

Fig. 1. Structure ofREX control system

3 Function block libraryRexLib4 REX runtime and diagnostics5 Configuration ofREX6 OPC (OLE for Process Control) utilization

2. STRUCTURE OFREX

The structure of theREX control system and its rela-tions to an environment are shown in fig. 1.

The top part of the figure contains components ofa host development environment which is (simul-taneously) the visualization and operator manage-ment environment. All current development tools ofREX are created for the Windows operating sys-tems (95/98/ME/NT/2000/XP). Standard visualiza-tion tools are used (some of them are shown in thefigure). Visualization tools are connected to the con-trol system through an OPC interface, which usesCOM (Component Object Model) and DCOM (Dis-tributed COM) services, or through Automation (OLEAutomation) and various scripts (VBScript, JScript,Visual Basic).

The bottom part of the figure presents the structureof the target enviroment, which implements real timecontrol algorithms. In addition to the Windows op-erating systems mentioned above, also e.g. WindowsCE or Phar Lap ETS can be chosen for the targetenvironment. In the case of the Windows operating

systems, the target and host environments can be thesame, even on a single computer.

The links between host and target environments arecarried out by a communication layer (in the middleof fig. 1). The most frequently used communicationprotocol is the TCP/IP standard, which is used as abasis of our own diagnostic protocol ofREX.

3. FUNCTION BLOCK LIBRARY

The control algorithms performed byREX are de-veloped using only a special function block library(block set) calledRexLib, (Schlegelet al., 2001). Atpresent, the library contains more than 120 functionblocks, which are compiled for Simulink and eachtarget platform (Windows, Windows CE and PharLap ETS). The library contains both simple functionblocks (similar to the corresponding Simulink blocks)and advanced industrial control blocks. The most so-phisticated function blocks are depicted in fig. 2.

PIDMA is the full ISA PID controller supplementedwith the built-in autotuning procedure. After startof the autotuner, the rectangle pulse is applied tothe input of the process and the first three processmoments are computed from the pulse response.Subsequently, the controller parameters are deter-mined by a model based design procedure (Schlegelet al., 2002).

dvsppvtvhvMANIDRUNHLDBRKSETCipsMFR

mvde

SATIDBSY

wxreximepvIDEiIDE

p1p2p3p4p5p6

SC2FA

HALTu0u1u2u3u4u5u6u7u8u9u10u11u12u13u14u15

erry0y1y2y3y4y5y6y7y8y9

y10y11y12y13y14y15

REXLANG

dv

sp

pv

tv

hv

MAN

IH

TUNE

TBRK

TAFF

ips

mvdmv

deSAT

TBSYTEite

trempkpti

ptdpndpbpc

PIDMA

Fig. 2. Examples of advanced function blocks fromRexLib

setpoint

hand value

MAN/AUT

tuner start

tuner break

tuner outputs

tuner results

ips=0: controller parameterstuner affirmation

par. set index

manipul. var.

Autotuning PID loop with analog output

HINT: 1. set tuner parameters2. in manual mode (MAN=1, TUNE=0), set a working point by hand value (hv) and wait for steady state

3. TUNE 0−−>1 starts the autotuning function (TBSY 0−−>1)4. wait for the end of tuning (TBSY 1−−>0); if TE=0, then all is OK 5. check the computed PID parameters in closed loop (TAFF=1, MAN=0, change sp or dv)

disturbance PROCESS

integrator hold

ips=1: process moments

ips=2: FOPDT processmodel

Scope

SLEEP

dv

sp

pv

tv

hv

MAN

IH

TUNE

TBRK

TAFF

ips

mvdmv

deSAT

TBSYTEite

trempkpti

ptdpndpbpc

PIDMA

u y

MDL

y

y

y

y

Y

Y

Y

Y

Y

Fig. 3. Simple autotuning control loop inREX

SC2FA is a self-tuning controller for lightly dampedprocesses. A new algorithm of the frequency do-main identification and the standard state space ap-proach form the core of the automatic controllerdesign method (?).

REXLANGis a special function block which allowsthe user to write his/her own code in the program-ming language called RexLang. This language sup-ports all common C language commands (e.g.if ,else , for , while , do-while , switch ), call-ing user defined functions, standard math functions,and work with indexed arrays. RexLang is almosta subset of the C language except for commandsinput , output , parameter , which map blockinputs (u0 to u15 ), outputs (y0 to y15 ) and pa-rameters (p0 to p15 ) to user defined C languagevariables.

Fig. 3 demonstrates the example of a simple controlloop with autotuning feature based on theRexLibblocks. Detailed information about these and otherblocks can be found in (REX Controls, 2004).

4. REX RUNTIME AND DIAGNOSTICS

The core ofREX consists of a program,RexCore,which runs continually on the target platform. Othertools are necessary for watching the control systembehavior from the host platform, especially duringputting the control system into operation. This aim ispartially satisfied by the already mentioned visualiza-

tion tools, but a detailed view is provided by a programcalledRexView.

4.1 RexCore – the control system core

RexCore is a rather complicated program performing,simultaneously, different activities which are usual incontrol systems. Particular activities are executed ac-cording to their priorities in the preemptive multitask-ing mode. The following activities belong to the coresubsystems:

Real-time Subsystemtakes care of the triggering oftasks and nested fuction blocks, and triggering ofI/O drivers. It also collects and renders diagnosticinformation about the system performance and thetiming variables of tasks and drivers.

Input-output Subsystem provides interfaces for theI/O drivers of hardware devices which are usedto acquire process inputs and to actuate processoutputs.

Algorithmic subsystem includes function block al-gorithms which are called from real-time subsystemtasks.

Diagnostic subsystemprovides runtime diagnosticinformation and enables application download anddebugging.

Archive subsystem serves for the archiving of events,alarms and historical trends of selected variables.

4.2 RexView – the diagnostic tool

The RexView program makes it possible to watchwhat is going on in the control system core. Therefore,it is a very important tool during the debugging ofthe control system and also in routine operation whena problem occurs. The program offers detailed, hier-archically ordered information about all core subsys-tems. The communication protocol based on TCP/IPmakes it possible to connectRexView to a runningcore on the local computer, local area network or re-mote network (e.g. through Internet).

Fig. 4 demonstrates one type of theRexView screen.A more detailed description of the program is con-tained in the user manual.

The left part of the figure is filled by the hierarchy ofcontrol system subsystems and objects. The selectedPIDMAblock is tenth block of the real-time subsystemtask mtuner in the tree structure.1 The PIDMAblock implements the PID controller equipped with abuilt-in autotuner (Schlegelet al., 2002).

TheWorkspace property page containing thePIDMAblock workspace variables is chosen on the right handpart of the screen. The top part of the property page

1 Blocks of the given task are ordered in the same way as they areexecuted in the task.

Fig. 4. Sample of aRexView program screen

contains checkboxes for the selection of the kinds ofvariable (inputs, outputs, parameters and states). Themiddle part of the page contains the list of selectedvariables whose values are periodically updated. Theconnections to adjacent blocks are also visible. Thebottom part makes it possible to enter the values ofparameters and to simulate the values of selected in-puts. In this case the inputMANis selected. Its value1means that the controller is in the manual mode. If wewant to switch the controller to the automatic modedirectly (for the debugging purpose), it is sufficient tocheck the itemConstant , then to choose the value0 in theConst value of input field and finallyto press the buttonSet .

The other property pages in the right hand part ofthe figure correspond to the properties of the superiorobjects of the selected blockPIDMA:

Task depicts the diagnostics of the taskmtuner(e.g. the measurements of current, average, mini-mum and maximum execution time variables, com-puting error indications)

Executive shows the identification and diagnos-tic data of the current real-time executive instanceActive executive (e.g. creation, downloadand last start dates and times, memory usage)

Target identifies the current target device (herepavel ) which is on-line (e.g. target device type,operating system name and version,REX versionand build date)

The program contains also property pages of the otherREX control system core objects. The appropriatepage is activated when a given type object is selected,e.g. a module, a driver, a trend or an archive.

prev next

loop

Modules

Drivers

Archives

QTask

Level0

Level1

Level2

Level3

EXEC

prev next

EFADRV

prev next

EFA

Fig. 5. A main fileexec.mdl of a simple controlloop example

5. CONFIGURATION OFREX

REX is configured by creating function block dia-grams consisting of a large function block library(Schlegelet al., 2001). The function block library isavailable in Simulink and all target platform versionsof REX. This fact makes it possible to draw functionblock diagrams in the Simulink built-in editor. Thesecond possibility is to useREX’s own editor,Rex-Draw.

Both programs, Simulink andRexDraw, store func-tion block diagrams in files with the.mdl extenstion(model). These text files are too big to be transferredto some memory limited embedded devices. That iswhy the .mdl files are compiled by theRexCompcompiler into the binary format.rex (section 5.2).

The configuration ofREX is demonstrated on a simplecontrol loop example which is shown in figures 5, 6and 7.

The rest of this section explains the mutual relationsof all the three figures.

Simulationof the process

dvsppvtvhvMANIH

mv

dmv

de

SAT

PIDU

u y

LIN_PV

u y

LIN_MV

EFA__AO_MV

[EFA__AI_PV]

y

CNR

Fig. 6. A particular simple control loop configurationexampleloop.mdl

Scope

u y

MDL

EFA__AI_PV[EFA__AO_MV]

Fig. 7. The simulation subsystemSimulationof the process of the configurationloop.mdl

5.1 RexDraw – Graphic editor of function blockdiagrams

The RexDraw program is used for function blockdiagrams design in a way very similar to the Simulinkbuilt-in editor. Both programs generate files with the.mdl extension but there are some differences in theiroptions.

First of all, RexDraw allows to compose.mdl filesusing only blocks from the large library ofREXblocks (Schlegelet al., 2001). All these blocks workin discrete time although many of them are dis-cretized for a given sampling period. This fact corre-sponds to the SimulinkSolver options param-eters:Type: Fixed step and discrete (nocontinuous states) .

While a whole Simulink configuration consists of theonly one file which can contain many subsystems(see the fileloop.mdl in fig. 6 and the subsystemSimulation of the process in fig. 7), anyREX configuration consists of at least two files. Onlyone of them is calledthe project main file(in this casethe fileexec.mdl in fig. 5).

The project main file specifies the configuration of theRexCore particular subsystems, which are describedin paragraph 4.1. Our example is very simple; the real-time executive is represented by the blockEXEC, theremaining blocks serve the following purposes:

EFADRV(ETS Fast Advantech Driver) is one of theREX control system modules. This particular mod-ule2 implements the fast driver of several PCIboards by Advantech for the hard real-time operat-ing system Phar Lap ETS (Embedded Tools Suite)by VenturCom.

EFA is an I/O driver block. Its first parameter is thename of a module implementing the driver, in thiscaseEFADRV. The next parameter is the name of aconfiguration file which contains information about

2 The present version ofREX supports also other drivers, e.g.Modbus master an slave (also over TCP/IP), standard Advantechdriver, OPC driver, etc. (see fig. 1.)

the source of control system inputs and destinationof outputs in addition to the device parameters. Forcontrol system design, the most important parame-ter is the name of the block (here it isEFA) whichdetermines the prefix of all names of inputs andoutputs connected to this driver (see paragraph 5.2for more details).

loop is the file name (the.mdl extension is ap-pended automatically) containing the control taskconfiguration. This task is inserted into the controllevel 0 (see the outputLevel0 of the blockEXEC).It is presented in fig. 6.

The described blocks possess inputsprev (previous)and outputsnext which allow to chain several blocksrepresenting modules, I/O drivers and control tasks inthe configuration. The same rule holds for archives(not used in the example) which are connected tothe Archives output of theEXECblock and fortasks of ohter control levels (Level1 , Level2 andLevel3 ). The only exception to the rule is the blockQtask (not used here) representing very quick con-trol task; there can be, at most, only one such task.

5.2 RexComp – Compiler of configurations

The RexComp program compiles a project mainfile in .mdl format into a binary configuration fileof the REX control system. Note that the main fileexec.mdl configuration is shown in fig. 5. The com-pilation process consists of the following steps:

(1) Finding of the real-time executive blockEXECinthe project main file, checking of the executiveparameters.

(2) Finding and checking of all control system ob-jects which are drawn in the project main file.

(3) Addition of configuration objects: modules, drivers,archives, the quick task and tasks of used com-puting levels.

(4) Memory allocation and setting of configuredblocks parameters.

(5) Checking of control task connections.(6) Whole configuration validation check.(7) Storing of the compiled file with the extension

.rex on the disc.

During its run, the compiler writes out the informationabout the files being compiled and about possiblecompilation errors. Each of the described steps canfail fatally, which results in compilation abort and thebinary file is not created.

Effective transition from simulation in Simulink torealtime control is supported by the following tworules ofRexComp:

(1) All subsystems (in.mdl files) the names ofwhich begin with the wordSimulation areskipped (i.e. they are not compiled)

(2) All blocks From and Goto whoseTag is ofthe form<prefix>__<name> are substituted

by standard input and output blocks of theREXsystem. These blocks refer to the I/O driver blockwith the name<prefix> . Further, the sym-bolic name<name> of an input or an outputis searched in the driver configuration. The twocharacters_ (underscore) serve as the separatorof a driver prefix and an input or an output vari-able name in the driver.

The following example demonstrates how these ruleswork. Due to rule 1, the subsystemSimulationof the process is eliminated. Rule 2 determinesthat the blockFrom with the tagEFA__AI_PV issubstituted by the standardREX input block whichrefers to the signalAI_PV of the driver with the nameEFA in the project main file (see fig. 5). Similarly, theblock Goto with the tagEFA__AO_MVrefers to thesignalAO_MVof the same driver.

Keeping the rules above guarantees the possibilityof transition from real-time system simulation inSimulink to real-time control inREX without the ne-cessity of any configuration file change.

6. OPC (OLE FOR PROCESS CONTROL)UTILIZATION

OPC is a relatively new but, at present, a verywidespread standard for automatic control devicesdata exchange, especially for communication of pro-cess stations and SCADA (Supervisory Control AndData Acquisition) or HMI (Human Machine Interface)levels. The currentREX version supports the OPCData Access Specification (OPC Foundation, 2000) intwo ways described below.

6.1 RexOPCsv – OPC server of theREX system

The first way is the OPC Data Access serverRex-OPCsv, which can be seen in the bottomTargetpart of fig. 1, was created mainly for the purpose ofcommunication with a supervisory level. The supre-visory system can be an arbitrary system which isOPC Data Access version 2.0 client. Today, there aretens of such systems on the market, some of them arepresented in fig. 1.

The structure shown in fig. 1 is applicable if the targetenvironment supports the DCOM standard, i.e. mainlyin the Windows operating systems. The server can alsobe launched in the host platform; it is necessary fortarget platforms supporting TCP/IP only. This struc-ture is suitable for large networks (Internet) wherethe gateways to local networks are protected againstunauthorized access (Firewalls). For this reason, theDCOM packet transfer may be a problem.

6.2 OPCDrv – I/O driver communicating with thirdparty OPC servers

The OPCDrv I/O driver represents the second wayof OPC utilization inREX. In contrast to theRex-OPCsv server, this driver is an OPC Data Access 2.0client. Thanks to this fact,REX can read (write) inputs(outputs) of arbitrary devices which are equipped withOPC Data Access servers. There are hundreds of suchdevices, produced by many companies, on the market.

7. CONCLUSION

The paper introduces a new control system calledREX which is compatible with Matlab-Simulink. Un-der certain circumstances, described in section 5.2, itis even possible to move from Simulink simulationto REX real-time control and vice versa without anyconfiguration modification.

Using REX instead of Real Time Workshop (RTW)or prototyping devices such as dSpace has severaladvantages:

• Existence of industrial control blocksetRexLib.• No need of software licenses for prototype de-

vices development.• Low price of prototype and/or final control sys-

tem application.

The proposed solution is also suitable for the buildingof real, remote and virtual laboratory control systems.

REFERENCES

OPC Foundation (2000).OLE for Process Control,Data Access Custom Interface Standard, Version2.04. OPC Foundation.

REX Controls (2004).Function blocks of the systemREX (in Czech). REX Controls s.r.o. Plzen.

Schlegel, M., P. Balda and M.Stetina (2001). C MEXblocks industrial control library with applicationexamples. In:Summaries Volume of the Matlab2001 Workshop. Humusoft s.r.o. Praha. pp. 361–369.

Schlegel, M., P. Balda and M.Stetina (2002). PID au-totuner for industrial use. In:Proceedings of theconference Control of power & heating systems.Zlın, Czech Republic.

The Mathworks (2001).Using Simulink, Version 4.1.Using Simulink, Version 4.1. Natick, MA.