A Knowledge-Based Environment for Intelligent Design and Supervisidn of Control Systems

L. V. R. Armda, R. LUders , W. C. Amaral, F. A. C. Gomide

Faculty Of E l d c a l E@neering - FE / DCA

UNICAMP, P. 0. Box 6101

13081-970, Campinas SP, Brazil

Abstract Most industrial processes have several particular characteristics, system requirements and pufomance which may not be obtained by classical control methodologies. In this case advanced control strategies must be considered. In face of different options, testing in simulation environments using software packages is a camnon practice. In this paper, an environment aimed at integrating different software resources in a consistent and d o r m way is proposed. It is based on object-oriented approach implemented into a knowledge based shell. In addition, full potential of knowledge based systems can be used for intellgent decision.

1. Introduction Industrial process control commonly requires the implementation of complex systems where controllers must satisfy different requirements such as stability and robustness, without degradation of the overall system performance. In this case advanced control methodologies must be considered and many tasks such as problem formulation, model validation, design methodology choice. closed-loop execution and supervision should be performed. Intelligent control is coming up as a promising scheme where hybrid approaches which include procedural and heuristic control actions are considered.

In face of different options and a large number of computational algorithms. testing in simulation environments is a need. Simulation can be used to validate a specific approach before application in a real process. Computational support, such as CAD systems, is an essential tool for control engineering tasks. Today, expert CAD systems are also available. Among them. a diversity of system architectures are noted 12-71. These systems are primarily aimed at environments for system development. The capability to self adapt to the user needs is fundamental. In many systems, the overall package functionalities are always present independently if, for instance, the user needs only a small set of the available tools. This is a serious drawback because the

resulting soft" is often large. ineffiient and difficult to

Moreover. architectures used by environments designed for control system development is typically composed by three basic parts :

a set of tools implementing tasks like simulation, control, analysis; an interface to make task specification more suitable for the end-user.

* a main program to coordinate the tools and interface execution

use.

In this case, a set of tools is usually implemented by programs with a structure that maps system tasks as a sequence of user actions and tool calls. This information is embedded in main program code lines. Every future modification (inclusion of new tools. new user options or system reduction) modifies the main program structure. If modifications are not handed properly, the resulting software is often inefficient and Micult to maintain.

In this paper a system architecture to model the main program role in a more suitable way for modifications and evolution is proposed. This architecture is based on the object-oriented approach, with a graphical representation of the information flow derived from the main program structure. A knowledge- based system is used to manage the software resources and to make easy the user-interaction. The final environment supporting intelligent design and supervision of control system is developed to satisfy the following requirements:

a modular and flexible environment; interaction with available control tools; easy and uniform user interaction; knowledge representation capability.

The architecture proposed herein is being implemented in a Sun SPARC station based network using G2. a real-time expert system shell. and MATLAB package. The final

