java interface to rex control system

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

JAVA INTERFACE TO REX CONTROL SYSTEM ˇ BALDA PAVEL, CECH MARTIN University of West Bohemia in Pilsen, Faculty of Applied Sciences, Department of Cybernetics, Univerzitni 8, 306 14 Pilsen, Czech Republic, emails: [email protected], [email protected] Abstract: REX control system is a hard real-time control system compatible with Matlab-Simulink. REX can be used for development of either industrial control systems or control systems of processes, plants and mechatronic models. REX is a suitable control system for building virtual and remote laboratories for automatic control teaching. This paper presents new communication interface to REX developed in Java programming language. The interface consists of several Java classes implementing the vast majority of REX communication protocol commands. Usage of the Java interface is demonstrated on two examples. The biggest advantage of Java interface to REX is its platform independence, i.e. it can be used in various web browsers and/or client operating systems. Keywords: Real-time control; Remote laboratory; Virtual laboratory; Java applet; Simulink

1

INTRODUCTION REX control system [Balda et al., 2005] is a software package implementing direct real-time control algorithms. At present, REX is ported to several platforms: Windows 2000/XP, Windows CE .NET and hard real-time operating system Phar Lap ETS. The biggest advantage of using REX is its compatibility with the global package Matlab-Simulink. The compatibility is guaranteed by the function block library (blockset) RexLib [Schlegel et al., 2001] containing more than 130 function blocks and implemented for Simulink and each target platform. REX has been verified in several applications as well as in teaching of automatic control. Recently, REX has been applied as the real-time engine of the remote and virtual laboratory [Balda et al., 2004] in Department of Cybernetics of the University of West Bohemia in Pilsen, Czech Republic. Until now, all interactive experiments in the laboratory use Genesis/WebHMI interface by [Iconics, 2006]. This is a good solution for Internet Explorer (IE) web browser because the visualization screens are implemented as ActiveX components and IE supports them. Other browsers intentionally does not support ActiveX components because of their potential security hazard. The only globally accepted solution in all significant web browsers is using of Java applets. That is why we decided to develop cross platform communication between REX 1 and Java classes – JavaREX. This interface is described in the paper. Section 2 briefly describes the internal communication protocol of REX, section 3 refers to the most important features of Java platform, section 4 introduces the newly developed Java classes and section 5 illustrates the usage of these classes. The last section 6 indicates the possible benefits of JavaREX. 2

REX XDG PROTOCOL Real-time control in REX (program RexCore) runs always in a separate operating system process. Other usual tasks (engineering diagnostic tools, SCADA/HMI systems, OPC server) run in different processes. That is why some data communication among these processes is necessary. This type of communication is implemented in the XDG protocol (reX DiaGnostic protocol) which is built-in to the majority of REX programs (real-time executive RexCore, diagnostic tool RexView, OPC server RexOPCsv, etc.). The main features of XDG protocol are the following: Client-server architecture. Any program RexCore running on the target device is a server, any program connected to the specified target is a client. 1

REX run-time engine RexCore is written in ANSI C++.

R145 – 1

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

Multi-client server architecture. Each server is able to support simultaneously up to 8 clients. The number 8 has been chosen only to limit the communication overhead. Command-reply protocol. Client sends a command and waits for the reply. Then the next command can be sent. It is not allowed to send several commands without waiting for the responses after each of them. Packet structure. A XDG protocol packet has the packet header XDG header followed by packet data. XDG header consists of a command code, command information (usually error code) and whole packet data size in bytes (including XDG header). Implementation. XDG protocol exists in two versions. First version implements the protocol under TCP/IP protocol and can be used for both local and remote (LAN, internet) connection to a target device. The second version is implemented using shared memory (memory mapped file). The second version is faster but can be used only for local machine connection. Figure 1 illustrates a TCP/IP packet with nested XDG packet. IP IP header header

TCP TCP header header

XDG XDG header header

Command/Reply Command/Reply data data

Figure 1 – XDG protocol TCP/IP packet structure

