An object-oriented two-tier architecture for integrating compiled and deep-level knowledge for process diagnosis

compur. Printed

~,hem. Engng. Vol. 12, No. 9/10, pp. in Great Britain. All rights reserved

903-921.

1988 Copyright

009% 1354/88 $3.00 + 0.00 0 1988 Pergamon Press plc

AN OBJECT-ORIENTED TWO-TIER ARCHITECTURE FOR INTEGRATING COMPILED AND DEEP-LEVEL KNOWLEDGE FOR PROCESS DIAGNOSIS V.

and S. H.

VENKATASUBRAMANIAN~

RICH

Intelligent Systems in Process Engineering Laboratory, Department of Chemical Engineering, Columbia University, New York, NY 10027, U.S.A. Abstract-The increasing complexity of chemical plants have caused the chemical industry to look towards automated and structured approaches for identifying and diagnosing process abnormalities during the normal course of a plant’s daily operation. One such approach is to make use of a knowledge-based expert system which can perform diagnostic analysis. Many of the recent attempts have focused on using compiled process knowledge, relating symptoms to causes represented as production rules in the knowledge base. Though this leads to real-time diagnostic efficiency, such expert systems lack flexibility to process changes and are incapable of diagnosing novel symptom combinations. The rule-based approaches also lead to knowledge bases that are difficult to develop and maintain as they lack structures that reflect higher-level organization of process knowledge. In this paper, we present a diagnostic methodology that provides the means to solve these problems. We advocate a diagnostic methodology that integrates compiled knowledge with deep-level knowledge, thus achieving diagnostic efficiency without sacrificing flexibility and reliability under novel circumstances. To formalize such an integration, we also propose an object-oriented two-tier knowledge base that houses process-specific compiled knowledge in the top-tier and process-general deep-level knowledge in the bottom-tier. The diagnostic reasoning effectively alternates between the two-tiers of knowledge for efficient and complete diagnosis. An important aspect of diagnostic reasoning is to be able to generate potential causes of the observed symptoms or faults as candidate malfunction hypotheses. We describe an agenda-based inference control algorithm that generates malfunction hypotheses by deriving them from structural and functional information of the process. We discuss the salient features of an expert system, called MODEXZ, that has been implemented using these ideas. 1. INTRODUCTION The timely detection and diagnosis of process abnormalities in a chemical plant is a major source of concern for plant management. The increasing complexity of modern chemical plants and the urgent need to diagnose quickly make it increasingly difficult to rely on human operators for diagnosis. The reliability of an operator is likely to suffer when forced to make quick judgement calls or when forced to depend upon operating and safety manuals which are written neither in a clear nor concise fashion. With safety instruction often given on a learning-by-rote basis rather than a reasoning-based approach, diagnosis of unexpected patterns of events, for which past experience cannot be used as a guide, proves difficult. The need, therefore, arises for developing a systematic approach for detecting and diagnosing faults. Ideally, such an approach should be automated to facilitate its application in a variety of situations. Though elegant, automated fault tree synthesis techniques (Lapp, 1977) and signed digraph methods (b-i et al., 1979) are not adequate by themselves (Rich and Venkatasubramanian, 1987). Knowledge-based expert systems have emerged as the most appropriate approach for automated process diagnosis. However, the conventional expert systems based on compiled knowledge represented as production rules have some tAuthor to whom all correspondence should be addressed.

drawbacks associated with them, even though they possess real-time diagnostic efficiency. They lack process generality and they tend to fail under novel (Rich and Venkatasubramanian, circumstances 1987). The rule-based knowledge bases are also difficult to understand as they lack higher-level representation and organization of process knowledge. Hence they involve substantial effort in development and maintenance (Venkatasubramanian and Dhurjati, 1987). To circumvent some of these problems, we proposed in a previous paper (Rich and Venkatasubramanian, 1987) a new deep-level knowledgebased diagnostic methodology, implemented in the form of an expert system called MODEX (Model Oriented Diagnostic Expert) that uses model-based reasoning. As model-based systems typically lack diagnostic efficiency, we propose an improved methodology that integrates compiled knowledge with deep-level knowledge for diagnostic reasoning. Besides being efficient, this is also a more accurate representation of the mental models of process operators and engineers who rely on both these knowledges in their reasoning. To formalize this integration, we also describe a systematic framework in the form of an object-oriented two-tier architecture for the knowledge base. The top-tier houses processspecific compiled knowledge while the bottom-tier contains the process-general deep-level knowledge such as constraints, confluences, causal and fault 903

904

V.

VENKATASUBRAMANIAN

models associated with the different process units. Causal models are qualitative representations of mechanisms which control the behavior of the system. Fault models associate plant abnormalities with sets of events, any of which may potentially be the local causal source of the abnormality. The two-tier knowledge base improves the efficiency of the expert system since the heuristics aid in expediting the search for the causal source(s) of the process abnormalities. The diagnostic reasoning alternates between the two-tiers of knowledge. An important aspect of the diagnostic reasoning process is being able to generate potential causes of the observed process symptoms as candidate malfunction hypotheses. In this paper, we present a process-general inference procedure that derives the malfunction hypotheses from the structure and behavior of the process plant. Thus this paper introduces several novel themes in the area of knowledge-based process diagnosis: the use of both compiled and deep-level knowledge, an object-oriented two-tier architecture for formalizing this methodology, and a general procedure for generating malfunction hypotheses based on structure and function of the process units. We also present an analysis of the knowledge engineering activity at different levels of abstraction to clarify methodological issues from modeling an implementational aspects. A discussion on the structuring of process knowledge along structural and functional decompositions is also presented. Two case studies involving a process of moderate level of complexity are also described using the MODEXZ system.

2.

KNOWLEDGE

ENGINEERING EXPERT SYSTEMS

OF

DlAGNOSTlC

Knowledge engineering is the process of building an expert system and it involves the development and implementation of a problem-solving methodology. In this section, we summarize an analysis of the knowledge engineering activity in the context of process fault diagnosis. The details of this analysis and its implications are discussed in Venkatasubramanian (1988). By viewing the knowledge engineering activity at different levels of abstraction, one is able to clarify methodological issues from formalization and implementation related ones. This analysis would also facilitate the understanding of the central ideas presented in this paper concerning a two-tier diagnostic methodology and its formalization in an object-oriented representation. The following analysis is applicable to the knowledge engineering activity in general, even though it has been presented from the perspective of diagnostic expert systems. 2.1.

Three

Even involves

Ieuels of abstraction

though several

the knowledge engineering process related activities, it can be viewed at