0-7803-21294194 $3.00 (b 1994 IEEE

environment is aimed at education, research and development purposes.

The paper is organized as follows. Section two introduces a formal description of system architecture. Section three makes an implementation description of system architecture using G2. section four gives an application example using MATLAB as an engine machine. Finally, section five presents the conclusions and future developments.

2. System Architecture

The proposed architecture models the main program through a set of objects, a connection diagram and a scheduler as shown in Fig. 1. Objects encapsulate algorithm models while the connection diagram represents flow information between objects. The scheduler translates connection diagram associated with the object definition into a suitable sequence of execution using various software resources. These resources are part of the object definition where they return their results. The user acts upon the system through an user interface which is a part of the object definition and the connection diagram. It provides user interaction with the software resources and can be used to modify the information flow among objects. The system has also a logical inte.ger clock representing the sampling time interval. At each time interval. the scheduler searches for an algorithm execution.

OBJECT DEFlNmON OBJECT CONNECTION DIAGRAM

I I

MAIN PROGRAM MOOEL

I EXECUTION

Fig. 1 - System architecture.

Object definition

An object models an algorithm with the following attributes :

stunts : algorithm status (see scheduler); time-increment : time interval for algorithm execution; last-update : last time that the algorithm was executed, input : algorithm input data; output : algorithm output data; parmeters : parameters to adjust algorithm behaviour; user-interface-resources : algorithm interface objects to

Each object is associated with a behavior, implemented by various integrated software resources. For example, an object

user interaction.

may have a procedural behavior implemented by means of a specific subroutine, a mathematical tool or a library function. During an execution. if an algorithm must be executed. its associated object receives an executing-message from scheduler. Then the data related in input attribute are collected, the algorithm code runs and the variable in outpuf attribute are updated.

Connection diagram

The connection diagram establishes the information flow between algorithms. It can represent processes (plant). controllers. or both as shown in fig, 2. The connection diagram is a graphical representation of the algorithm procedures dependencies. i. e., a visual representation of how the algorithm procedures depend on each other. This representation can be easily and consistently manipulated to create, to modify and to destroy relations between objects.

I CONTROLLER Objod SUPERVISOR 0bj.d PROCESS wed

XY Fig. 2 - Connection diagrams and their objects.

Scheduler

The scheduler provides control mechanisms to translate the information contained in COM~C~~OII diagram and object definition into a suitable sequence of software resource calls. These control mechanisms are deagncd to provide complete independence of algorithm details. At the scheduler level. an algorithm is viewed as a processing cell that collects input data, returns output data, and inserts in a context of dependencies, i.e. it depends on the other algorithm results. This level of abstraction allows the use of a number of algorithms in a uniform and distributed way. The scheduler sets different algorithm status and uses a set of rules for status transition. as shown in fig. 3.

Fig. 3 - Algorithm status and status transitions.

268 1

The status definition is :

OK : the input and output algorithm data have valid values until the next algorithm execution time;

CHECKING : the algorithm must be executed in the actual time interval and the scheduler is testing dependencies of other algorithms;

pRE(poST)-WAITING : there are not enough conditions to execute an algorithm and it must waic

*HISTORY : all algorithms are waiting for executing Conditions but any event can change this situation. This deadlock situation can occur in a C O M ~ C ~ ~ O ~ I diagram with feedback;

EXECUTZNG : an algorithm has collected input data, started execution of the associated code, and is waiting for results;

COMPLETE : the algorithm has received the results;

*ERROR : the algorithm did not run in the same time interval (it must sign inconsistent information flow ).

The set of rules defining status transition is derived (for each algorithm A contained in the C O M ~ C ~ ~ O ~ diagram) by analysis of the necessary conditions for status change as follows :

OK-KHEXXNG : rime-increment and last-update of A define the execution of A in actual time interval;

-G+PREbWmG : an algorithm connected to the input of A must be executed before;

CHECKING+POST-WAll"G : an algorithm ~ ~ ~ e c t e d to the output of A cannot receive input data;

CHECIUNG+HISmRY : all algorithms have pre-waiting or post-waiting status;

*PRE(POS")-WAI"G+CHECKING : the status of an algorithm connected to either input or output of A was set to OK;

HISTORY4XWKING : the status of an algorithm into a feedback loop was set to OK by validating the input and output algorithm data with values calculated in the last execution time;

CHECKING+-G : all algorithms connected to the input of A have valid output data and all algorithms connected to the output of A are ready to receive new input data;

EXXUIING-XOMPLEWE : the code associated with A was executed and the results were returned,

same time interval;

interval.

COMPLETE+ERROR : A was not run successhrlly in the

COMPIETE+OK : A has run successfully in the same time

3-62 System Implementation The Real-Tune Expert System G2 [81 is a shell for knowledge-based system development. It was chosen as a development tool for implementing the architecture presented in last section due to the following features :

hybrid knowledge representation : object-oriented, rule-

communication interface with &mal programs; powerful user interface and debugging facilities; incremental and modular development system documentation facilities.

The architecture implementation with G2 is shown in fig. 4. The main program model was entirely implemented in G2 using its inference machine to construct the scheduler block and to execute global coordination. Algorithm codes are distributed through many softwares running at the same or remote G2 machine in a network. The GSI package (G2 Standard Inkrface) is used to access external softwares and to perform suitable routing of G2 sends and requests.

based and procedural formalisms;

DEFINITION

ALQORITHMS

MATHEMTICAL PACKAQES

Fig. 4 - Architecture implementation in G2.

System implementation is beiig done in a modular fashion. This is useful in incremental system development, because developers can easily introduce or reduce system features. The modular architecture is shown in fig. 5.

TOP LEVEL

Fig. 5 - Modular system implementation.

2682

In fig. 5 TOP LEWL module represents the final application, i.e. the system itself. TOOL modules are specified by the developer and contain specific tools for tasks like simulation, control or analysis. Dotted lines means that certain modules may or may not be present in the final application. USER INTERFACE module provides the elements to support consistent user interface development. Finally, the SCHEDULER module defines the algorithm class and contain knowledge to implement the scheduler policy.

Algorithm class definition

The algorithm class attributes for corresponding objects are : status, time-increment and Ius-update. Every algorithm object defined by developer is a subclass of an algorithm class and they may have particular capabilities (like input, output. parameters and user-interface-resources).

i( MY-AL50RITHMClASS \ ALGORITHM CLASS

OTHER ALQORITHM CLASS 3

This garantees proper scheduler functioning, providing the flexibility to accommodate particular algorithm features.

Scheduler rules

The scheduler policy was implemented by four rules and four procedures - one rule for each main status. Rules deal with status transitions, while procedures take actions such as attribute condition tests and status set. Rules are fied by forward chaining after algorithm status change. The last rule and procedure have a special role. When the scheduler sets the status of an algorithm to EXECUTING it gives control to the algorithm. enabling the execution of actions programmed at algorithm level. The end of execution is signed by setting the algorithm status to COMPLETE. returning control to the scheduler. While an algorithm is running, the inference engine maintain the scheduler policy over other objects.

fw my d#hn G if the stahis of G is CtECKlNG then

rM sIgorithn-check (0) ALGM1ITHM-CHECK

for any mlgorithm G if the slatus at Q la COMPLETE then

ALGORITHM_COMPL€rE start algodlhm-complete (Q)

I f m e r t a ~ r o f O i r OKthen ALGORITHM-OK

for my mynlgoilhm M if lhr mtltU8 ol M is EXECUTING lha

start update-mmlgori" M UPDAE-W.ALG0RITHM

Logical clock

The dynamics of status transition is taking into account by a logical clock. It is implemented by a pair rule-procedure as follows.

for any discretedock K for any algorithn G upon the worlupsce of K whenever K receivn I vdue then

start elgori"-search (G) ALGORITHM-SEARCH

I I

For each clock update, each algorithm in the connection diagram is tracked and status transition started. Clock update is either done automatically by the inference engine in normal mode or manually (step by step) in debug mode.

4. Application Example The application example is a prototype for simulation and control of a multivariable process: a distillation column.

The whole plant is shown in upper left corner of fig. 7. There are five objects in the plant (sub-classes of algorithm object) : top draw composition, side draw composition and bottom temperature set-points; shell-process and supervisor. Set- point objects provide set-point patterns to test process behaviour. They can be a sequence of set-point changes or they can be read from real process data. Supervisor object implements intelligent plant dmgnostics. These tasks are separate modules and they will not be presented here.

In TOP LEVEL module the object shell-process is an algorithm object that implements process simulation and control. This module requires USER INTERFACE and S O W R modules.

The process is a heavy oil fractionary column considered in literature as Shell Process. It is based on a model developed by Prett and Morari [l] to include all important control problems of a real fractionary column. The process schematics is shown in right side of fig. 7. The column feed flow provides necessary heat to proper column operation. There are three output flows : top. side and bottom draws. Tap and side product specification are fixed by economic and operational goals. Composition values are measured by analysers in the top and side end. The bottom temperature must be controlled between fixed limits set by operational constraints. There are three control loops to regulate heat flow: the upper, intermediate and bottom reflux duties. Other column parts are bumed by the heat moved and different heat flow rates are needed. These heat flows are time variant. The bottom loop has an enthalpy controller to regulate heat removal through the bottom reflux duty. removed from the other parts acts as column disturbances.

The composition and bottom temperature are the controlled variables. The input variables top and side draws are used to control the top and side compositions, respectively. The bottom temperature is controlled by the bottom reflux duty. Since this module integrates process simulation and control hto a shgle input-oulput model. only values for reference and output are available (control variables are internals). The

2683

control algorithm implemented is a Generalised Predictive Controller with input constraints described in 191.

The main steps involved in module definition are aa follows :

i) identification of input and output variables and algorithm patametus;

i i) data associaton between G2 and algorithm implementation;

iii) user intedace building;

iv) algorithm implementation.

