Virtual laboratory communication.

Stremy, Maximilian ; Elias, Andrej

1. INTRODUCTION

Within the project granted by Cultural and Education Grant Agency (KEGA, Nr. 3/4110/06) is realizing the virtual laboratory at the Institute of Applied Informatics, Automation and Mathematics. Main goals of this project are the software design and implementation of the logical controller Siemens LOGO!12/24 RC, needful communication interface--dispatcher and selected virtual processes. With the appropriate reconnection of the particular interfaces (communication dispatcher, virtual controller and virtual process) we are obtaining the possibility for the virtual workstation creating.

Communication dispatcher is the important element of the whole virtual laboratory. Many virtual controllers were created before and at least one process for every such controller, but there was the minimal or none compatibility between various devices (Mudroncik, 2000). The designed and implemented communication interface (dispatcher) for virtual devices is in the fact a process, which is designed to ensure information interchange between virtual controllers and virtual processes (Goldsmith, 1993). It's based on the Client-Server architecture, where the dispatcher acts as a server and all devices and processes acts as clients (Stevens et al., 2003). Communication between dispatcher and process is based on text messages, send through the TCP socket.

[FIGURE 1 OMITTED]

2. COMMUNICATION DISPATCHER

For the implementation of the communication dispatcher was determined Lazarus environment. This development tool meets the basic condition of the project realization--software and hardware independence (Tanuska, 2006). Contains many of the libraries, some of them were chosen for the project realization (e.g. synapse library--provides the functions and procedures covering the TPC/IP communication).

Like all servers, by default, the dispatcher waits for clients. All clients must send their identification data to the dispatcher. This identification contains client's description, number of inputs and outputs. IP address and TCP port number are taken from communication. Multithreading design ensures creating of new thread for communication with every client. Timeout is set to 60 seconds. If there is no activity from client for more than 60 seconds, dispatcher will automatically close connection with it and will end his thread. The dispatcher maintains a "client table" with identifications of all clients. Every client can request list of other clients in system. Client then sends requests to connect his inputs/outputs to outputs/inputs of other selected client(s). These requests are stored in "IO connections" table. The dispatcher acts here like a router and "IO connections" table is his routing table.

Every client has a TCP/IP interface. This interface ensures communication with the dispatcher and translates messages to simple analog or digital values. The process kernel in client doesn't need to know how the data is transferred. This allows easy integration of existing processes and controllers by simple adding TCP/IP interface and doing some minimal changes in source code.

Basic overview of the communication between devices is showed in the figure 2.

[FIGURE 2 OMITTED]

2.1 Messages

The messages are the simple texts used for the bidirectional communication between virtual devices without any need for complex encoding/decoding of the data. The structure of the communication can be divided into 4 parts:

* Identification--client sends this message to identify itself by dispatcher, e.g.: VR SIEMENS_LOGO001 Q08 I08 AQ02 AI03

"VR"--means that this is a virtual regulator or virtual controller

"SIEMENS_LOGO001"--identification name of the controller

"Q08"--means that the controller has 8 digital outputs

"I08"--means that there are 8 digital inputs

"AQ02 AI03"--the controller has 2 analog outputs and 3 analog inputs

* Device list--after successful connection the dispatcher will send list of devices to the new client, e.g.:

VR:SIEMENS_LOGO002:Q08:I08:AQ02:AI03:192.168.0. 23:3334

VR:SIEMENS_LOGO003:Q08:I08:AQ02:AI03:192.168.0. 23:3335

VP:TESTING_BOARD:Q32:I32:AQ16:AI16:192.168.0.20 :3330

VR:SIEMENS_LOGO001:Q08:I08:AQ02:AI03:192.168.0. 22:3334

This means that there are two SIEMENS LOGO controllers on computer with IP address 192.168.0.23, one of them running on port 3334, second on port 3335. Virtual process (Testing board) runs on computer 192.168.0.20, port 3330. The last controller is the one connected with the previous message.

* Values--all values are sent like analog values. This allows to implement voltage hysteresis on the digital inputs, e.g.: P Q1=20 Q2=20 Q3=5 Q4=24 Q5=0 Q6=0 Q7=0 AQ0=10 AQ1=15 AQ2=0

* Assigning inputs/outputs--when a client wants to assign his input to other processes output, he must send following message:

CONNECT I1:P1:Q2 Q1 :P2:I4

This mean that sending process will connect his input #1 to output #2 of process P1 and his output #1 to input #4 of process P2. These four basic messages allow clients to establish connection, configure routing and send/receive data.

3. USAGE OF THE COMMUNICATION

DISPATCHER

The dispatcher allows to create a Distributed Control System. Figure 3 shows, that there can be near unlimited number of clients in the system. We can run virtual PLC (Programmable Logic Controller) on the one computer, virtual process on the second computer and the dispatcher itself on the third computer. We can also, for example, run ten virtual controllers, twenty virtual processes and for all of that we need only one dispatcher.

Our design allows to cascade controllers (output of one controller is connected to input of the other one etc.). The dispatcher doesn't make difference between processes and controllers--all that are just clients with some inputs and outputs. TCP/IP implementation allows process cooperation through the internet.

[FIGURE 3 OMITTED]

3.1 Connecting to other systems

Any system with ASCII driver support is able to connect and communicate with our system. For example: The ControlWeb (SCADA/HMI software) contains free ASCII driver for communication with devices on RS232/RS485 port (Holoubek et al., 2006). We have created small application that parses all data from TCP/IP stream to RS232 stream. We have used a virtual driver to create new RS232 port. ControlWeb can connect to this port and communicate with devices in system through dispatcher. The example of such connection shows Figure 4.

[FIGURE 4 OMITTED]

Actually, for better usage with ControlWeb software, we are designing a native driver for ControlWeb 5, based on ControlWeb's DDK.

3.2 Connecting to real devices

There is a possibility to connect a real regulator/PLC into system to control some virtual technological process or otherwise--control real technological process with virtual controller. Interfaces to Advantech DAQ devices, such as PCI cards, USB DAQ and Advantech ADAM are currently in development stage.

4. CONCLUSION

Dispatcher was developed in Lazarus/Free Pascal to achieve good readability and maintainability of the whole system. The system was tested on both main OS (Win32 and Linux), what means that the dispatcher is platform-independent and due to Free Pascal Compiler can be compiled for Win32, Win64, WinCE, Linux, FreeBSD, MacOS and other systems without changing the application code (or just with minor changes).

At the present time is finalizing the implementation of the interface to SCADA/HMI system in the environment of ControlWeb 2000 and also is designing interface to real I/O will improve scalability and extensibility of the whole system in the near future.

5. REFERENCES

Goldsmith, S. (1993). A practical guide to real-time systems development, Prentice Hall, ISBN 0-13-718503-0, Hertfordshire

Holoubek, L.; Kukla, R. & Kadlec, R. (2006). Monitoring of glasshouse climatic processes with the proposal of their control. Research in agricultural engineering, Vol. 52, 48-54, ISSN: 1212-9151

Mudroncik, D. (2000). Control system software, Vydavatel'stvo STU, ISBN 80-227-1341-4, Bratislava

Stevens, W. R. Fenner, B. & Rudoff, M. A. (2003). Unix Network Programming, Addison-Wesley Professional Computing Series, ISBN 0-131-411-551, Boston

Tanuska, P.; Mudronclk, D. & Kunlk, S. (2006). The virtual laboratory realisation of industrial programmable controllers. Materials Science and Technology, Vol. 6, Nr. 4, ISSN 1335-9053.