and S. H. RICH three somewhat namely:

decoupled

levels

of

abstraction,

l Development of the problem-solving methodology. . Formalization or modeling of the methodology. l Implementation of the methodology.

At the first level, one is concerned with the methodological aspects of how to diagnose faults related controllers, reactors and other units to sensors, present in the given process. The diagnostic methodology could be based on compiled knowledge of relating symptoms to causes, or on first-principles based reasoning involving the structure and function of the process explicitly, or on some combination of these. The problem-solving methodology thus developed may be entirely specific to the given process or one may integrate the process-specific and the process-general aspects explicitly in a flexible framework. The latter approach, clearly, would be the desirable one as it would facilitate rapid-prototyping 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 procedure, etc. The problem-solving methodology developed at the first level could conceivably be modeled through different representational formalisms (such as procedures, rules, frames, or objects, or some combination of these) and by adopting different reasoning techniques (such as forwardchaining, backward-chaining, 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 representational and reasoning formalisms. For example, the use of objects for knowledge representation might be preferred over the use of rules due to the character of a diagnostic methodology as discussed in Section 4.1.1. At the third level, one is concerned about the software issues such as AI languages or shells as well as the support hardware. Once again, even though there is some amount of freedom of choice at this level, level two requirements could limit the options. Although one can decouple the knowledge engineering process along these various levels there can be strong interactions between these levels. These levels of abstraction are summarized in Fig. 1. 2.1. I. Methodological us implimentational issues. Decomposing the overall knowledge engineering process into the several separate, and somewhat decoupled, levels of activities has the benefit of being able to analyze 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,

Integrating

METHODOLOGICAL

compiled

and deep-level

Diagnostic Compiled

knowledge

Fmblem-Solving h5ahodology. vs First-RinGpIcaKnowledge(or both)

Qualitative YSQuamitiveApproach

FORMALIZATIONAL

Objects. h&urcs. Inference Formalism Backward-Chaining,

IMPLEMENTATIONAL

Fig. 1.

The

Software Hardware

three levels of abstraction

FORMALIZING

PROCESS

Shell. etc.) Worksrarions.

Lisp

Machintr.

etc.)

in knowledge engineering in the context of process of fault diagnosis.

helps to minimize confusion by separating purely methodological problem-solving issues from, say, formalization and implementation related aspects. It is also helpful in identifying how the various difficulties in knowledge engineering 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 can not be resolved by solutions at another level (e.g. by changing the representational or the inferential scheme, or the AI language, etc.).

3.