The algorithm implementation (for both simulation and control) is actually coded in MATLAB language. Example of data shared between G2 and MATLAB is shown in fig. 6. This figum shows input and output variables and their respective vector element needed by MATLAB. There is a vector "w" whose elements Contain reference values for top and side compositions. and bottom temperature. These values are specified in G2 and sent to MATLAB. Also, there is a vector "y" whose elements Contain values for top and side compositions, and bottom temperature obtained by application of the simulation and control algorithms upon the references values. These values are requested from MATLAB by G2. The "routing" have the necessary information to associate G2 requests with proper variables mapped either in G2 or in MATLAB. The algorithm code acts upon these vectors for each algorithm call.

Fig. 6 - G2 / MATLAB input and output mapping.

For every time interval, set-point objects provide values for the inputs of shell-process. With these values the control algorithms are executed and the results can be displayed for analysis. Moreover, intelligent reasoning can be done by supervisor object and the cycle repeats until the inference engine stops.

User interface is built creating a process image and a confortable way for parameter adjustment (shown in down left comer of fig. 7). This is done using G2 interface facilities: icon description, input data, display objects, etc. The end-user has a procRss schematic characterized by color graphic multiwindowing display included mouse interaction. In this application example, the workspace Shell-Process-Details is

automatically created and shown by clicking on Shell-Process

