A Status Report on REACT, a Control Engine that ...

35 downloads 611 Views 189KB Size Report
created for data logging, control, and monitoring, ... ments, air conditioning monitoring/control, pump .... cessing the object header file with a special keyword.
A Status Report on REACT, a Control Engine that runs on top of GNU/Linux for Creating SCADA and DCS Systems Don W. Carr, Rub´ en Ruelas, Benjamin Ojeda Maga˜ na, Adriana Corona Nakamura Universidad de Guadalaara Jos´e Guadalupe Zuno 48, Col. Los Belenes, C.P. 45101, Zapopan, Jalisco, M´exico [email protected]

Abstract REACT is a control engine that runs on GNU/Linux, written in C/C++, for creating SCADA and DCS systems, or just simple controllers for a single machine or laboratory equipment. The design was based on the experience of the author on large SCADA systems for natural gas pipelines, natural gas distribution systems, and water distribution systems, software for testing military, industrial, and light vehicle transmissions, and research on control systems in general. REACT was designed as a general purpose control engine to scale similar to how GNU/Linux scales: from tiny embedded devices in the field, all the way up to large computers. Thus, REACT can run as the central software on a server as a SCADA system, and can also run on small hardened devices as the software for an RTU, or DCS controller.

1

Introduction

is supported through a code generator that automatically generates the code to link the script function to the object.

The development of REACT [1],[2],[3], was started in 2002 for Masters students at the University of Guadalajara, so that students would be able to actually see the software used for real-time systems and take the mystery away. It was first used for a project of two electronics masters students to automate a liquid chromatography instrument, with robotic system for changing samples, for the molecular biology department at the University of Guadalajara. REACT allows the configuration of all the common objects often referred to as point types or tagnames that are common for a SCADA or DCS systems: analog input, analog output, discrete input, discrete output, timed discrete output, pulse count input, PID controller, etc. A variety of other object types have been created for data logging, control, and monitoring, etc, for special applications such as laboratory instruments, air conditioning monitoring/control, pump station monitoring/control, silo monitoring/control, etc. There is also a scripting language with the scripts tokenized for faster execution. Scripts can call member functions of all the REACT objects, which

2

REACT Driver Model

When we started out, the code to communicate with the data acquisition card was compiled directly into REACT, and communicated with the factory driver that was a shared object file (.so). The problem is that it created a dependency on a particular shared object file, and the code had to be commented out for other systems that did not use this code. So, we quickly moved to putting the driver interface code into shared objects that can be loaded on demand using the system API dlopen(), dlsym(), dlerror(), dlclose(). To support objects, we use this API to load an object factory function that is called to instantiate an object that inherits from our abstract base class iodriver t which defines the interface to all I/O drivers. The factory function for each driver must return a pointer to iodriver t. We currently have drivers for Modbus RTU, Modbus ASCII, Modbus 1

be done using code generation from a configuration file that named the database field names/types, and the corresponding field names in the objects. We also quickly realized that this same configuration file could be used to convert existing projects with delimited text files, to use database files. Finally, the existing user interface was a text editor to edit the delimited text files, and we would need a new user interface to edit the object configurations/configure REACT. With these same configuration files, if we add a few prompts, and a few other simple things, we can generate either a web based user interface for editing the configuration, or, a text interface, based on curses, to edit remotely via ssh. We have implemented the code generator for converting existing projects, and to read/write the configurations from REACT, and are working on generating a web interface so that we can offer an online configuration editor. For now, we are using the SQLite console application to remotely edit configuration parameters via ssh.

TCP/IP, various PC data acquisition cards, Dallas 1-Wire via the OWFS project, a simple ASCII protocol that we developed, and, some simulators that we developed that load as drivers. This driver model allows us to write a simple simulator that loads as a driver to use during testing, and then switch easily to the real driver in the field. It allows us to keep the code compact for memory constrained embedded systems.

3

REACT Object model

We needed an object model to implement all of the control engine objects, often referred to as point types or tagnames, or just tags. Actually, we identify all control objects by their tagname which serves as a unique ID. As you will see, there is a need to have a unique ID to refer to objects from scrips, displays, etc. We have four basic types of objects: 1) Input objects that receive process values via a device driver, 2) Output objects that send/write process values via a device driver, 3) Control objects that access process values via input objects, and send process values via an output object, and, 4) Objects that only calculate values, do data logging, do user interfaces, etc. Currently, all of the object types must be hard-coded into REACT, but, we are in the process of switching them to be all loaded on demand at load-time, if they are needed for a particular project. We have started by implementing dynamic loading for one object type (analog input).