(Language. (PC. 3%bit

or P H&id) (ForwordChaining. Weak Methods. etc.)

KNOWLEDGE

Problem-solving tasks, such as diagnosis, require substantial amounts of domain knowledge to characterize the various states through which a system can pass and to guide the search towards a solution. The types of process knowledge required include objects, relationships, concepts, taxonomies, and behavioral knowledge. In the chemical engineering domain, a reactor would be an example of an object and isothermal operation would be an example of a concept. Classification schemes or taxonomies are useful when some of the knowledge shows some hierarchical structures, e.g. subdividing the general class of objects “heat exchangers” into subclasses In process based on the flow configuration. engineering applications one often encounters: (a) object relationships based on spatial arrangement e.g. the inlet of stream 5 is connected to reactor 1 and stream 5’s outlet is connected to valve 3; or (b) activity relationships based on temporal sequencing e.g. heat feed stream 2 prior to reacting it in reactor 1 with material in stream 1. Behavioral knowledge

might

take

the

form

of

constraints

which

govern

behavior, such as mass and energy balances, or might define a causal relationship between two variables e.g. the boiling point of a refrigerant increases with increasing pressure. Knowledge can also be classified as deep-level or first-principles knowledge and compiled knowledge. Deep-level process knowledge often stands for knowledge that is generic and process-independent involving concepts, constraints and behaviors of process units that are applicable to a variety of situations. On the other hand, compiled knowledge is essentially a compilation of past experiences typically restricted to a given process. system

3. I. Deep -level knowledge Deep-level knowledge used in the expert system MODEX2 falls into several categories. A more detailed discussion of this has been presented elsewhere (Rich and Venkatasubramanian, 1987) and the following summarizes the essential details. The first category represents constraints derived from material and energy balances, restrictions based on the laws of conservation of mass and energy. For example, if a valve is functioning properly and the size of its opening is properly set, then the outlet flowrate from the valve equals the inlet flowrate. A constraint associated with a pump, for example, would require that the pressure from the outlet stream of a properly functioning pump be greater than the pressure of the inlet stream to the pump. A second category corresponds to confluence equu tions (qualitative differential equations) (de Kleer and Brown, 1984) which represent the influence of one state variable on another state variable. For instance, if a valve is functioning properly then:

amowout, a (inletstream= +,

P=Um) ak’,, - aF,,, = 0.

906

V. VENKATASUBRAMANIAN

Material and energy balances may also be viewed as confluence relations. If Fin and F,,, represent inlet and outlet flowrates respectively, then: aF,, -

aF,,,

= 0,

represents a material balance over a properly working valve (Rich and Venkatasubramanian, 1987). Confluence equations are useful in making inferences and propagating disturbances. A third set corresponds to a library of fault models of different process units which attempt to explain the local cause of a low or high state variable value. For example, in the fault model of a tank, the knowledge that a low tank level could be due to low inlet flowrates, or high outlet flowrates, or a leak, or some combination of these would be represented. A fourth set deals with causal models of process units that would generate local effects given some cause. An example might be, that a clogged valve would cause the outlet flowrate to be low (compared to its normal expected flowrate). 3.2. Compiled us deep-level expert systems

knowledge

in diagnostic

A model-based reasoning strategy is better than conventional approaches that typically carry out the diagnosis using compiled knowledge alone, as they have the disadvantage of being process-specific and inflexible. In addition, the development and maintenance of such knowledge bases involve substantial amount of time and effort (Rich and Venkatasubramanian, 1987; Venkatasubramanian and Dhurjati, 1987; Venkatasubramanian, 1988). This type of reasoning could also lead to erroneous conclusions or total failures, when faced with novel faults which were not anticipated and for which there is no compiled knowledge based on past experience to rely upon. However, relying on deep-level knowledge alone makes the diagnosis time consuming, limiting the expert system from real-time applications. Problemsolving using compiled knowledge as an important advantage here over the deep-level approach. The latter leads to large search spaces examining a number of causes which are probably unlikely to happen. Thus the search could become slow and inefficient. This is where heuristic or compiled knowledge comes in handy by proposing likely causes which have been seen in the past. For example, if historically, the temperature of the contents of a feed tank has been notoriously difficult to control, then it is likely that an abnormal temperature in a stream or tank downstream of this feed tank can be attributed to the temperature control problem. Another simple heuristic might be based on observations that certain valves, pipes or pumps tend to clog easily. This in turn may lead to low flowrates or abnormal tank levels. By using such heuristics based on past experience large searches can be avoided and the efficiency can be improved substantially for large process

and S.

H.

RICH

plants. Expert operators skillfully exploit this technique by combining their experiential knowledge with model-based reasoning using deep-level knowledge of the process plant (Rowan, 1986). It is clear that for an efficient, reliable, flexible system one needs to couple the process-general deep-level knowledge with process-specific compiled knowledge. In this paper we discuss the salient features of the expert system MODEXZ that uses such a two-tier approach for process fault diagnosis. 3.3. Structural us functional

decomposition

of knowl-

edge

A chemical process plant may be viewed at various levels of aggregation. At the highest level, it can be thought of as a single entity whose function is to produce a product (or set of products) by transforming a set of input feed streams using chemical or physical means. At the next lower level of aggregation, the process can be decomposed into subsystems based on structural or functional considerations. A structural decomposition might divide the plant into subsystems on the basis of spatial relationships or based on readily identifiable subsystem input-output streams, i.e. subsystems which can be decoupled. In a functional decomposition, the plant might be viewed as a sequence of process operations or as a set of subsystems each with an identifiable task. For example, associated with a chemical reactor, one might have a mixing system, cooling system, pressure control system, etc. Generally, in a structural decomposition, an equipment unit will be assigned to a single subsystem. This need not be the case for functional decompositions. At the lowest level of aggregation, the plant is seen as being comprised of a set of equipment units. At this level, a structural decomposition would consider interconnections between the units while a functional decomposition would view the units in terms of their functional tasks, e.g. a heat exchanger serves both as a site for heat transfer and as a conduit for fluid transport. Ultimately, diagnostic systems applied to the same problem should reach similar conclusions regardless of whether a structural or functional decomposition is used. However, depending on the form of the decomposition, the diagnosis will proceed along different lines because the reasoning strategies employed by the systems will be different. Because a unit or subsystem’s function cannot be readily divorced from its structure, sharp distinctions between structural and functional decompositions often cannot be made. For example, in the recent literature on fault diagnosis, control loops have been identified using both structural (Shafaghi et al., 1984) and functional (Finch and Kramer, 1986) decomposition strategies. MODEXZ makes use of a combination of both strategies. Spatial relationships and interconnections between equipment units guide the diagnostic search through the plant for the causal origin(s) or process abnormalities while functional

Integrating compiled and deep-level knowledge equipment descriptions are embedded in the fault models associated with each piece of equipment. Consider, for instance, a process stream with a low flowrate. MODEXZ attempts to search for the source of this abnormal flowrate by first working in the direction opposite of material flow and then in the direction of material flow. If the stream is found to be the outlet stream from the tube side of a shell-andtube heat exchanger (structural decomposition), then those portions of the stream fault model which pertain to a stream whose inlet is connected to the tubeside of a heat exhanger are invoked. In diagnosing the low flowrate, one would consider the flowrate and pressure of the tubeside inlet stream and the state of the heat exchanger tubes, i.e. whether they are blocked or leaking. Note that the diagnosis is making use only of the heat exchanger’s function as a conduit for material transport. If this outlet stream were found to have an abnormal temperature as well, then MODEX2 would consider flowrates and temperatures of both inlet streams to the heat exchanger, in addition to questioning whether the tubes are fouled or the shell side is frosted. Here, MODEX2 invokes diagnostic methods associated with the heat transfer function of a heat exchanger. 3.3.1. Control loops. To this point in the discussion, we have addressed a structural decomposition of a chemial plant in terms of its units. We now enlarge the scope of the term structural decomposition to include subsystems which consist of a set of units. In particular, our interest is focused on control loops. Control loops function to maintain a control variable at a desired setpoint value by manipulating a second process variable. Control loops, viewed as a subsystem of units, are comprised of: (1) a sensor which measures the variable controlled by the loop; (2) a controller which sends a signal to an equipment unit, e.g. a control valve, that can alter the value of the manipulated variable; (3) the process equipment to which the control system is attached to; and (4) the lines through which information is passed in the control loop and any streams or equipment through which the manipulated variable passes. The control loop fails when the control variable deviates outside of its normal operating range. Con-

Fig. 2. Lapp and Powers operator

907

trol loop failures may be the result of: l

l

Internal loop disturbances which can either: (a) cause the control loop to malfunction (e.g. setpoint set to high or sensor biased); or (b) cause a change in the gain of the loop [e.g. reversed control valve action (causes reversal in gain) or valve stuck (causes gain to change to zero). External loop disturbances which either: (a) are so large that the control loop cannot cancel the disturbance completely, i.e. the control loop action is saturated; or (b) cause a disturbance in the manipulated variable.

Diagnosis of a process abnormality associated with a control variable requires more than just a search of local causes in neighboring equipment units. Appropriate causal and fault models of control loops have been implemented in MODEX2 in a manner akin to the analysis in Henley and Kumamoto (1985), Lapp (1977) and Shafaghi et al. (1984). An example of one such generalized operator for a negative feedback loop is shown in Fig. 2. Within the object-oriented framework, these generalized operators can be readily modeled in the diagnostic expert system. An object called control loop in the knowledge base would represent the general class of control loops. This object would have attribute slots such as name, type, control variable, manipulated variable, controled device etc. Other parameters and equations associated with the controller can also be represented. If a process abnormality is associated with the control variable of a negative feedback loop, then initially the system attempts to determine if there are any internal loop disturbances which cause a controlloop malfunction or cause the gain of the loop to go to zero such that it can no longer respond to a disturbance. The exhaustive list of potential internal loop disturbances is likely to be quite lengthy. Such a list could be pruned by making use of heuristics which determine those internal loop disturbances which have the greatest likelihood of occurrence. If no internal disturbance is found, then the system assumes that the control loop is functioning properly and begins to investigate whether there is a dis-

for a

negative feedback loop.

V.

908

VENKATASLJBRAMANIAN

turbance, external of the control loop, which is causing the control variable to deviate from its normal operating range. If it is found that there is a large external disturbance which the control loop cannot cancel, then the system makes note of this and proceeds in its normal fashion to locate the causal source(s) of this external disturbance. If the external disturbance is not sufficient to saturate the control action, then the system prompts the user to determine if the control loop has reversed gain and gone positive. If this is not the case, the final possibility is that the external disturbance has an immediate effect on the manipulated variable, e.g. (referring to the level control example above) a sudden increase in the pressure in stream 3 (in Fig. 9) can result in a sudden increase in the flowrate in stream 4, thereby causing a high level in reactor 1. 4. INTEGRATING COMPILED AND DEEP-LEVEL KNOWLEDGeA TWO-TIER OBJECT-ORIENTED APPROACH

4. I. Object -oriented

modeling

of process

knowledge

are the basic building blocks in a object oriented framework (Stefik and Bobrow, 1986). In an object-oriented framework, knowledge is compartmentalized into groups of facts, heuristics and procedures being associated with specific objects or general classes of objects. Action in object-oriented programming comes from sending messages between objects. An object responds to messages by executing procedures, called methods, that are attached to the object. For example (send-message stream6diagnosetemperature high) sends a message to the target object Objects

OBJIXX

RELATIONSHIF’S

-+j++

3.

RICH

named stream6 telling it to find a way to diagnose the abnormally high temperature of the material which is flowing through it. The object stream6 then calls upon its diagnose-temperature method to locate the cause(s) of the high temperature. Process knowledge can be formalized by initially establishing a hierarchy of object classes. In the object-oriented framework, each class of equipment units is represented as an object with the various attribute slots and methods that characterize the class of equipment. There are two basic relationships between objects: (1) member-of representing class membership; and (2) instance-of representing specialization. A partial hierarchy of units in the current system is shown in Fig. 3. Two important notions in object-oriented programming are inheritance and incremental specialization. The attribute slots and methods of an object associated with a specific equipment unit are inherited by some other unit that is either an instance of or a member of the class. Incremental specialization allows objects to get more specialized by inheriting various qualities from different parents, thus becoming a composite object Methods attached to objects correspond to constraints, confluences and casual and fault models. Confluence methods group together all behavioral knowledge associated with confluences pertaining to a particular class of equipment units or a specific unit. When a message is sent to an object to execute its confluence method, all possibilities contained within the method are scanned to determine if any inferences can be drawn. For example, the method ualue:conj?uence attached to the (general class of) $0~ valves object contains behavioral knowledge based on mass

)

Fig.

and S. l-l.

MEMBER OFCLASS INSTANCE-OF

Process unit hierarchy.

909

Integrating compiled and deep-level knowledge USER

INTERFACE INFERENCE

ENGINE

II EXPLANATION FACILITY

HEURISTICS GRAPHICS

I

INTERFACE

CAUSAL & FAULT MODELS

I

I

I KNOWLEDGE

SASE

Fig. 4. The object-oriented architecture of MODEX2 balance, inlet pressure-outlet flow, and temperature confluences over properly functioning valves. Methods corresponding to fault models list sets of rules which examine all potential local causes of the fault. The sequence of rules in the method, i.e. the order in which potential local causes of a fault are examined, is determined by the likelihood of their occurrence. There is one such method for each state unit variable in each equipment class, e.g. stream:diagnose-temperature, tank:diagnose-level, etc. Object-oriented programming also facilitates MODEX2 to have a graphics interface. Each object which is an instance of a general class of equipment units has an icon associated with it in a graphical display of the plant configuration. The icons are drawn using methods attached to general classes of objects, e.g. stream:draw, pump:draw. When the method is inherited by an instance of the class, data specific to the object, is supplied so that the icon is drawn at its proper location on the screen, in the proper size, and with the correct spatial orientation. The overall architecture of MODEXZ is presented in Fig. 4. 4.1.1. OPS5 US object-oriented programming. In this section a comparison is made between the performance of the diagnostic methodology as implemented in an object-oriented programming framework and an OPSS environment. Control proved to be a problem when MODEX was implemented in a rule-based environment such as OPSS (Brownston et al., 1985; Rich and Venkata-

subramanian, 1987) because any rule in production memory could fire if the data-base contained data memory elements (which represent the current state of the system) that matched the rule’s left-handside conditions. If the set of current data memory elements could match more than one rule, a control mechanism (internal to OPS5) based on the time that the data element was last updated (recency criterion) and the number of left-hand-side conditions in the rule (specificity criterion) determined the order in which the rules fired. Since priority is given to those data memory elements which were modified most recently, the reasoning strategy is said to be opportunisitic. One of the potential problems with such a strategy is that the Sow of knowledge is akin to a controlled pandamonium. The rules may not fire in what is perceived to be a systematic fashion which could confuse the user about the expert system’s logic (Rich and Venkatasubramanian, reasoning 1987). This becomes a concern when diagnosis is performed for multiple, unrelated faults. It would also prove to be a cumbersome task to implement the two-tier methodology described in this paper in a production rule system such as OPSS. In the object-oriented approach, this control problem was circumvented using an inference strategy utilizing the message-passing concept as described in Section 4.1. Besides better control of inference, the object-oriented approach also facilitates easier develand maintenance opment of knowledge bases through the use of inheritance and speciatization. Relating to the material described in Section 1,

V. VENKATASIJBRAMANIAN

910

object-oriented representation becomes an important issue at the second level of abstraction. As discussed in Section 1, the same problem-solving methodology can be formalized using an object-oriented approach or a rule-based approach. The former leads to a much better model over the latter due to better flexibility and control in inference and process knowledge representation. 4.2. The two-tier

inregration:

an example

Diagnostic reasoning based on models using structure and behavior information about a process leads to the exploration of local causes, that is, examining for faults within a neighboring piece of equipment. This procedure certainly has its merits since the knowledge base need not be process-specific. However, a diagnosis may be slow if the system is restricted to passing through each equipment unit on the path between the unit with the physical malfunction (basic level event) and the unit with the top-level abnormality. The addition of compiled knowledge or heuristic rules based on experiential knowledge can give the expert system the freedom to explore for basic causes in equipment units which are not spatially adjacent to the unit being diagnosed, thereby improving efficiency by expediting the search for a goal state in the state space. Heuristic rules are often process-specific since they are based on compiled observations of the process under study. For example, if historically, the temperature of the contents of a feed tank has been notoriously difficult to control, then it is likely that an abnormal temperaure in a stream or tank downstream of this feed tank can be attributed to the temperature control problem. Another simple heuristic might be based on observations that certain pipes, valves, or pumps tend to clog easily. This in turn may lead to low flowrates or abnormal tank levels. The following simple example illustrates the salient features of the two-tier approach of coupling compiled knowledge with the deep-level knowledge. Consider Fig. 9. Let us say from experience the process operator has learnt that whenever the reactor1 level is low it is because rank] had failed to operate properly. Even though, a clogged valve1 or value2 could have caused the same fault, experience has taught him otherwise. This is what we call as heuristic of experimental knowledge, a compiled association of one set of events with another without any explicit reference to the causal linkage. Whenever the operator finds the fault low tank level in reactorI he is going to suspect tank1 first. In the MODEX2 system, the current objectoriented device fault models have a two-tier knowledge base. The first tier in the knowledge base houses the process-specific, compiled, knowledge such as: IF THEN

