- Email: [email protected]
Towards a specialized shell for diagnostic expert systems for chemical plant
Towards a specialized shell for diagnostic expert systems for chemical plant V. Venkat~ub~ma~ian Intelligent Systems in Process Engineering Laboratory, Engineering, Columbia University, NY 10027, USA
Department
of Chemical
Recent developments on the application of artificial intelligence (Al) concepts and techniques for the automation of chemical process fault diagnosis has met with some success. However, the process of developing such systems, called knowledge engineering, is time-consuming and expansive involving specialized labour. This bottleneck presents a serious barrier that must be overcome if the benefits of Al-based approaches are to be realized at iarge in the process industry. Towards that goal, we present an analysis of the knowledge engineering process in the context of process diagnosis and a possible solution strategy. By viewing the knowledge engineering activity at different levels of abstraction, one is able to identify how the different aspects of the bottleneck emerge and also clarify methodological issues from formalization- and implementation-related ones. The analysis suggests that a specialized environment or shell, that already possesses the diagnostic methodology and the related modelling constructs, is the natural way of circumventing the bottleneck. As a potential knowledge core of such a shell, a diagnostic methodology that has the characteristics to facilitate rapid prototyping, easy modification, and maintenance of diagnostic expert systems is described. (Keywords:
expart systems;
fault administration;
The automation of chemical fault diagnosis using computers has been a subject of considerable interest for some time, owing to the substantial benefits that can be realized by the process industry’. Past attempts using fault tree’ &rd digraph3 approaches, despite having some elegant ideas and attractive features, have not been completely satisfactory. Recently there has been renewed interest in this area owing to the availability of newer methodologies, techniques, and tools originating from the discipline of A14. With this emerging methodology, it is now possible to automate some cfasses of human problem-solving expertise that typically involve symbolic reasoning and skilful manipulation of large amounts of domain knowledge_ Such automated systems, called knowledgebased systems or expert systems 5*6, have the potential to make a serious impact on process engineering’. The recent knowledge-based approaches to process fault diagnosis produced some interesting results, demonstrating the suitability and the viability of this technology for the process industries’-“. The development of diagnostic expert systems, even for a moderately sized process, turns out to be a time-consuming and expensive process involving specialized labour6*‘2*‘3. Unless the serious difficulties associated with this so-called knowledge engineering activity are solved, the potential benefits of knowledgeReceived
IO December
.J. Loss Prev. Process
based systems will not be realized at large in the process industry. In this paper, we analyse the knowledge engineering activity in the context of process diagnosis at different levels of abstraction to identify the various factors that contribute to the different problems in knowledge engineering. Many of the recent attempts in diagnostic expert systems have drawbacks at the methodological or modelling level for being two process-specific, thus restricting the flexibility and modification of the expert system”. Typically this is due to process-specific heuristics, or formalizing the methodology, even when based on general principles, in a process-specific fashion 14.
Knowledge systems
engineering
of diagnostic
expert
The entire process of developing a problem-solving methodology that can be automated, and then implementing it as an expert system is known as knowledge engineering.
Three levels of abstraction Even though the knowledge engineering process involves several related activities, it can be viewed at three levels of abstraction, namely: 8 development of the problem-solving methodology; (I, modelling or formalization of the methodology
1987
0950-4230~98~020084~0853.00 611988 Butterworth & Co. (Publishers) Ltd
84
modelling)
lnd.,
1988,
Vof 1, April
by
Specialized
shell
for diagnostic
specifying the architecture of the knowledge-based system with regard to the organization of the domain knowledge and its representation, the inference procedure or the control of the reasoning process, user-interface and explanation related issues; 0 Implementational issues such as the software and the hardware aspects of the expert system.
systems
for chemical
Table
1
in the
context
The
three of
V. Venkatasubramanian
of abstraction
process
fault
Level
Issues
Methodological
Diagnostic Compiled Qualitative Modeling
Formalizational
The development of a problem-solving methodology that can be modelled and automated is a crucial part where the domain experts, such as process operators and engineers, play a significant role. This typically involves determination of how the human experts go about solving the problem. Often, this is done by interviewing the experts about their problem-solving strategies, presenting them with sample problems and scenarios, trying to formalize their reasoning process, etc. The conventional approach has been to let computer scientists (knowledge engineers) interact with the domain experts and carry out this knowledge acquisition. However, this process can be greatly facilitated if the knowledge engineer him/herself is also the domain expert, i.e. a process engineer familiar with the process at hand. At this stage of the knowledge engineering one is concerned with the methodological process, aspects such as how to diagnose faults related to sensors, controllers, reactors, and other units present in the given process. The related issues here would be: what kinds of data from the process are required; how are they scanned and interpreted; and how are these process symptoms or evidences to be analysed with the final determination of the status of the process, identification of faults or process abnormalities and their causal origins, and the recommendation and initiation of the necessary control actions. The problem-solving methodology thus developed may be entirely specific to the given process or one may integrate the processspecific and the process-general aspects explicitly in a flexible framework. The latter approach, clearly, would be the desirable one as it would facilitate rapidprototyping and ease of maintenance and modification of the expert system. At the second level, one tries to model or formalize the methodology by resolving the various architectural issues regarding the structure or organization of the domain knowledge and its representation, the inference etc. The problem-solving methodology procedure, developed at the first level could conceivably be modelled through different representational formalisms (such as procedures, rules, frames, or objects, or some combination of these) and by adopting different reasoning techniques (such as forward-chaining, backwardchaining, etc., or some combination of these). Thus there would be some amount of freedom available at this stage to transform the methodology of stage one towards the final goal. However, the methodology itself could dictate certain needs which could be accommodated only through some appropriate choice of reasoning formalisms. For representational and example, the use of objects for knowledge represent-
levels
plant:
Knowledge Knowledge objects, Inference
in knowledge
problem-solving versus
Software Hardware Machines.
methodology.
first-principles
versus r&ted
approach
issues
base
structuring
representation
(rules,
procedures, formalism
frames.
or a hybrid) (forward-chaining, weak
(Language, (PC,
knowledge
quantitattve
backward-chaining, Implementational
engineering
diagnosis
3Zbit
Shell,
methods,
etc.1
etc.)
Workstations,
Lisp
etc).
ation might be preferred over the use of rules due to the character of a diagnostic methodology’5. At the third level, one is concerned about the software issues such as Al languages or shells as well as the support hardware. Once again, even though there is some amount of freedom of choice at this level, the requirements could limit the options. Although one can decouple the knowledge engineering processes along these various levels, there can be strong interactions between these levels. These levels of abstraction are summarized in Table 1. Knowledge
engineering
bottleneck
in process diagnosis
The knowledge engineering process is labour-intensive and time-consuming, and accounts for a major portion of the cost of an expert system. The cost invested in the hardware and software of an expert system project is often small, typically <25% of the total project cost. The experts are often busy with their day-to-day activities, making the knowledge acquisition process difficult. In addition, if the domain experts were to interact with knowledge engineers who are not familiar with process engineering, knowledge acquisition becomes even more frustrating for everyone involved as substantial time and effort (and hence money) must be expended in educating the knowledge engineers about process engineering fundamentals. One solution is to educate chemical engineers with the concepts, methodologies, techniques, and tools of Al. Besides this, one also needs flexible and powerful knowledge engineering environments, designed specifically for the development of diagnostic expert systems, that can be used by processing engineers directly, thereby resolving the knowledge engineering bottleneck. Experience from the FALCON project seems to indicate that developing a diagnostic expert system for a process of moderate size’2S’3 takes about 12 personyears, although it has also been pointed out that it could be reduced to about 3 person-years by utilizing the current tools and the diagnostic methodologies that have been developed. Even though the utility of expert systems in process diagnosis and operations is becoming increasingly clear, the large scale impact is not going to be felt until the knowledge engineering process is
J. Loss Prev.
Process
Ind.,
1988,
Vol
1, April
85
Specialized
simplified we identify knowledge methodology the desired
shell
for diagnostic
systems
for chemical
and made faster. In the following sections, and describe the various factors causing the engineering bottleneck, and also outline a that has the necessary characteristics of solution.
Methodological versus implementational issues. Decomposing the overall knowledge engineering process into the several separate, and somewhat decoupled, levels of activities has the benefit of being able to analyse them individually without mixing up issues which belong to different levels. This kind of structured analysis, or looking at the knowledge engineering activity at several levels of abstraction, helps to minimize confusion separating purely by methodological problem-solving issues from, say, formalizationand implementation-related aspects. It is also helpful in identifying the various factors of the knowledge engineering bottleneck, at which level they originate, and how they may be resolved by addressing them at the appropriate level or level of abstraction. This is important because there is much confusion among people involved in the development of expert systems about how the different difficulties of the knowledge engineering process may be resolved. The point here is that problems associated with one level (e.g. the methodological aspects) typically cannot be resolved by solutions at another level (e.g. by changing the representational or the inferential scheme, or the AI language, etc.). Factors causing the bottleneck and a solution strategy. Let us at this point identify and analyse the different factors that contribute to the knowledge engineering bottleneck by examining them in the context of the various levels of the knowledge engineering activity. The major problems currently associated with the knowledge engineering process are centred around the following activities: Prototype development: it takes too long, and is too much effort, to develop a prototype and the complete expert system. It takes several person-years and hence is too expensive. Modification: once the prototype or the complete expert system has been developed, maintenance of the knowledge base is quite difficult when process changes are involved. Even in the case of simple changes in the process, and even if the change to the knowledge base itself is small, it still takes someone who is thoroughly familiar with the system to make these changes. It takes too much effort and time for someone new, who may know the process thoroughly but not the expert system, to learn about the various aspects of the expert system in order to be able to make the modifications. Verification and tuning: the process of testing the prototype, and the final version, on either real-plant data or using data from simulation again turns out to be a time-consuming process, particularly if simul-
86
J. Loss Prev.
Process
Ind.,
1988,
Vo/
7, April
plant:
V. Venkatasubramanian
ations were to be performed. The testing and tuning procedure tends to be exhaustive and may have to be repeated completely even for small modifications of the knowledge base to ensure the reliability of the new version. Thus the solution strategies towards these problems should facilitate rapid-prototyping, ease of learning and modification, and efficient verification and tuning of the diagnostic expert system. A common source of these problems can often be traced to the first level, in the form of a rigid and limited diagnostic methodology that is process-specific. Many of the current expert system approaches have this drawback of tailoring the solution specifically to the given process, and then encoding this compiled knowledge of symptoms-and-cause associations in the knowledge base (these are discussed in more detail elsewhere”). In such approaches, the structural and functional aspects of the different process units are not represented explicitly, but buried implicitly in the compiled knowledge. When one analyses how people reason about chemical process failures, one immediately recognizes that the reasoning strategy involves certain general principles that are valid for a variety of process plant, as well as some specific information that is true only for the given process. Examples of the general or first-principles would include constraints, confluences, causal dependencies, etc. The ability to alternate the reasoning process between the user of first-principles knowledge and processspecific knowledge helps a human operator to cope with process changes more readily than a conventional expert system. When faced with a new version of an old, familiar, process, the human operator does not feel the need to go through the learning process from the beginning 16. He or she is able to transfer a lot of knowledge acquired with the old version, make some modifications, and adapt to the new surroundings smoothly. The absence of such a methodology, and its suitable formalization, is chiefly responsible for the bottleneck, and the problems outlined above. Even in those cases where attempts have been made to base the diagnosis on first-principles type approaches, the diagnostic methodology was developed and modelled in a process-specific manner I4 resulting in systems that have these problems. This is a combination of issues in levels one and two. Other factors that contribute to the bottleneck arise from incorrect choices made at levels two or three. In level two, these choices would be concerned with issues such as how the knowledge is organized, representational formalisms such as rules, frames, or objects, control aspects of the reasoning process, etc. In our own experience, we have experimented with two different level two approaches for the same problem-solving methodology. The first approach, which centred around the production rule-based representation of knowledge, had certain difficulties associated with the control of the reasoning, has been described”. The
Specialized
shell
for diagnostic
systems
for chemical
plant:
V. Venkatasubramanian
second approach, which utilizes an object-orientated representational formalism, supports the requirements of the same diagnostic implications and the methodology. Further problems can arise due to inappropriate choice of AI languages or tools. It is quite clear that for diagnostic expert systems, the use of AI software that supports object-orientated programming and related graphics helps in development and maintenance.
of developing a diagnostic methodology and formalizing it is still largely left to the process engineer. Thus, the knowledge engineering bottleneck though somewhat reduced would still be around for all practicality. The proposed specialized environment is required to have the diagnostic methodology, and its modelling aspects already built-in if it were to have any significant impact on the knowledge engineering process.
Towards a specialized expert systems
Diagnostic reasoning based on structure and behaviour of process plants
environment
for
diagnostic
The development of a knowledge engineering environment or shell, specifically addressing the needs of diagnostic expert systems is the next natural evolutionary stage of AI-based tools. It is quite clear that as the cost of AI hardware and software plunges, and the supply of engineers knowledgeable about AI increases, the trend would be the evolution of more and more specialized knowledge engineering environments or shells that would be task- or problem-specific. At the first stage of this evolution, we had AI languages such as LISP which were totally generic, that came with no built-in problemsolving knowledge or framework, and were completely open-ended with respect to applications. At the next stage was the development of knowledge engineering environments or shells such as KEE and ART, which provided the knowledge representation and inference engine facilities, but not the problem-solving methodology or the domain knowledge specific to some task at hand, thus leaving the entire burden of knowledge engineering to the expert system developers. The design specifications and characteristics of such a shell can be viewed using the levels of abstraction perspective discussed above. From the level one perspective, the shell should already possess the problemsolving methodology and domain knowledge appropriate for process diagnosis. This methodology should clearly differentiate, and flexibly integrate, the general principles from the process-specific aspects. Viewed from the second level, the shell should possess the appropriate components for formalizing and supporting the diagnostic methodology. The issues involved at this level would include decomposition and structuring of the knowledge base, a library of causal and fault models knowledge representational of the process units, aspects, inference mechanisms, integration of processgeneral and process-specific knowledge, constraint management and propagation facilities, procedural attachments to perform the quantitative calculations, etc. The required modelling constructs are to be provided by this shell. At the next level the implementational aspect of the shell surfaces, which in the case of the prototype discussed in this paper is in the object-orientated programming language flavours. One should bear in mind that having a facility such as a graphics interface, even though it may have been tailor-made for processing engineering applications, is not adequate by itself to provide the kind of environment described in this paper. This is so because the task
The diagnostic methodology separates the general principles from process-specific information, and also provides a way to flexibly integrate them. The knowledge base related aspects of the methodology by analysing the first-principles knowledge required and the organization of the knowledge base are presented. The objectorientated character of this methodology is also illustrated, with the aid of concepts in object-orientated programming. The framework discussed in this paper has been implemented in the form of two expert system prototypes, called MODEX and MODEXZ, and are outlined here. The details of these systems are presented elsewhere”‘“. Knowledge
base-related
aspects
of the methodology
The first-principles knowledge used in the diagnostic process can be grouped into several categories. The first represents constraints. derived from material and energy balances around a given process unit or a collection of several units. For example, if a valve is functioning properly and the size of its opening is properly set, then the outlet flow rate from the valve equals the inlet flow rate. The constraints can be treated quantitatively, or qualitatively as in confluence equations “. The second category represents confluence equations (qualitative differential equations) that represent the influence of one state variable on another. When treated qualitatively, material and energy balances can be viewed as confluence relations. The third category of process-general knowledge used in this methodology corresponds to a library of fault models of the different process units. A fault model contains typical fault modes associated with a process unit linking an observed process abnormality (such as a high tank level) to its local causes (such as a high inlet flow rate, or a low outlet flow rate, etc.). A fourth category deals with causal models of process units that represent how certain equipment malfunctions will cause certain process abnormalities or faults. Examples include how a clogged valve or pipe might result in a low flow rate. The causal models, in some sense, are the inverse of fault models relating causes to effects. Together, the fault and causal models capture the functional aspects of the process units explicitly by identifying how different functions of a process unit are affected by the various unit related failures (called basic events). These also represent the causal dependencies
J. Loss Prev.
Process
Ind.,
1988,
Vol
1, April
87
Specialized shell for diagnostic systems among
state variables,
e.g. an increase
for chemical plant: V. Venkatasubramanian
in temperature
in
a reactor would cause an increase in pressure. Thus the reasoning is based on these general principles, which are applicable to a variety of processes. It is a well known result that in dealing with complex systems one should view the system at different levels of abstraction, thus suitably decomposing the system 18. In our methodology, the overall process is decomposed, using a combination of structural and functional information about the process and the process units. Thus the diagnostic reasoning is based on structural knowledge about the process such as how the units are configured, and behavioural knowledge such as how the functions of the different units are related to one another and to equipment failures. Since such knowledge about the process is represented explicitly, not compiled and buried implicitly, the expert system can accommodate changes in the process more readily, as different processes are viewed as different configurations of the same units that are modelled in the library. This also facilitates rapid-prototyping as the diagnostic methodology is already embedded in a generic manner. Addition of new units, in the form of causal and fault models, not present in the library is also easier, due to the object-orientated organization of the knowledge base. Characteristicsof the object-orientated methodology One of the central ideas of this methodology is the use of a library of models of the process units. Thus the methodology, viewed from the level one perspective, has this object-orientated character associated with it. Fortunately, this inherent feature (or requirement) can be supported at level two by utilizing object-orientated knowledge representation and programming techniques. Object-orientated techniques advocate a philosophy where the programming is centred around objects and interactions between objects 19. Objects are the basic
Object relatwwhws -
Member
+=HtH+-
Instance-of
Figure
88
1
An
J. Loss
of class
object-orientated
process
unit
hierarchy
Prev. Process Ind., 1988,
Vol 1, April
building blocks in the framework. Objects are entities that serve as focal points for chunking knowledge together. Objects have properties and values, and can have procedures called methods attached to them. Examples of objects might be process units such as reactors, valves, sensors, controllers, etc. Objectorientated programming, derived from semantic networks and frames, is inheritance which permits the automatic transfer of knowledge (such as properties, methods, etc.) from one object to another through inheritance hierarchies. This is depicted in Figure 1. Inheritance facilitates compact and efficient organization of knowledge, and the creation of taxonomic structuring. Another important idea, absent in semantic networks and frames, is communication between objects in the form of passing messages between objects. Action in object orientated programming is centred around the passing of these messages. Thus the process units, their structural and behavioural properties, the causal and fault models, etc. are represented as objects and methods. Use of multiple representations in the knowledge base The knowledge engineering process can be facilitated by the use of appropriate organization and representation of the knowledge base. Along these lines, we have been experimenting with the notion of multiple representations of knowledge in the context of the diagnostic expert system FALCON developed at the University of Delaware’2*8. The central theme in this approach is that the mental models engineers’ use in reasoning about a chemical process is largely centred around the process flowsheet and the process units. One thus has a hierarchical structuring of the process knowledge. Also, people associate a variety of different types of knowledge with individual units, resulting in some generic default models of these process units with some specific characteristics incorporated additionally. Such knowledge would include structural connectivity information, functionality, typical faulty behaviours, their causal origins and their consequences, constraints, etc. Thus for a knowledge base to be transparent, its representation and organization should closely reflect the nature of the conceptual models the engineers have about the process. We refer to this representation as the conceptual representation of the process plant. Using this engineer’s interface, the process engineer developing or modifying the knowledge base would see a perspective of the knowledge base that is centred around the process flowsheet and the individual units. New knowledge would thus be introduced using this conceptual representation by selectively editing the various objects presented to the engineer as icons in a graphical interface. The conceptual representation would thus capture the hierarchical and process unitcentred nature of an engineer’s reasoning. However, the conceptual representation, which is an appropriate and a convenient formalism to be presented to a process engineer, may not be suitable for efficient processing of this knowledge due to the computational
Specialized
shell
for diagnostic
Process enqneer
I
c
Objects annpiler
systems
for chemical
plant:
V. Venkatasubramanian
is removed, and the branch of the diagnostic tree is terminated. The expert system then returns to continue the diagnosis of the fault currently at the top of the agenda. When the agenda has been emptied, the diagnostic session ends. The ordering of faults in the agenda is thus dynamic. If a fault on the list is found to be a local cause of the topmost abnormality on the agenda, then this fault moves from the middle to the top of the agenda. A record is kept of the agenda such that once faults are removed they never can appear again on the agenda. This prevents the expert system from reexamining a fault that it has previously diagnosed. This control algorithm is shown in Figure 3. Using
both
-first-principles
knowledge
and
compiled
knowledge Knowtedgebase Figure 2
Architecture
ot the object-orientated
version of FALCON
overhead associated with such a representation. From the performance and inference mechanisms point of view, one requires a different internal representation for efficient processing. The current FALCON representation is closer to this internal representation and quite removed from the conceptual representation an engineer might feel comfortable with. Thus one requires two different representational formalisms, one for the process engineer’s convenience and one other for efficient run-time performance. The translation from the conceptual representation to the internal representation would be performed by the module called the objects compiler. Figure 2 shows the organization of the FALCON based on the dual representational formalism. An agenda-based
control
The advantages of this diagnostic strategy discussed so far are flexibility and generality, ease of modification and updating. However, since the approach relies on general principles alone, it does not utilize any processspecific, compiled, knowledge that might be available. Hence the search tends be exhaustive, and examines more potential causes than is necessary. An expert familiar with the given process would have a lot of knowledge of compiled associations process symptoms and their causal origins. With such knowledge, an expert would outperform a novice who would not know much about such specific behavioural aspects of the process. Thus an expert would typically try out these process-specific heuristics first to diagnose the faults. When faced with new faults, however, use of such heuristics would not be helpful (as there would be
Inputhnowl facts about currentSystemState
Estabtishagenda canalstingof obsewedprocessatwrmalitii
of reasoning
In reasoning about process faults, the proposed methodology searches for causal origins or basic events responsible for the faults by identifying the local causes, through the use of structural aspects of the process along with behavioural information about the process units, and then propagating the local causes recursively until the basic events are discovered. This is facilitated by the use of an agenda-based control that derives a depth-first search. All initially observed process abnormalities are recorded on an agenda. Each confluence method is then called to attempt to generate inferences from the initial data from the process. The diagnosis of the abnormality at the top of the agenda is then pursued, by calling the appropriate fault model method, until all potential local causes are examined. If a local cause is found to be present, then this fault is placed at the top of the agenda and all of its potential local causes are examined. This process can be viewed as constructing a diagnostic tree (or network) of nodes and arcs. The diagnostic search continues until a basic event is found or the set of potential local causes has been exhausted. In either case, a summary is printed, the fault at the top of the agenda
abwrnwlity fromagenda
Figure 3
An agenda-based
J. Loss Prev.
Process
control algorithm
fnd.,
1988,
Vol
I, April
89
Specialized shell for diagnostic systems
for chemical plant: V. Venkatasubramanian
no solutions from past experience) and the expert would resort to some sort of an analysis based on the structure and behaviour of the process. The proposed methodology also facilitates the integration of processspecific heuristics with the generic principles, similar to the combined reasoning strategy of an expert. In the latter framework, the knowledge base consists of twotiers with the compiled knowledge in the top-tier and the first-principles knowledge in the bottom-tier. In the diagnostic process, top-tier heuristics are tried out first. If they fail, then the system resorts to the already described reasoning strategy based on structure and behaviour. Thus reasoning alternates between the two tiers of knowledge. This methodology has been implemented in the form of an expert system, called MODEX 2, that has performed successfully on prototypical process plants. The details of this framework and the MODEXZ system are described elsewhere”*16. An example using MODEX This example does not include the two-tier reasoning approach. The test case is a number of process abnormalities associated with the prototypical process plant shown in Figure 4. Even though this case study does not involve control loops, the methodology can handle such subsystems as well (as described previously 15). The initial agenda of process abnormalities reads: l high
stream 0 high reactor l high reactor
temperature level pressure
= -
- - -
Stream I
Tank 2
stream3
Valve I
voive2
stream 2
stream 4
s-7
Pressure mlief Mlve I
-_
_
RWctW
(vdve 4)
2
Yy VOIW 3
Slmam7
PumpI
CT=--.
Tank3
& Figure 4
90
J.
A prototypical
AND comectiin Node tsepackladif expert systemasks user ttw question. Numbers: crderin which node
Is conditiontrue ? X - bmnch ferminoted
The system is also initially informed that the pump is functioning properly, and that feed tank1 does not have a leak. The diagnostic tree that results from the analysis is shown in Figure 3. A directed arc connecting two nodes in the tree implies that the event represented by the incident node is caused by the event represented by the terminal node of the arc. The numbers associated with
Tank I
Key :
process plant for case study
Loss Prev. Process Ind., 1988,
Vol 1, April
i-H++-+ Figure 5
Yes X
Arrow withbars Impliesinfcnnatian onnode is usedelsewhasinlhetree Diagnostic
tree for the case study
each node give the order in which MODEX generated the node. The expert system determines that the high reactor level can be attributed to valve 2 which is excessively open, and both the high temperature in stream 6 and the high reactor pressure can be traced to the high temperature in feed tank 2. This example demonstrates the ability of the stream first, to divide the initial set of observed faults into subsets of related faults and second, to locate multiple causal origins of a fault should there be multiple origins. The system is able to use information gathered from the diagnosis of one fault in the diagnosis of another, unrelated, fault. For instance the knowledge that valve 2 is open (determined in the search for the cause of the high reactor temperature) allows the system to determine the cause of the high flow rate in stream 4. Note that in using the depth first control strategy MODEX systematically proceeds down a branch of the tree until the branch is terminated. Due to space constraints in Figure 5, the organization of the nodes are not in the traditional depth-first manner, though the search is depth-first in nature.
Conclusions In this paper,
we have examined
the different
factors
Specialized
shell
far diagnostic
contributing to the knowledge engineering bottleneck currently faced in the development of diagnostic expert systems for chemical plant. Difficulties lie in rapidprototyping, modifying and updating, and verifying and tuning the expert systems. An analysis of the knowledge engineering activity at different, and somewhat decoupled, levels of abstraction helps to clarify and separate the various issues contributing to the bottleneck. The diagnostic problem-solving methodology emerges as the central issue. This is a level one issue, in the terminology used in this paper, which has a direct effect on the bottleneck. We also identify that level two issues, such as the formalization aspects like knowledge representation and inference techniques, as other important factors that can create the bottleneck even if the correct methodology had been chosen. Problems such as real-time performance of the system are closely related to the specific choice of software and hardware, and they tend to be temporary as they will be adequately resolved with the emergence of faster and cheaper hardware as the current trend indicates. The really important and challenging aspects of the bottleneck that we should be concerned with are factors related to methodology (at level one) and formalization of the methodology (at level two). It is also suggested that the current difficulties in knowledge engineering can be largely solved with the aid of a knowledge engineering environment or shell, that is specifically designed for developing diagnostic expert systems. The primary difference between such a shell and the environments such as KEE or ART will be the inclusion of the diagnostic methodology and the related domain knowledge. T’his seems to be the next natural evolutionary stage of artificial intelligence based tools. Since the methodological and formaliz~tion~ aspects play such a central role, we present a device-centred diagnostic methodology that facilitates rapidprototyping, ease of modification and updating of the expert system. Such a mefhodology could for instance serve as the central generic core of a diagnostic shell or environment. The diagnostic methodology decomposes the process plant into a hierarchy of subsystems by using a combination of structural and functional decomposition. The reasoning is based on first-principles knowledge such as constraints, confluences, and a library of causal and fault models of the process units, all of which are process-general and applicable to a variety of processes. An agenda-driven control algorithm is used for guiding the inference. The unit-orientated character of this methodology is formalized with the aid of concepts and techniques from object-orientated knowledge representation. We have also outlined a two-tier knowledge base architecture for integrating the process-general aspects of this framework with process-specific, compiled,
systems
for chemical
plant:
V. Venkatasubramanian
knowledge. The performance of the expert system prototype MODEX, implementing this methodology, has been found to be satisfactory on prototypical process plant.
Acknowledgements The author thanks Professor P. Dhurjati and Professor D. Lamb, members of the FALCON project team at the University of Delaware. The author is also grateful to A. Varma and J. Kantor for the invitation, hospitality, and for generously offering the department’s computational facilities. The research and development efforts of S. Rich of Columbia University working on the MODEX project are also appreciated.
References I
Himmelblau, L?. M., in ‘Fault Detection and Diagnosis in Chemical and Petrochemical Processes’, Elsevier Scientific Publishing Co., Amsterdam 1978 Lapp, S. A., and Powers, G. MEE Trans. Rehb. 1977. April Shiotaki, J., Matsuyama, H., O’Shima, E., and Iri, M. Com-
puters& Chemical
6 7
8
9 10 11 12 13 14 I5 16 17
Engineering,
1985, 9, 285-293
Rich, E., in ‘Artificial Inteiligence’, McGraw-Hill Pub. Co., NY, USA, 1983 Hayes-Roth, F., Lenat, D. B., and Waterman, D. A., (Eds.), in ‘Btdidirtg Expert Sysfems’, Addison-Wesley Publishing Co., Reading, MA, USA, 1983 Water&an, D,, in ‘A Guide to Expert Systems’, Addison-Wesley Pub. Co., Reading, MA, USA, 1985 Banares-Akantar& R., S&am, D., Venkatasubramanian, V., Westerberg, A., and Ryehener, M. Chem. Eng. Prog. 1985, 9, 25-30 Dhurjati, P., Lamb, D. and Chester, D., ‘Experience in the Development of an Expert System For Fault Diagnosis in a Commercial Scale Chemical Process’, Proc. Int. Conf. on the Foundations of Computer-Aided Process Operations, Park City, Utah, July 1987 Kramer, M., and Palowitch, B., Expert System and KnowiedgeBased Approaches to Process Malfunction Diagnosis, presented at the AIChE Annuai Meeting, Chicago, November, 1985 Niida, R, ‘Some Expert System Experiments in Processing Engineering, in IChemE. Symp. Ser. 1985, p. 529-538 Rich, s. H., and Venkatasubramanian, V. Computers & Chemicaf E&twering 1987, II f2), Ill- 122 Rowan; D. A.: ‘Chemical Plant Fault Diagnosis Using Expert Systems Technology: A Case Study’, in Proc. IFAC Conference, Kyato, Japan, 1986 Shirley, R. S., ‘Status Report 3 With Lessons: An Expert System to Aid Process Control’, in Proceedings of ISA/87, 1987 Venkatasubramanian, V., and Dhurjati, P., Proc. Int. Conf. on Foundations of Computer-Aided Process Operations, Park City, Utah, USA, 1987 Venkatasubramanian, V., and Rich. S. H.. Computers & Chemical fhgitteerittg, 1988, submitted for publication Venkatasubramanian, V., and Rich, S. H., Proc. 2nd Int. Conf. On Artificial Intelligence Applications in Engineering, Boston, MA, USA, 1987 de Kleer, J. and Brown, J. S., Arrificiai Inrelligence 1984, 24, 7--1% Simon, H. A., ‘Sciences of the Artificial’, MIT Press, Cambridge, MA. USA, I969 Stefik, M., and Bobrow, D. 0. ‘Object-Oriented Programming: Themes and Variations’, AI Maguzine, Winter, 1986, pp. 40-62 _”
18 19
J. Loss Prev.
Process
in&
1988,
Vol
I, April
91
Department
of Chemical
Recent developments on the application of artificial intelligence (Al) concepts and techniques for the automation of chemical process fault diagnosis has met with some success. However, the process of developing such systems, called knowledge engineering, is time-consuming and expansive involving specialized labour. This bottleneck presents a serious barrier that must be overcome if the benefits of Al-based approaches are to be realized at iarge in the process industry. Towards that goal, we present an analysis of the knowledge engineering process in the context of process diagnosis and a possible solution strategy. By viewing the knowledge engineering activity at different levels of abstraction, one is able to identify how the different aspects of the bottleneck emerge and also clarify methodological issues from formalization- and implementation-related ones. The analysis suggests that a specialized environment or shell, that already possesses the diagnostic methodology and the related modelling constructs, is the natural way of circumventing the bottleneck. As a potential knowledge core of such a shell, a diagnostic methodology that has the characteristics to facilitate rapid prototyping, easy modification, and maintenance of diagnostic expert systems is described. (Keywords:
expart systems;
fault administration;
The automation of chemical fault diagnosis using computers has been a subject of considerable interest for some time, owing to the substantial benefits that can be realized by the process industry’. Past attempts using fault tree’ &rd digraph3 approaches, despite having some elegant ideas and attractive features, have not been completely satisfactory. Recently there has been renewed interest in this area owing to the availability of newer methodologies, techniques, and tools originating from the discipline of A14. With this emerging methodology, it is now possible to automate some cfasses of human problem-solving expertise that typically involve symbolic reasoning and skilful manipulation of large amounts of domain knowledge_ Such automated systems, called knowledgebased systems or expert systems 5*6, have the potential to make a serious impact on process engineering’. The recent knowledge-based approaches to process fault diagnosis produced some interesting results, demonstrating the suitability and the viability of this technology for the process industries’-“. The development of diagnostic expert systems, even for a moderately sized process, turns out to be a time-consuming and expensive process involving specialized labour6*‘2*‘3. Unless the serious difficulties associated with this so-called knowledge engineering activity are solved, the potential benefits of knowledgeReceived
IO December
.J. Loss Prev. Process
based systems will not be realized at large in the process industry. In this paper, we analyse the knowledge engineering activity in the context of process diagnosis at different levels of abstraction to identify the various factors that contribute to the different problems in knowledge engineering. Many of the recent attempts in diagnostic expert systems have drawbacks at the methodological or modelling level for being two process-specific, thus restricting the flexibility and modification of the expert system”. Typically this is due to process-specific heuristics, or formalizing the methodology, even when based on general principles, in a process-specific fashion 14.
Knowledge systems
engineering
of diagnostic
expert
The entire process of developing a problem-solving methodology that can be automated, and then implementing it as an expert system is known as knowledge engineering.
Three levels of abstraction Even though the knowledge engineering process involves several related activities, it can be viewed at three levels of abstraction, namely: 8 development of the problem-solving methodology; (I, modelling or formalization of the methodology
1987
0950-4230~98~020084~0853.00 611988 Butterworth & Co. (Publishers) Ltd
84
modelling)
lnd.,
1988,
Vof 1, April
by
Specialized
shell
for diagnostic
specifying the architecture of the knowledge-based system with regard to the organization of the domain knowledge and its representation, the inference procedure or the control of the reasoning process, user-interface and explanation related issues; 0 Implementational issues such as the software and the hardware aspects of the expert system.
systems
for chemical
Table
1
in the
context
The
three of
V. Venkatasubramanian
of abstraction
process
fault
Level
Issues
Methodological
Diagnostic Compiled Qualitative Modeling
Formalizational
The development of a problem-solving methodology that can be modelled and automated is a crucial part where the domain experts, such as process operators and engineers, play a significant role. This typically involves determination of how the human experts go about solving the problem. Often, this is done by interviewing the experts about their problem-solving strategies, presenting them with sample problems and scenarios, trying to formalize their reasoning process, etc. The conventional approach has been to let computer scientists (knowledge engineers) interact with the domain experts and carry out this knowledge acquisition. However, this process can be greatly facilitated if the knowledge engineer him/herself is also the domain expert, i.e. a process engineer familiar with the process at hand. At this stage of the knowledge engineering one is concerned with the methodological process, aspects such as how to diagnose faults related to sensors, controllers, reactors, and other units present in the given process. The related issues here would be: what kinds of data from the process are required; how are they scanned and interpreted; and how are these process symptoms or evidences to be analysed with the final determination of the status of the process, identification of faults or process abnormalities and their causal origins, and the recommendation and initiation of the necessary control actions. The problem-solving methodology thus developed may be entirely specific to the given process or one may integrate the processspecific and the process-general aspects explicitly in a flexible framework. The latter approach, clearly, would be the desirable one as it would facilitate rapidprototyping and ease of maintenance and modification of the expert system. At the second level, one tries to model or formalize the methodology by resolving the various architectural issues regarding the structure or organization of the domain knowledge and its representation, the inference etc. The problem-solving methodology procedure, developed at the first level could conceivably be modelled through different representational formalisms (such as procedures, rules, frames, or objects, or some combination of these) and by adopting different reasoning techniques (such as forward-chaining, backwardchaining, etc., or some combination of these). Thus there would be some amount of freedom available at this stage to transform the methodology of stage one towards the final goal. However, the methodology itself could dictate certain needs which could be accommodated only through some appropriate choice of reasoning formalisms. For representational and example, the use of objects for knowledge represent-
levels
plant:
Knowledge Knowledge objects, Inference
in knowledge
problem-solving versus
Software Hardware Machines.
methodology.
first-principles
versus r&ted
approach
issues
base
structuring
representation
(rules,
procedures, formalism
frames.
or a hybrid) (forward-chaining, weak
(Language, (PC,
knowledge
quantitattve
backward-chaining, Implementational
engineering
diagnosis
3Zbit
Shell,
methods,
etc.1
etc.)
Workstations,
Lisp
etc).
ation might be preferred over the use of rules due to the character of a diagnostic methodology’5. At the third level, one is concerned about the software issues such as Al languages or shells as well as the support hardware. Once again, even though there is some amount of freedom of choice at this level, the requirements could limit the options. Although one can decouple the knowledge engineering processes along these various levels, there can be strong interactions between these levels. These levels of abstraction are summarized in Table 1. Knowledge
engineering
bottleneck
in process diagnosis
The knowledge engineering process is labour-intensive and time-consuming, and accounts for a major portion of the cost of an expert system. The cost invested in the hardware and software of an expert system project is often small, typically <25% of the total project cost. The experts are often busy with their day-to-day activities, making the knowledge acquisition process difficult. In addition, if the domain experts were to interact with knowledge engineers who are not familiar with process engineering, knowledge acquisition becomes even more frustrating for everyone involved as substantial time and effort (and hence money) must be expended in educating the knowledge engineers about process engineering fundamentals. One solution is to educate chemical engineers with the concepts, methodologies, techniques, and tools of Al. Besides this, one also needs flexible and powerful knowledge engineering environments, designed specifically for the development of diagnostic expert systems, that can be used by processing engineers directly, thereby resolving the knowledge engineering bottleneck. Experience from the FALCON project seems to indicate that developing a diagnostic expert system for a process of moderate size’2S’3 takes about 12 personyears, although it has also been pointed out that it could be reduced to about 3 person-years by utilizing the current tools and the diagnostic methodologies that have been developed. Even though the utility of expert systems in process diagnosis and operations is becoming increasingly clear, the large scale impact is not going to be felt until the knowledge engineering process is
J. Loss Prev.
Process
Ind.,
1988,
Vol
1, April
85
Specialized
simplified we identify knowledge methodology the desired
shell
for diagnostic
systems
for chemical
and made faster. In the following sections, and describe the various factors causing the engineering bottleneck, and also outline a that has the necessary characteristics of solution.
Methodological versus implementational issues. Decomposing the overall knowledge engineering process into the several separate, and somewhat decoupled, levels of activities has the benefit of being able to analyse them individually without mixing up issues which belong to different levels. This kind of structured analysis, or looking at the knowledge engineering activity at several levels of abstraction, helps to minimize confusion separating purely by methodological problem-solving issues from, say, formalizationand implementation-related aspects. It is also helpful in identifying the various factors of the knowledge engineering bottleneck, at which level they originate, and how they may be resolved by addressing them at the appropriate level or level of abstraction. This is important because there is much confusion among people involved in the development of expert systems about how the different difficulties of the knowledge engineering process may be resolved. The point here is that problems associated with one level (e.g. the methodological aspects) typically cannot be resolved by solutions at another level (e.g. by changing the representational or the inferential scheme, or the AI language, etc.). Factors causing the bottleneck and a solution strategy. Let us at this point identify and analyse the different factors that contribute to the knowledge engineering bottleneck by examining them in the context of the various levels of the knowledge engineering activity. The major problems currently associated with the knowledge engineering process are centred around the following activities: Prototype development: it takes too long, and is too much effort, to develop a prototype and the complete expert system. It takes several person-years and hence is too expensive. Modification: once the prototype or the complete expert system has been developed, maintenance of the knowledge base is quite difficult when process changes are involved. Even in the case of simple changes in the process, and even if the change to the knowledge base itself is small, it still takes someone who is thoroughly familiar with the system to make these changes. It takes too much effort and time for someone new, who may know the process thoroughly but not the expert system, to learn about the various aspects of the expert system in order to be able to make the modifications. Verification and tuning: the process of testing the prototype, and the final version, on either real-plant data or using data from simulation again turns out to be a time-consuming process, particularly if simul-
86
J. Loss Prev.
Process
Ind.,
1988,
Vo/
7, April
plant:
V. Venkatasubramanian
ations were to be performed. The testing and tuning procedure tends to be exhaustive and may have to be repeated completely even for small modifications of the knowledge base to ensure the reliability of the new version. Thus the solution strategies towards these problems should facilitate rapid-prototyping, ease of learning and modification, and efficient verification and tuning of the diagnostic expert system. A common source of these problems can often be traced to the first level, in the form of a rigid and limited diagnostic methodology that is process-specific. Many of the current expert system approaches have this drawback of tailoring the solution specifically to the given process, and then encoding this compiled knowledge of symptoms-and-cause associations in the knowledge base (these are discussed in more detail elsewhere”). In such approaches, the structural and functional aspects of the different process units are not represented explicitly, but buried implicitly in the compiled knowledge. When one analyses how people reason about chemical process failures, one immediately recognizes that the reasoning strategy involves certain general principles that are valid for a variety of process plant, as well as some specific information that is true only for the given process. Examples of the general or first-principles would include constraints, confluences, causal dependencies, etc. The ability to alternate the reasoning process between the user of first-principles knowledge and processspecific knowledge helps a human operator to cope with process changes more readily than a conventional expert system. When faced with a new version of an old, familiar, process, the human operator does not feel the need to go through the learning process from the beginning 16. He or she is able to transfer a lot of knowledge acquired with the old version, make some modifications, and adapt to the new surroundings smoothly. The absence of such a methodology, and its suitable formalization, is chiefly responsible for the bottleneck, and the problems outlined above. Even in those cases where attempts have been made to base the diagnosis on first-principles type approaches, the diagnostic methodology was developed and modelled in a process-specific manner I4 resulting in systems that have these problems. This is a combination of issues in levels one and two. Other factors that contribute to the bottleneck arise from incorrect choices made at levels two or three. In level two, these choices would be concerned with issues such as how the knowledge is organized, representational formalisms such as rules, frames, or objects, control aspects of the reasoning process, etc. In our own experience, we have experimented with two different level two approaches for the same problem-solving methodology. The first approach, which centred around the production rule-based representation of knowledge, had certain difficulties associated with the control of the reasoning, has been described”. The
Specialized
shell
for diagnostic
systems
for chemical
plant:
V. Venkatasubramanian
second approach, which utilizes an object-orientated representational formalism, supports the requirements of the same diagnostic implications and the methodology. Further problems can arise due to inappropriate choice of AI languages or tools. It is quite clear that for diagnostic expert systems, the use of AI software that supports object-orientated programming and related graphics helps in development and maintenance.
of developing a diagnostic methodology and formalizing it is still largely left to the process engineer. Thus, the knowledge engineering bottleneck though somewhat reduced would still be around for all practicality. The proposed specialized environment is required to have the diagnostic methodology, and its modelling aspects already built-in if it were to have any significant impact on the knowledge engineering process.
Towards a specialized expert systems
Diagnostic reasoning based on structure and behaviour of process plants
environment
for
diagnostic
The development of a knowledge engineering environment or shell, specifically addressing the needs of diagnostic expert systems is the next natural evolutionary stage of AI-based tools. It is quite clear that as the cost of AI hardware and software plunges, and the supply of engineers knowledgeable about AI increases, the trend would be the evolution of more and more specialized knowledge engineering environments or shells that would be task- or problem-specific. At the first stage of this evolution, we had AI languages such as LISP which were totally generic, that came with no built-in problemsolving knowledge or framework, and were completely open-ended with respect to applications. At the next stage was the development of knowledge engineering environments or shells such as KEE and ART, which provided the knowledge representation and inference engine facilities, but not the problem-solving methodology or the domain knowledge specific to some task at hand, thus leaving the entire burden of knowledge engineering to the expert system developers. The design specifications and characteristics of such a shell can be viewed using the levels of abstraction perspective discussed above. From the level one perspective, the shell should already possess the problemsolving methodology and domain knowledge appropriate for process diagnosis. This methodology should clearly differentiate, and flexibly integrate, the general principles from the process-specific aspects. Viewed from the second level, the shell should possess the appropriate components for formalizing and supporting the diagnostic methodology. The issues involved at this level would include decomposition and structuring of the knowledge base, a library of causal and fault models knowledge representational of the process units, aspects, inference mechanisms, integration of processgeneral and process-specific knowledge, constraint management and propagation facilities, procedural attachments to perform the quantitative calculations, etc. The required modelling constructs are to be provided by this shell. At the next level the implementational aspect of the shell surfaces, which in the case of the prototype discussed in this paper is in the object-orientated programming language flavours. One should bear in mind that having a facility such as a graphics interface, even though it may have been tailor-made for processing engineering applications, is not adequate by itself to provide the kind of environment described in this paper. This is so because the task
The diagnostic methodology separates the general principles from process-specific information, and also provides a way to flexibly integrate them. The knowledge base related aspects of the methodology by analysing the first-principles knowledge required and the organization of the knowledge base are presented. The objectorientated character of this methodology is also illustrated, with the aid of concepts in object-orientated programming. The framework discussed in this paper has been implemented in the form of two expert system prototypes, called MODEX and MODEXZ, and are outlined here. The details of these systems are presented elsewhere”‘“. Knowledge
base-related
aspects
of the methodology
The first-principles knowledge used in the diagnostic process can be grouped into several categories. The first represents constraints. derived from material and energy balances around a given process unit or a collection of several units. For example, if a valve is functioning properly and the size of its opening is properly set, then the outlet flow rate from the valve equals the inlet flow rate. The constraints can be treated quantitatively, or qualitatively as in confluence equations “. The second category represents confluence equations (qualitative differential equations) that represent the influence of one state variable on another. When treated qualitatively, material and energy balances can be viewed as confluence relations. The third category of process-general knowledge used in this methodology corresponds to a library of fault models of the different process units. A fault model contains typical fault modes associated with a process unit linking an observed process abnormality (such as a high tank level) to its local causes (such as a high inlet flow rate, or a low outlet flow rate, etc.). A fourth category deals with causal models of process units that represent how certain equipment malfunctions will cause certain process abnormalities or faults. Examples include how a clogged valve or pipe might result in a low flow rate. The causal models, in some sense, are the inverse of fault models relating causes to effects. Together, the fault and causal models capture the functional aspects of the process units explicitly by identifying how different functions of a process unit are affected by the various unit related failures (called basic events). These also represent the causal dependencies
J. Loss Prev.
Process
Ind.,
1988,
Vol
1, April
87
Specialized shell for diagnostic systems among
state variables,
e.g. an increase
for chemical plant: V. Venkatasubramanian
in temperature
in
a reactor would cause an increase in pressure. Thus the reasoning is based on these general principles, which are applicable to a variety of processes. It is a well known result that in dealing with complex systems one should view the system at different levels of abstraction, thus suitably decomposing the system 18. In our methodology, the overall process is decomposed, using a combination of structural and functional information about the process and the process units. Thus the diagnostic reasoning is based on structural knowledge about the process such as how the units are configured, and behavioural knowledge such as how the functions of the different units are related to one another and to equipment failures. Since such knowledge about the process is represented explicitly, not compiled and buried implicitly, the expert system can accommodate changes in the process more readily, as different processes are viewed as different configurations of the same units that are modelled in the library. This also facilitates rapid-prototyping as the diagnostic methodology is already embedded in a generic manner. Addition of new units, in the form of causal and fault models, not present in the library is also easier, due to the object-orientated organization of the knowledge base. Characteristicsof the object-orientated methodology One of the central ideas of this methodology is the use of a library of models of the process units. Thus the methodology, viewed from the level one perspective, has this object-orientated character associated with it. Fortunately, this inherent feature (or requirement) can be supported at level two by utilizing object-orientated knowledge representation and programming techniques. Object-orientated techniques advocate a philosophy where the programming is centred around objects and interactions between objects 19. Objects are the basic
Object relatwwhws -
Member
+=HtH+-
Instance-of
Figure
88
1
An
J. Loss
of class
object-orientated
process
unit
hierarchy
Prev. Process Ind., 1988,
Vol 1, April
building blocks in the framework. Objects are entities that serve as focal points for chunking knowledge together. Objects have properties and values, and can have procedures called methods attached to them. Examples of objects might be process units such as reactors, valves, sensors, controllers, etc. Objectorientated programming, derived from semantic networks and frames, is inheritance which permits the automatic transfer of knowledge (such as properties, methods, etc.) from one object to another through inheritance hierarchies. This is depicted in Figure 1. Inheritance facilitates compact and efficient organization of knowledge, and the creation of taxonomic structuring. Another important idea, absent in semantic networks and frames, is communication between objects in the form of passing messages between objects. Action in object orientated programming is centred around the passing of these messages. Thus the process units, their structural and behavioural properties, the causal and fault models, etc. are represented as objects and methods. Use of multiple representations in the knowledge base The knowledge engineering process can be facilitated by the use of appropriate organization and representation of the knowledge base. Along these lines, we have been experimenting with the notion of multiple representations of knowledge in the context of the diagnostic expert system FALCON developed at the University of Delaware’2*8. The central theme in this approach is that the mental models engineers’ use in reasoning about a chemical process is largely centred around the process flowsheet and the process units. One thus has a hierarchical structuring of the process knowledge. Also, people associate a variety of different types of knowledge with individual units, resulting in some generic default models of these process units with some specific characteristics incorporated additionally. Such knowledge would include structural connectivity information, functionality, typical faulty behaviours, their causal origins and their consequences, constraints, etc. Thus for a knowledge base to be transparent, its representation and organization should closely reflect the nature of the conceptual models the engineers have about the process. We refer to this representation as the conceptual representation of the process plant. Using this engineer’s interface, the process engineer developing or modifying the knowledge base would see a perspective of the knowledge base that is centred around the process flowsheet and the individual units. New knowledge would thus be introduced using this conceptual representation by selectively editing the various objects presented to the engineer as icons in a graphical interface. The conceptual representation would thus capture the hierarchical and process unitcentred nature of an engineer’s reasoning. However, the conceptual representation, which is an appropriate and a convenient formalism to be presented to a process engineer, may not be suitable for efficient processing of this knowledge due to the computational
Specialized
shell
for diagnostic
Process enqneer
I
c
Objects annpiler
systems
for chemical
plant:
V. Venkatasubramanian
is removed, and the branch of the diagnostic tree is terminated. The expert system then returns to continue the diagnosis of the fault currently at the top of the agenda. When the agenda has been emptied, the diagnostic session ends. The ordering of faults in the agenda is thus dynamic. If a fault on the list is found to be a local cause of the topmost abnormality on the agenda, then this fault moves from the middle to the top of the agenda. A record is kept of the agenda such that once faults are removed they never can appear again on the agenda. This prevents the expert system from reexamining a fault that it has previously diagnosed. This control algorithm is shown in Figure 3. Using
both
-first-principles
knowledge
and
compiled
knowledge Knowtedgebase Figure 2
Architecture
ot the object-orientated
version of FALCON
overhead associated with such a representation. From the performance and inference mechanisms point of view, one requires a different internal representation for efficient processing. The current FALCON representation is closer to this internal representation and quite removed from the conceptual representation an engineer might feel comfortable with. Thus one requires two different representational formalisms, one for the process engineer’s convenience and one other for efficient run-time performance. The translation from the conceptual representation to the internal representation would be performed by the module called the objects compiler. Figure 2 shows the organization of the FALCON based on the dual representational formalism. An agenda-based
control
The advantages of this diagnostic strategy discussed so far are flexibility and generality, ease of modification and updating. However, since the approach relies on general principles alone, it does not utilize any processspecific, compiled, knowledge that might be available. Hence the search tends be exhaustive, and examines more potential causes than is necessary. An expert familiar with the given process would have a lot of knowledge of compiled associations process symptoms and their causal origins. With such knowledge, an expert would outperform a novice who would not know much about such specific behavioural aspects of the process. Thus an expert would typically try out these process-specific heuristics first to diagnose the faults. When faced with new faults, however, use of such heuristics would not be helpful (as there would be
Inputhnowl facts about currentSystemState
Estabtishagenda canalstingof obsewedprocessatwrmalitii
of reasoning
In reasoning about process faults, the proposed methodology searches for causal origins or basic events responsible for the faults by identifying the local causes, through the use of structural aspects of the process along with behavioural information about the process units, and then propagating the local causes recursively until the basic events are discovered. This is facilitated by the use of an agenda-based control that derives a depth-first search. All initially observed process abnormalities are recorded on an agenda. Each confluence method is then called to attempt to generate inferences from the initial data from the process. The diagnosis of the abnormality at the top of the agenda is then pursued, by calling the appropriate fault model method, until all potential local causes are examined. If a local cause is found to be present, then this fault is placed at the top of the agenda and all of its potential local causes are examined. This process can be viewed as constructing a diagnostic tree (or network) of nodes and arcs. The diagnostic search continues until a basic event is found or the set of potential local causes has been exhausted. In either case, a summary is printed, the fault at the top of the agenda
abwrnwlity fromagenda
Figure 3
An agenda-based
J. Loss Prev.
Process
control algorithm
fnd.,
1988,
Vol
I, April
89
Specialized shell for diagnostic systems
for chemical plant: V. Venkatasubramanian
no solutions from past experience) and the expert would resort to some sort of an analysis based on the structure and behaviour of the process. The proposed methodology also facilitates the integration of processspecific heuristics with the generic principles, similar to the combined reasoning strategy of an expert. In the latter framework, the knowledge base consists of twotiers with the compiled knowledge in the top-tier and the first-principles knowledge in the bottom-tier. In the diagnostic process, top-tier heuristics are tried out first. If they fail, then the system resorts to the already described reasoning strategy based on structure and behaviour. Thus reasoning alternates between the two tiers of knowledge. This methodology has been implemented in the form of an expert system, called MODEX 2, that has performed successfully on prototypical process plants. The details of this framework and the MODEXZ system are described elsewhere”*16. An example using MODEX This example does not include the two-tier reasoning approach. The test case is a number of process abnormalities associated with the prototypical process plant shown in Figure 4. Even though this case study does not involve control loops, the methodology can handle such subsystems as well (as described previously 15). The initial agenda of process abnormalities reads: l high
stream 0 high reactor l high reactor
temperature level pressure
= -
- - -
Stream I
Tank 2
stream3
Valve I
voive2
stream 2
stream 4
s-7
Pressure mlief Mlve I
-_
_
RWctW
(vdve 4)
2
Yy VOIW 3
Slmam7
PumpI
CT=--.
Tank3
& Figure 4
90
J.
A prototypical
AND comectiin Node tsepackladif expert systemasks user ttw question. Numbers: crderin which node
Is conditiontrue ? X - bmnch ferminoted
The system is also initially informed that the pump is functioning properly, and that feed tank1 does not have a leak. The diagnostic tree that results from the analysis is shown in Figure 3. A directed arc connecting two nodes in the tree implies that the event represented by the incident node is caused by the event represented by the terminal node of the arc. The numbers associated with
Tank I
Key :
process plant for case study
Loss Prev. Process Ind., 1988,
Vol 1, April
i-H++-+ Figure 5
Yes X
Arrow withbars Impliesinfcnnatian onnode is usedelsewhasinlhetree Diagnostic
tree for the case study
each node give the order in which MODEX generated the node. The expert system determines that the high reactor level can be attributed to valve 2 which is excessively open, and both the high temperature in stream 6 and the high reactor pressure can be traced to the high temperature in feed tank 2. This example demonstrates the ability of the stream first, to divide the initial set of observed faults into subsets of related faults and second, to locate multiple causal origins of a fault should there be multiple origins. The system is able to use information gathered from the diagnosis of one fault in the diagnosis of another, unrelated, fault. For instance the knowledge that valve 2 is open (determined in the search for the cause of the high reactor temperature) allows the system to determine the cause of the high flow rate in stream 4. Note that in using the depth first control strategy MODEX systematically proceeds down a branch of the tree until the branch is terminated. Due to space constraints in Figure 5, the organization of the nodes are not in the traditional depth-first manner, though the search is depth-first in nature.
Conclusions In this paper,
we have examined
the different
factors
Specialized
shell
far diagnostic
contributing to the knowledge engineering bottleneck currently faced in the development of diagnostic expert systems for chemical plant. Difficulties lie in rapidprototyping, modifying and updating, and verifying and tuning the expert systems. An analysis of the knowledge engineering activity at different, and somewhat decoupled, levels of abstraction helps to clarify and separate the various issues contributing to the bottleneck. The diagnostic problem-solving methodology emerges as the central issue. This is a level one issue, in the terminology used in this paper, which has a direct effect on the bottleneck. We also identify that level two issues, such as the formalization aspects like knowledge representation and inference techniques, as other important factors that can create the bottleneck even if the correct methodology had been chosen. Problems such as real-time performance of the system are closely related to the specific choice of software and hardware, and they tend to be temporary as they will be adequately resolved with the emergence of faster and cheaper hardware as the current trend indicates. The really important and challenging aspects of the bottleneck that we should be concerned with are factors related to methodology (at level one) and formalization of the methodology (at level two). It is also suggested that the current difficulties in knowledge engineering can be largely solved with the aid of a knowledge engineering environment or shell, that is specifically designed for developing diagnostic expert systems. The primary difference between such a shell and the environments such as KEE or ART will be the inclusion of the diagnostic methodology and the related domain knowledge. T’his seems to be the next natural evolutionary stage of artificial intelligence based tools. Since the methodological and formaliz~tion~ aspects play such a central role, we present a device-centred diagnostic methodology that facilitates rapidprototyping, ease of modification and updating of the expert system. Such a mefhodology could for instance serve as the central generic core of a diagnostic shell or environment. The diagnostic methodology decomposes the process plant into a hierarchy of subsystems by using a combination of structural and functional decomposition. The reasoning is based on first-principles knowledge such as constraints, confluences, and a library of causal and fault models of the process units, all of which are process-general and applicable to a variety of processes. An agenda-driven control algorithm is used for guiding the inference. The unit-orientated character of this methodology is formalized with the aid of concepts and techniques from object-orientated knowledge representation. We have also outlined a two-tier knowledge base architecture for integrating the process-general aspects of this framework with process-specific, compiled,
systems
for chemical
plant:
V. Venkatasubramanian
knowledge. The performance of the expert system prototype MODEX, implementing this methodology, has been found to be satisfactory on prototypical process plant.
Acknowledgements The author thanks Professor P. Dhurjati and Professor D. Lamb, members of the FALCON project team at the University of Delaware. The author is also grateful to A. Varma and J. Kantor for the invitation, hospitality, and for generously offering the department’s computational facilities. The research and development efforts of S. Rich of Columbia University working on the MODEX project are also appreciated.
References I
Himmelblau, L?. M., in ‘Fault Detection and Diagnosis in Chemical and Petrochemical Processes’, Elsevier Scientific Publishing Co., Amsterdam 1978 Lapp, S. A., and Powers, G. MEE Trans. Rehb. 1977. April Shiotaki, J., Matsuyama, H., O’Shima, E., and Iri, M. Com-
puters& Chemical
6 7
8
9 10 11 12 13 14 I5 16 17
Engineering,
1985, 9, 285-293
Rich, E., in ‘Artificial Inteiligence’, McGraw-Hill Pub. Co., NY, USA, 1983 Hayes-Roth, F., Lenat, D. B., and Waterman, D. A., (Eds.), in ‘Btdidirtg Expert Sysfems’, Addison-Wesley Publishing Co., Reading, MA, USA, 1983 Water&an, D,, in ‘A Guide to Expert Systems’, Addison-Wesley Pub. Co., Reading, MA, USA, 1985 Banares-Akantar& R., S&am, D., Venkatasubramanian, V., Westerberg, A., and Ryehener, M. Chem. Eng. Prog. 1985, 9, 25-30 Dhurjati, P., Lamb, D. and Chester, D., ‘Experience in the Development of an Expert System For Fault Diagnosis in a Commercial Scale Chemical Process’, Proc. Int. Conf. on the Foundations of Computer-Aided Process Operations, Park City, Utah, July 1987 Kramer, M., and Palowitch, B., Expert System and KnowiedgeBased Approaches to Process Malfunction Diagnosis, presented at the AIChE Annuai Meeting, Chicago, November, 1985 Niida, R, ‘Some Expert System Experiments in Processing Engineering, in IChemE. Symp. Ser. 1985, p. 529-538 Rich, s. H., and Venkatasubramanian, V. Computers & Chemicaf E&twering 1987, II f2), Ill- 122 Rowan; D. A.: ‘Chemical Plant Fault Diagnosis Using Expert Systems Technology: A Case Study’, in Proc. IFAC Conference, Kyato, Japan, 1986 Shirley, R. S., ‘Status Report 3 With Lessons: An Expert System to Aid Process Control’, in Proceedings of ISA/87, 1987 Venkatasubramanian, V., and Dhurjati, P., Proc. Int. Conf. on Foundations of Computer-Aided Process Operations, Park City, Utah, USA, 1987 Venkatasubramanian, V., and Rich. S. H.. Computers & Chemical fhgitteerittg, 1988, submitted for publication Venkatasubramanian, V., and Rich, S. H., Proc. 2nd Int. Conf. On Artificial Intelligence Applications in Engineering, Boston, MA, USA, 1987 de Kleer, J. and Brown, J. S., Arrificiai Inrelligence 1984, 24, 7--1% Simon, H. A., ‘Sciences of the Artificial’, MIT Press, Cambridge, MA. USA, I969 Stefik, M., and Bobrow, D. 0. ‘Object-Oriented Programming: Themes and Variations’, AI Maguzine, Winter, 1986, pp. 40-62 _”
18 19
J. Loss Prev.
Process
in&
1988,
Vol
I, April
91