XDG Protocol contains several sets of commands: • Connection commands – initialization, termination and keep alive commands. • Identification commands – getting REX version, finding and converting REX symbols. • Simple type commands – getting/setting of simple variables or block flags. • Group commands – reading, writing, adding, removing and refreshing groups of variables. These commands are similar to OPC Data Access group managing functions [OPC Foundation, 2003]. • Object commands – reading of block variables and real-time diagnostic information on I/O drivers, execution levels, tasks and subsystems. • Trend and archive commands – reading of trend and archive configurations and real-time trend and archive history. • Download/upload commands – commands for sending and reading files and control system configurations and command for pausing and running the current configuration. This command set is the only set which is not supported by JavaREX interface. 3

JAVA PLATFORM In the last decade one can see a boom of Java technology [Sun Microsystems, 2006] in various areas – mobile phones, pocket PC’s, embedded microcomputers, web pages or server and database programming (Java server pages, JDBC). Java is a modern object-oriented language. The growing popularity of Java is caused by free accessibility of large complex libraries (Java API) and complete GUI development tools as well (NetBeans). Java is an interpreted programming language, therefore the Java Virtual Machine (JVM) is necessary to run Java applications. However, the programs are not interpreted directly from the source code files (*.java) but they are compiled to the optimized platform independent byte-code classes R145 – 2

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

Figure 2 – Java program compilation schema

Figure 3 – Java architecture

(*.class). This procedure is depicted in Fig. 2. The JVM in fact bridges the gap between compiled classes and native OS instructions set (Fig. 3). In the past, the C/C++ programming languages provide a platform independence on lower level of console applications. The Java technology brings the platform independence on the higher level including advanced OS features such as graphical user interface, event handling, printing, net access, multithreading, system clipboard, drag and drop operations, etc. (Fig. 4). As a platform-independent environment, the Java platform can be a bit slower than native code. However, advances in compiler and virtual machine technologies are bringing performance close to that of native code without threatening portability. Moreover, the time-critical pieces of codes are automatically compiled to the native code (Java HotSpot Virtual Machine).

Figure 4 – Java platform independence

R145 – 3

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

Thanks to the above mentioned advantages Java 2 became a basic programming language for students at a lot of technical universities. That is why we decided to implement the XDG protocol in Java. REX target 1

XDGProtocol 1 PORT #ABCD

XDGProtocol 2 XDGProtocol 3

INTERNET TCP/IP

JAVA client 1

REX target 2

XDGProtocol 1 XDGProtocol 2

PORT #ABCD

JAVA client 2

Figure 5 – XDG Java clients

4

JAVA XDG INTERFACE Let us briefly describe the classes of developed JavaREX interface. Complete description is avaliable in HTML form. All compiled classes of the JavaREX interface are contained in the Java package called rexServer. The XDG communication is based on standard TCP sockets, which are also fully supported in Java. The classes can be divided into four groups 1. Communication classes – the cooperation between following communication classes is depicted in Fig. 6. • XDGProtocol – basic communication class inherited from java.net.Socket. Each instance represents one socket connection to any REX target with the given IP address (Fig. 5). It implements the highest level procedures similar to standard industrial protocols such OPC (addGroup(), readGroup(), writeGroup(), refreshGroup(), etc.). The socket input and output are filtered by the RexInputStream or RexOutputStream instance, respectively. • RexInputStream – the socket input filter. Implements procedures at a lower level (readXB() for Boolean, readXL() for long, readXD() for double variables, etc.) to transform byte stream to REX variables and objects classes. 2

Note, that in the last few years the .NET platform and C# programming language grows into the biggest Java rivals.

R145 – 4

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

• RexOutputStream – the socket output filter. Implements procedures at a lower level (writeXB() for Boolean, writeXL() for long, writeXD() for double variables, etc.) to transform REX variables and objects classes into the byte stream.

XDGProtocol instance RexInputStream 10010 readGroup() writeGroup() refreshGroup() ...

TCP/IP socket