This

reactor1 level is low check tank1 level first

knowledge

is process-specific

as it explicitly

and S. H. RICH

assumes the existence of the dependence between reactor1 and tank1 which may not be true in other plant configurations, even using the same units. It is also necessarily process-specific as these specific facts are the ones that help reduce the search space and improve efficiency. The second tier houses deep-level knowledge such as: IF THEN

(a) (b) (c)

the reactor1 level is low the possible causes are: the inlet flowrate is low the outlet flowrate is high there is a tank leak

or or

This knowledge does not explicitly assume the existence of other process units connected to the tank and hence it is a process-general piece of knowledge. If the heuristic rules are placed at the beginning of fault model methods, then thr knowledge base has two levels of knowledge to work with. In this manner, the expert system can check if any heuristic rules apply to arrive at a quick diagnoses. If the rules do not apply then the system falls back upon its deeplevel knowledge and diagnoses based on first principles. Since each method has its own set of heuristic rules, the system reverts back and forth between the two levels during the course of a diagnostic session. The necessary modifications to the inference control mechanism (Figs 5-7) are illustrated in Fig. 8. Note that even if the heuristics do apply to the current situation, the user has the option of dropping down to the deep-level knowledge to either: (1) verify all the intermediate causal relations omitted in the heuristic; or (2) examine other potential causes of the process abnormality to which the heuristic applied. The sets of problematic equipment units can be expanded as diagnoses are reviewed in order to search for recurring problem spots in the plant. If the expert system could keep a record of its own diagnoses, then conceivably it should be able to automatically perform this updating task. The system would then lx acquiring new knowledge by responding to a given situation after repeated experiences in that situation. Therefore, the expert system is learning by observation. Devising mechanisms to allow MODEX2 to learn is being explored. 5. INFERENCE

