An expert system approach to malfunction diagnosis in chemical plants

Consput. them. Engng, Vol. 12, No. 1, pp. 27-36, 1988 0098-1354/88 83.00 + 0.00 Printed in Great Britain. All rights reserved Copyright 6 1988 Pergamon Journals Ltd

AN EXPERT SYSTEM APPROACH TO MALFUNCTION DIAGNOSIS IN CHEMICAL PLANTS

S. K. SHUM, J. F. DAVIS,~ W. F. PUNCH 111s and B. CHANDRASEKARAN$

Department of Chemical Engineering, The Ohio State University, Columbus, OH 43210, U.S.A.

(Received 15 August 1986; final revision received 12 March 1987; received for publication 17 March 1987)

Abstract-An efficient knowledge-based system approach to malfunction diagnosis in chemical processing plants is discussed. The approach involves a hierarchical diagnostic structure in which the nodes represent specific malfunction hypotheses. Instead of being a static collection of knowledge, the hierarchy is a collection of small individual specialists coordinated to arrive at an overall diagnosis. Each specialist contains compiled and qualitative domain knowledge for evaluating the malfunction h Tthesis. This malfunction hierarchy is particularly effective in handling multiple symptom and multtpl malfunctton situations. Conclusions are based on a working prototype system which has been built and tested to demonstrate the computational methodology.

Scope-Often, in the operation of chemical processing plants, problem trouble shooting and decision- making on control actions cannot be carried out at the operator level because the necessary technical expertise is not available or severe pressure, as a result of time constraints, prevents clear reasoning. Moreover, technological improvements and enhanced data collection methods have made plants more operationally complex and have provided an overwhelming amount of information for the operator to interpret. Whenever problem-solving tasks must be transferred from the operator level or when there is not enough time for the task to be carried through, product quality, plant reliability, operational safety and ultimately cost can be significantly affected. Only at the operator level can there be immediate corrective or preventive actions in the event of a process problem. Hence, there are potential benefits in a chemical plant for greater intelligence in process control computers which will aid the operator in diagnosing equipment failures, instrumentation problems and process abnormalities.

