SOFTWARE FOR DATA ACQUISITION AND CONTROL

ABSTRACT

A software package for data acquisition and control of real-tine processes is described. The system is built as a number of separate tasks, which define their own commands and variables, and is easy to expand with new facilities. Common variables are globally accessible, and tasks may request “software interrupts” whenever a particular variable has been updated. The system is process independent except for the task which interfaces directly with the actual process.

Keywords. Computer control, computer software, control system synthesis, data acquisition, on- line operation.

INTRODUCTION

This paper describes the ideas behind a recently developed software package for data ac- quisition and control of real time processes.

Our first experience with real time systems dates back to the mid-seventies, where we developed a real time system for control of a fixed-bed reac- tor (3). During the years since then, where we have investigated widely different control strate- gies on the reactor, we got increasingly frustrated with the shortcomings of that system due to it’s lack of modularity and flexibility.

Exisitng packages which do offer these advantages can be divided into two main groups: those intended for university use, and those in- tended for industry use. Packages in the first group are primarily intended for teaching purposes, and hence seldom have any real time facilities at all, but they put heavy emphasis on the simulation aspect and the offline analysis of control systems design. Commercial packages often are intended for control of industrial processes, and therefore have good real time facilities, but they are usu- ally very closed in the sense that addition of e.g. a new controller type is very hard, if not altogether impossible, to come about, and also the data processing facilities tend to be meagre.

The system being described here is intended for use in a changing environment, where we want to investigate new ideas concerning control sys- tems design, and therefore needs flexible access to measurements and actuators, and the ability to perform extensive manipulations on recorded data. At the time teing, the package does not include all the features one would like to have in such a system, but the design concept is chosen such as to allow easy expansion when the needs arise.

In order to facilitate maintenance and fu- ture expansion, we have made extensive use of modern software design methods, such as described by e.g. Aho and Ullman cl), and Gomaa (2).

In the following paragraphs we shall describe the main ideas concerning the overall design con- cept and the system interface to: the operator, the process and the file system. These three in- terfaces are the core of the system upon which all facilities are built.

DESIGN CONCEPTS

The main components necessary to run, moai- tor and control a process are wieved as being:

- a process

- a terminal for an operator, monitoring the process measurements, and nanipulatiag the process actuators

- a mass-storage device with a data base, coa- taining a log of “what has happened” (i.e., previous measurements, control actions, error conditions etc.).

Each of these pieces of hardware has an associated software driver (task), called the process manager, the operator manager and the data base manager. The “managers” communicate with each other using well defined interfaces. These tasks are the framework of the minimal system - other tasks may be added for special purposes (e.g., automatic control, special graphics representation).

One crucial point of the software is to write it as system independent as possible, coa- sequeatly the data base contains no information of the process manager.

Our main goal in the design of the system has been to ensure a high degree of flexibility. This means that:

- the system is built as a number of separate tasks, which can be added and deleted as needed, online. Thus, also system maintenance and documentation is made easier, since each task does a well-defined job, and has a well-defined interface with other tasks in the system. The drawback of this approach is that more overhead is involved in passing information from one part of the system to another, hence overall perform- ance is slower, but we have considered this obstacle a minor one compared to the obvious advantages.

the system is process independent, except for the task which interfaces directly with the process in question. We have not thought it feasible to acquire process independence at this level, since so many different interface types are in

use, ranging from D/A and A/D converters to serial interfaces of various kinds. But since the process interface task also has a well ds- fined and limited job to do, it will not be tao hard to rewrite this task when a new Process is considered.

each task defines it’s awn “environment.” Upon initialization 3 task, among other things, creates it’s own set of commands. Thus, when the operator enters 3 line contafnfng 3 command belonging to some task, the line (sfter suitable r decoding) vfll be passed on to that task for execution.