AND

CONTROL

STRATEGIES

The reasoning strategy in our approach is quite different from that of conventional diagnostic expert systems. In the conventional approach one searches or reasons through a knowledge base that has all the faults and their causal origins encoded already in the form of compiled knowledge. Thus inferences in conventional expert systems rely entirely on compiled knowledge alone. In the proposed approach, MODEXZ will first invoke its compiled knowledge base to determine solutions by the experience-based, short-cut, method. If this fails, the reasoning will automatically drop down to the second tier, deep-

Integrating

level, based

knowledge reasoning

base will

where determine

compiled

first-principles the

and

deep-level

model-

cause(s)

of

ATPOINT

As the original fault is related to some local cause, the compiled knowledge base can be invoked again to find a short-cut solution for the remaining problem as in the above mentioned example. Thus the reasoning would alternate between compiled and deep-level knowledge tiers for achieving efficiency faults.

REMOVE

0

PRCCESS

BEENDLWN~ED

I

PRBvIoUsLY

OPERATOR

Ra-EN-mR

Fig. 6. Agenda-based

ABNORMALKY

inference

PLAC6

LOCATE

O2

LOCAL

DIRECTED

MOVE

Fig. 5. Agenda-based

CAUSE

OF ABNORMALITY

BY APPROPRJATX

LGCAL

METHOD

CAUSE

inference control

algorithm

UXAL

control

CAUSE

AT TOP OF AGENDA

ON AGENDA

FROM AGENDA

AS

7

coNTROLLOOP

DlAGNlXBTlXMoTT

ABNORMALI’IY

911

ENTER FJGURB 3

the

and reliability. The object-oriented programming framework implemented in FranzLisp has no internal problemsolving control strategies. Only the mechanisms for inheritance and message-passing are built-in as part of the language (Stefik and Bobrow, 1986). Therefore, the control strategy is designed solely by the architect of the system. A depth-first control strategy is chosen in which all initially observed process abnormalities are placed on a master agenda list. Each confluence method is called to attempt to generate inferences from the initial data inputted by the user. The diagnosis of the abnormality at the top

knowledge

(part

1).

algorithm

(part 2).

912

and S. H.

V. VENKATASUBRAMANIAN

LOCATELCCALDtS-tURBANCB(E LOOP) WHICH CAUSES

RICH

xTEBNAL

CONIROL

VARtABLB

OF CONTROL ABNOBMALtTY

+ ISTHERKAN

DISTUXBANCE

WHtCHLQCALLY-

coNTINuEwITt-t DIAGNOSIS

BXTEBNAL

MANIPULATED

OF

(UKW)

VARtABLB

1

EXTEBNALDtSTURBANCE

PRINT

PABl7AL

SOLU-t’tON

Fig. 7. Agenda-based

inference control

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 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 is removed, and the branch of the diagnostic tree is terminated. The system then returns to continue the diagnosis of the fault currently at the top of the agenda. When the agenda has been emptied (all branches terminated) the diagnostic session ends. The ordering of faults in the agenda is 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 list. This prevents the expert system from reexamining a fault that it has previously diagnosed. Each top-level problem [an abnormality (fault) initially inputed by the operator] is solved in rum

algorithm

(part 3).

unless the abnormalities can be related to each other e.g. a low tank level may be found to be result of an observed low flowrate; the search then moves to locating the basic cau.se of the low flowrate since this cause is common to both the low flowrate and the low tank level. When a basic cause is found, the branch of the tree is terminated. The expert system then retraces through its steps leading from the basic event to the initial observed fault. Each fault relating to a state variable is then reactivated so that the system can determine whether the fault can be attributed to other basic events. For example, a low stream pressure might result from both a failed pump and a pipe leak. When all potential local causes of faults have been examined, the session ends. The modifications to the inference control mechanism reflecting the presence of control loops would depend on the type of the control loop, e.g. negative feedback, feedforward, etc. Figure 6 represents these modifications in a general sense. In particular, the modification corresponding to the negative feedback operator shown is illustrated in Fig. 7. Thus a hypothesize-and-test inference procedure is being used in the diagnostic process. Malfunction hypotheses are automatically generated by reasoning

Integrating compiled and deep-level knowledge

DROP DOWN

TO

DEEP-LEVEL KNOWLEDGE

BLOCK:

913

-REMOVE

ABNOFWALITY