RexOutputStream 10010

Figure 6 – Detail of the XDGProtocol instance with input/output filters

2. REX objects classes – it is necessary to be familiar with the following classes to work effectively with JavaREX interface • XAV – object containing any REX variable (long, double, boolean, etc.) and actual variable type. The values can be read or written by get/set functions (getXBOOL(), setXBOOL(), getXDOUBLE(), etc.) • RexTStamp – represents the complete time (dd/mm/yyyy hh:mm:ss.msec) when some value or event occurs in the REX target. • RexFlags – represents a 32bit flag object to set/get states of REX blocks and models. • RexVersion – encapsulates complete information about REX version (hiVersion, loVersion, build no., date of build, etc.). • RexGroup – contains array of XAV instances (values). Variable names are converted into corresponding id’s and stored into RexIdent instance when a RexGroup constructor is executed. It further contains time stamps of the start and stop time of the last read/write command applied to this group. Important is also the field groupID which is set when addGroup() is performed. After that, the fast refreshGroup() command can be used. The illustrating schema of RexGroup can be reviewed in Fig 7. • RexTrend – contains cyclic buffer of REX trend values, current RexTrndReadState, RexTrndCfg and other features necessary to draw trend values into axis figure. The complete description is omited for brevity. 3. Transparent REX objects classes – these classes are internally used by communication classes and for users working at the highest XDGProtocol level are transparent. • RexCmdInit – simple object which parameters are sent to the target when a new XDGProtocol instance is created. • RexCmdHdr – simple object which parameters (especially commandID) are written/read at the beginning of each XDG command/response packet. • RexTrndCfg – simple object which parameters (trend title, number of signals, etc.) are read when new RexTrend instance is created. R145 – 5

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

• RexTrndReadState – simple object which is used in each trend read command to hold the current read position. • RexIdent – contains arrays of variable names and corresponding id’s used for communication (internally used by RexGroup). RexTStamp tBegin

RexGroup shortgroupID

RexTStamp tEnd

RexIdent

values

names

XAV1 XAV2 .... XAVn

String1 String2 ... Stringn

ids RexItemID1 RexItemID2 ... RexItemIDn

Figure 7 – Detail of the RexGroup instance

4. Others • RexError – container of static variables – REX error codes and error strings. • RexConsts – container of other static constants – especially XDG command codes and variable types codes. • RexServerException – is thrown whenever the response packet signalizes any error or warning; it contains the error code and error description string. 5

PRACTICAL EXAMPLES Consider that the REX model called ’mtuner’ (Fig. 8) is running at the target with IP address ’10.1.1.18’. 5.1

Simple data access Firstly, let us show how easily one can get values from any REX target with specified IP address. The following fragment of source code shows all steps necessary to read/write REX values belonging to the controller block PIDMA: ... // create IP adress of the REX target InetAddress target = InetAddress.getByName("10.1.1.18"); // open new XDGProtocol (socket) with given IP adress and port number XDGProtocol xdg = new XDGProtocol(target, RexConsts.PORT_NUMBER); // initialize communication with the REX target xdg.init(new RexCmdInit(RexConsts.XDG_PROTO_TCP, RexConsts.OSP_TCP_DEFAULT, RexConsts.DCIG_STREAM_DEFAULT_SIZE)); ... // create new group to be read with given array of items RexGroup rdGroup = new RexGroup(new String[] {"mtuner.PIDMA:pv", "mtuner.PIDMA:sp"},xdg); // add group to the target and obtain the group handle xdg.addGroup(rdGroup);

R145 – 6

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

tv UP DN y rv LOC

u1 u2 y SW

MCU_SP

SWMAN

y

TDIS

u1 y u2 u

y

GAIN

y

PDIS

ADDDIS

[sp] dv mv dmv de pv SAT tv TBSY TE hv ite MAN trem pk IH pti TUNE ptd TBRK pnd pb TAFF pc ips sp

[pv]

Y

MAN

[mv]

tv UP DN y rv LOC