the system should be as machine independent 3s possible. Hence, all programming is done in a high-level language (in this case, FORTRAN 771, and machine dependent features are eollect3d in a limited number of modules. Thutus, transporta- bility is eased.

fntertask Communication

Tasks communicate through variable-length buffers, which 3re marked with a sender and 3 recefver task number, and 3 flag, which is used to denote buffer type.

A task nay read it*.9 own buffers on a ffrst- inffirst-out basis, or setecttvaly by Specifying the desired sender task number and/or the desired flag. If no buffer of the specified description is available, the receiving task may either suspend it’s execution until another task h&s sent one, or continue $%X$XWtfQki.

T&e roessage buffer arr?B, as we11 as thQ common variable area, is part of each job’s ad- dress space, but is accessed only through SystQm routine calls, thus ensuring a high degree of protection and a well defined task interface structure. The system routines also ensure that only one task at a time can read or write these common areaS.

Another means of comm~~~catio~ is thraugh the “notify” interrupts, described later, which make updated variables known to interested tasks. The notify concept also is implemented through message buffers, flagged uiCh a special “notify” flag.

System Variables

Common variables <as well as reserved words) are created as needed using commands like

CREATE T14 REAL ‘DEG C ’ which makes the supervisory system enter the identifier +I14 in a table, gives T14 type REAL, and associatps uith it the text string ‘BEG C’. Cnly the task which has created a variable can change it’s value, but aLI other tasks may read that variable. Access to the common varia- bles is given Chrough system routine calls, and only one task at 3 time has accass to the ares where the variables are stored, Thus it is pussl- bPe to ensure uninterrupted (simultaneous) up- dating of a number of variables.

Noiffy

An important feature of the system is the so-called “notify” concepC, which allows a Cask to be “notified” whenever a variable has been updated, A task (e.g., 3 control task, or the data loggfng task) which must know when 3 variabfe has changed value, does so by requiring 3 notify on that vari- able. Ti’ie syste~l then sends a message to the task every Lime the variable has changed value, thus relieving the task of cons.tnnCly monitoring the value of that variable. The purpose of the nbCify

thus fs to generate a kind of software interrupt. Variables updated simultaneously generate only one notify message, thus redwcfng the number of notify messages, and Preserving variable synchronization.

This is also the principal way of introducing sampling times, as discussed in the description of the process manager.

THE GPPZATOR MANAGRR

The operator manager fthe supervisory system) is respaasfbla for consun~catio~ with the operator, and for general system supervision Such as creation of variables, starting of tasks etc.

Input Line Processing

Input Ifnes may originate from different sources:

- frOm the te?Xin& (cperatnr-entQrQd 1fReS).

- from other tasks (i.e., input lines which create new commands, or which are commands to other tasks 1.

- from a “bafch processor” which reads input Iines from a file ftkfs facility 1s especially useful during start-up).

Whatever their origin, all input lines are parsed by an input 1EnQ processor, and passed on to the appropriate command-owning task for execu- tion. The general syntax is:

‘reSliSt’ *command’ ‘exlfst’

where

‘reslist’ is a list of resQrvQd words, separated by blanks or comma, ‘reslist’ may be empty.

“command’ is the co~and name,

‘exlist’ is a list of expressions, separated by blanks or comma. Each rlement of ‘exlist’ ir:

- a single identifier (i.e., a varfa- ble name, a constant, a reserved word, a text string, etc.1

- an expression {i.e., X * GW2*PIY))

- an assignment (i.e., P 111 C*5 + C*3.48) ‘exlist’ may be empty.

The fnput line processor replace3 al1 Sden- tffiers etc. by pointers to the appropriate tables, and converts expressiona into postfix Polish notation (but does nor actually evaluate expres- SiOns)*

This input line structure allows 3 very flexible type of command, but does incur a certain amount of input line validation on the command owning task.

Cornsands, which do not need the general StruCCure of ‘exlist’ may be declared to accept a subset of ‘exlist’ components only, namely:

text strings only, in which case the part of the lina following ‘command’ is passed on without any processing.

a list of ZdfnCifiers and constants only, in trhl.ch case rhe input line processor rejects expressions and assignments as components of ‘exrist’, thus relieving the command owning task of Chis type checking.