FRO

AGENDA”

Fig. 8. Agenda-based inference control algorithm (two-tier case) from the structure of the process and the behavior of the process units. The test part of the procedure is done by the user who evaluates each hypothesis presented to him by MODEX2. However, as one can readily see, this can be incorporated into the system as well by providing the system with the relevant data. The control strategy is summarized in Figs 4-8. Any diagnostic expert system, if it were to inspire confidence in its users, must be able to explain its reasoning in a convincing and transparent manner. In MODEXZ, there are four explanation levels available, with the levels representing increasing comprehensive coverage of the diagnostic reasoning process. 6. CASE STUDIES The process presented in Fig. 9 is considered to demonstrate the diagnostic ability of MODEXZ when applied to processes at a moderate level of complexity. The process is comprised of two feed streams, an isothermal continuously-stirred tank reactor, and one product stream which is pumped from the reactor, cooled in a heat exchanger and passed to a storage tank. The temperature of the reactor is maintained by

regulating the flow of fresh cooling water which passes through a cooling jacket that surrounds the reactor. The reactor level is controlled by the flowrate of an inlet stream (stream 4) to the reactor. The following assumptions are made: (a) the temperature of the second feed stream to the reactor, stream 4, is assumed to be lower than the temperature of first feed stream, stream 2. With this assumption, it is further assumed that an abnormal reactor temperature can result from an abnormal (in the directon of the reactor temperature) flowrate in stream 2 and an abnormal (in the direction opposite of the reactor temperature) flowrate in stream 4; (b) the effects of variations of feed concentrations on the temperature of the reactor contents are not considered; (c) control valves, valve 4 and valve 5, are assumed to be air-to-close. Both control loops are negative feedback loops; (d) the heat exchanger is of a shell and tube configuration. the product stream passes on the tube side; (e) alarms will sound if system disturbances to the reactor temperature or reactor level cause the temperature or level to fall outside some normal operating band; (f) online sensors are available to measure any process variable for which MODEX2

914

V.

VENKATASUBRAMANIAN

and S. H. RICH

Fig. 9. Flowsheetfor the case study. queries the system user. Sensors not associated with control loops are assumed to be functioning properly without any measurement bias, i.e. no sensor performance degradation. All valves have reliable position indicators and all pumps have reliable meters which read pump speed; (g) the effects of a basic event propagate quickly through the system. The system is at steady-state when MODEX2 begins its diagnostic analysis; (h) no information is known about the state of the system or equipment units, other than the observed process abnormalities which trigger the diagnostic session. Two case studies representing diagnostic consultation sessions with MODEX2 are presented in this section. The second case study illustrates the use of the two-tier approach. Both diagnostic sessions are triggered by a pair of process abnormalities, a low temperature in the reactor which is recognized by the temperature alarm sounding and a low terminal product temperature in stream 8 which is recognized by the plant operator from a reading on the control panel. MODEXZ is asked to locate the causal source(s) of these abnormalities.

6. I. Case study 1 In this example, the diagnosis of the two initially recognized abnormalities will be based solely on deep-level knowledge. In the course of this particular diagnosis MODEX2 will examine the following set of basic events as potential causal origin(s) to which either one or both of the abnormal process conditions can be attributed: 1. Wrong set point to reactor temperature controller. 2. Valve 4 stuck. 3. Reactor temperature sensor biased. 4. Loss of signal from sensor to controller. 5. Loss of control air to valve 4. 6. Reversed valve 4 action. 7. Temperature controller reverse acting. 8. Pipe blockage or leak in hot reactor inlet feed system. 9. Low tank 1 level. 10. Reactor leak. Additionally, other basic level events such as valve 3

Integrating compiled and deep-level knowledge stuck closed, a pipe leak upstream of stream 8, improper temperatures at cooling water sources feeding streams 9 and 13, or improper reactor level control-loop action could have been examined by MODEX2 eliminates these MODEX. However, events from consideration based on user responses to system queries, e.g. the knowledge that the level control loop successfully compensates for a low flowrate in stream 2 by increasing the flowrate of stream 4 causes MODEXZ to conclude that the level control loop is functioning properly. It will be assumed that the correct diagnosis is a low level in feed tank 1 and a positive gain in the reactor temperature control loop caused by reversed action in the controller. The diagnostic consultation session is presented as a set of diagnostic trees in Figs 11-14. The diagnostic trees are comprised of a set of text nodes and a set of arcs which connect these nodes. The nodes correspond to conditions in the plant which may or may not be present. An arc connecting two text nodes implies that there is a causal relationship between the two conditions represented by the nodes. The direction of causality is

915

taken as the direction of the arc, i.e. the condition associated with the incident node of the arc is caused by the condition associated with the node at which the arc terminates. Corresponding to each node in the tree is a number which gives the order in which it was generated during the course of its diagnosis. Before proceeding with a detailed description of the diagnosis, the manner in which the two identified causal source(s) propagate their effects through the system will be examined. A low tank 1 level results in a low flowrate in the hot inlet stream (stream 2) to the reactor. The temperature control loop attempts to compensate for this disturbance by manipulating the flowrate of fresh cooling water (stream 11) to the cooling jacket. Because the controller is reverseacting, the control loop action opens valve 4 in response to the low stream 2 flowrate thereby reinforcing (rather than compensating for) the low reactor temperature. The reactor level control loop also reacts to the low flowrate in stream 2 by opening valve 2 to increase the flowrate of stream 4. This event also works towards lowering the temperature in the reactor, since stream 2 is the cold inlet stream.

Fig. 10. Summary of the diagnosis for case study I.

916

V. VENKATASUBRAMANIAN

and S. H. RICH

Abnonnalkies

X

Fig. 11. Diagnostic tree for case study 1 (part 1).

The low temperature in the reactor is passed along to the product outlet stream. Because the temperature of the source of cooling water which serves the heat exchanger is fixed, a low temperature in stream 7 results in a low temperature in the terminal product stream, stream 8. The propagation of the effects of the basic events are summarized diagramatically in Fig. 10. MODEXZ begins its diagnosis by placing (in a user-defined sequence) the two initially observed process abnormalities on an agenda of abnormalities to be diagnosed. In this example, the system user. has chosen to diagnose the low temperature in stream 8 prior to the low reactor temperature (nodes l-3). Calling upon the method stream8:diugnose -tempera ture, MODEX2 recognizes that the low temperature may be a result of a low temperature in the hot inlet stream to the heat exchanger, stream 7. An affirmative response to a system query confirms that stream 7 temperature is low and the agenda is