This need for more intelligence in process diagnosis has been pursued in several directions. These include systems which package and present sensor data in forms which are more easily interpretable [l, 21, model-based algorithmic failure detection and isolation techniques [3-81, fault tree approaches [9, lo] and more recently knowledge-based or expert system techniques [I l-231. Approaches based on combinations of these techniques have also been reported [13,24]. With respect to knowledge-based approaches the Chemical Processing Plant (CPP) is recognized as a domain in which a significant portion of the problem-solving is not mathematical or quantitative, but is still knowledge-rich in terms of human expertise. Thus, it is argued that knowledge-based approaches potentially can capture an important layer of human problem-solving which is present in the operation of chemical plants [25,26].

Generally, a large amount of knowledge and an appropriate problem-solving method are required for a diagnostic expert system to be powerful. Therefore, recent studies of the application of knowledge-based approaches in process diagnosis have concentrated on finding an effective method of representing and organizing the domain knowledge and a suitable problem-solving strategy for the diagnostic task.

1 Approaches involving compiled (model-free) and “deep” (model-based) knowledge as well as separate and Integrated knowledge bases and inference mechanisms have been studied. In the CPP domain, Chester et al. [ll] proposed a causal model knowledge representation. Kumamoto and Henley (121 used an AND/OR tree structure with knowledge compiled in if-then rules. Kramer and Palowitch [13] proposed a “deep” knowledge approach based on a combination of inferences generated by several different diagnostic techniques operating in parallel. Ungar [14] proposed an integrated rule- and frame-based knowledge representation. The predominant approach in the development of expert systems has involved separating the knowledge base and inference mechanism [27]. On the other hand, Davis and co-workers [15-17] have presented an approach which involves an integrated knowledge base and inference mechanism and makes use of compiled knowledge. In the nuclear power plant domain similar efforts to those in the CPP domain have been reported [18-231.

In this work, we present this knowledge-based system approach which is based on a formalism which attempts to match the relevant problem-solving task of the human expert. It is our hypothesis that this formalism, which directly mirrors the human diagnostic task:

(1) takes advantage of the efficient problem solving of the domain expert, (2) permits a natural decomposition of the domain for focus and control, (3) enhances the knowledge acquisition process, (4) has a wide range of applicability in the domain. With this point of view, it is recognized that much of the diagnostic task can be handled efficiently by

human experts using compiled forms of knowledge and qualitative considerations. Thus, this task-oriented

tTo whom all correspondence should be addressed. iDepartment of Computer and Information Science.

27

S. K. Snuu et al.

approach, which reflects relevant human organizational strategies and conceptual abstractions and matches a significant form of domain knowledge used in the diagnosis, will capture directly the efficiency of the domain expert in generating plausible hypotheses that explain the data.

The emphasis in this paper will be on the application of compiled forms of knowledge during diagnostic problem-solving. However, it is our view that, ultimately, a system likely will require integration of model-based reasoning and reasoning with compiled knowledge. Among the topics of our continuing research in this area, the approach presented provides a structure for including and efficiently focusing model-based reasoning and quantitative considerations.

To demonstrate the methodology, a working prototype expert system which diagnoses malfunctions in a chemical plant has been built and tested. The system is built for the oxidation reactor of a terephthalic acid manufacturing plant. In this paper the computational methodology and conclusions based on the prototype system are discussed.

Conelusions and Sigdficance-Malfunction diagnosis in the Chemical Processing Plant domain is identified as a classificatory task, which is to match a set of symptoms with a specitic malfunction hypothesis in a predetermined hierarchy of possible hypotheses. The programming language CSRL (Conceptual Structures Representation Language), which supports the paradigm of a hierarchy of coordinated specialists, captures an important problem-solving strategy useful for diagnosis in the CPP domain. The use of “malfunction hypothesis” as the conceptual basis for constructing the hierarchy and the use of compiled qualitative knowledge have proved to bc effective in the diagnostic task. The malfunction hierarchy is easy to construct and is particularly convenient for handling multiple-symptom and multiple-malfunction situations.

DIAGNOSTX TASK

Examination of diagnostic problem solving in the CPP domain has led to the recognition that deep, model-based reasoning is not used initially by domain experts. Rather, at the onset of process abnormalities, the diagnostic task is approached using qualitative considerations and compiled forms of knowledge. In this initial stage, the problem solving of the domain expert is very efficient and generally the problem is resolved or, at least, considerably narrowed. The quantitative structure of the domain and deeper forms of reasoning are brought into the task only when the initial compiled/qualitative approach fails to completely identify the cause(s) of the abnormalities. Since the compiled/qualitative approach generally serves to reduce the solution space, the deep/model-based reasoning which follows is, therefore, more focused, i.e. the problem is associated with a particular segment of the plant.

In the CPP domain, the compiled/qualitative diagnostic task is identified as one in which appropriate process symptoms are used to establish or reject hypotheses about malfunctions. The diagnostic process begins with the consideration of malfunction hypotheses about broad segments of the plant. If process symptoms suggest that a malfunction hypothesis is valid, then the diagnostic process con- tinues with more refined hypotheses about more detailed subunits of that particular plant segment. On the other hand, if a malfunction hypothesis is rejected, then the entire plant segment can be excluded from further consideration. As illustrated in Fig. 1, the diagnosis may start with a general malfunction hypothesis about the pressure control system. It may then continue with a hypothesis about the pressure feedback control loop of the pressure control system and so on. This type of diagnosis is generically called

match a set of symptoms with a specific malfunction hypothesis in a predetermined structure of possible hypotheses.

Using domain-specific knowledge, the set of possible malfunction hypotheses for the plant can be enumerated. (Note that the enumeration of possible malfunction or fault hypotheses is a requirement of both this compiled knowledge approach and other model-based approaches reported [13, 141). By directly associating with each hypothesis the discriminating symptoms, our diagnostic approach utilizes compiled knowledge about the process. This knowledge is extracted from domain experts who may have acquired it originally in a compiled foqn, developed

SYMPTOMS HYPOTHESIS

REPEATED PROCEDURE OF ESTABLISHING HYPOTHESES AT SUCCESSIVELY HIGHER LEVELS OF PROCESS DETAIL

CJaASSIFlCA7TON

classification 128,291. The classificatory task is to Fig. 1. Malfunction diagnosis as a classificatory task.

Malfunction diagnosis in chemical plants 29

it through experience, or derived it from a deeper model of the process. For example, if there is a malfunction in the pressure control system, the pressure alarm should be activated and the pressure measurement is expected to be either high or low. Thus, the hypothesis of a pressure control system malfunction has “pressure alarm” and “abnormal pressure” as discriminating symptoms which must be present for the hypothesis to be valid. In other words, if these symptoms are present, we may conclude that a malfunction in the pressure control system is a likely possibility. This is again illustrated in Fig. 1. During diagnosis, the process symptoms on hand are matched against the discriminating symptoms of the malfunction hypotheses to determine whether or not the hypotheses are relevant. The symptoms of malfunctions include hard-wired alarms, sensors and direct operator information (sight, sound, smell, etc.).

HIERARCHICAL PROBLEM SOLVING

A powerful way to organize domain concepts in classificatory problem solving is in a hierarchical structure which is involved intimately with the inference mechanism [30-351. For diagnosis in the CPP domain, our studies have shown that an appropriate domain concept is “malfunction hypothesis.” Thus, in applying this hierarchical approach each malfunction hypothesis is represented as a node in a classificatory hierarchy. Nodes higher in the hierarchy are associated with more general malfunction hypotheses while lower nodes are associated with more specific hypotheses. The diagnostic process starts from the top of the hierarchy by considering general malfunction hypotheses about broad segments of the plant and proceeds down the hierarchy with successively refined hypotheses about in- creasingly detailed segments. The hierarchical structure, therefore, allows the decision process to proceed from a high level of generality to a high level of detail.

Not only are the nodes associated with specific malfunction hypotheses, but, in addition, they con- ceptually represent diagnostic specialists. Instead of being a static collection of knowledge, they par- ticipate in the problem solving. Each node has only knowledge pertinent to establishing or rejecting the relevance of a particular malfunction hypothesis. Thus, each node in the hierarchy represents a mini- expert system which makes a single decision. Nodes higher in the hierarchy are associated with more general malfunction hypotheses and as a result have more general knowledge while lower nodes have more specific knowledge to make more detailed deci- sions, i.e. a distributed problem-solving situation. The diagnostic hierarchy can be visualized as a community of many small expert systems which are coordinated to arrive at an overall decision about potential malfunctions in the plant.

The classificatory task is performed by a top-down strategy which is known as “establish-refine.” Each

concept tries to establish or reject itself, All the knowledge that is pertinent to establishing or rejecting the relevance of the malfunction hypothesis associated with a node is locally contained in the node. If a concept is established, using the knowledge local to the node, the control is passed on to its successors, which will then try to establish them- selves, i.e. the refinement process. This is continued until a “tip node” is reached or no node can refine any further. A tip node is the most specific hypothesis that can explain the symptoms. On the other hand, if a concept is rejected, then the entire branch of the hierarchy under it will be pruned. For efficient problem-solving this is one advantage of the hierarchical approach.

This approach effectively integrates the knowledge base and the inference mechanism. The hierarchy is associated both with the organization of the knowledge and the problem-solving strategy. Indeed, the problem-solver is embedded in each of the diagnostic specialists in the hierarchy. Therefore, the knowledge structure also specifies how the individual problem- solvers perform to reach an overall solution. Al- though the currently dominant approach involves separating the knowledge base and the inference mechanism [27J, some researchers [28-30,36,371 have argued that it is unlikely that a complete separation of knowledge base and inference mechanism is viable as a basic principle in the organization of expert systems. Indeed, they believe that knowledge and its use are likely to be more strongly intertwined as the difficulties and variety of the tasks performed by expert systems increase. It has been recognized that domain knowledge needs to be organized not simply for efficiency, but for focus and control in problem- solving [38]. The hierarchy of diagnostic specialists provides a framework upon which the domain knowledge can be organized so that individual specialists can reach a decision about the relevancy of a particular hypothesis. In this way the domain knowledge is organized according to the problem that needs to be solved. Although a compiled knowledge approach is discussed in this paper, this decision- making process could involve a compiled knowledge approach, a model-based approach or both. With respect to compiled knowledge, the hierarchy of specialists provides a framework for grouping re- lations between symptoms and malfunctions. With respect to model-based knowledge, the hierarchy can offer a distributed problem-solving approach which focuses the reasoning on specific segments of the plant.

Furthermore, the main rationale for separating the knowledge-base and the inference mechanism is to provide a methodology in which the knowledge-base can be changed for different applications without having to alter the problem solving mechanism [27]. In our hierarchical problem solving approach, the integration of the knowledge-base and the inferencing strategy is associated with the overall coordination of

30 S. K. SWUM et al.

COOLING AIR FEED PRESSURE *** A /I CONTROL

.i 1. ..A F..,.A& RELIEF CONTROL VALVE VALVE

Fig. 2. Fragment of a diagnostic hierarchy.

the diagnostic specialists during a diagnostic session. However, with respect to the construction of each individual specialist (a small expert system), the knowledge-base and inference mechanism are quite separate. The hierarchical structure, as a result, actu- ally aids in the construction of knowledge-base because the domain knowledge used to establish or reject the malfunction hypotheses is modularized. The domain knowledge contained in each node can be modified easily and independently without affecting the inferencing strategy used at each node. The hierarchy itself can be changed easily because it functions as a coordinator of the specialists but remains independent of the inference mechanism used at each node (by each specialist).

Fig. 4. Reactor segment of plant for producing

Feedback Pressure Control

Manual Valve

+ RelieP Valve

* Pressure IndicatorControllerand Alarm

Fig. 3. Pressure control system of the reactor.

MALFUNCTION HIERARCHY

A fragment of a typical diagnostic hierarchy found in the CPP domain is illustrated in Fig. 2. It shows that the diagnostic framework of a plant segment, reactor in this case, can be built in terms of malfunction hypotheses. As shown, the nodes, “Pressure Control”, “Cooling”, “Air Feed,” etc. represent general malfunction hypotheses that can be further refined into more specific hypotheses or nodes. For example, the “Pressure Control” branch corresponding to the process segment shown in Fig. 3, can be further refined into three subnodes associated with more detailed malfunction hypotheses in the process.

r LlQ”ul NlTROGEN

acid by oxidation of terephthalic paraxylene.


Since the domain concept for constructing the hierarchy is potential malfunctions in the chemical plant, we refer to the hierarchy as a malfunction hierarchy.

The complete malfunction hierarchy for our prototype expert system based on the process plant segment shown in Fig. 4 is shown in Fig. 5. In addition to being an appropriate structure for efficient problem solving (as will be discussed), the malfunction hierarchy has proven to be particularly easy to construct for a CPP domain application. This is a result of the fact that a natural way to think about a process is in terms of a functional decomposition, and that there is a one-to-one correspondence between a system function hierarchy and a malfunction hierarchy. Since experts naturally think about a process in functional terms, this approach makes it easier to extract domain knowledge from the experts. There- fore, it is convenient to construct a hierarchy and its knowledge-base corresponding to a functional decomposition, The malfunction hierarchy can be easily extended to include the entire processing plant by building a hierarchy for each major functional seg-

ment of the plant and grouping them together into an overall hierarchy.

A malfunction hierarchy appears to be a convenient and promising representation for the CPP domain because it maintains a clear distinction between symptoms, events and malfunctions. The hierarchy is constructed in terms of malfunctions; symptoms are used to establish or reject malfunction hypotheses; and events which are not observable are excluded from consideration. This clear separation that results aids the process of sorting information from experts and the construction of the knowledge- base. Here, a malfunction refers to a physical disor- der which may lead to an undesirable event with observable symptoms. Note that an event may or may not be a directly observable symptom itself. For example, a malfunction in the pressure control system may lead to either the “high pressure” or “low pressure” event with “high pressure reading” or “low pressure reading,” respectively, as the symptom, i.e. the event is a directly observable symptom. On the other hand, a malfunction in the transfer system may

-4 CWSecCooli&Sys CWMechanical

I

CondensateWithdrawalSy6 cwsettsng CWElectronic

< RpmSetting

MixingSya

f

Motor DriveSys B&Drive

MechanicalSeal

<

CSecLiquidFeedSys

CoolingSys

CoolingWaterSys f

WabrTempCtrl WaterQualityCtrl WaterSupplyCtrl

ChemReactor PressuroControlSys

AirFaedSys

NitrogenFeedValve PSecAirFeedSys PSecCoolingSys PSeoLiquidFeedSys ManualValve ReliefValve

\

f

PMechanical PFeedbackControlSys Psetting

PElectronic

compressor FlowCtrlMechanical FlowCtrlSetting FlowCtrlElectronic

APressursFeedhackSys AMechanical ASetting AElectronic

TSecAirFeedSys

SolidConcCtrl TSecCoolingSye

<

TSecCondensate TSecMiz&gSys RuptureDisc

TransferSys

TMechanical

TValve

’ Comp”terControl

Fig. 5. The complete malfunction hierarchy.

32 S. K. SHUM et al.

lead to the event “line plug” in the solid product transfer line with “high reactor liquid level” as the symptom, i.e. the event must be deduced from other observable symptoms. Additionally, a malfunction hierarchy is a convenient representation when different functional systems and subsystems have the same physical equipment. When this occurs, the knowledge structures for those nodes are the same. For example, the nodes for the pressure feedback control system include the same knowledge in both air feed system and pressure control system.

It is important to note that the hierarchy is not based on a fault tree structure as suggested by Sriram et al. [26]. A fault tree is a graphical representation of the logical interconnections among the contributing event sequences which result in a specified top event [lo]. Each node in the fault tree represents a contributing event. With this representation, a fault tree needs to be built for every undesirable event of interest. Therefore, it makes organization of the domain knowledge into an overall diagnostic structure difficult. In our malfunction hierarchy, each node represents a malfunction hypothesis, the events are only implied and not explicitly stated. By constructing the diagnostic hierarchy in terms of malfunction hypotheses, there should be a smaller number of nodes in the hierarchy compared with an event-oriented approach like fault tree analysis. Thus, a malfunction hierarchy is a more compact knowledge representation such that fewer nodes need to be

considered in the diagnosis. This is a result of the fact that a malfunction may lead to various undesirable events depending on the exact sense of the malfunction. For example, a pressure feedback control valve malfunction may lead to a ‘high pressure” or “low pressure” event when the valve fails in a closed or open position, respectively. As illustrated in Fig. 6, the “Pressure Control System” node in our hierarchy will he replaced by “High Pressure” and “Low Pressure” nodes while the “PMechanical” node, which represents a mechanical malfunction of the control valve will be replaced by “Control Valve Failed Closed” and “Control Valve Failed Open” nodes in a fault tree hierarchy which is based on events.

Furthermore, limiting the number of nodes can be brought about by recognizing that malfunction hypotheses in the hierarchy need to be refined only to a level of process detail sufficient for the operator to take appropriate action. For example, it is only necessary for the operator to know that there is a malfunction in an electronic controller. It is not necessary to know which electronic component might have failed. The impact of this is that careful selection of the level of process detail at the tip nodes will limit the number of nodes in the hierarchy and improve the efficiency of the diagnostic system.

A simple illustrative example of the hierarchical approach in terms of malfunctions is shown in Fig. 7. Here, we show typical examples of the knowledge

Pressure Feedback Control

PMechenical PElectronic

a) Malfunction Hierarchy

High Pressure Low Pressure

. . . Pressure Feedback l ‘* l ** Pressure Feedback l *’ Control Control

Control Valve Electronic Controller Control Valve Electronic Controller Failed Closed Failure : CLOSE Failed Open Failure : OPEN

b) Fault Tree Hierarchy

Fig. 6. Comparison of malfunction hierarchy with fault tree hierarchy.


Fig. 7. Pressure control system hierarchy.

required for each node to establish or reject itself. Comparison of parent and sibling nodes shows how this approach uses specific symptomatic information at the proper level of process detail. A specific malfunction will be identified by proceeding down the hierarchy through successively established nodes. The knowledge contained in each node is in terms of two types of diagnostic rules:

(1) confirmatory rules-these rules utilize data that are helpful in establishing the concept under which they are located,

(2) exclusionary rules--these rules respond to data which provide negative evidence for a given malfunction.

The knowledge that is in these diagnostic rules is compiled and qualitative. This knowledge is obtained from human experts who have acquired it originally in a compiled form, developed it through experience, or derived it from a deeper model of the domain.

PROTOTYPE DIAGNOSTIC SYSTEM

Programming language

Classification using a hierarchical knowledge structure and employing the concept of nodal specialists, as discussed in the previous sections, has resulted in the development of a high-level language called CSRL (Conceptual Structures Representation Language) at the Ohio State University Laboratory for Artificial Intelligence Research [32]. Just as EMYCIN was developed for building systems based on MYCIN- like problem solving, CSRL is particularly suitable for implementing diagnostic expert systems based on the distributed hierarchical problem-solving ap-

proach. Due to the modular nature of the programming language, the hierarchy can be easily modified by inserting more nodes into the hierarchy or deleting some nodes from the hierarchy without rewriting the computer code for any other nodes. This language has been successfully used to construct expert systems for diagnosing liver diseases [34], for diagnosing automobile fuel system problems [35] and for diagnosing problems in nuclear power plants [20].

CSRL has been used to implement our prototype system in the CPP domain. The language captures the essence of the diagnostic task, i.e. the classification concept discussed previously. It also provides a basic structure for organizing knowledge hierarchically and a mechanism for top-down, parallel refinement. An example of the actual program structure in CSRL is shown in Fig. 8 for the “Feedback Control System” node shown previously in Fig. 7. There are three major sections in the program module.

1. Declaration Statements-these are created or updated automatically by the CSRL operating system when the hierarchy is constructed or modified, respectively. They define the relationships of the specialist to other specialists in the hierarchy.

2. Knowledge Groups (kgs)--one or more of these may appear in a specialist. In this example, only one is involved, namely, “pfcontrol.” It is the main part of the program where domain-specific expert knowledge is encoded in the form of diagnostic rules. Questions for additional data that need to be asked during a diagnostic session are included here. The capability to ask questions is important because it allows the program access to a wider range of data. Although data like alarm states and sensor readings may and will be fed to the diagnostic system directly

Fig. 8. CSRL program for the PFeedbackControlSys specialist.


from a data base, other data which are not directly measurable or require human actions must be supplied by the operator interactively. Currently, two types of questions are used in the prototype system for the purpose of obtaining plant and sensor data. The “AskYNU?” (Ask Yes, No, Unknown) type expects responses of Y, N or U (Represented inter- nally as True, False or Unknown). The “AskHLN?” (Ask High, Low, Normal) type allows responses of H, HH, L, LL, N, or U (High, Very High, Low, Very Low, Normal or Unknown). Since the focus of the research has been on the diagnostic procedure, at the present time, all sensor and alarm data are supplied by the user. Specification of a sensor state as H, L, N, etc. requires a decision by the user. For situations in which the user cannot firmly decide on the response to the question due to lack of information, the Unknown response is used.

The answers to the questions are matched against the pre-conditions of the diagnostic rules. Thus, a knowledge group serves as a pattern matcher where symptoms of the current case are matched against discriminating symptoms of the malfunction to determine whether the malfunction hypothesis is relevant. The answers are stored in a data base so that when any of the questions appear again in another knowledge group or specialist, they will not be asked again. If a match can be found, as illustrated in Fig. 8, the corresponding confidence value is assigned to the knowledge group.

A confidence value is a qualitative measure of the degree of certainty that a malfunction hypothesis is potentially valid for a given set of process symptoms. On a discrete scale of - 3 to + 3, a confidence value of -3 suggests that the hypothesis is highly unlikely while a +3 indicates the opposite. Intermediate values suggest lower degrees of confidence. In this approach, uncertainty is handled separately in each specialist and is therefore hypothesis-specific. Fur- thermore, within each specialist there are no explicit rules of combining uncertainties. In fact, the confidence values are not manipulated mathe- matically at all. Instead, the values reflect directly the confidence the human expert has in a malfunction hypothesis given particular sets of process observables. For example, as illustrated in Fig. 8, the first two diagnostic rules require the matching of three symptoms of fairly equal importance while the third and fourth rules require the matching of only two of the three symptoms. The confidence values associated with the first two rules are therefore higher (3 vs 2). The assignment of the confidence values by the domain expert takes into account an implicit combination of uncertainties associated with individual process symptoms. A more detailed discussion on this issue has been given by Chandrasekaran and Tanner [W.

3. Messages-this section contains procedures which specify how the specialist will respond to different messages from its super-specialist. In this

example, the messages section sets the confidence value of the specialist equal to the value of the “pfcontrol” knowledge group. Then it checks the confidence value to determine whether the specialist is established. A specialist is considered to be established when the confidence value is +2 or + 3 and rejected when it is -2 or -3. It is suspended when the value is - 1, 0 or + 1, i.e. there is not enough evidence to make a final decision.

Implementation

The implementation of our prototype expert system has been carried out on a Xerox 1108 (Dan- delion) workstation which supports the CSRL language in an Interslip-D programming environment. The prototype system was built for a segment of an actual industrial process in order to demonstrate the methodology. In order to confine the problem to only one of generating malfunction hypotheses, the process was considered to be operating at steady state and normally before any malfunction(s) occurred. Diagnostically, the state of the plant was considered at a single point in time, i.e. temporally varying effects are detected by repeated scanning of the diagnostic state. The initial scan begins when the first symptom of a malfunction is detected. Additionally, it is our view that diagnosis of malfunctioning sensors requires another layer of problem solving super- imposed upon the methodology presented. For the purposes of the discussion presented in this paper, alarm and sensor data have been taken as valid. Later relaxation of this assumption does not invalidate the methodology.

Performance characteristics

Multiple symptoms and multiple malfunctions. Due to the highly integrated nature of chemical processing plants and the strong interdependencies among the operating parameters, situations involving multiple symptoms and multiple malfunctions are very likely to occur. Therefore, a diagnostic system in the domain must be able to handle these situations. The hierarchical diagnostic approach making use of malfunction hypotheses enables situations involving multiple symptoms and non-interacting multiple malfunctions to be dealt with effectively. Here, multiple symptoms refer to activated alarms, abnormal sensor readings, and other observables. There are two rea- sonable scenarios:

1. Multiple Symptom+Single Malfunction-In a multiple symptom situation, it is quite possible that more than one branch of the hierarchy will be considered at some point during the diagnosis. How- ever, if there is a single malfunction, only one branch will push through to a primary tip node. For example, referring to Fig. 5, if the temperature and reactor liquid level alarms are activated and the temperature and reactor liquid level readings are abnormal, then both the “CoolingSys” node and the “TransferSys”


node will be established in the diagnosis. The sub- specialists in the two branches, namely, “CSecLiquid- FeedSys”, “CoolingWaterSys”, “SolidConcCtrl” and “TValve,” will then be considered in the refinement process. If there is only one malfunction, only one branch in the hierarchy will be able to push through to a primary tip node, thereby identifying the corresponding malfunction.

2. Multiple Symptoms-Multiple Malfunctions- The diagnostic process in this case is essentially the same as discussed above. However, if more than one malfunction is involved, then more than one tip node will be established. The number of established tip nodes corresponds to the number of malfunctions identified in the diagnosis.

Note that in order to identify all the malfunctions in the diagnosis, it is necessary to consider all the sub-specialists of any established parent nodes in the hierarchy. The hierarchical approach is efficient in this case because generally only a small number of specialists is established at each level so that many branches are pruned.

The computational methodology presented can readily resolve independent multiple malfunction situations. However, if the multiple malfunction situation involves interacting malfunctions, the methodology will not be able to identify the source malfunction. The classification task described in this paper would identify a small set of plausible hypothesis which explain the data. A different problem- solving task is needed to identify and resolve the interacting malfunctions. This extension to the classification task is the subject of on-going research [40,41].

Secondnry specialists

For completeness in interpreting the results, secondary nodes are included in the hierarchy (in Fig. 5, secondary nodes contain “Set” in the label). They are not necessary to the diagnostic process but are used to indicate that the symptoms which have caused consideration of a particular malfunction hypothesis are secondary to some other malfunction hypothesis. For example, if we have a malfunction in the cooling system, the temperature rise may cause the pressure to rise also, i.e. a multiple symptom situation. In this case, both the “PressureControlSys” and “Cool- ingbys” nodes will be established. the “CoolingSys” branch will push through to a tip node identifying a specific malfunction. However, for the “Pressure- ControlSys” branch, only the PSecCoolingSys” node should be established. The established “P&C- CoolingSys” node indicates that only a malfunction in the cooling system is involved, i.e. not a multiple malfunction situation.

Testing of prototype system

Our prototype system has been tested with numer-

volving multiple symptoms and non-interacting multiple malfunctions have been used. The testing procedure is as follows:

1. A malfunction or a set of several malfunctions corresponding to the tip node(s) in the malfunction hierarchy is hypothesized and the diagnostic system is run.

2. The questions asked by the system during the diagnostic session are answered by the domain expert based on his knowledge of what should be observed given the malfunction(s).

3. The diagnostic conclusions reached by the system are compared with the malfunction(s) hypothesized in Step 1) to determine whether or not the system has identified not only all of the hypothesized malfunction(s) but also no others.

Within the working assumptions discussed previously, the prototype system has been able to reach correct diagnostic conclusions for all recent test cases.

Acknowledgement-This work was supported by the Ohio State University Seed Grant.

1.

2.

3.

4.

5.

6.

I.

8.

REFERENCES

Electric Power Research Institute, Evaluation of SPDS concepts. Report EPRI NP-2239, Palo Alto, Calif. (1982). L. P. Goodstein, Discriminative Display Support for Process Operators. In Human Detection and Diagnosis of System Failures (J. Rasmussen and W. B. Rouse, Eds). Plenum Press, New York (1981). Y. Ben-Haim, Malfunction isolation in linear stochastic systems: application to nuclear power plants. Nucl. Sci. Engng 85, iS6 (1983). C. Bonivento and A. Tonielli, A detection-estimation multifilter approach with nuclear application. Proc. 9th World Congress of IFAC, Budapest, Hungary, pp. 1771-1776 (1984). A. Halme and J. Selkainaho, Instrument fault detection using an adaptive filtering method. Proc. 9th World Congress of IFAC Budapest, Hungary, pp. 1765-1770 (1984). R. Isermann, Process fault detection based on modeling and estimation methods. Aufomatica 20, 387 (1984). J. A. Romagnoli and G. Stephanopoulos, Reactification of process measurement data in the presence of gross errors. Chem. Enana Sci. 36, 1849 (1981). G. M. Stanley and-R. S. H. Mah; Observability and redundancy in process data estimation. Chem. Engng Sci. 36, 259 (1981).

9. R. E. Barlow and H. E. Lambert, Introduction to I-autt Tree Analvsis. In Reliabilitv and Fault Tree Analysis (R. E. Bahiw, J. B. Fussefi and N. D. Singpurwalla, Eds). Society for Industrial and Applied Mathematics, Pa. (1975).

10. G. J. Powers and F. C. Tompkins Jr, Fault tree ;;;II for chemical processes. AIChE JI 20, 376

t 1. D. L. Chester, D. E. Lamb and P. Dhurjati, An expert system approach to on-line alarm analysis in power and process plants. ASME-Computers in Engineering 1, 345 (1984).

12. H. Kumamoto and E. J. Henley, Application of expert system techniques to fault diagnosis. Presented at ,.^^~\ AIChE 1984 Annl Mtg, San rranclsco (lY84). ous hypothetical cases. Complicated test cases in-


13. M. A. Kramer and B. L. Palowitch, Expert system and knowledge-based approaches to process malfunction diagnosis. Presented at AIChE 1985Annl Mtg, Chicago (1985).

14. L. H. Ungar, A framework for automated reasoning about chemical processing plants. Submitted to Com- par. them. Engng (1988).

15. J. F. Davis, W. F. Punch, S. K. Shum and B. Chan- drasekaran, Application of knowledge-based systems for the diagnosis of operating problems. Presented at AIChE 1985 Ann1 Mtg, Chicago (1985).

16. S. K. Shum, I. F. Davis, W. F. Punch and B. Chan- drasekaran, An expert system for diagnosing process plant malfunctions. Presented at IFAC Workshop on Fault Detection and Safety in Chemical Plants, Kyoto, Japan (1986).

17. S. K. Shum and J. F. Davis, Application of CSRL to malfunction diagnosis in complex processing plants. Presented at Second Ann1 Conf. Expert Systems in Government, McLean, Va. (1986).

18. B. Chandrasekaran and D. W. Miller, An artificial intelligence approach to sensor conflict resolution. Presented at ht. Top. A4tg Comput. Applies Nucl. Power PIant Operation and Control, Pasco, Wash. (1985).

19. B. Chandrasekaran, D. D. Sharma and D. W. Miller, The application of knowledge-based systems of reactor operations. Presented at ANS Winter Mtg, Washington (1982).

20. S. Hashemi, B. K. Hajek, D. W. Miller, B. Chan- draksekaran and J. R. Josephson, Expert systems application to plant diagnosis and Sensor data validation. Proc. 6th Power Plant Dynamics, Control and Testing Symposium, Knoxville, Tenn. (1986).

21. W. E. Nelson, REACTOR an expert system for diagnosis and treatment of nuclear reactor accidents. Proc. Nat. Conf. AI, Pa (1982).

22. D. D. Sharma, D. W. Miller and B. Chandrasekaran, Design of artificial intelligence system for safety function maintenance. Trans. Am. Nucl. Sot., pp. 29+297, November (1985).

23. W. E. Underwood, A CSA model-based nuclear power - plant consultant. Proc. Not. Conf. AI, Pa (1982).

24. H. E. Stephanou, An evidential framework for intel- ligent control, Proc. of the 1st IEEE Workshop on ZnteiIigent Control, Rensselaer Polytechnic Institute, Troy, New York (1985).

25. P. E. Hart, Expert systems and technological problems. Proc. 2hd Int. Cons. Foundations Comput.-Aided Process Des. Snowmass, Co10 (1983).

26. D. Sriram, R. Banares-Alcantara, V. Venkatasubra- manian, A. Westerburg and M. Rychener, Knowledge- based expert systems: an emerging technology for CAD in chemical engineering. Report DRC-06-76-84, Design Research Center, Carnegie-Mellon University (1984).

27. E. Rich, ArtiJicial Intelligence. McGraw-Hill, New York (1983).

28. B. Chandrasekaran, Towards a taxonomy of problem solving types. AI Magazine 4, 9 (1983).

29. B. Chandrasekaran, Expert Systems: Matching Tech- niques to Tasks. In Artificial Intelligence in Business (W. Reitman, Ed.). Ablex Publishing, USA (1984).

30. F. Gomez and B. Chandrasekaran, Knowledge organization and distribution for medical diagnosis. IEEE Trans on Systems, Man and Cybernetics SMC-11, 34 (1981).

31. B. Chandrasekaran and S. Mittal, Conceptual Repre- sentation of Medical Knowledge for Diagnosis by Com- puter: MDX and Related Systems. In Advances in Computers, Vol. 22 (M. Yovits, Ed). Academic Press, New York. (1983).

32. T. Bylander, S. Mittal and B. Chandrasekaran, CSRL: A language for expert systems for diagnosis. Proc. Znt. Joint Conf. AI 8, 218 (1983).

33. B. Chandrasekaran, F. Gomez, S. Mittal and J. W. Smith, An approach to medical diagnosis based on conceptual structures. Proc. Int. Joint Conf. Al 4, 134 (1979).

34. S. Mittal, B. Chandrasekaran and J. W. Smith. An overview of MDX-a medical diagnosis system. Proc. III Ann1 Symp. Comput. Applies Medical Care, Wash- ington, D.C. (1979).

35. M. C. Tanner and T. Bylander, Application of the CSRL language to design of expert systems. The auto- mech experience. ArtiJiciai Intelligence in Maintenance: Proceedings of the Joint Services Workshop. AFHRL- TR-84-25, pp. 131-151, Air Force Human Resources Lab Report (1984).

36. R. Davis, Expert systems: where are we? and where do we go from here? AI Magazine 3, 3 (1982).

37. M. Stefik, J. Aikins, R. Balzer, J. Benoit, L. Birnbaum, F. Hayes-Roth and E. Sacerdoti, The Organization of Expert Systems: A Prescriptive Tutorial. Technical Rept, Xerox PARC (1982).

38. D. B. Lenat and G. Harris, Designing A Rule System That Searches For Scientific Discoveries. In Pattern- Directed Inference Systems (D. A. Waterman and F. Hayes-Roth, Eds). Academic Press, New York (1978).

39. B. Chandrasekaran and M. C. Tanner, Uncertainty Handling in Expert Systems: Uniform vs Task-Specific Formalisms. In Uncertainty in Artz$cial Intelligence (L. N. Kanal and J. Lemmer, Eds). North Holland, Amsterdam (1986).

40. J. F. Davis, W. F. Punch, III and T. M. Hess, An expert system approach to diagnosis of product quality devi- ations. Presented at AIChE 1987 Spring Meeting, Houston (1987).

41. J. Josephson, B. Chandrasekaran and J. Smith, Assem- bly of the best explanation. Proc. IEEE Workshop on Principles of Knowledge-Based Systems, Denver (1984).

Documents

An expert system approach to malfunction diagnosis in chemical plants