- Email: [email protected]
Model-integrated on-line problem-solving in chemical engineering
Control Eng. Practice, Vol. 5, No. 1, pp. 1-9, 1997 Copyright © 1997 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0967-0661/97 $17.00 + 0.00
Pergamon Pli:S0967-0661 (96)00201-8
MODEL-INTEGRATED ON-LINE PROBLEM-SOLVING IN CHEMICAL ENGINEERING G. Karsai* and F. DeCaria** *Department of Electrical and Computer Engineering, Vanderbilt University, Nashville, TN 37235, USA (gabor @vuse. vaderbilt.edu) **Old Hickory Plant, DuPont DeNemours Films, PET Resins and Chemicals, OM Hickory, TN 37216, USA
(Received May 1996; in final form October 1996) A b s t r a c t : Complex chemical plants need various custom monitoring, control, simulation and diagnostic software codes that necessitate the integration of models into the problem-solving process. This paper describes a system and its practical applications that support this process. The work described here is based on the Multigraph Architecture: a generic framework for building model-based systems. The paper discusses the modeling paradigm and techniques used, how the applications are generated, and some practical, existing applications.
K e y w o r d s : Chemical industry, software engineering, process automation, diagnosis
1. I N T R O D U C T I O N T h e evolution of manufacturing systems seems to lead towards information- and software-based manufacturing. There are many driving factors contributing to this evolution, including the need for continuous improvement in a competitive market environment, the requirements stemming from environmental regulations, and the need for process safety management. In all these cases (and in many others) the key factor contributing to success is the efficient use of information. For example, to improve a chemical manufacturing process, process information needs to be collected and analyzed, environmental regulations require the management of on-line and up-to-date models of the plant such that pollutant emissions can be estimated, and safety requirements mandate current and available design information. Thus, the management of information in a plant environment is quickly becoming an extremely important factor in operations. It should also be recognized, however, that information management is not a goal in itself; rather, it is part of a larger problemsolving process.
Information management involves software development at some level. Because plants and operations change and evolve over time, information management structures (i.e. the software) must change as well. It is accepted that, when a complex chemical plant is built, not all of the software is developed at once; rather, only the part that is required for basic operations. A large amount of software development takes place, in fact, afterthe plant's construction, during its lifetime, as needs for improvements, changes, and evolution arise. As the information system of the plant evolves, there is a constant need to develop custom, specialized, sometimes "throw-away", codes for solving problems. These software codes are highly dependent on the actual plant, on the current configuration of the plant, etc., and for this reason are very expensive to manufacture. The required functionality of these codes includes tasks such as: • store and maintain design information about the plant, • perform custom monitoring functions,
2
G. Karsai and F. DeCaria
MODEL EDFF]NG
MODEL INTERPRETATION
- INTERPRET MODELS - CREATE OBJECTS - CONFIGURE OBJECTS
Fig. 1. Model-based system development • implement custom supervisory control algorithms, • diagnose sensor failures, • determine the causes of plant upsets, • take recovery actions in cases of failure by instructing the process computer to reconfigure control to new setpoints, etc. Note that all these functionalities require intimate knowledge of the plant: its configuration and its behavior. It is natural that the best person for developing these codes is a plant engineer who has the necessary knowledge. However, a plant engineer is very rarely a software engineer, and faces difficulties in creating these codes, that require software engineering expertise. The system described in this paper, called IPCS (Intelligent Process Control System), addresses these problems, and offers a solution that seems to be widely applicable, even beyond the scope of chemical process engineering. This more-general scope is that of "domain-specific" problem-solving environments, that provide support tools for creating application software by domain engineers. The paper first discusses some background issues; next it describes the approach taken in IPCS. Then it presents some example applications, followed by a discussion of other approaches, and finally summarizes and evaluates the results.
2. BACKGROUND Creating domain-specific problem-solving tools can be approached from many different directions. One can identify at least three distinct methods:
(1) object-oriented software design, (2) application generators, and (3) expert-system environments. The approach using object-oriented design can be summarized as follows: the user (typically a plant engineer) learns the design techniques of objectoriented programming, preferably with a standard notation (e.g. that of Booch (Booch, 1994) or OMT (Rumbaugh, et al., 1991)), and uses these techniques to create solutions to problems. This approach results in well-structured, high-quality computer solutions, but at a very high cost. Domain engineers require training in OOD techniques, and they have to learn how to translate their "language" into that of OOD.
Application generators (e.g., Matrix-X) offer excellent solutions to part of the problem. For example, they support the block-diagram-oriented modeling (and building) of control systems. They are based on a visual notation, typically learned in engineering disciplines (e.g., control theory), that is used to specify problem solutions. However, they do not offer ways of capturing the engineer's knowledge or physical data (e.g., sizes) about the plant. They are typically very easy to use and are appealing, but they seem to lack the rich semantics required for domain-specific systems. Expert-system environments (e.g., G2 (GENSYM, 1990)) support the knowledge-based approach: knowledge is encoded in the form of frames and rules, with the possibility of attaching arbitrary procedural code. The problem-solving strategies must be explicitly coded in the form of rules. This method has some serious drawbacks: engineers require training to become knowledge engineers, the possibility of using frames and rules does not offer any support for how to use them, and they lack the predefined concepts prevailing in the application domain. While there are many practical systems and environments that try to solve problems using the above approaches, one can anticipate that, as the system's complexity increases, their shortcomings will become more prevalent. This does not mean, however, that these approaches are not valuable: they have their own place and application. A better approach might be to use the "modelbased programming" technique for building such domain-specific problem-solving environments. The approach itself is described in another paper (Abbott, et al., 1993); here, it is summarized as follows: • The central idea is to use models, which are abstract representations of concepts and entities relevant to the problem-solving process. A model, technically speaking, is merely a data object that represents something mean-
Problem-Solving in Chemical Engineering
3
~,
Ixam-a~,l" i n,
L~
il.. I............................................"L-~ .....................................! ............ .............
..............................................................................................................
~:~.....L~.. . ..J
..........
!,.,.~..~ .......... ~ ~@_... |
...................................................................................
Fig. 2. A process model ingful. Examples of models will be given below. * A visual model-building environment (Karsai, 1995) is used for creating models of the plant, and the problem-solving activity to be used. This environment has built-in concepts from the application domain (e.g. Process, Process
variable,
Equipment,
Failure
mode), and some concepts for typical problemsolving activities (e.g. Operator i n t e r f a c e , S i m u l a t i o n , Event, etc.). The problemsolving activities are configured through a visual language, although procedural code might be embedded as well. These models are stored in a model database. • A system component, called the model interpreter, is responsible for interpreting the models, configuring networks of active, "executable" objects that implement predefined (or user-specified) problem-solving strategies. This process is automatic, and corresponds to the compilation step in traditional approaches. The result of this step is a network of active objects, which are interfaced to the data streams in a plant, and/or possibly other software components (e.g., process simulators), etc. • A run-time support component schedules the computations (i.e., activates the objects) as data arrives a n d / o r user interaction mandates it. This component acts as a "runtime system integrator" which couples the computational activities and essentially runs the system.
The steps of this model-based approach can be seen in Fig. 1. This approach has the following advantages: (1) Domain engineers can work with their own concepts and language; there is no need to learn a new language. (2) Problem-solving activities can utilize knowledge that was formalized and represented, and (3) the problem-solving strategies themselves are formulated in a way that is close to the thinking of domain engineers. While, admittedly, there are drawbacks in this approach with respect to efficiency, they are outweighed by the advantages gained. A model-embedded problem-solving environment has been implemented for chemical engineering applications; that system is described next. In implementing the system the Multigraph Architecture (Sztipanovits, et al., 1995) has been used, which is a generic framework for implementing model-based environments.
3. MODEL-BASED PROBLEM-SOLVING ENVIRONMENT The first question to be answered when creating a model-based environment is: "What are the relevant model categories and modeling concepts in the domain?" The choice of model categories is influenced by the context and the purpose of the environment; thus the following two categories of models are needed: models of the plant, and models of the problem-solving activities to be performed. Note that this concept is different from the approach taken in OOD: unlike in OOD, the
4
G. Karsai and F. DeCaria Category Plant
Model Stream model Process model
Equipment model
Activity
Algorithmic Timer State machine Operator interf. External interf. Simulation Compound
Aspects Process flow Process flow Finite states Equations Failure propagations Proc./equipm. associations Structure Finite states Faults Signal flow Signal flow Signal flow Signalflow Signalflow Signal flow Signal flow
Table 1. Models in IPCS context (the "environment") of the final application is extremely relevant, and is represented explicitly, not only through some "interfaces".
3.1 Modeling concepts In the IPCS, in line with the above observations, there are two major categories of model, with several types of model available in each. The various model types within a category are used to describe the entities (conceptual or real) that are relevant. The application developer (who is a domain engineer) builds these models using a visual model editing tool. Models are built through composition: the user creates pictures by dragging and placing icons (i.e., objects) onto a screen, possibly specifying textual attributes for them, and possibly establishing connections between the icons. Models tend to grow very complex if there are many icons on the screen simultaneously. To reduce this problem, models are divided into aspects that show only a subset of model components at a time. Aspects provide a natural way of allowing structured viewing and editing of models: they subdivide a model into a set of screens according to some organizing principle (although overlaps among aspects are allowed). Table 1 summarizes the model categories, the allowed model types in each category, and the set of modeling aspects. The P l a n t category contains the models that are used to represent what a domain engineer knows about the plant. The plant is modeled in terms of (1) plant functionalities, and (2) plant equipment. This conceptual distinction was found useful, because, e.g. it is conceivable that one type of equipment may be used in many, different processes, and vice versa. Plant functionalities are described in terms of streams and processes. A stream represents an
arbitrary material, energy, or information flow in the plant, while a process represents a transformation that maps input streams to output strearas. Processes and streams form hierarchically structured diagrams, that are very similar to process flowsheets. The process flows show only one aspect of processes; the other aspects include
• finite states, that model the process as a finite-state machine with discrete states and transitions linking them, • equations, that model the process in terms of linear and non-linear differential equations and s- or z-domain polynomials, • failure propagations, that model the anticipated failure modes of the process and how they propagate to other processes, and • "process-equipment" associations, that link equipment models to the process, indicating what hardware is involved in realizing the functionality of the process. The aspects listed have many, primitive, objects that represent the components of the model. For example, a process may have a number of process variables, which will be represented by multiple instances of the icon that stands for a process variable. Connections between icons represent some kind of relationship (e.g., failure propagation between failure modes). Processes can be organized into "part-whole" hierarchies, where, on the higher level a lower-level process is represented by one icon. Figure 2 shows an example of a process model. Plant equipment is described in terms of equipment models that describe the actual hardware of the plant. The aspects of equipment models include:
• structure, to describe connectivity and the hierarchical organization of equipment,
• finite states, that model the equipment as a finite-state machine, and
,, faults, that represent the anticipated equipment problems. These equipment faults are typically related (and thus connected) to process failure modes. Plant and equipment models are "linked", and this linkage happens in the context of the process models: in the "process-equipment" association view one can reference and connect equipment models to the process. The plant models represent and store in a structured way what the plant engineer knows about the plant: how it works, how it is constructed, etc. This service in itself provides an integrated database functionality for archiving plant design information. The problem-solving activities are represented in the form of distinct A c t i v i t y models, that are essentially computational blocks. A
Problem-Solving in Chemical Engineering
5
H~
[I.~.1
4
I~ftSt~ml
t
ZI
,
tl
......
'
!1 t tl It
.........
..............................................J
Fig. 3. A compound activity model computational block, in its most general form, is responsible for receiving data from another block, processing it, and sending it out to another block. The computational blocks are used to form networks of computations that are scheduled according to the dataflow principle: a computational block executes if data is available on its inputs, performs the processing, and then sends out the results on its output, to the next block in the chain. Various kinds of activities are possible, including: algorithmic (for calculations or user-supplied computations), timer (for timedbehavior, like delays), finite-state-machine (for finite-state control algorithms that are modeled using a finite-state automaton), operator interface (for sending data to and receiving data from a human operator), external interface (for exchanging data with the plant's data-acquisition system), and simulation (for solving the model equations and interfacing the equation solver with the datastreams present in an activity diagram). Primitive activities can be embedded in compound activity models (that may contain other compound models), and thus complex applications can be integrated visually. Figure 3 shows an example (compound) activity model. The activity models are not independent of the plant models. Rather, they are linked together, and, in fact, activity models utilize the information present in the plant models. For example, simulation activities explicitly refer to the process models, and activity parameters can use the design values stored in the context of equipment models. This integration is one powerful feature of
IPCS: the problem-solving activities utilize explicit knowledge stored in plant models. From a practical standpoint, the interface issues play an important role. The interfaces are considered as computational blocks, whose "computation" is performed by some external entity (e.g. the plant, the human operator, etc.). The generated IPCS application is equipped with the following interfaces:
• External interface. This interface couples the application to the plant data-acquisition system. A T C P / I P - b a s e d protocol has been defined that connects the application to a data server process. This data server needs to be developed once for every data-acquisition system: it is typically a 2-man-weeks effort. The data server is responsible for both sending and receiving data to and from the dataacquisition system. • Operator interface. The operator interface functionality is also implemented in a separate process that communicates through a T C P / I P protocol. An example of a generic operator interface has been built using Motif/X, but this part can easily be replaced by any other package. Figure 4 shows some screens of the generic operator interface. • External simulators. Some enhanced versions of IPCS have interfaces to external simulators. These interfaces appear as new activity model types that can be used just like any other activity model. The interface includes dedicated server code running on the computer containing the simulator, that couples it to the IPCS run-time system. Cur-
6
G. Karsai and F. DeCaria
Fig. 4. I P C S run-time system: operator interface rently these interfaces are available for various, standard chemical engineering packages. Note t h a t activity models are more than the diagrams used in application generator tools: they also contain links back to the process and equipment models. As an additional gain, in this way applications can be made and kept consistent with the plant models.
3.2 Modeling techniques There are some modeling techniques that are used in all model categories. These techniques help in reducing the complexity of the visual models, and are applicable in systems for other engineering disciplines as well. The techniques are summarized below. • H i e r a r c h y . Using this modeling technique the models are organized into part-whole diagrams, t h a t form a tree structure. When a model is edited, only one node in the tree is shown: it can be the root node, a leaf, "primitive" node, or any intermediate, "compound" node. Wherever the node is, only the immediate children of t h a t node are shown. Obviously, the diagrams are simpler t h a n if all the details were shown. Figure 5 illustrates a model hierarchy. Examples of hierarchical model organization are the process, equipment, and compound activity models. • R e f e r e n c e s . When multiple hierarchies are used, it is not possible to link up objects in different trees. Even in one hierarchy, if
a connection needs to be established to a remote object (on a different subtree), it is quite difficult. References can help in this case: a reference is an object in a model, that is really a pointer to another object in another model. Figure 6 shows an example of referencing. The reference can be established by a graphical "drag-and-drop" operation. Examples of references are the "processequipment" connections, and other examples in the activity models where activities use objects that are present in various plant models. C o n d i t i o n a l s . Visual models are static diagrams that cannot express a dynamic system. However, there was a need to express different configurations of a system using one diagram. The technique of conditionals helps ill this as follows: (1) The model should be built to contain the union of all the possible configurations. (2) Specific "control" objects should be "activated", and components (objects and connections) of the model should t)e attached to them. This attachment represents the fact that if the control object is active, the attached objects are active as well. Figure 7 shows an example of conditionals. The technique helps in visualizing tile different configurations, where, depending on which control object is active, different parts of the diagram are shown. One example of conditional models is present in the process models: failure propagation models (i.e. failure propagation connections and failure modes) can be conditional, based on the state of the system.
Problem-Solving in Chemical Engineering ROOT MODEL
........ []
I ::i1 l
-.
I,RiNrn'cls M ~ I ~ k
Fig. 5. Model hierarchy
Fig. 6. Model reference
3.3 Model interpretation and execution
erator and external interfaces); MGK handles the scheduling issues here as well.
The models are created visually and stored in an object database. The models are not directly executable; hence they must be translated into executable code first. This process is performed by model interpreters in IPCS. Model interpretation is somewhere between compilation and interpretation: primitive operations (i.e. algorithmic activities) are compiled into machine code, while the higher-level structure of the generated application remains interpreted. This approach preserves computational efficiency at the level of calculations, while providing great flexibility for system integration. The end-user gets an application that runs reasonably fast, and can still be changed quickly, debugged, etc. Some activity models have their built-in run-time support system (e.g., the equation solver for the simulation): for these, the interpreters simply configure certain data structures. Model interpreters are thus responsible for: • arranging the compilation and linking of code (if needed), • configuring run-time system components as needed, and • configuring the overall application. For the last step, IPCS is using a macro-dataflow kernel, called the MultiGraph Kernel (MGK), that supports the dynamic building of computational structures that contain executable objects. MGK is the execution environment for IPCS that provides great flexibility in system integration. When the executable objects (i.e., the primitive activities) are developed, they can be written without regard to the environment in which they will be used. That is determined by the higher-level, compound activity models, that "wire up" the application (by specifying the dataflows among activities). This information is used by the model interpreters to create communication channels between the objects (with the help of MGK). Once the network is built, MGK schedules the objects as the dataflow paradigm dictates. Some objects can perform I / O (e.g., op-
Obviously, the end-user does not see anything of this: everything is hidden behind models of activities. The only situation when the end-user may get some exposure is when debugging is activated, that makes possible the monitoring of datastreams in an MGK application from a different process. This facility provides a highlevel interface to activities in applications, but the usual method for interactions with an application is to use the operator interface activities.
4. APPLICATIONS IPCS has been, and is being, used for developing custom applications in a large chemical plant and at various, smaller, industrial sites. One of the first applications was a monitoring tool, that calculated and displayed 32, business-critical variables in the plant. The application was developed in a couple of days by an engineer who had not been exposed to the system before. The next application was a sensor diagnostics application (Padalkar, et al., 1995). The objective of this application was to monitor the health of 35+ sensors (mostly flowmeters and level sensors), and to detect various failures on them. From a model of the processes the application filtered out all the information for calculating loop balances, and could thus identify sensor failures in cases of too-large residuals. Again, the application was created rather rapidly: in about 3 weeks, by one engineer.
Another, large-scale application illustrates the system integration capabilities of IPCS. In that application a large nonlinear dynamic model is used (executed on a remote supercomputer, using a commercial simulation package). The IPCS application collects data from the plant dataacquisition system, preprocesses it, and sends it, in part, to the simulator. When the results are received, it plots them, together with other on-line
8
G. Karsai and F. DeCaria
UNION
O
(NOTHINGIS ACTIVE)
which identify the faulty equipment. This detection process may result in changing the setpoints of controllers, a n d / o r changing the monitoring strategy used for observing the process.
6. CONCLUSIONS SI CONTROL IS ACTIVE
:."~_3L"
_t..-" [__t ....
.___
-t, ,__
S2 CONTROL IS ACTIVE
Fig. 7. Model conditionals data. It also provides tools for operator interactions (e.g. switching between variables, etc.). The first version of this application (for handling about 40 variables) was developed in about one manmonth, but it is still being enlarged and improved. The applications have shown the major characteristics of IPCS: model-integrated application development, visual programming, and easy system integration. These features were well received by practising plant engineers.
5. R E L A T E D W O R K The use of problem-solving environments for chemical process industries is not a new idea: ASCEND (Dee and Westerberg, 1992) and MODEL. LA (Stephanopoulos, 1990) are two examples of problem-solving environments in a chemical engineering setting: the first is a high-quality design environment (with sophisticated solvers, languages, etc.); the second is a general modeling approach and framework for representing processes in chemical industries. In IPCS a slightly different approach was taken: in addition to modeling the processes, facilities are provided for representing (or "coding") the problem solution strategies as well. Very complex applications can be built using this approach and, through the use of the activity models, vastly different problem-solving strategies can be integrated. For instance, real-time plant data can be acquired, and compared against ideal models (through the use of a simulator). Next, if failures are detected, process diagnostics can be started
A model-based problem-solving environment has been developed and used in real-life applications. The system has demonstrated the feasibility of using models in on-line operations. It has also shown that in a complex environment (like a chemical plant), software applications are easier to develop using a high-level (i.e., visual) formalism for generating systems, than they are otherwise. Typical IPCS users are engineers who are familiar with the concepts of programming, but are not system integrators. They want to use the language of chemical engineering (and models), and are looking for simpler ways of building applications of small to medium complexity. It is believed that IPCS is a successful step in providing an environment for their needs.
7. A C K N O W L E D G E M E N T S The research described here was funded, in part, by Osaka Gas and OGIS-RI, Osaka, Japan, Boeing Aerospace, USAF, and Sverdrup Technology. Their support is gratefully acknowledged. OGIS-RI is commercializing IPCS in Japan. Tile IPCS development was done at the Measurement and Computing Systems Laboratory ( h t t p : / / m c s l . vuse. v a n d e r b i l t , edu) of the Department of Electrical and Computer Engineering of Vanderbilt University, led by Dr. Janos Sztipanovits.
8. R E F E R E N C E S Abbott, B., T. Bapty, C. Biegl, G. Karsai and J. Sztipanovits (1993). Model-based approach for software synthesis. IEEE Software pp. 4252. Booch, G. (1994). Object-oriented Analysis and Design with Applications, 2nd. ed.. The Benjamin/Cummings Publishing Company, Inc. Dee, K. and A. Westerberg (1992). Cephda: Chemical engineering process hierarchical design with ascend. Engineering Design Re-
search Center Research Report. GENSYM (1990). G2 Reference Manual. Gensym Corporation. Karsai, G. (1995). A configurable visual programruing environment. IEEE Computer pp. 36 44.
Problem-Solvingin ChemicalEngineering Padalkar, S., G. Karsai, J. Sztipanovits and F. DeCaria (1995). On-line diagnostics makes manufacturing more robust. Chemical Engineering. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W. Lorensen (1991). Object-Oriented Modeling and Design. Prentice Hall. Englewood Cliffs, N.J.
S~ephanopoulos, G. (1990). MODEL.LA. A modeling language for process engineering. Coinputers and Chemical Engineering 14, 495539. Sztipanovits, J., G. Karsai, Cs. Biegl, T. Bapty, A. Ledeczi and A. Misra (1995). Multigraph: An architecture for model-integrated computing. In: Proc. of First IEEE International Conference on Engineering of Complex Computer Systems. pp. 361-368. Ft. Lauderdale, FL.
Pergamon Pli:S0967-0661 (96)00201-8
MODEL-INTEGRATED ON-LINE PROBLEM-SOLVING IN CHEMICAL ENGINEERING G. Karsai* and F. DeCaria** *Department of Electrical and Computer Engineering, Vanderbilt University, Nashville, TN 37235, USA (gabor @vuse. vaderbilt.edu) **Old Hickory Plant, DuPont DeNemours Films, PET Resins and Chemicals, OM Hickory, TN 37216, USA
(Received May 1996; in final form October 1996) A b s t r a c t : Complex chemical plants need various custom monitoring, control, simulation and diagnostic software codes that necessitate the integration of models into the problem-solving process. This paper describes a system and its practical applications that support this process. The work described here is based on the Multigraph Architecture: a generic framework for building model-based systems. The paper discusses the modeling paradigm and techniques used, how the applications are generated, and some practical, existing applications.
K e y w o r d s : Chemical industry, software engineering, process automation, diagnosis
1. I N T R O D U C T I O N T h e evolution of manufacturing systems seems to lead towards information- and software-based manufacturing. There are many driving factors contributing to this evolution, including the need for continuous improvement in a competitive market environment, the requirements stemming from environmental regulations, and the need for process safety management. In all these cases (and in many others) the key factor contributing to success is the efficient use of information. For example, to improve a chemical manufacturing process, process information needs to be collected and analyzed, environmental regulations require the management of on-line and up-to-date models of the plant such that pollutant emissions can be estimated, and safety requirements mandate current and available design information. Thus, the management of information in a plant environment is quickly becoming an extremely important factor in operations. It should also be recognized, however, that information management is not a goal in itself; rather, it is part of a larger problemsolving process.
Information management involves software development at some level. Because plants and operations change and evolve over time, information management structures (i.e. the software) must change as well. It is accepted that, when a complex chemical plant is built, not all of the software is developed at once; rather, only the part that is required for basic operations. A large amount of software development takes place, in fact, afterthe plant's construction, during its lifetime, as needs for improvements, changes, and evolution arise. As the information system of the plant evolves, there is a constant need to develop custom, specialized, sometimes "throw-away", codes for solving problems. These software codes are highly dependent on the actual plant, on the current configuration of the plant, etc., and for this reason are very expensive to manufacture. The required functionality of these codes includes tasks such as: • store and maintain design information about the plant, • perform custom monitoring functions,
2
G. Karsai and F. DeCaria
MODEL EDFF]NG
MODEL INTERPRETATION
- INTERPRET MODELS - CREATE OBJECTS - CONFIGURE OBJECTS
Fig. 1. Model-based system development • implement custom supervisory control algorithms, • diagnose sensor failures, • determine the causes of plant upsets, • take recovery actions in cases of failure by instructing the process computer to reconfigure control to new setpoints, etc. Note that all these functionalities require intimate knowledge of the plant: its configuration and its behavior. It is natural that the best person for developing these codes is a plant engineer who has the necessary knowledge. However, a plant engineer is very rarely a software engineer, and faces difficulties in creating these codes, that require software engineering expertise. The system described in this paper, called IPCS (Intelligent Process Control System), addresses these problems, and offers a solution that seems to be widely applicable, even beyond the scope of chemical process engineering. This more-general scope is that of "domain-specific" problem-solving environments, that provide support tools for creating application software by domain engineers. The paper first discusses some background issues; next it describes the approach taken in IPCS. Then it presents some example applications, followed by a discussion of other approaches, and finally summarizes and evaluates the results.
2. BACKGROUND Creating domain-specific problem-solving tools can be approached from many different directions. One can identify at least three distinct methods:
(1) object-oriented software design, (2) application generators, and (3) expert-system environments. The approach using object-oriented design can be summarized as follows: the user (typically a plant engineer) learns the design techniques of objectoriented programming, preferably with a standard notation (e.g. that of Booch (Booch, 1994) or OMT (Rumbaugh, et al., 1991)), and uses these techniques to create solutions to problems. This approach results in well-structured, high-quality computer solutions, but at a very high cost. Domain engineers require training in OOD techniques, and they have to learn how to translate their "language" into that of OOD.
Application generators (e.g., Matrix-X) offer excellent solutions to part of the problem. For example, they support the block-diagram-oriented modeling (and building) of control systems. They are based on a visual notation, typically learned in engineering disciplines (e.g., control theory), that is used to specify problem solutions. However, they do not offer ways of capturing the engineer's knowledge or physical data (e.g., sizes) about the plant. They are typically very easy to use and are appealing, but they seem to lack the rich semantics required for domain-specific systems. Expert-system environments (e.g., G2 (GENSYM, 1990)) support the knowledge-based approach: knowledge is encoded in the form of frames and rules, with the possibility of attaching arbitrary procedural code. The problem-solving strategies must be explicitly coded in the form of rules. This method has some serious drawbacks: engineers require training to become knowledge engineers, the possibility of using frames and rules does not offer any support for how to use them, and they lack the predefined concepts prevailing in the application domain. While there are many practical systems and environments that try to solve problems using the above approaches, one can anticipate that, as the system's complexity increases, their shortcomings will become more prevalent. This does not mean, however, that these approaches are not valuable: they have their own place and application. A better approach might be to use the "modelbased programming" technique for building such domain-specific problem-solving environments. The approach itself is described in another paper (Abbott, et al., 1993); here, it is summarized as follows: • The central idea is to use models, which are abstract representations of concepts and entities relevant to the problem-solving process. A model, technically speaking, is merely a data object that represents something mean-
Problem-Solving in Chemical Engineering
3
~,
Ixam-a~,l" i n,
L~
il.. I............................................"L-~ .....................................! ............ .............
..............................................................................................................
~:~.....L~.. . ..J
..........
!,.,.~..~ .......... ~ ~@_... |
...................................................................................
Fig. 2. A process model ingful. Examples of models will be given below. * A visual model-building environment (Karsai, 1995) is used for creating models of the plant, and the problem-solving activity to be used. This environment has built-in concepts from the application domain (e.g. Process, Process
variable,
Equipment,
Failure
mode), and some concepts for typical problemsolving activities (e.g. Operator i n t e r f a c e , S i m u l a t i o n , Event, etc.). The problemsolving activities are configured through a visual language, although procedural code might be embedded as well. These models are stored in a model database. • A system component, called the model interpreter, is responsible for interpreting the models, configuring networks of active, "executable" objects that implement predefined (or user-specified) problem-solving strategies. This process is automatic, and corresponds to the compilation step in traditional approaches. The result of this step is a network of active objects, which are interfaced to the data streams in a plant, and/or possibly other software components (e.g., process simulators), etc. • A run-time support component schedules the computations (i.e., activates the objects) as data arrives a n d / o r user interaction mandates it. This component acts as a "runtime system integrator" which couples the computational activities and essentially runs the system.
The steps of this model-based approach can be seen in Fig. 1. This approach has the following advantages: (1) Domain engineers can work with their own concepts and language; there is no need to learn a new language. (2) Problem-solving activities can utilize knowledge that was formalized and represented, and (3) the problem-solving strategies themselves are formulated in a way that is close to the thinking of domain engineers. While, admittedly, there are drawbacks in this approach with respect to efficiency, they are outweighed by the advantages gained. A model-embedded problem-solving environment has been implemented for chemical engineering applications; that system is described next. In implementing the system the Multigraph Architecture (Sztipanovits, et al., 1995) has been used, which is a generic framework for implementing model-based environments.
3. MODEL-BASED PROBLEM-SOLVING ENVIRONMENT The first question to be answered when creating a model-based environment is: "What are the relevant model categories and modeling concepts in the domain?" The choice of model categories is influenced by the context and the purpose of the environment; thus the following two categories of models are needed: models of the plant, and models of the problem-solving activities to be performed. Note that this concept is different from the approach taken in OOD: unlike in OOD, the
4
G. Karsai and F. DeCaria Category Plant
Model Stream model Process model
Equipment model
Activity
Algorithmic Timer State machine Operator interf. External interf. Simulation Compound
Aspects Process flow Process flow Finite states Equations Failure propagations Proc./equipm. associations Structure Finite states Faults Signal flow Signal flow Signal flow Signalflow Signalflow Signal flow Signal flow
Table 1. Models in IPCS context (the "environment") of the final application is extremely relevant, and is represented explicitly, not only through some "interfaces".
3.1 Modeling concepts In the IPCS, in line with the above observations, there are two major categories of model, with several types of model available in each. The various model types within a category are used to describe the entities (conceptual or real) that are relevant. The application developer (who is a domain engineer) builds these models using a visual model editing tool. Models are built through composition: the user creates pictures by dragging and placing icons (i.e., objects) onto a screen, possibly specifying textual attributes for them, and possibly establishing connections between the icons. Models tend to grow very complex if there are many icons on the screen simultaneously. To reduce this problem, models are divided into aspects that show only a subset of model components at a time. Aspects provide a natural way of allowing structured viewing and editing of models: they subdivide a model into a set of screens according to some organizing principle (although overlaps among aspects are allowed). Table 1 summarizes the model categories, the allowed model types in each category, and the set of modeling aspects. The P l a n t category contains the models that are used to represent what a domain engineer knows about the plant. The plant is modeled in terms of (1) plant functionalities, and (2) plant equipment. This conceptual distinction was found useful, because, e.g. it is conceivable that one type of equipment may be used in many, different processes, and vice versa. Plant functionalities are described in terms of streams and processes. A stream represents an
arbitrary material, energy, or information flow in the plant, while a process represents a transformation that maps input streams to output strearas. Processes and streams form hierarchically structured diagrams, that are very similar to process flowsheets. The process flows show only one aspect of processes; the other aspects include
• finite states, that model the process as a finite-state machine with discrete states and transitions linking them, • equations, that model the process in terms of linear and non-linear differential equations and s- or z-domain polynomials, • failure propagations, that model the anticipated failure modes of the process and how they propagate to other processes, and • "process-equipment" associations, that link equipment models to the process, indicating what hardware is involved in realizing the functionality of the process. The aspects listed have many, primitive, objects that represent the components of the model. For example, a process may have a number of process variables, which will be represented by multiple instances of the icon that stands for a process variable. Connections between icons represent some kind of relationship (e.g., failure propagation between failure modes). Processes can be organized into "part-whole" hierarchies, where, on the higher level a lower-level process is represented by one icon. Figure 2 shows an example of a process model. Plant equipment is described in terms of equipment models that describe the actual hardware of the plant. The aspects of equipment models include:
• structure, to describe connectivity and the hierarchical organization of equipment,
• finite states, that model the equipment as a finite-state machine, and
,, faults, that represent the anticipated equipment problems. These equipment faults are typically related (and thus connected) to process failure modes. Plant and equipment models are "linked", and this linkage happens in the context of the process models: in the "process-equipment" association view one can reference and connect equipment models to the process. The plant models represent and store in a structured way what the plant engineer knows about the plant: how it works, how it is constructed, etc. This service in itself provides an integrated database functionality for archiving plant design information. The problem-solving activities are represented in the form of distinct A c t i v i t y models, that are essentially computational blocks. A
Problem-Solving in Chemical Engineering
5
H~
[I.~.1
4
I~ftSt~ml
t
ZI
,
tl
......
'
!1 t tl It
.........
..............................................J
Fig. 3. A compound activity model computational block, in its most general form, is responsible for receiving data from another block, processing it, and sending it out to another block. The computational blocks are used to form networks of computations that are scheduled according to the dataflow principle: a computational block executes if data is available on its inputs, performs the processing, and then sends out the results on its output, to the next block in the chain. Various kinds of activities are possible, including: algorithmic (for calculations or user-supplied computations), timer (for timedbehavior, like delays), finite-state-machine (for finite-state control algorithms that are modeled using a finite-state automaton), operator interface (for sending data to and receiving data from a human operator), external interface (for exchanging data with the plant's data-acquisition system), and simulation (for solving the model equations and interfacing the equation solver with the datastreams present in an activity diagram). Primitive activities can be embedded in compound activity models (that may contain other compound models), and thus complex applications can be integrated visually. Figure 3 shows an example (compound) activity model. The activity models are not independent of the plant models. Rather, they are linked together, and, in fact, activity models utilize the information present in the plant models. For example, simulation activities explicitly refer to the process models, and activity parameters can use the design values stored in the context of equipment models. This integration is one powerful feature of
IPCS: the problem-solving activities utilize explicit knowledge stored in plant models. From a practical standpoint, the interface issues play an important role. The interfaces are considered as computational blocks, whose "computation" is performed by some external entity (e.g. the plant, the human operator, etc.). The generated IPCS application is equipped with the following interfaces:
• External interface. This interface couples the application to the plant data-acquisition system. A T C P / I P - b a s e d protocol has been defined that connects the application to a data server process. This data server needs to be developed once for every data-acquisition system: it is typically a 2-man-weeks effort. The data server is responsible for both sending and receiving data to and from the dataacquisition system. • Operator interface. The operator interface functionality is also implemented in a separate process that communicates through a T C P / I P protocol. An example of a generic operator interface has been built using Motif/X, but this part can easily be replaced by any other package. Figure 4 shows some screens of the generic operator interface. • External simulators. Some enhanced versions of IPCS have interfaces to external simulators. These interfaces appear as new activity model types that can be used just like any other activity model. The interface includes dedicated server code running on the computer containing the simulator, that couples it to the IPCS run-time system. Cur-
6
G. Karsai and F. DeCaria
Fig. 4. I P C S run-time system: operator interface rently these interfaces are available for various, standard chemical engineering packages. Note t h a t activity models are more than the diagrams used in application generator tools: they also contain links back to the process and equipment models. As an additional gain, in this way applications can be made and kept consistent with the plant models.
3.2 Modeling techniques There are some modeling techniques that are used in all model categories. These techniques help in reducing the complexity of the visual models, and are applicable in systems for other engineering disciplines as well. The techniques are summarized below. • H i e r a r c h y . Using this modeling technique the models are organized into part-whole diagrams, t h a t form a tree structure. When a model is edited, only one node in the tree is shown: it can be the root node, a leaf, "primitive" node, or any intermediate, "compound" node. Wherever the node is, only the immediate children of t h a t node are shown. Obviously, the diagrams are simpler t h a n if all the details were shown. Figure 5 illustrates a model hierarchy. Examples of hierarchical model organization are the process, equipment, and compound activity models. • R e f e r e n c e s . When multiple hierarchies are used, it is not possible to link up objects in different trees. Even in one hierarchy, if
a connection needs to be established to a remote object (on a different subtree), it is quite difficult. References can help in this case: a reference is an object in a model, that is really a pointer to another object in another model. Figure 6 shows an example of referencing. The reference can be established by a graphical "drag-and-drop" operation. Examples of references are the "processequipment" connections, and other examples in the activity models where activities use objects that are present in various plant models. C o n d i t i o n a l s . Visual models are static diagrams that cannot express a dynamic system. However, there was a need to express different configurations of a system using one diagram. The technique of conditionals helps ill this as follows: (1) The model should be built to contain the union of all the possible configurations. (2) Specific "control" objects should be "activated", and components (objects and connections) of the model should t)e attached to them. This attachment represents the fact that if the control object is active, the attached objects are active as well. Figure 7 shows an example of conditionals. The technique helps in visualizing tile different configurations, where, depending on which control object is active, different parts of the diagram are shown. One example of conditional models is present in the process models: failure propagation models (i.e. failure propagation connections and failure modes) can be conditional, based on the state of the system.
Problem-Solving in Chemical Engineering ROOT MODEL
........ []
I ::i1 l
-.
I,RiNrn'cls M ~ I ~ k
Fig. 5. Model hierarchy
Fig. 6. Model reference
3.3 Model interpretation and execution
erator and external interfaces); MGK handles the scheduling issues here as well.
The models are created visually and stored in an object database. The models are not directly executable; hence they must be translated into executable code first. This process is performed by model interpreters in IPCS. Model interpretation is somewhere between compilation and interpretation: primitive operations (i.e. algorithmic activities) are compiled into machine code, while the higher-level structure of the generated application remains interpreted. This approach preserves computational efficiency at the level of calculations, while providing great flexibility for system integration. The end-user gets an application that runs reasonably fast, and can still be changed quickly, debugged, etc. Some activity models have their built-in run-time support system (e.g., the equation solver for the simulation): for these, the interpreters simply configure certain data structures. Model interpreters are thus responsible for: • arranging the compilation and linking of code (if needed), • configuring run-time system components as needed, and • configuring the overall application. For the last step, IPCS is using a macro-dataflow kernel, called the MultiGraph Kernel (MGK), that supports the dynamic building of computational structures that contain executable objects. MGK is the execution environment for IPCS that provides great flexibility in system integration. When the executable objects (i.e., the primitive activities) are developed, they can be written without regard to the environment in which they will be used. That is determined by the higher-level, compound activity models, that "wire up" the application (by specifying the dataflows among activities). This information is used by the model interpreters to create communication channels between the objects (with the help of MGK). Once the network is built, MGK schedules the objects as the dataflow paradigm dictates. Some objects can perform I / O (e.g., op-
Obviously, the end-user does not see anything of this: everything is hidden behind models of activities. The only situation when the end-user may get some exposure is when debugging is activated, that makes possible the monitoring of datastreams in an MGK application from a different process. This facility provides a highlevel interface to activities in applications, but the usual method for interactions with an application is to use the operator interface activities.
4. APPLICATIONS IPCS has been, and is being, used for developing custom applications in a large chemical plant and at various, smaller, industrial sites. One of the first applications was a monitoring tool, that calculated and displayed 32, business-critical variables in the plant. The application was developed in a couple of days by an engineer who had not been exposed to the system before. The next application was a sensor diagnostics application (Padalkar, et al., 1995). The objective of this application was to monitor the health of 35+ sensors (mostly flowmeters and level sensors), and to detect various failures on them. From a model of the processes the application filtered out all the information for calculating loop balances, and could thus identify sensor failures in cases of too-large residuals. Again, the application was created rather rapidly: in about 3 weeks, by one engineer.
Another, large-scale application illustrates the system integration capabilities of IPCS. In that application a large nonlinear dynamic model is used (executed on a remote supercomputer, using a commercial simulation package). The IPCS application collects data from the plant dataacquisition system, preprocesses it, and sends it, in part, to the simulator. When the results are received, it plots them, together with other on-line
8
G. Karsai and F. DeCaria
UNION
O
(NOTHINGIS ACTIVE)
which identify the faulty equipment. This detection process may result in changing the setpoints of controllers, a n d / o r changing the monitoring strategy used for observing the process.
6. CONCLUSIONS SI CONTROL IS ACTIVE
:."~_3L"
_t..-" [__t ....
.___
-t, ,__
S2 CONTROL IS ACTIVE
Fig. 7. Model conditionals data. It also provides tools for operator interactions (e.g. switching between variables, etc.). The first version of this application (for handling about 40 variables) was developed in about one manmonth, but it is still being enlarged and improved. The applications have shown the major characteristics of IPCS: model-integrated application development, visual programming, and easy system integration. These features were well received by practising plant engineers.
5. R E L A T E D W O R K The use of problem-solving environments for chemical process industries is not a new idea: ASCEND (Dee and Westerberg, 1992) and MODEL. LA (Stephanopoulos, 1990) are two examples of problem-solving environments in a chemical engineering setting: the first is a high-quality design environment (with sophisticated solvers, languages, etc.); the second is a general modeling approach and framework for representing processes in chemical industries. In IPCS a slightly different approach was taken: in addition to modeling the processes, facilities are provided for representing (or "coding") the problem solution strategies as well. Very complex applications can be built using this approach and, through the use of the activity models, vastly different problem-solving strategies can be integrated. For instance, real-time plant data can be acquired, and compared against ideal models (through the use of a simulator). Next, if failures are detected, process diagnostics can be started
A model-based problem-solving environment has been developed and used in real-life applications. The system has demonstrated the feasibility of using models in on-line operations. It has also shown that in a complex environment (like a chemical plant), software applications are easier to develop using a high-level (i.e., visual) formalism for generating systems, than they are otherwise. Typical IPCS users are engineers who are familiar with the concepts of programming, but are not system integrators. They want to use the language of chemical engineering (and models), and are looking for simpler ways of building applications of small to medium complexity. It is believed that IPCS is a successful step in providing an environment for their needs.
7. A C K N O W L E D G E M E N T S The research described here was funded, in part, by Osaka Gas and OGIS-RI, Osaka, Japan, Boeing Aerospace, USAF, and Sverdrup Technology. Their support is gratefully acknowledged. OGIS-RI is commercializing IPCS in Japan. Tile IPCS development was done at the Measurement and Computing Systems Laboratory ( h t t p : / / m c s l . vuse. v a n d e r b i l t , edu) of the Department of Electrical and Computer Engineering of Vanderbilt University, led by Dr. Janos Sztipanovits.
8. R E F E R E N C E S Abbott, B., T. Bapty, C. Biegl, G. Karsai and J. Sztipanovits (1993). Model-based approach for software synthesis. IEEE Software pp. 4252. Booch, G. (1994). Object-oriented Analysis and Design with Applications, 2nd. ed.. The Benjamin/Cummings Publishing Company, Inc. Dee, K. and A. Westerberg (1992). Cephda: Chemical engineering process hierarchical design with ascend. Engineering Design Re-
search Center Research Report. GENSYM (1990). G2 Reference Manual. Gensym Corporation. Karsai, G. (1995). A configurable visual programruing environment. IEEE Computer pp. 36 44.
Problem-Solvingin ChemicalEngineering Padalkar, S., G. Karsai, J. Sztipanovits and F. DeCaria (1995). On-line diagnostics makes manufacturing more robust. Chemical Engineering. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W. Lorensen (1991). Object-Oriented Modeling and Design. Prentice Hall. Englewood Cliffs, N.J.
S~ephanopoulos, G. (1990). MODEL.LA. A modeling language for process engineering. Coinputers and Chemical Engineering 14, 495539. Sztipanovits, J., G. Karsai, Cs. Biegl, T. Bapty, A. Ledeczi and A. Misra (1995). Multigraph: An architecture for model-integrated computing. In: Proc. of First IEEE International Conference on Engineering of Complex Computer Systems. pp. 361-368. Ft. Lauderdale, FL.