any variable caa be dqlayod into a graphics (as shown in pig. 7 for top &uw composition). by choosing the analyzer or another sensor Bssociatcd with the variable. Moreover to prevent the user when a problem or M important event was occurred. the supervisor changes the color of the icon Bssociattd with the variable that has changed. Fbr instance. the following set of rules is used to supervise the flow's composition in an analyzm

object into Plnnt-oVer~iew workspa~e. N~mUieal values f a

la Rukr

icorrcdoc of W to red

icomolor of rhenprocerr to red and edom the opemior Iha "he cotnposilion sct-point was changed Inform the opentar that lhe unit is ope- n RED

if setpoint U YELLOW then change the face icon-cdor of rhell-procers to yellow and inform h e openlor that 'The comporilion sdepoint was changed lnfom the operator that the unit is opentinp in YELLOW state.'

where an analyzer with yellow-icon is under normal operation and red-stare assigns a fault situation. In summary. the user interface is a frontad for external software which is very similar to the operator panel of the real plant.

5. Conclusion

The environment proposed in this paper has four main characteristics: existing software can be easily integrated allowing the use of desirable software properties (access to a large set of solutions to common problems, good numerical properties, efficient implementation, etc.); the end-user interacts with only one interface; modular and object-oriented development allows custom versions to be easily created, and the use of an expert shell allows "intelligent" solutions as a natural option. The potential of the proposed approach is aimed at developing more complex systems integrating control. identification, analysis and design tools.

6. Acknowledgments

The first and second authors thank the C N P W for grants 360669192-1 and 360215/92-0. The remaining authors

2684

are grateful for W q . the Brazilian National Research Council for grants 301345/84 and 300729/86-3 respectively.

7. References

[l] D. M. Prett, C. E. Garcia and B. L. Ramaker, The Second Shell Process Control Workshop, Butterworths. Stoneham. 1990. [21 J. H. Taylor, D. K Frederick, C. M. Rimvall, H. Sutherland, "Computer - aided control engineering environments : architecture. user interface, data-base management and expert aiding". in Proc. 11th IFAC Congress, pp. 337-348, Taillin. USSR, 1990. 131 W. C. Amaral, S. P. Bingulac. P. A. V. Ferreira, W. Fontanini. F. A. C. Gomide, "A knowledge based environment for computer-aided control engineering". Proc. 4th IFAC Symp. on Computer-Aided Design in Control

CAD and supervision of control system", 1st European Control. 1991. [5] W. C. Amaral. F. A. C. Gomide, R. Nauptta and G. H. C. Oliveira, "Intelligent environment for system identification and adaptive control", in Recent Advances in Computer-Aided Control System Engineering, Elsevier Science Publishers B. V.. Edited by M. Jamshidi and C. J. Herget. 1991. [61 G. K H. Pang, "Knowledge Based Control System Design", in Recent Advances in Computer-Aided Control System Engineering. Elsevier Science Publishers B. V., Edited by M. Jamshidi and C. J. Herget. 1992. 171 H. A. Barker, M. Chen. P. W. Grant, C. P. Jobling, P. Townsend, "Open architecture for computer-aided control engineering". IEEE Control System. vo1.13. pp. 17-27. April. 1993. [8] G2 Reference M m l - version 3.0. Gensym Corporation, July, 1992. [9] G. H. C. Oliveira, Internd report. DCA / FEE /

Systems, pp. 23-25, Beijing, China, 1988. [41 L. V. R. Arruda, P. Senges. G. Favier. S . Bueno, E. Acundeger, R. Settineri. "A knowledge-based system for

WCAMP, Brazil, 1993.

r m G2

Click on any compment fW dmlll

SET-POINTS

SHELL-PAOCESS

BOTTOMTEMPERATURE

Controller Parameters

Initial ~orizont (NI)

Prediction Horiront (NY)

contrd ~orizont (NU)

Process Parameters

Upper Perturbation (" Intermediate Perturbation L'stPchastic'

& (TOP]

Fig. 7 - System Interface.

2685