The lexical analyser, which identifies the components of the input line, and the parser generator have been constructed following the ideas of Aho and Ullman (1).

THE PROCESS MANAGER

The process manager is responsible for communication with the process, and is the only part of the system which has any built-in knovledge of the interface structure.

Among the commands that the process manager will recognize are commands to configure measure- ments and actuators that fs. to establish connec- tions between e.g., a D/A converter channel and a common variable, and to convert the readings to engineering units before updating the associated common variable.

Also, the process manager may collect a set of measurements into a sample which is updated simultanteously whenever all the pertinent mea- surements have been taken. The definition of which variables go into a sample is given as a command : thus, very little a priori information is assumed, but the entire configuration is command driven, and thus may be changed online if needed.

Depending on the process, sampling intervals may be fixed or may be given a8 a command, but the Test of the system has no (and need not to have any) knowledge of sampling intervals. Also, dif- ferent samples may have different sampling inter- vals. For example, some measurements are taken on a regular basis, whereas others, such as e.g., binary alarm signals, appear infrequent and on an asynchronous basis.

When the process manager receives a command to start a (previously configured) actuator, it requests a notify on it’s associated variable and thus will be informed whenever another task (a control task, say) updates the actuator variable, whereupon the process manager can effectuate the change. Thus, a control task and the process manager need not “know” each other, but are inde- pendent. This also means that it is easy to perform, say, a simulation of the process in question, since only part of the process manager has to be changed.

THE DATA BASE !iANAGER

The data base manager is responsible for communication with the file system of the computer. The data base contains information about:

- online data: measurements, message/error log, etc.

- configuration data: links between process and internal variables, conversion factors, etc.

The main job of the data base manager is to store and retrieve measurements and other vari- ables which must be logged whenever they are updated.

As soon as the data base manager is ordered to start logging certain variables it issues notify requests on those variables, and hence- forth gets messages whenever these variables change value. Variables which are updated to- gether, and therefore are placed in the same notify message, will be stored together in the same record, making up a set. Each record consists of a time indication, a set indication, and the values of the variables belonging to the set. Another Eile then contains set definitions with conversion factors, units, etc. Thus, new

log variables may be added during an experiment since no priori information (about record length, no. of variables to store, etc.) is assumed, but the informaiton is created online. The data log- ging file is binary, with all values converted to integer representation in order to save space.

tnother important job of the data base manager is to store and keep track of various messages such as error messages. usage of certain commands, etc. These messages are stored in text files and thus may be easily inspected af tervards.

CONCLUSIONS

The data acquisition and control system described here is designed with strong emphasis on future expansion possibilities. The system is best suited for real time applications, but may also be used for off-line analysis such as simulation and 4dentification studies. Thus, we think that it can be used to great advantage as a core system in future projects concerning real time control, and that it will satisfy most of our requirements on a flexible real time control system.

The system is being implemented on a PDP 11/73 running RSXll?4+, and the first application will be the control of a distillation column with about 100 analog measurements and 15 actuators, and about 200 binary control and status signals. our ultimate goal is to develop a system which we can take out in industry and connect to existing con- trol hardware, and thus with little effort be able to test our control methods on industrial relevant problems.

ACKNOWLEDGEMENTS

The author8 gratefully acknowledge many stimulating diSCUsSiOn uith Prof. Sten Bay Jorgensen, with Niels Held Pederscn and Bjarne Toftegaard during the course of this project.

REFERENCES

1. Aho, Alfred V. and Ullman, Jeffrey D., Princi- ~a:~,~~,C~t:~s,~~sign. Addison-Wesley.

2. Gomea, H., “A Software Design Method for Realtime Systems,” 949 (1984).

Corms. ACH, 27, 9, pp. 93g- --

3. Sorensen, Jan P., “Experimental Investigation of the Dynamics of a Fixed-bed Reactor.” Chem. Engn. Sci., _, 31 pp 719-725 (1976).