updated as follows: (1) low stream 7 temperature; (2) low stream 8 temperature; (3) low reactor temperature to reflect that the expert system has now focused its attention on searching for local causal sources of the low temperature in stream 7. The other three potential local causes of a low stream 8 temperature (low stream 7 flowrate, low stream 15 temperature, high stream 15 flowrate) will be examined later in the diagnosis. Through a series of two inferences, MODEX concludes that the low temperature in stream 7 can be attributed to a low temperature in stream 5 (nodes 4-8). Recognizing that the conditions of the outlet stream from a CSTR represent the conditions in the reactor, the expert system infers (after calling the method stream5:diagnose_temperalure) that a low reactor temperature causes the low temperature in stream 5 (nodes 8 and 9). The agenda is updated by moving low reactor temperature from the bottom to the top of the agenda. The new diagnostic agenda reads: (1) low reactor temperature;

917

Integrating compiled and deep-level knowledge

[termlna~ ahw

..-.

I

dllrmatlvs .

-___.

X

Nomd NO X

YES

NO X

NO

[expanded in Figura I&l

YES [expanded

in FbJun 144

Fig. 12. Diagnostic tree for case study 1 (part 2).

(2) low stream 5 temperature; (3) low stream 6 temperature; (4) low stream 7 temperature; and (5) low stream 8 temperature. MODEXZ does not remove an abnormality from the agenda until it has determined that all potential local causes have been examined.

Reactor temperature is the control variable of a negative feedback loop and as such MODEX2 employs the diagnostic strategy suggested in Fig. 7. Initially, MODEXZ checks for the presence of an internal loop disturbance which will either inactivate the control loop (a zero gain event such as a stuck

NO

YES

NO

X Fig. 13. Diagnostic tree for case study 1 Cpart 3).

918

V.

VENKATASUBRAMANIAN

and S.

YES X

NO X

Fig. 14. Diagnostic tree for case study I (part 4).

control valve) or which prevents the control loop from completely compensating for a disturbance to the control variable (e.g. sensor bias) (nodes 1 l-15). In practice, MODEXZ would search through a list of these events in an ordering based on their likelihoods of occurrence. As there are no such disturbances, MODEXZ proceeds by searching for an external disturbance to reactor temperature. Such a disturbance could lead to a low reactor temperature if either: (1) it is so large that the control loop is unable to completely compensate for it (as evidenced by the control valve positioned at its lowest extreme (< 5% open)); or (2) some event has occurred causing the gain of the control loop to go positive; the control loop then functions to reinforce rather than compensate for the disturbance (nodes 17-20). If no external disturbance to reactor temperature is found, MODEX2 looks for an external disturbance to the manipulated variable, In this case MODEX would check whether the flowrate in stream 11 is too high or the stream’s temperature is too low (node 21). There are four possible external disturbances to reactor temperature as given by nodes 22, 23, 32 and

33 in Fig. 12. A response of low to a system query on stream 2 flowrate confirms that there is a system disturbance to reactor temperature. MODEX2 takes the response of “low” (as opposed to “very-low”) to imply that if the control loop were functioning properly it should be able to completely cancel the disturbance. Since the disturbance is not cancelled (the reactor temperature is low) MODEXZ asks whether a reversed gain event has occurred (nodes 24 and 25) and learns that the controller is reverse acting. Low stream 2 flowrate is placed on the top of the diagnostic agenda and the method streamZ:diagnose-powrate is called upon to examine all potential local causes of the low flowrate. Figure 13 (nodes 23-29) summarizes MODEX’s findings in which the expert system concludes that the low stream 2 flowrate is caused by a low level in feed tank 1, possibly a result of operator error. At this point in the diagnosis, the agenda reads: (1) low tank 1 level; (2) low stream 1 flowrate; (3) low stream 2 flowrate; (4) external disturbances to low reactor temperature; (5) low reactor temperature; (6) low stream 5 temperature; (7) low stream 6 tem-

Integratingcompiled and deep-levelknowledge perature; (8) low stream 7 temperature; and (9) low stream 8 temperature. MODEX2 completes its diagnosis of low stream 2 flowrate by exhausting all potential local causes of low tank 1 level, low stream 1 flowrate and low stream 2 flowrate in the direction of material flow and opposite material flow. These three events are removed from the agenda and diagnostic focus returns to external disturbances to low reactor temperature (node 32). Stream 4 temperature is found to be normal. However, the flowrate of (cold reactor inlet) stream 4 is high. High stream 4 flowrate is placed on the top of the diagnostic agenda. Recognizing that stream 4 flowrate is the manipulated variable of the reactor level control loop, MODEX2 attempts to determine whether the flowrate has gone high to compensate for a disturbance to reactor level. MODEXZ infers that the control loop must be functioning properly since the reactor level is normal (node 35) and MODEX2

INITIAL of

919

continues its diagnosis by searching for a disturbance to reactor level (nodes 36-39). Low stream 2 flowrate is one such event. However, it is not placed on the agenda because this event has been diagnosed earlier in the session. In completing the diagnosis of high stream 4 flowrate, MODEXZ has completed its diagnosis of the low temperature in the reactor and all events which lie above low stream 5 temperature on the agenda are removed. The new agenda reads: (1) low stream 5 temperature; (2) low stream 6 temperature; (3) low stream 7 temperature; and (4) low stream 8 temperature. MODEX2 concludes that it has examined all potential local causal sources of the low temperatures in stream 5, stream 6 and stream 7. Diagnostic focus returns to low stream 8 temperature. MODEX2 asks the system user for the temperature and flowrate of stream 15 (the cold inlet to the heat exchanger) and the flowrate of stream 7. Finding that they are all

STATE

SYSTEM Abnormalities

HEURISTICS

FIRST PRINCIPLES KNOWLEDGE

-_._.___

(

Reactor

)

Fig. 15. Diagnostic tree for case study 2.

920

V. VENKATASUBRAMANIAN

normal, MODEXZ empties the diagnostic agenda by removing low stream 8 temperature and the diagnosis concludes. 6.2. Case study 2 Case study 2 presents the two-tier diagnosis of the low temperatures in stream 8 and the reactor using both heuristic and first-principles knowledge. As noted in the earlier discussion of heuristic knowledge, the inclusion of heuristic knowledge aids in hastening the search for causal origin(s) by focusing the expert system’s attention early in the diagnosis on events which, in the past, have shown themselves to occur with the greatest frequencies. Suppose, for example, that the process operates in a multiproduct plant. With the changeover from one product to the next, various plant operating conditions must be altered, for example, by changing control-loop set points. It is conceivable that some of these changes may be neglected by a plant operator if either the number of operating conditions to be altered are numerous, the plant operator is not experienced, or all necessary modifications cannot be made by manipulating dials on the control panel (i.e. the plant operator must go to various equipment units to change control settings). In the process under study, it is likely that at these production changeovers the temperatures of the sources of cooling water for the heat exchanger and the reactor cooling jacket must be reset. If. historically, plant operators have neglected to make these changes then the following two heuristics could be added to the heuristic knowledge base: IF stream 7 temperature is found to be abnormal THEN check if the temperature of stream 13 is abnormal (in the direction of the stream 7 abnormality) IF reactor temperature is abnormal THEN check if the temperature of stream 9 is abnormal (in the direction of the reactor temperature abnormality) The diagnostic tree corresponding to the two-tier diagnosis is presented in Fig. 15. For the purposes of this case study it will be assumed that there is a single causal source to which the two low temperatures can be attributed, namely a low temperature in stream 9. In beginning its diagnosis of the low temperature stream 7, MODEX initially checks the temperature of stream 13 as directed by the first heuristic presented above. Since the cooling water temperature is found to be normal for the specific product currently being produced in the plant, the heuristic fails. Assuming that there are no other heuristics which apply to low stream 8 temperature, the expert system drops down to its first principles knowledge base and generates a diagnostic path connecting nodes 5-10 in the same fashion as in case study 1 by methodically searching for local causal sources. (Here, an assumption is

and 8. H. RICH

being made that there are no heuristics in the knowledge base which apply to low tempertures in streams 5 and 6.) With “low reactor temperature” now at the top of the diagnostic agenda, MODEXZ returns to the heuristic level of the knowledge base and applies the heuristic which relates reactor temperature to stream 9 temperature. The system user verifies that stream 9 temperature is low and the diagnosis conthis heuristic not been present, cludes. Had MODEXZ would have first checked for internal loop disturbances in the reactor temperature control loop and if none were found, MODEXZ would subsequently check for an external disturbance to the reactor temperature. In the event that there were no such occurrences, MODEX would look for disturbances to the manipulated variable (node 21 in Fig. 12). By diagnosing in the direction opposite of material flow, MODEX2 would ultimately arrive at low stream 9 temperature as the causal source.

7. CONCLUSION

In this paper, we discuss a methodology that employs the integration of experiential and firstprinciples knowledge in diagnostic expert systems for chemical process plants. We describe a two-tier object-oriented representation for the knowledge base of such an expert system. Knowledge is grouped so that all facts and heuristics which refer to an object are linked to the object. Thus the knowledge base consists of a library of objects that model the different process units. Inheritance between objects reduces redundancy and improves flexibility in the knowledge base. The top-tier of the knowledge base houses the process-specific, compiled knowledge while the bottom-tier contains the process-general, firstprinciples knowledge. The diagnostic reasoning thus alternates between the two-tiers. The addition of compiled knowledge or heuristic rules based on exeriential knowledge can give the expert system the freedom to explore for basic causes in equipment units which are not spatially adjacent to the unit being diagnosed, thereby improving efficiency by expediting the search for a goal state in the state space. We also present a general procedure for automatically generating the malfunction hypotheses by reasoning from the structure of the process and the behavior of the process units. MODEXZ uses a combination of structural and functional decomposition. The explicit usage of the structure and behavior of the process leads to generality of the knowledge base, thus enabling the system to diagnose different configurations of the same process units. The methodology shows flexibility in that it can simultaneously search for the causes of unrelated faults and can handle faults which are attributed to multiple origins, thus achieving the much desired fault diversity quality.

Integrating compiled and deep-level knowledge The compiled knowledge base (top-tier) is necessarily process-specific and hence will have to be rewritten as the process configuration is changed. This is equivalent to the operator being assigned to a new plant where he will have to learn all the new heuristics from experience. We are currently investigating the automatic learning of new heuristics by the expert system. There is some loss of generality as the compiled knowledge tier is process-specific. However, one gains in efficiency which would be important for real-time diagnosis in large plants. Besides, the two-tier approach is a more natural mode1 of a human process operator and the resulting system’s behavior makes more sense and is more transparent to the users. Moreover, the proposed framework facilitates the convenient development of this compiled knowledge tier by letting one add these an device-oriented manner. This heuristics in simplifies the task of developing and managing the compiled knowledge base. Even though we have not addressed issues such as transient effects, and the MODEX2 system as it stands does not take these into account, they can be quite easily integrated in the proposed architecture.

Acknowledgemenzs-Part of this research was supported by an equipment grant from the DuPont company. The authors would like to thank the Computer Science Department of Columbia University for the usage of their computing facilities.

921

REFERENCES Brownston L., R. Farrel, E. Kant and N. Martin, Programming Experr Systems Rule-Based Programming.

in OPSS:

An Introduction

Addison-Wesley,

to

Reading,

Mass. (1985). Finch E. and M. Kramer, Narrowing diagnostic focus using control system decomposition. Presented at the AIChE Natl Mtg, Houston (1986). Henley E. J. and H. Kumamoto, Designing for Reliabiliry and Safiry Control. Prentice-Hall, Englewood Cliffs, New Jersey (1985). Iri M., K. Aoki, E. O’Shima and H. Matsuyama, An algorithm for diagnosis of system failures in the chemical process. Compu!. them. Engng 3, 489-493 (1979). de Kleer J. and J. S. Brown, A qualitative physics based on confluences. Artificial InteN. 24, 7-83 (1984). Lapp S. A. and G. J. Powers, Computer-aided synthesis of fault trees. IEEE Tram Reliability, April (1977). Rich S. H. and V. Venkatasubramanian, Model-based reasoning in diagnostic expert systems for chemical process plants. Comput. them. Engng 11, 11 l-122 (1987). Rowan D. A., Chemical plant fault diagnosis using expert systems technology: a case study. In Proc. IFAC Con/., Kyoto, Japan (1986). Shafaghi A., P. K. Andow and F. P. Lees, Fault tree synthesis based on control loop structure. Chem. Engng Res. Des. 62, 101-110, March (1984). Stefik M. and D. G. Bobrow, Object-oriented programming: themes and variations. Al Msg. 6, 4-2 (1986). Venkatasubramanian V., Towards a specialized shell for diagnostic expert systems for chemical plants. J. Loss Prevention Process Indusrries 1, 84-91 (1988). Venkatasubramanian V. and P. Dhurjati, An objectoriented knowledge base representation for the expert system FALCON. Proc. Conf. Foundations ComputerAided Process Oper., Park City, Utah (1987).