- Email: [email protected]
CATPAC - An Interactive Software Package for Process Analysis and Control
COMPUTER AIDED DESIGN OF DIGITAL COMPUTER CONTROL SYSTEMS I
Copyright © IFAC Software for Computer Control Madrid, Spain 1982 -
CATPAC - AN INTERACTIVE SOFrWARE PACKAGE FOR PROCESS ANALYSIS AND CONTROL M. Barthelmes, P. Bressler, D. Biinz, K. Giitschow, and U. Schreiber
J. Heeger, R. Kersic
Philzps GmbH Forschungs laboratorium Hamburg, Postbox 540840, D-2000 Hamburg 54, Federal Republic of Germany
Abstract. The automation of complex industrial processes can only be carried out by the use of efficient computer-aided tools. The CATPAC software package provides a powerful tool-box containing mathematical algorithms for process analysis, design of control strategies and simulation of dynamic systems. Keywords. Computer-aided techniques. control system analysis. process analysis. process control. software package. BASIC CONCEPT OF THE CATPAC SOFTWARE SYSTEM
INTRODUCTION If we have a look at the automation of an industrial process, we can distinguish several phases:
The CATPAC software system appears in different ways to
o Firstly the control engineer needs a mathematical description of the dynamical behaviour of the process. Such a model may be calculated from measured values of the input and output signals. o The next step is the design of a suitable control strategy based on the resulting model of the process analysis phase. o The derived models of different controllers serve as input data for the design of the control system itself.
o the user, o the procedure programmer, and o the administrative function programmer. The user is, for example, the control engineer. He activates a procedure to apply it to input models and to generate output models by an appropriate setting of procedure specific data. Then he has to discuss and assess the results to decide about further steps. A procedure is a programmed method for a control task.
o Afterwards the set-up and installation of the instrumentation system has to be carried out.
The procedure programmer makes such a method available within the CATPAC system. The written program has to meet some restrictions according to documentation and standard service routines.
o So finally the initial operation and tests of the complete system may start. In practice the sequence of working steps described above may have to be suspended in any stage because of insufficient results.
The administrative function programmer is responsible for all programs called service routines which enable not only a comfortable procedure development but also a faultless support to users of the CATPAC software system.
In this case the sequence will have to be repeated once more, starting at an arbitrary previous step. The CATPAC software system, the concept of which is described in this paper, shall support the first two phases: process analysis and design of control strategies.
The typical approach of the user for solving control problems is an interactive one, so CATPAC is designed as an interactive system. This feature induces the choice of procedures as well as the choice of the input mo183
M. Barthelmes et al.
184
dels during runtime. The results are to be presented graphically whenever possible, and they are stored as input models for other procedure activations or for detailed discussions of the resulted model dependent on the design parameters. So, stress is laid on dialogue, graphic, and documentation as well as on model and procedure handling capabilities. With the intention sibility to insert dures or to delete performance of the adapted to varying
to provide the posadditional proceexisting ones, the system can be requirements.
The system will be available on a process computer. Using some features of a real-time operating system the realization of the conception of the system may be more efficient. To facilitate a transfer of the system to other process computers the software package must be portable. Portability is influenced by the chosen programming language and by the interface to the computing system environment. So, great care has to be taken in these areas. The system is supposed to be available for a long life cycle and to be used frequently. For this reason the security aspect of the programs becomes very important, especially concerning the data security when a system break-down occurs, and also in case of runtime errors of procedures. Readability of program source texts will simplify the construction of correct programs, ensure an easy maintenance, and help to become acquainted with the system. Readable programs can be set up by comprehensive documentation as well as by considering DiALOGUE ORIENTED CATPAC FRAME
their general structure in terms of modular design, structured programming, and high level language. Based on the represented requirements, a basic concept of the CATPAC software structure has been developed, see Fig. 1. o From the software point of view the procedures and models are no longer regarded as belonging to special classes (for example: process analysis, controller design, simulation etc.). o A standardized structure of models will enable different procedures to access models in a correct manner. The correctness is guaranteed by special access routines. o All generated models and all available procedures are comprised in a model library and a procedure library respectively. To enable the management of these libraries, there exists a catalogue for each of them containing reference data to any item. o The program system itself has mainly to activate procedures controlled by interactive user requests. This program part within the dialogue oriented CATPAC frame needs access to both catalogues: the procedure catalogue, to activate the respective procedure, and the model catalogue, to assign the models in a correct manner. o The central part of management of the model library and procedure library respectively is supported by two other program parts within the CATPAC frame. They enable the user to modify the contents of catalogues and to access the respective item. To provide a more modular structure of the whole system, and to contribute to the consistence of the catalogue data spec ~ al access routines are also introduced in this case. In the foll~~ing some aspects of this basic concept are discussed in more detail.
MOOEL LIBRARY
PROCEDURE
CATALOGUE
~
EJ .. ODEL;
ACTIVATED
I OIALOG~)
':/
'
"~
o~ E~
Fig.
1. Basic concept of the CATPAC software system.
CATALOGUE CONCEPTION As already mentioned in chapter 2 within the CATPAC-software system all the available procedures and generated models are comprised in a model library and a procedure library respectively. To enable the management of libraries in a fast and systematic way a standardized catalogue con-
CATPAC- An Interactive Software Package
ception has been designed which is the same for both the model li.brary and the procedure library. General Structure A catalogue is hierarchically structured; it consists of three levels. The components are tables which are composed of a header and an arbitrary number of entries. The header consists of a table descriptor and parts for storing text and other data which are important for documentation. The table descriptor contains the table name, pointers to those parts just mentioned before and a pointer to the first entry of the table. For every entry there exists an entry descriptor; its elements are an entry name, a pointer to the next entry, pointers to descriptive parts and, if the entry belongs to a table of level one or two, a pointer to the corresponding table of the subordinate level. An entry of a table belonging to the third level contains a pointer to the corresponding object that is a model file oc a procedure information on a file containing among other things the name of the related load module.
185
To have access to the records of the file, there are routines available which belong to the lowest level. These routines are called by the segment access routines. The following operations on record base are possible: to read, to attach, to release, to chain, to write a record. MODELS The dynamic behaviour of a process can be described by measured values, state differential equations, transfer functions etc. The different notations of these models are put together in three categories of models: parameter sets (e.g. vector differential equations), tables of values (e.g. measured values), and characteristic values (e.g. gain). In every step of analysis and design the concerned procedure needs one or more input models and generates one output model. The generated outputmodel can again be an input-model for other procedures. To enable a uniform access to these models a standardized structure of model data is a necessary precondition. This is even more evident when one considers that otherwise for every model category dedicated sets of access-routines would be required.
Access Conception For the CATPAC-software a modular and hierarchically structured access conception has been elaborated. Routines of the highest level represent the interface between the procedure programmer and the catalogues. They only allow an access to logically combined parts of the catalogues, e.g. to read a table descriptor, to write an entry descriptor etc. The information about the realization of such a logical part on the file is hidden from the procedure programmer. Every logical part to which an access is possible is interpreted as an integer field. The routines of the highest level call subroutines, belonging to the subordinate level, which have access to so-called segments. A segment is a part of the integer field which is identified by its start position within the integer field and its length. The construction of segments makes it possible to set up, to read or to alter the integer field in arbitrary parts.
~I
MODEL DESCRICTOR USER'S COMMENT
1\1\
'\
\1
({till
MODEL SPECIFICATION
)
MODEL INFORMATION
PROCEDURE DATA DESCRIPTION OF MODEL DATA
HEADINGS
\ NUMERICAL DATA
MODEL DATA
\ PARAMETER LIST
Fig. 2. Standardized model file. When outlining the standardized model file it has to be taken into account that the model data can be parameter sets, tables of values or characteristic values. Their different structures and meanings must be described. For the description of model data in
M. Barthelmes et aL.
186
the model file which is a random access file the so-called model information is provided. As shown in the diagram the model information is divided into several parts: The model descriptor contains references to the other parts of the model information. The first part is the block comprising a user's comment. The following block called model specification includes information about the corresponding input-models and the applied procedure. The procedure specific data are located in a separated data block. For example when designing a state controller weighting matrices are such procedure specific data. To define the structure of the model data a block called description of model data is provide~ Taking a table of values as an example its structure is given by the number of rows and the number of columns of each table. Moreover for each column the data type is specified. To make the model data accessible pointers are provided, which specify certain records of the model data section. The model data themselves are divided into 3 parts: the real numeric model data, the attached headings, and a parameter list. The separate parameter list contains data which cannot be an integral item of the numeric model data block (e.g. description of an ope rating point) . PROCEDURES The philosophy of the CATPAC-package defines a procedure as a programmed method for a control task. The purpose of procedures, which operate upon models only, is to process data that are present in form of inputmodel(s) and to produce a new set of data, the output-model. The procedures are hierarchically classified into three levels. The highest level consists of nine general classes, namely: 1. 2. 3. 4. 5. 6. 7. 8. 9.
process analysis controller design digital simulation signal generators model transformation model connection model examination model input model output
Each of these general classes is divided into classes and each of them into subclasses again. The entries of the subclass level pOint to the proper procedures. Every
procedure represents a logical unit (in accordance with the model) which comprises two parts. These parts are the procedure information and the program load module. But in contrast to the logical unit 'model' these parts are stored on different files. The procedure information part contains data for the frame-program and for the procedure itself. Data for the frame-program are: a pointer to the program load module, requirements concerning the input and output models and requirements of the peripheral units. Information data for the procedure itself are given by default values of procedure specific data which are numerical parameters (e.g. precision parameters) and system design parameters (e.g. weighting matrices) . It is the intention to provide the possibility to insert additional procedures and to change the existing ones. in this sense the system is expandable. There are good reasons for this requirement: o The development of such a system is easier if not all desired procedures must be available from the very beginning. o New developed procedures can be included without any reorganisation of the existing system. o The system can act as a test environment for new procedures. Because new procedures will be created and included independently from the set-up of the system itself, programming aids for procedures will be available. These will include: o Pools of standardized routines for the handling of interfaces between procedures and models, and between procedures and the system respectively. o Aids for dialogue, graphic, I / O, and for program documentation like generation of standardized program headers and the existence of a module library. These programming aids available to the procedure programmer will be located in the module library. MODEL OUTPUT In the following chapter it will be shown - with the aid of models described by tables of values - which output facilities will be offered.
CATPAC- An Interactive Software Package
187
There exist two output facilities, a numeric one to be depicted on a line printer or a display and a graphic one for plotter or graphic display representation.
sable length of the axes will be divided up optimally. Of course, it must be possible to render an individual scaling of the ordinates according to the respective graphs to be drawn.
Numeric output
At this point the previously stored information about the desired representation will be used and the frame with its text as well as the axes with their tick marks and legends are produced. The graphs themselves may consist of
As there are two different devices with different line measure to establish the numeric output a distinction has to be drawn automatically in preparing the layout. Without regard to the device there exist some requirements which must be fulfilled automatically or controlled by the user (user control indicated by * ) .
o centered symbols at selected points o line connected points with or without symbols o vertical lines to selected points (in the case of just one graph per figure)
o the data of the models - or of subsets of models - must correspond with their headings o the respective format must be partitioned in a suitable way o a choice of well-defined subsets of data to be output must be possible
Additional distincti v e features are several colours and different line types. It will be ensured that the relationship of the graphs with their ordinates will be e v ident.
(* )
o the table of the independent variable must be printed repeatedly, if necessary (*) o the output must be performed with requested precision (*) Graphic output For the graphic output there are two types of devices freely usable, a plotter and a graphic display. For both the user may choose a standardized version or a more comfortable one. The standardized versio n implies e.g. o only one ordinate o only one graph o standard headings and legends of the axes o a preset line type or a preset colour of the graph The comfortable version offers: o frame with text and date o up to three ordinates with six individual inscriptions o linear or logarithmic graduation of the axes o linear or logarithmic grid o individual text for headings o up to six graphs in different colours and line types. The information relevant to draw the figure is demanded from the user by dialogue and stored for further utilization. After specification of the desired model (or partial model (s)) an automatic integer scaling will be performed in such a way that the dispo-
DIALOGUE-ORIENTED PROGRAM FLOW The entire software package can be divided into three main parts: 1. A part for procedure activation - it enables the user to apply different procedures in an interacti v e manner. Therefore it activates the chosen procedure and prov ides the selected input mod e ls. To carry out these operations, this program part needs access to both catalogues. 2. A part for procedure handling - it allows the user to manipulate procedures, that means to include new procedures or to write, to alter, to delete already catalogued ones. Therefore the procedure catalogue must be accessible to this program part. 3. A part for model handling - it gives the possibility to manipulate models in an analogous manner as mentioned in point 2. It is quite clear, that for these manipulations the model catalogue must be accessible. To ensure an easy and convenient use of these three parts, an interactive program flow has been designed. For procedure activation this will be made clear in a more detailed description of the operations mentioned above. Procedure Activation A very simplified flow diagram of procedure activation is shown in Fig. 3.
M. Barthelmes et aL.
188
DOCUMENTATION AND PROVISIONS TO ENSURE PORTABILITY OF THE SOFTWARE SYSTEM Documentation For designing, use and maintenance of a software system it is very important to have a detailed and well structured documentation.
FRAME
Classification of the CATPAC-documentation. The documentation of the CATPAC-software can be subdivided: ,. YES
o o
OOIFICATION OF PROCEDURE SPECIFIC DATA
o
PROCEDURE
YES
+---
NUMERICAL OR GRAPHIC PRESENTATION
2.
3.
Fi g . 3 . Flow diagram of procedure acti v ati o n. All the different step s of such an activ ation are dialo gue-controlled. The most important part o f this dialogue is the eventual modification of procedure data. These data can be read in either from the corresponding procedure information (default values) or from an output-model, which has been g enerated by the same procedure in a former activ ation run. After that the user has the possibility to alter the numerical v alues of those data he wants to modify. Another essential step within procedure activation is the presentation of provisional results. Such a presentation may be e.g. a lineprinter output of the calculated temporary output model or a graphic output of preliminary simulation results. On the basis of this presentation the user should be able to judge the computed results. Now he can decide, whether the procedure should be started anew or continued or ended. This is a very important feature of the designed activation scheme, because it enables an iterative handling of algorithms.
Concerning the whole interactive program system Its philosophy will be described. There have to be different manuals for the user, the procedure programmer and the administrative function programmer. The organization and the construction of the entire program package will be described in detail by block diagrams. Information about the structure of model data and of procedure specific data including their default values is an integral part of the documentation. The realization of the algorithms within their corresponding programs will be described by Nassi-Shneiderman diagrams and source texts.
Storage of Documentation. Documentation not changing or changing slowly its information contents is called static (e.g. manuals, program structure), documentation changing quickly is called dynamic (e.g. contents of the catalogues). Static information could be stored outside the computer, e.g. on papers, dynamic information has to be present for updating inside the computer. Aids for Documentation. There exists a program that generates dialogue-oriented a standardized program header which is placed at the beginning of the source text of a program module. The program header contains all the relevant information relating to the module. Provisions to ensure portability of the CATPAC-software To facilitate an implementation of a software package on different computer systems the program should be portable. The following aspects are considered as very important: 1.
Programming language - Avoidance of programming in as-
CATPAC- An Interactive Software Package
sembly language
2.
3. o
o
- Adherence to a current language standard - Disciplined use of language constructions Interfaces of user programs to computer systems - Least possible dependence on the operating system - Concentration of indispensable references to the operating system in a well defined and well described manner - Use of standard peripheral units for input and output - Use of secondary storage units by standard operations Program structure Structure within a module - Utilization of 'structured programming' - No use of 'tricky' programming - Providing sufficient documentation Relationship between the modules - Using a hierarchical concept - Clear arrangement of data communication CONCLUSION
So far a brief survey of the CATPAC software has been presented. The idea of this project became apparent during applications of process analysis, controller design and simulation in different process automation tasks carried out in the past. The gained experience revealed the necessity of advanced computer-aided tools. The CATPAC software will be the framework, providing, besides other features, a fast and flexible use of these tools. For these reasons CATPAC is not only an appropriate tool to supply research work but also represents an efficient support to industrial applications. REFERENCES Dymschiz, E. (to be published). CADCASISO-Ein Programmpaket zum rechnergestUtzten Entwurf van Regelalgorithmen mit ProzeBrechnern. PDVEntwicklungsnotiz PDV-E. Gesellschaft fur Kernforschung, Karlsruhe. Hafler, A.B. (1977). RASP-G-Ein FORTRAN-Programmpaket zur graphischen ~ystem-Darstellung. Ruhr-Universitat Bochum, Institutsbericht Lehrstuhl fur MeB- und Regelungstechnik. Isermann, R. and Dy~schizl E. (1977). Computer Aided Design of Control Algorithms Based on Identified Process Models. In N. Lemke (Ed.),
189
Digital Comp-uter App-lications to Process Control, IFAC and NorthHolland Publishing Company, M1-1, pp. 431-438. Schmid, Chr. and Unbehauen, H. (1979). KEDDC, A General Purpose CAD Software System for Applications in Control Engineering. In 2 nd IFAC/IFIP Symposium on Software for Computer-Control (SOCOCO), Prague. Schmid, Chr. Handbuch zur interaktiven Benutzung des KEDDC-Systems. Interner Bericht der Ruhr-Univer sitat Bochum. ESL-7607.
Copyright © IFAC Software for Computer Control Madrid, Spain 1982 -
CATPAC - AN INTERACTIVE SOFrWARE PACKAGE FOR PROCESS ANALYSIS AND CONTROL M. Barthelmes, P. Bressler, D. Biinz, K. Giitschow, and U. Schreiber
J. Heeger, R. Kersic
Philzps GmbH Forschungs laboratorium Hamburg, Postbox 540840, D-2000 Hamburg 54, Federal Republic of Germany
Abstract. The automation of complex industrial processes can only be carried out by the use of efficient computer-aided tools. The CATPAC software package provides a powerful tool-box containing mathematical algorithms for process analysis, design of control strategies and simulation of dynamic systems. Keywords. Computer-aided techniques. control system analysis. process analysis. process control. software package. BASIC CONCEPT OF THE CATPAC SOFTWARE SYSTEM
INTRODUCTION If we have a look at the automation of an industrial process, we can distinguish several phases:
The CATPAC software system appears in different ways to
o Firstly the control engineer needs a mathematical description of the dynamical behaviour of the process. Such a model may be calculated from measured values of the input and output signals. o The next step is the design of a suitable control strategy based on the resulting model of the process analysis phase. o The derived models of different controllers serve as input data for the design of the control system itself.
o the user, o the procedure programmer, and o the administrative function programmer. The user is, for example, the control engineer. He activates a procedure to apply it to input models and to generate output models by an appropriate setting of procedure specific data. Then he has to discuss and assess the results to decide about further steps. A procedure is a programmed method for a control task.
o Afterwards the set-up and installation of the instrumentation system has to be carried out.
The procedure programmer makes such a method available within the CATPAC system. The written program has to meet some restrictions according to documentation and standard service routines.
o So finally the initial operation and tests of the complete system may start. In practice the sequence of working steps described above may have to be suspended in any stage because of insufficient results.
The administrative function programmer is responsible for all programs called service routines which enable not only a comfortable procedure development but also a faultless support to users of the CATPAC software system.
In this case the sequence will have to be repeated once more, starting at an arbitrary previous step. The CATPAC software system, the concept of which is described in this paper, shall support the first two phases: process analysis and design of control strategies.
The typical approach of the user for solving control problems is an interactive one, so CATPAC is designed as an interactive system. This feature induces the choice of procedures as well as the choice of the input mo183
M. Barthelmes et al.
184
dels during runtime. The results are to be presented graphically whenever possible, and they are stored as input models for other procedure activations or for detailed discussions of the resulted model dependent on the design parameters. So, stress is laid on dialogue, graphic, and documentation as well as on model and procedure handling capabilities. With the intention sibility to insert dures or to delete performance of the adapted to varying
to provide the posadditional proceexisting ones, the system can be requirements.
The system will be available on a process computer. Using some features of a real-time operating system the realization of the conception of the system may be more efficient. To facilitate a transfer of the system to other process computers the software package must be portable. Portability is influenced by the chosen programming language and by the interface to the computing system environment. So, great care has to be taken in these areas. The system is supposed to be available for a long life cycle and to be used frequently. For this reason the security aspect of the programs becomes very important, especially concerning the data security when a system break-down occurs, and also in case of runtime errors of procedures. Readability of program source texts will simplify the construction of correct programs, ensure an easy maintenance, and help to become acquainted with the system. Readable programs can be set up by comprehensive documentation as well as by considering DiALOGUE ORIENTED CATPAC FRAME
their general structure in terms of modular design, structured programming, and high level language. Based on the represented requirements, a basic concept of the CATPAC software structure has been developed, see Fig. 1. o From the software point of view the procedures and models are no longer regarded as belonging to special classes (for example: process analysis, controller design, simulation etc.). o A standardized structure of models will enable different procedures to access models in a correct manner. The correctness is guaranteed by special access routines. o All generated models and all available procedures are comprised in a model library and a procedure library respectively. To enable the management of these libraries, there exists a catalogue for each of them containing reference data to any item. o The program system itself has mainly to activate procedures controlled by interactive user requests. This program part within the dialogue oriented CATPAC frame needs access to both catalogues: the procedure catalogue, to activate the respective procedure, and the model catalogue, to assign the models in a correct manner. o The central part of management of the model library and procedure library respectively is supported by two other program parts within the CATPAC frame. They enable the user to modify the contents of catalogues and to access the respective item. To provide a more modular structure of the whole system, and to contribute to the consistence of the catalogue data spec ~ al access routines are also introduced in this case. In the foll~~ing some aspects of this basic concept are discussed in more detail.
MOOEL LIBRARY
PROCEDURE
CATALOGUE
~
EJ .. ODEL;
ACTIVATED
I OIALOG~)
':/
'
"~
o~ E~
Fig.
1. Basic concept of the CATPAC software system.
CATALOGUE CONCEPTION As already mentioned in chapter 2 within the CATPAC-software system all the available procedures and generated models are comprised in a model library and a procedure library respectively. To enable the management of libraries in a fast and systematic way a standardized catalogue con-
CATPAC- An Interactive Software Package
ception has been designed which is the same for both the model li.brary and the procedure library. General Structure A catalogue is hierarchically structured; it consists of three levels. The components are tables which are composed of a header and an arbitrary number of entries. The header consists of a table descriptor and parts for storing text and other data which are important for documentation. The table descriptor contains the table name, pointers to those parts just mentioned before and a pointer to the first entry of the table. For every entry there exists an entry descriptor; its elements are an entry name, a pointer to the next entry, pointers to descriptive parts and, if the entry belongs to a table of level one or two, a pointer to the corresponding table of the subordinate level. An entry of a table belonging to the third level contains a pointer to the corresponding object that is a model file oc a procedure information on a file containing among other things the name of the related load module.
185
To have access to the records of the file, there are routines available which belong to the lowest level. These routines are called by the segment access routines. The following operations on record base are possible: to read, to attach, to release, to chain, to write a record. MODELS The dynamic behaviour of a process can be described by measured values, state differential equations, transfer functions etc. The different notations of these models are put together in three categories of models: parameter sets (e.g. vector differential equations), tables of values (e.g. measured values), and characteristic values (e.g. gain). In every step of analysis and design the concerned procedure needs one or more input models and generates one output model. The generated outputmodel can again be an input-model for other procedures. To enable a uniform access to these models a standardized structure of model data is a necessary precondition. This is even more evident when one considers that otherwise for every model category dedicated sets of access-routines would be required.
Access Conception For the CATPAC-software a modular and hierarchically structured access conception has been elaborated. Routines of the highest level represent the interface between the procedure programmer and the catalogues. They only allow an access to logically combined parts of the catalogues, e.g. to read a table descriptor, to write an entry descriptor etc. The information about the realization of such a logical part on the file is hidden from the procedure programmer. Every logical part to which an access is possible is interpreted as an integer field. The routines of the highest level call subroutines, belonging to the subordinate level, which have access to so-called segments. A segment is a part of the integer field which is identified by its start position within the integer field and its length. The construction of segments makes it possible to set up, to read or to alter the integer field in arbitrary parts.
~I
MODEL DESCRICTOR USER'S COMMENT
1\1\
'\
\1
({till
MODEL SPECIFICATION
)
MODEL INFORMATION
PROCEDURE DATA DESCRIPTION OF MODEL DATA
HEADINGS
\ NUMERICAL DATA
MODEL DATA
\ PARAMETER LIST
Fig. 2. Standardized model file. When outlining the standardized model file it has to be taken into account that the model data can be parameter sets, tables of values or characteristic values. Their different structures and meanings must be described. For the description of model data in
M. Barthelmes et aL.
186
the model file which is a random access file the so-called model information is provided. As shown in the diagram the model information is divided into several parts: The model descriptor contains references to the other parts of the model information. The first part is the block comprising a user's comment. The following block called model specification includes information about the corresponding input-models and the applied procedure. The procedure specific data are located in a separated data block. For example when designing a state controller weighting matrices are such procedure specific data. To define the structure of the model data a block called description of model data is provide~ Taking a table of values as an example its structure is given by the number of rows and the number of columns of each table. Moreover for each column the data type is specified. To make the model data accessible pointers are provided, which specify certain records of the model data section. The model data themselves are divided into 3 parts: the real numeric model data, the attached headings, and a parameter list. The separate parameter list contains data which cannot be an integral item of the numeric model data block (e.g. description of an ope rating point) . PROCEDURES The philosophy of the CATPAC-package defines a procedure as a programmed method for a control task. The purpose of procedures, which operate upon models only, is to process data that are present in form of inputmodel(s) and to produce a new set of data, the output-model. The procedures are hierarchically classified into three levels. The highest level consists of nine general classes, namely: 1. 2. 3. 4. 5. 6. 7. 8. 9.
process analysis controller design digital simulation signal generators model transformation model connection model examination model input model output
Each of these general classes is divided into classes and each of them into subclasses again. The entries of the subclass level pOint to the proper procedures. Every
procedure represents a logical unit (in accordance with the model) which comprises two parts. These parts are the procedure information and the program load module. But in contrast to the logical unit 'model' these parts are stored on different files. The procedure information part contains data for the frame-program and for the procedure itself. Data for the frame-program are: a pointer to the program load module, requirements concerning the input and output models and requirements of the peripheral units. Information data for the procedure itself are given by default values of procedure specific data which are numerical parameters (e.g. precision parameters) and system design parameters (e.g. weighting matrices) . It is the intention to provide the possibility to insert additional procedures and to change the existing ones. in this sense the system is expandable. There are good reasons for this requirement: o The development of such a system is easier if not all desired procedures must be available from the very beginning. o New developed procedures can be included without any reorganisation of the existing system. o The system can act as a test environment for new procedures. Because new procedures will be created and included independently from the set-up of the system itself, programming aids for procedures will be available. These will include: o Pools of standardized routines for the handling of interfaces between procedures and models, and between procedures and the system respectively. o Aids for dialogue, graphic, I / O, and for program documentation like generation of standardized program headers and the existence of a module library. These programming aids available to the procedure programmer will be located in the module library. MODEL OUTPUT In the following chapter it will be shown - with the aid of models described by tables of values - which output facilities will be offered.
CATPAC- An Interactive Software Package
187
There exist two output facilities, a numeric one to be depicted on a line printer or a display and a graphic one for plotter or graphic display representation.
sable length of the axes will be divided up optimally. Of course, it must be possible to render an individual scaling of the ordinates according to the respective graphs to be drawn.
Numeric output
At this point the previously stored information about the desired representation will be used and the frame with its text as well as the axes with their tick marks and legends are produced. The graphs themselves may consist of
As there are two different devices with different line measure to establish the numeric output a distinction has to be drawn automatically in preparing the layout. Without regard to the device there exist some requirements which must be fulfilled automatically or controlled by the user (user control indicated by * ) .
o centered symbols at selected points o line connected points with or without symbols o vertical lines to selected points (in the case of just one graph per figure)
o the data of the models - or of subsets of models - must correspond with their headings o the respective format must be partitioned in a suitable way o a choice of well-defined subsets of data to be output must be possible
Additional distincti v e features are several colours and different line types. It will be ensured that the relationship of the graphs with their ordinates will be e v ident.
(* )
o the table of the independent variable must be printed repeatedly, if necessary (*) o the output must be performed with requested precision (*) Graphic output For the graphic output there are two types of devices freely usable, a plotter and a graphic display. For both the user may choose a standardized version or a more comfortable one. The standardized versio n implies e.g. o only one ordinate o only one graph o standard headings and legends of the axes o a preset line type or a preset colour of the graph The comfortable version offers: o frame with text and date o up to three ordinates with six individual inscriptions o linear or logarithmic graduation of the axes o linear or logarithmic grid o individual text for headings o up to six graphs in different colours and line types. The information relevant to draw the figure is demanded from the user by dialogue and stored for further utilization. After specification of the desired model (or partial model (s)) an automatic integer scaling will be performed in such a way that the dispo-
DIALOGUE-ORIENTED PROGRAM FLOW The entire software package can be divided into three main parts: 1. A part for procedure activation - it enables the user to apply different procedures in an interacti v e manner. Therefore it activates the chosen procedure and prov ides the selected input mod e ls. To carry out these operations, this program part needs access to both catalogues. 2. A part for procedure handling - it allows the user to manipulate procedures, that means to include new procedures or to write, to alter, to delete already catalogued ones. Therefore the procedure catalogue must be accessible to this program part. 3. A part for model handling - it gives the possibility to manipulate models in an analogous manner as mentioned in point 2. It is quite clear, that for these manipulations the model catalogue must be accessible. To ensure an easy and convenient use of these three parts, an interactive program flow has been designed. For procedure activation this will be made clear in a more detailed description of the operations mentioned above. Procedure Activation A very simplified flow diagram of procedure activation is shown in Fig. 3.
M. Barthelmes et aL.
188
DOCUMENTATION AND PROVISIONS TO ENSURE PORTABILITY OF THE SOFTWARE SYSTEM Documentation For designing, use and maintenance of a software system it is very important to have a detailed and well structured documentation.
FRAME
Classification of the CATPAC-documentation. The documentation of the CATPAC-software can be subdivided: ,. YES
o o
OOIFICATION OF PROCEDURE SPECIFIC DATA
o
PROCEDURE
YES
+---
NUMERICAL OR GRAPHIC PRESENTATION
2.
3.
Fi g . 3 . Flow diagram of procedure acti v ati o n. All the different step s of such an activ ation are dialo gue-controlled. The most important part o f this dialogue is the eventual modification of procedure data. These data can be read in either from the corresponding procedure information (default values) or from an output-model, which has been g enerated by the same procedure in a former activ ation run. After that the user has the possibility to alter the numerical v alues of those data he wants to modify. Another essential step within procedure activation is the presentation of provisional results. Such a presentation may be e.g. a lineprinter output of the calculated temporary output model or a graphic output of preliminary simulation results. On the basis of this presentation the user should be able to judge the computed results. Now he can decide, whether the procedure should be started anew or continued or ended. This is a very important feature of the designed activation scheme, because it enables an iterative handling of algorithms.
Concerning the whole interactive program system Its philosophy will be described. There have to be different manuals for the user, the procedure programmer and the administrative function programmer. The organization and the construction of the entire program package will be described in detail by block diagrams. Information about the structure of model data and of procedure specific data including their default values is an integral part of the documentation. The realization of the algorithms within their corresponding programs will be described by Nassi-Shneiderman diagrams and source texts.
Storage of Documentation. Documentation not changing or changing slowly its information contents is called static (e.g. manuals, program structure), documentation changing quickly is called dynamic (e.g. contents of the catalogues). Static information could be stored outside the computer, e.g. on papers, dynamic information has to be present for updating inside the computer. Aids for Documentation. There exists a program that generates dialogue-oriented a standardized program header which is placed at the beginning of the source text of a program module. The program header contains all the relevant information relating to the module. Provisions to ensure portability of the CATPAC-software To facilitate an implementation of a software package on different computer systems the program should be portable. The following aspects are considered as very important: 1.
Programming language - Avoidance of programming in as-
CATPAC- An Interactive Software Package
sembly language
2.
3. o
o
- Adherence to a current language standard - Disciplined use of language constructions Interfaces of user programs to computer systems - Least possible dependence on the operating system - Concentration of indispensable references to the operating system in a well defined and well described manner - Use of standard peripheral units for input and output - Use of secondary storage units by standard operations Program structure Structure within a module - Utilization of 'structured programming' - No use of 'tricky' programming - Providing sufficient documentation Relationship between the modules - Using a hierarchical concept - Clear arrangement of data communication CONCLUSION
So far a brief survey of the CATPAC software has been presented. The idea of this project became apparent during applications of process analysis, controller design and simulation in different process automation tasks carried out in the past. The gained experience revealed the necessity of advanced computer-aided tools. The CATPAC software will be the framework, providing, besides other features, a fast and flexible use of these tools. For these reasons CATPAC is not only an appropriate tool to supply research work but also represents an efficient support to industrial applications. REFERENCES Dymschiz, E. (to be published). CADCASISO-Ein Programmpaket zum rechnergestUtzten Entwurf van Regelalgorithmen mit ProzeBrechnern. PDVEntwicklungsnotiz PDV-E. Gesellschaft fur Kernforschung, Karlsruhe. Hafler, A.B. (1977). RASP-G-Ein FORTRAN-Programmpaket zur graphischen ~ystem-Darstellung. Ruhr-Universitat Bochum, Institutsbericht Lehrstuhl fur MeB- und Regelungstechnik. Isermann, R. and Dy~schizl E. (1977). Computer Aided Design of Control Algorithms Based on Identified Process Models. In N. Lemke (Ed.),
189
Digital Comp-uter App-lications to Process Control, IFAC and NorthHolland Publishing Company, M1-1, pp. 431-438. Schmid, Chr. and Unbehauen, H. (1979). KEDDC, A General Purpose CAD Software System for Applications in Control Engineering. In 2 nd IFAC/IFIP Symposium on Software for Computer-Control (SOCOCO), Prague. Schmid, Chr. Handbuch zur interaktiven Benutzung des KEDDC-Systems. Interner Bericht der Ruhr-Univer sitat Bochum. ESL-7607.