PIDMA

u1 y u2

u

ADD

MDL

y

u1 u2 y SW

y

u1 u2 y SW

SINT

SWA

u

SWA1 Y

u1 y u2

ADD1 u

y

u1 u2 y SW

[pv]

SWPV

extpv

ASTAT [mv] [sp] [pv] [mv]

u1 u2

RUN

RUN

MCU_HV

y2

u3 u4

Y

y1

R1

y3 y4 iE

TRND

Figure 8 – Example of REX model ’mtuner’

// read new values of the REX group from the target and print them xdg.refreshGroup(rdGroup); // write the pv and sp values to the console System.out.println("pv="+group.getValueAt(0).getXDOUBLE()); System.out.println("sp="+group.getValueAt(1).getXDOUBLE()); ... // create new group to be written with given array of items RexGroup wrGroup = new RexGroup(new String[] {"mtuner.PIDMA:sp"},xdg); // set the group value and write it to the target wrGroup.getValueAt(0).setXDOUBLE(3.0); xdg.writeGroup(wrGroup);

The source code example consists of three parts: • the first part instantiates the XDG protocol object, establishes the connection with the target a initializes the protocol with default properties, • the middle part creates the group of items to be read, read two REX values sp (setpoint) and pv (process variable) and print them to the console, • the last part creates the group of a single item to be written, sets the new value of sp and write it to the target. 5.2

REX trend To obtain and store values from any REX target, the simple REX trend based on JavaREX interface has been developed (Fig. 9). The user can easily specify the IP address and the trend name (in example model ’mtuner.TRND’) and start values reading. For further analysis in Matlab, Excel, etc., the values obtained can be immediately saved into the text *.csv (Comma Separated Variables) file. 6

CONCLUSIONS The developed JavaREX interface is very useful in both educational and practical areas. The students will extend the Java skills in more practical fields e.g. industrial protocols, data acquisition and R145 – 7

7th International Scientific – Technical Conference – PROCESS CONTROL 2006 June 13 – 16, 2006, Kouty nad Desnou, Czech Republic

Figure 9 – Simple REX trend

HMI systems. From the practical point of view, the new interface allows to create visualization screens for REX based on Java and avoid expensive SCADA/HMI tools (e.g. Genesis, InTouch, LabView, etc.). To speed up the visualization development, one can use a lot of free accessible Java components and tools, e.g. Easy Java Simulations [S´anchez et al., 2004]. Finally, the visualization screens can be presented in a form of Java applets embedded into web pages. In such a way, the developed JavaREX interface provides remote Internet access all over the world. REX and JavaREX can be downloaded from [?, RexControls] References ˇ ETINA, ˇ BALDA, P.; SCHLEGEL, M.; ST M. 2004. An open autotuning PID control remote laboratory based on industrial standards. In Preprints of the IFAC Workshop IBCE’04 Internet Based Control Education, 1–5. Grenoble, France. ˇ ETINA, ˇ BALDA, P.; SCHLEGEL, M.; ST M. 2005. Advanced control algorithms + simulink compatibility + real-time os = rex. In Proceedings of the 16th IFAC World Congress. Prague. ICONICS 2006. Iconics web page: http://www.iconics.com. OPC FOUNDATION 2003. OPC Data Access Custom Interface Standard Version 3.00. http://www.opcfoundation.org. ´ SANCHEZ, J.; DORMIDO, S.; ESQUEMBRE, F.; PASTOR, R. 2004. Interactive learning of control concepts using Easy Java Simulations. In Preprints of the IFAC Workshop IBCE’04 Internet Based Control Education, 1–6. Grenoble, France. ˇ ETINA, ˇ SCHLEGEL, M.; BALDA, P.; ST M. 2001. C mex blockset for industrial automation. In ˇ Proceedings of the 9th Matlab Conference (in Czech), 361–369. Prague: Vydavatelstv´ı V SCHT. SUN MICROSYSTEMS 2006. Java technology web page: http://java.sun.com.

R145 – 8