4

See below, the configuration file for discrete outputs in Figure 1, and then, the user interface generated from this file, in Figure 2.

REACT Configuration

Like many projects, we started out storing all configuration in a directory full of delimited text files. However, there are possible corruption problems, and it is tedious to copy all of the files to the target system, and retrieve all of the configuration files, after local changes have been made, for backup. For this reason, we are moving to putting all of the configurations into SQLite, to eliminate the problems of corruption by using transactions, and, thus simplify copying the configurations to a target system, and backing up, since SQLite stores the complete database with all tables in a single file. SQLite is also extremely compact and can itself be loaded when needed, and then unloaded using dlopen(), dlsym(), dlerror(), dlclose().

FIGURE 1: Config File used to AutoGenerate code for Discrete Outputs

Faced with the need to write all of the functions to read/write the configuration for ALL object types, we quickly realized that it was repetitive, and could 2

things like sleep, wait for condition to be true, wait for user input, write text to output, etc. These scripts have proven to be very useful and have been used on many different projects. Below is an example of a script to control the level in a tank between a low point and a high point. We basically open the valve when we reach the high point, and close the valve when we reach the low point. The tag hi level is a discrete input connected to a level sensor that is on/true when the water is at or above the high point. The tag lo level is a discrete input connected to a level sensor that is on/true when the water is at or above the low point. The tag valve 2 is a discrete output that activates a drain valve that is opened by sending the value true, and closed by sending the value false. The 15 second wait was introduced to avoid the valve opening and closing in rapid succession when a wave was generated.

FIGURE 3: Example Script to Control Level in a Tank

FIGURE 2: Auto-Generated Form for Discrete Outputs

5

As an alternative to scripts, we are also working on state diagrams [4],[5] to describe control algorithms/sequences. For state diagrams, we will still use the script commands described here to specify actions that take place on arriving at a state, or leaving a state.

REACT Scripts

Early on, we realized the need for simple scripts so that common users, that may be control experts, but, are not programmers could extend the funtionality of REACT by creating, for example, test sequences, control sequences, interlocks, alarm sequences, shutdown sequences, etc. Thus, we developed a parser to tokenize scripts for faster run-time execution, and a code generator to bind scripts to actual C++ object method calls. The code generator works by processing the object header file with a special keyword (SCRIPT OBJECT) added (in comments) above objects that support script functions, and then another special keyword (SCRIPT FUNCTION) above each method that can be executed from a script. Using the tagname, at load-time, we can identify the object, verify it has the method with the given name and parameters, and bind to that object/method. Thus, at run-time, when the script reaches the line with this method call, the given method is called, on the given object, with the given parameters.

6

Conclusion

We have created REACT, a very useful free software application that runs on GNU/Linux for creating SCADA systems, DCS systems, simple machine/instrument controllers, etc. REACT is extensible through creating new objects written in C/C++, and also, for non-programmers by writing REACT scripts. We make extensive use of code generation for repetitive programming tasks to save time and eliminate errors, and enable new funtionality to be added faster. We use dynamically loaded shared objects for drivers and REACT objects, to eliminate dependency conflicts, reduce code size, and allow new drivers/object types to be added without re-compiling REACT.

We also needed to create system functions for 3

References

[3] Donald Wayne Carr Finch, Rub´en Ruelas, Apolinar Gonz´alez Potes, Ra´ ul Aquino Santos, 2007, REACT: An Object-Oriented Control Engine for Rapidly Building Control Systems, Conference on Electronics, Robotics, and Automotive Mechanics, Cuernavaca, M´ exico.

[1] Don W. Carr, R. Ruelas, Ram´ on Reynoso, Anne Santerre, 2006, An Extensible Object-Oriented Instrument Controller for Linux, The Eighth Real-Time Linux Workshop, Lanzhou, Gansu, China.

[4] D. Harel, E. Gery, 1996, Executable Object Modeling with Statecharts, Proceedings of the 18th International Conference on Software Engineering, pp246–257.

[2] Donald Wayne Carr Finch, Rub´en Ruelas, Ra´ ul Aquino Santos, Apolinar Gonz´ alez Potes, 2007, Interlocks For An Object-Oriented Control Engine, The 3rd Balkan Conference in Informatics, Sofia, Bulgaria.

[5] D. Harel, 1987, Statecharts: A visual formalism for complex systems, Science of Computer Programming, no. 8, pp231–274.

4