mds: an integrated architecture for associational and model-based diagnosis

Applied Intelligence 14, 179–195, 2001c© 2001 Kluwer Academic Publishers. Manufactured in The Netherlands.

MDS: An Integrated Architecture for Associationaland Model-Based Diagnosis

XUDONG W. YUDepartment of CS, SIUE, Edwardsville, IL 62026, USA

[email protected]

GAUTAM BISWASDepartment of EECS, Vanderbilt University, Nashville, TN 37235, USA

[email protected]

JERRY WEINBERGDepartment of CS, SIUE, Edwardsville, IL 62026, USA

[email protected]

Abstract. This paper discusses the design and implementation of an integrated diagnosis system, MDS (Multi-level Diagnosis System), which combines associational and model-based approaches to diagnosis. The designand implementation of the associational module is tailored to achieving efficiency in routine diagnostic problemsolving, and to providing a desirable interface for the users. The model-based diagnosis module is developed toachieve completeness and consistency in the fault isolation task, and to avoid the brittleness that often occurs inassociational systems. MDS addresses the important issue of combining the use of “deeper” knowledge in theform of a system model with “shallow” (or associational) knowledge, using a diagnostic controller to improvecompleteness and consistency without sacrificing efficiency. The diagnostic controller also employs a methodologyfor automated knowledge refinement by identifying incomplete and inconsistent rules and diagnostic tests in theassociational module, and then by performing updates to correct the problems. This paper focuses on the designand implementation of the diagnostic controller.

Keywords: model-based reasoning and diagnosis, integrated diagnosis system, automated knowledge refinement,rule-based reasoning and diagnosis, hybrid system

1. Introduction

A field mechanic looks at the trouble report generatedby the flight crew for an airplane which pulled up tothe gate about 20 minutes ago, then walks up to theairplane and performs a half dozen tests. After delib-erating for a while, he ends up swapping a valve in thepneumatic system, and this fixes the problem indicatedin the report.

The mechanic then walks to another airplane witha similar trouble report and attempts to isolate the

problem following the same procedures. But this time,he cannot seem to isolate the problem. He then sitsdown, studies the schematic diagrams of the pneumaticsystem for a while, goes back to the airplane, performsa few additional tests, and discovers that the problemthis time is a broken wire at the back of the controller.

An understanding of the mechanic’s reasoningprocesses and the activities he performed providesmuch insight into how human experts solve complexproblems. This understanding can be essential whenwe construct automated computer-based systems and

180 Yu, Biswas and Weinberg

computer assistants for complex problem solving tasks.In the first case, the trouble report immediately indi-cated to the mechanic that the situation was similar tocases he had successfully dealt with before. Based onhis experience, he made a quick guess as to where theproblem might be and proceeded to verify his conjec-ture by doing some relevant tests. The results confirmedhis initial guess, and he quickly fixed the problem byswapping the faulty valve. In this case, the mechanicrelied mainly on his past experience to quickly narrowdown the problem to a small number of possible faults,and a few directed tests helped him confirm the truefault.

This scenario suggests that effective automated trou-bleshooting systems can be built by capturing experts’experience, and transferring them into “rules of thumb”that can be encoded into computer programs. From theearly 70’s, computer systems have been developed thatfocus on the use of this knowledge for effective di-agnosis of complex systems. These systems have hadtheir share of successes, but they have also exhibiteda number of very important limitations. Most notably,they tend to be brittle, i.e., they fail in situations thatare not specifically covered by the set of explicit rules.Factors that contribute to this brittleness include theincompleteness of experts’ knowledge and the difficul-ties in translating experts’ heuristics into a cohesive setof rules.

To see how the associational systems can be im-proved, it is again useful to look at what our expertmechanic did when faced with an unfamiliar situation.He first tried to cast the new problem (in the second air-plane) in terms of problems he had seen before, but soonrealized that this problem was different and solutions hehad tried before wouldn’t work. He then went back tostudy the system from a more fundamental perspective(i.e., study the system schematics and functionality todetermine components that could be linked to the ob-served symptoms). This led to new possibilities andadditional tests that helped to isolate the real problem.

This example illustrates that effective diagnosis alsorelies on fundamental knowledge about a system. Sincethe mid 80s, diagnosis system design has focused onthe use of this fundamental knowledge to achieve ef-ficient and effective diagnosis (e.g., [1]). The funda-mental knowledge is typically expressed as a modelof the correctly functioning system that can be usedto generate expected system behavior. For diagnosis,this behavior is compared with the observed behav-ior of the system, and discrepancies are analyzed to

derive possible faults. Typically, system models that de-rive behavior from structure are easier to construct forhuman-engineered systems, where design documentsin the form of schematics and system specifications arereadily available. This is in contrast to systems, suchas physiological processes, where the mapping fromstructure to function is not well defined, and the samecomponent can play different roles in different con-texts. The ability of a model-based diagnosis system tocorrectly identify different faults is very dependent onthe existence of a goodmodelof the system [1]. There-fore, constructing adequate models becomes a crucialtask for successful diagnosis.

The use of more fundamental and first principleknowledge in model-based diagnosis systems enablethem to deal with a more comprehensive set of sit-uations and previously unseen faults. This mitigatesthe brittlenessproblem suffered by traditional asso-ciational systems. However, a disadvantage of usingmodel-based diagnosis techniques, especially for large,complex systems with large number of componentsand possible interactions, is that the diagnosis processcan become computationally expensive. This is not tosay that the model-based diagnosis algorithms are lessefficient. As Davis has correctly pointed out [2], thecomputational speed of the system does not depend onthe form in which knowledge is used, but on the levelof detail that is represented in this knowledge struc-tures. Knowledge based systems that use associationalknowledge derived from human experts often tend toproduce more efficient performance because the ex-perts have already succeeded in “inventing the rightvocabulary and the right set of abstractions” [2] for thetasks at hand. It is not easy to use generic model build-ing techniques to develop models that include the rightlevel of detail to cover all faults of interest while ensur-ing irrelevant details are omitted. Expert designers andanalysts who are good at creating system models areoften not the expert diagnosticians. To address theseproblems, AI researchers have investigated strategiesthat focus the diagnosis to make it more efficient us-ing techniques for model abstraction [3] and functionaldecomposition [4]. Prior knowledge about componentfailures, expressed as probabilities have also been usedto prune the search space [5].

Our research addresses the above problem by adopt-ing an integrated approach to diagnosis. The primarygoal is to develop a robust and efficient diagnosis sys-tem for complex, real-world systems. This approachcombines the associational knowledge available from

MDS: An Integrated Architecture 181

human experts with a model-based approach. The ideais to employ the more efficient and tailored associa-tional knowledge for routine faults. When the associa-tional module fails, the model-based diagnosis com-ponent is invoked to derive a correct solution. Thisway, the system maintains a good tradeoff betweenefficiency and robustness. In addition, our system em-ploys knowledge refinement techniques to transfer newknowledge to the associational module from the model-based component to improve problem solving effi-ciency. In a way, this leads to transformations of moregeneric, fundamental knowledge into a form more use-ful for diagnosis. This process leads to improvementsin efficiency of diagnosis without sacrificing reliability.

These ideas are incorporated into Multi-level Diag-nostic System (MDS), a system that assists mechanics1

in the diagnosis of complex aircraft subsystems [6].These subsystems, such as the pneumatic system ofan airplane, cover multiple domains such as hydraulic,mechanic, thermodynamic, and electric. MDS con-tains two diagnostic modules: (i) an associational mod-ule that uses heuristics extracted from troubleshootingmanuals and human experts, and (ii) anMBD (Model-Based Diagnostic) module that relies on behavior andfunctional knowledge of the system to be diagnosed.The MBD module performs steady-state diagnosis. Theimplication is that the system was operating normallyin steady state before a failure occurred, which causedthe system to deviate from the known steady state. Wefurther assume that the failures are not catastrophic,i.e., they do not cause drastic changes in system behav-ior and functionality. The activities of the two modulesand the knowledge/data transfer between the two arehandled by a third module, thediagnostic controller.

This paper focuses on the design and implementa-tion of the diagnostic controller. This involves two pri-mary tasks: (i) controlling the interaction among thetwo diagnostic modules, and (ii) updating and refiningthe associational module using results derived from theMBD module when the associational module is foundto be incomplete or in error. To facilitate this discus-sion, the two diagnosis modules are briefly presented inSection 5, but additional details can be found in [7–9].The system has been applied to trouble-shooting thepneumatic system of the DC-10 aircraft.

2. Background

A number of techniques have been developed for auto-mated computer-based diagnosis in different domains.

Early programs employeddecision trees, fault direc-tories, andprobability theorytechniques for diagno-sis tasks. These approaches were successful in simpleapplications that involved well-understood systems innarrow and carefully chosen domains. However, theysuffered serious drawbacks when attempts were madeto scale them up for complex systems where the num-ber of possible interactions among components is high.The primary pattern was that the complexity resultedin incomplete and inconsistent diagnostic knowledge,which in turn produced incorrect diagnoses.

To address these problems, artificial intelligence andknowledge based techniques were applied to build-ing diagnostic systems. An important characteristic ofearly AI work was the use of heuristics and judgmentalknowledge of human experts to improve system per-formance. For example, the MYCIN system [10] en-coded expert knowledge in the form of heuristic pro-duction rules with certainty factors. Other approachesused causal models (e.g., CASNET [6]) andset cov-ering techniques that allowed for simultaneous diag-nosis of multiple diseases (e.g., [11]). As discussedearlier, these systems exhibited performance problemsthat could be attributed to: (i) incompleteness and in-consistencies in the knowledge of human experts, (ii)the difficulty in extracting heuristic information fromhuman experts, and (iii) the task dependency of the de-rived knowledge. These limitations motivated the de-velopment ofmodel-basedsystems.

The key to model-based approaches to diagnosis isthe availability of knowledge about the structure andbehavior of thecorrectly functioning device (or sys-tem), and the means to explicitly represent this knowl-edge (e.g., via measured variable values). This knowl-edge can then be used to predict the behavior of the de-vice or system using quantitative or qualitative simula-tion mechanisms (e.g., GDE [12], Sherlock [5], MIMIC[13], and GDE+ [14]). For example, the General Di-agnostic Engine (GDE) performed multiple fault diag-nosis using an Assumption-Based Truth MaintenanceSystem (ATMS). For purposes of efficiency, diagnosissystems also store, as part of the model, nominal be-havior of the device for standard input sets (e.g., [15,16]). Model-based approaches have also employed di-rected causal relations between system variables fordiagnostic analysis [17]. Qualitative simulation meth-ods have also formed the basis for monitoring and di-agnosis (e.g., [13]). For example, TEXSYS [18] usedGDE-like methodology for monitoring and diagnosisof a complex thermal system. DEDALE [19] employed


order of magnituderelations. This work was extendedto deal with more continuous analog systems (CATS[20]). Gallanti et al. [15] combined a Boolean modelfor candidate generation with a simplified quantita-tive (difference equation) model for candidate verifi-cation. Their work focused on control issues and didnot relate faulty parameters to individual componentfailures. More recently, there has been work that em-ploys a temporal causal graph and higher order deriva-tives to model system dynamics and represent faultysituations as dynamic transients [20]. A progressivemonitoring scheme compares observations to the pre-dicted transients to isolate the true faults. To improvethe diagnostic efficiency, diagnostic systems have alsoincorporated fault models (e.g., Sherlock [5], GDE+[14]). Sherlock used fault models to rank candidates.GDE+ used fault models to eliminate spurious candi-dates (i.e., candidates that are inconsistent with the setof known faults) and MIMIC [13] used fault models tohypothesize candidates.

Techniques have been developed that combine dif-ferent approaches to diagnosis. Fink and Lusth’s IDMsystem [21] combines the use of associational andfunctional reasoning for diagnosis of complex electro-mechanical systems. IN-ATE [22] uses associationalrules to generate initial candidates (i.e., one or a set ofsuspects) and then uses a model-based approach to fur-ther test and discriminate among the candidates. ABEL[23], a system developed for medical diagnosis, com-bines the use of multi-level causal models that describesdomain phenomena at different levels of granularityfor effective problem solving. More recently, many hy-brid systems have been developed that integrate differ-ent modules (usually two), such as neural network andmodel-based systems [24], neural network and associ-ational systems [14], constraint satisfaction and case-based systems, (e.g., [25, 26]), and model-based withcase-based (e.g., [27, 28]). The modules these systemsintegrate are different from MDS in terms of: (i) the in-dividual modules they employ—none of them combinemodel-based with associational rule base, and (ii) theway the two modules cooperate to generate better per-formance. However, their goal of achieving efficiencyand completeness are similar to ours.

3. Architecture of MDS

The architecture of the MDS system is illustrated inFig. 1. The associational module uses rules that are di-rect associations between symptoms and hypotheses.

Since its knowledge base is created by human expertsand is based on the vocabulary and tasks that the aircraftmechanics use to perform their day-to-day operations,it helps define the right level of detail at which diagnos-tic analysis needs to be performed in this domain. Theknowledge for this module was extracted largely fromtroubleshooting documents such as the TAFI (TurnAround Fault Isolation) manuals,2 and human experts(both mechanics and engineers). This module also pro-vides the appropriate vocabulary used in the system’sinteraction with the users (i.e., the mechanics) in theform of a partial decision tree which most mechanicsare trained to use.

The MBD module incorporates schematic, func-tional, and behavioral models of the system as describein [7]. The MBD module is invoked when the associ-ational module fails to identify faults in a given situa-tion. In this process it can be used to identify errors inthe associational module, and assist engineers and ex-pert mechanics in updating the associational module.However, when updating the associational module withnew rules, we assign lowbelief valuefor new faults ini-tially. These new rules are considered temporary andtheir belief values are adjusted when the same condi-tions are encountered again. A temporary rule is madepermanent only after its belief value exceeds a presetthreshold as a result of multiple occurrences of the samefault. New tests may also be added to the associationalmodule, but only after being approved by the engineersand the mechanics. In this way, we maintain a relativesmall knowledge base in the associational module forefficient reasoning.

To achieve the integrated capabilities, thediagnos-tic controller coordinates the diagnostic activities be-tween the associational and MBD modules. The idea isto derive typical faults quickly using symptom-causeassociations and drop down to the MBD module onlyfor unusual cases. During diagnosis, the associationalmodule is invoked first. If a conclusion is derived, thenthe MBD module is used to verify the conclusion. Ifthe result is correct, then the problem is solved. Oth-erwise, the MBD module goes back and deduces thesolution from the initial symptoms. When the associa-tional module cannot derive a definite conclusion, theMBD module takes over. Information obtained by theassociational module is transferred to the MBD mod-ule by the diagnostic controller. Conclusions as wellas intermediate results derived by the two modules areused by the diagnostic controller to identify problemswithin the associational module.


Figure 1. Architecture of MDS.

4. The Pneumatic System of the DC-10 Aircraft

Our diagnosis tasks focus on the part of the pneumaticsystem (Fig. 2) that regulates air pressure and tem-perature drawn from one of three engines before it isdelivered through the manifold system to different sub-systems of the aircraft that constitute loads (e.g., thewing de-icing system).

The pneumatic pressure is regulated by apressureregulator subsystem.The pressure regulator valve ismodeled as a first-order system, where the opening ofthe regulating valve is determined by the changes inpressure at the regulator output. The temperature is con-trolled by apre-cooler subsystem, whose primary com-ponent, a heat exchanger, draws cool air from a secondsource to cool the bleed air from the engine. Feedbackmechanisms sense the temperature at the pre-cooleroutput. This information is fed back to the valve con-troller that adjusts the opening of the valve to controlthe amount of cold air input to the heat exchanger, usingthe power obtained from the hot air transmitted throughthe sense line. For the diagnosis model, both the pres-sure regulator and pre-cooler subsystem are modeled

in more detail in terms of primitive components. Forexample, the pre-cooler subsystem is modeled in termsof six primitive components (Fig. 3): (i) the heat ex-changer, (ii) the feedback controller, (iii) the valve, (iv)the valve controller, (v) the temperature control sensor,and (vi) the sense line.

5. The Diagnosis Modules

This section provides an overview of the associationaland model-based diagnosis modules. Details of the de-sign and implementation of these modules are pre-sented in [7–9].

5.1. The Associational Module

The associational module adopts a conventional ex-pert system architecture with the focus on developingmethods for generating partial decision trees that indi-cate to the mechanics suggested sequences of tests forfault isolation. The system has three primary compo-nents: theknowledge base, theinference engine, and thedecision tree generator.


Figure 2. The pneumatic system.

Figure 3. The pre-cooler subsystem.

Information in the knowledge base is derived directlyfrom human experts and existing troubleshooting man-uals (in this case, the TAFI manual), and is representedas: (i)production rulesthat link symptoms to hypothe-ses, and (ii)a list of available tests. Production rulesare used to derive plausible hypotheses from availablesymptoms. A typical rule has the form (LHS BF RHS

BV), where LHS (Left Hand Side) specifies one ormore symptoms and situations that need to be true forthe rule to be fired. RHS (Right Hand Side) containsthe conclusions of the rule i.e., possible hypotheses thatexplain the given symptoms. BV (Belief Value) speci-fies the confidence level associated with each hypoth-esis in the conclusion on a scale of 0 to 1. BF (Belief


Function) specifies the confidence level of the rule it-self. The Dempster-Schafer belief function model isused to combine various belief values during the infer-encing process [29]. An example of the rules used inthe current system is show below:

(|rule121| ((((system)(pneumatic)) ((templight) (on)) ((stagelight) (normal))((pneutemp) (high)) ((pneupressure) (normal)) 0.7)

((((hyp) (heatexchanger))) 0.7) (((hyp)(valve))) 0.6)))

The above rule states that if the system is pneumatic,the temperature light is on, the stage light is normal,the pneumatic temperature is high, and the pneumaticpressure is normal, then the two possible fault candi-dates are the heat exchanger and the valve, with beliefvalues of 0.7 and 0.6, respectively. The overall confi-dence level for this rule is 0.7. An interpretation of thelater value is that the importance of this fact in the faultisolation process is 0.7.

The test list contains relevant tests that either sup-port individual hypotheses or help to further discrim-inate among the individual hypotheses in the possiblefaults list. Each test in the list contains the followinginformation:

• Rankings of the tests in terms of the three criterion:(i) cost of the test, (ii) time required to perform thetest, and (iii) the predictability of the test.• How the result of that test may affect other tests.• Conclusions or intermediate results that may be de-

rived directly from the result of the test, when one ormore hypotheses are verified. (Otherwise, the resultof a test is considered a new symptom that can beused to update the hypothesis list.)

The inference engine controls the diagnostic activ-ity within the associational module. It assumes an it-erativehypothesize, test, and refine control structure[9, 29]. The system first derives initial symptoms frompreliminary information collected by mechanics. A setof hypotheses (possible malfunctioning components)is then generated from the initial set of symptoms us-ing a forward chaining reasoning mechanism. Giventhe set of hypotheses, a backward chaining reasoningmechanism is used to select tests that eitherdiscrimi-nateamong candidate hypotheses orverify that a po-tential candidate is actually faulty. This basic forwardand backward chaining reasoning structure is adoptedfrom the MIDST expert system shell [29]. The tests arethen ordered and presented as a partial decision tree.In the current system, the tests are ordered based ona value computed from the three criteria listed above.

The weighting scheme for the criteria is determined bymechanics [9] based on the particular situation. The testwith the highest rank becomes the root of the decisiontree. For each possible result of that test, a new set oftests is generated, and their scores are calculated. The

test with the highest score on each branch becomes theroot of that sub-tree. This process continues recursivelyuntil either a leaf node is encountered (i.e., the child ofa test is a conclusion) or the tree has reached a pre-determined number of levels. (For an example partialdecision tree, see Fig. 4.)

The user can study the decision tree presented, andconduct one or more tests.3 Results of the additionaltests performed are fed back into the system. Thesemay determine that a particular hypothesis has beenverified. This would complete the current diagnos-tic session. Otherwise, the system goes back to de-rive new symptoms based on the test results, and usesthese symptoms to update and prune the list of possi-ble hypotheses. A new set of tests is then selected, andthe diagnostic session continues. The system repeatsthe symptoms-hypotheses-testloop until either thefaulty components are identified or all hypothesis areeliminated.

It should be pointed out that the reasoning processof associational module is designed to make the test-ing process efficient while providing users with a lot offlexibility in performing the tests. Rather than askinga mechanic to conduct one test at a time, it generatesa partial decision tree dynamically, so that a set of re-lated tests could be conducted before the user has tocome back to the system for additional information andhelp. The decision tree approach provides the user bothflexibility (test orders are determined dynamically) andefficiency (the results of one test will change the impor-tance of some other tests). From our interaction withmechanics, we found that they prefer the decision treeapproach. On the other hand, just providing a com-plete, static decision tree annoyed them, because theyfelt tied to a pattern that they could not alter, even iftheir experience indicated otherwise.

5.2. The Model-Based Diagnostic Module

The Model-Based Diagnostic (MBD) module has twomain components: themodel builderand themodel-


Figure 4. A partial decision tree used in the example.

based diagnoser. Given a description of the physicalsystem, (e.g., system schematics and design documentsthat describe the functions of the components of thesystem and their interconnections) the model builderassists the expert in developing equation models of thephysical systems that can be used effectively for diag-nosis. Based on the model of the system, the diagnos-tic engine isolates faulty components using an iterativesequence of candidate generation and testing, and mea-surement selection.

5.2.1. Equation Model of the Pre-Cooler System.The model builder assists the human expert in devel-oping the model of a physical system as a set of outputequations that relate measurable parameters to param-eters that are directly linked to individual components.The diagnosis algorithm uses the output equations tohypothesize and refine fault candidates. Since the mod-eling process is not the focus of this paper (it is dis-cussed in detail elsewhere [7, 9]), we start with theoutput equations for the pneumatic system. It is impor-tant to note that the diagnosis algorithm is independentof the modeling scheme used to create the equations. Itworks with output equations that are either generatedby the model builder [7] or provided by human experts[8].

For the pre-cooler system shown in Figs. 2and 3, the following two sets of output equationare generated for output parameters Tho (Eqs. (1)through (6)) and Pho (Eqs. (7) and (8)), the output

temperature and pressure of the bleed air at the load,respectively.

Tho = Thi − Ch(Thi − Tci)

(v

l− l

Cc Rc D

)(1)

D = CcCh R2p

l2

v2+ cRp

Rh Rcl

× (Cc Rc(Rh + Rp)+ Ch Rh(Rc + Rp))

+ R2p

Rc Rh(Rc + Rh + Rp) (2)

Cc = V cρ = 1t Fccρ = l

vFccρ (3)

Fc =√

P3

C3(Xmax− X) (4)

X = A

k(Pro − Rs Fs)E (5)

E = E f + Ec(Tset− RcsQr ) (6)

Pho = Pin

(1− Rp

Rp + C3xh

)(7)

Xh = Xset− A2(Pin − Rpt fpt)E p

K p(8)

Parameters in the above equations are listed in the tablebelow.


Parameter Their meaning in the Pneumatic System

Thi Initial temperatures of the hot air

Tci Initial temperatures of the cold air

V Velocity of the hot air flow

L Length of the path the air masses traverse in thepre-cooler

Rc Resistance of the pipe line from the cold air sourceto heat exchanger

Rh Resistance of the pine line from the hot air sourceto heat exchanger

V Volume of the cold air in the heat exchanger unit

ρ Density of the air

C Unit thermal capacitor of the air

Fc Flow rate of the cold air

Rs Resistance of the sense line to liquid flow

Rp Heat flow resistance of the heat exchanger

E f Effort transfer ratio of the valve controller

Ec Effort transfer ratio of the controller

Rcs Heat flow resistance of the control sensor

K Spring constant of the cold air valve

Xmax Maximum length of opening of the cold air valve

P3 Pressure difference over the cold air valve

C3 Cold air valve constant

Tset Desired temperature

Pro Pressure of the flow from the pressure regulatorsubsystem

A Area of the opening of the sense line

Pin Input pressure of the flow to the pneumatic system

Xset Default opening of the pressure regulator

A2 Area of the opening of the pipe to the pressureregulator

Rpt Liquid flow resistance of the pipe line from the hotair source to the

Fpt Liquid flow constant

E p Effort transfer ratio of the feedback controller

K p Spring constant of the pressure regulator valve

For diagnosis purposes, parameters of a system aredivided into four categories:

1. Output parameters—measurable parameters at theoutput of the system being diagnosed, such as Tho

andPho.2. Input parameters—they model upstream subsys-

tems that are not the focus of diagnostic scrutiny.Examples arePin, Thi, andTci.

3. Component parameters—parameters that are di-rectly linked to the functionality of individual

components in the system. For example,Rp rep-resent the resistance of the heat exchanger toheat flow. Other component parameters include:Rs, E f , k, Rs, Ec, Rcs, kp, andRpt. The set of com-ponent parameters defines the set of possible singlefault hypotheses that are considered for diagnosticanalysis.

4. Co-component parameters—intermediate parame-ters that combine equations from different subsys-tems and domains to establish direct links betweenoutput parameters to component parameters. Forexample,Cc represents the thermal capacitance ofthe heat exchanger. This parameter helps to connectthe thermal and fluid parts of the system. They canbe derived from component parameters and othersystem variables (e.g., see Eq. (3)), and, therefore,are not included as possible fault hypotheses. Otherco-component parameters include:D, Fc, X, E, P,andXh . Note that a single equation can be generatedfor each output parameter by repeatedly substitutingco-component parameters. However, this often pro-duces complicated forms that result in less efficientanalysis by our automated algorithm.

5. Constants—domain and system parameters whosevalue do not change within the subsystem, such asthe density of the airρ and the cold air valve (spring)constantC3.

5.2.2. Model-Based Diagnosis.Given the set of mea-surements made on the system and the system descrip-tion which include parameter definitions and the cur-rent set of output equations, the diagnostic algorithmis summarized as follows:

Repeat until one candidate is confirmed or all can-didates are eliminated{1. Generate partial explanations, one for each new

measurement.2. Generate/update candidate set using best first

search.3. Perform test(s) selected using a decision theo-

retic scheme.

}The diagnosis algorithm is based on the assumptions:

(a) the system was operating in steady-state, (b) themeasurement sampling rate is high enough to catchdeviations soon after they manifest, and (c) the faults donot cause catastrophic changes in the system. Diagnosisis initiated when observed system behavior deviatesfrom a steady state. Again, the pneumatic system is


used to illustrate the process. Details of step 1 and 2can be found in [8].

Step 1. Generatepartial explanationsby perform-ing qualitative causal analysis on the set of outputequations. For each output parameter and a new mea-surement, first determine the sign of PDC(Pk,Wi(+|−))(Possible Direction of Change of Pk caused by changein Wi) for all output parameter Pk and component pa-rameter Wi pairs by computing the partial derivative

∂pk

∂wi= ∂pk

∂s1

∂s1

∂s2· · · ∂sn−1

∂sn

∂sn

∂wi

where s1, s2, . . . , si are co-component parameters thatlink Pk to Wi. For example, the relation between Rs,and Tho can be determined using Eqs. (1)–(5):

∂Tho

∂Rs= ∂Tho

∂Cc

∂Cc

∂Fc

∂Fc

∂X

∂X

∂Rs

=(−Ch(Thi − Chi)

l

C2c Rc D

)•(

l

vcρ

)

•(−√

P3

C3

)•(− A

KFs E

)Since the qualitative values of variables A, k, E,Fs,Cc,Rc, c, ρ,D, `,Ch,C3,P3 and v are all knownto be+ and our steady-state assumption implies thatThi−Tci > 0 (i.e., the initial temperature difference be-tween hot and cold air may fluctuate but is always pos-itive), the partial derivative evaluates to−, therefore,PDC(Tho,Rs+) is −, and PDC(Tho,Rs−) is +. Next,partial explanations for each measurable parameter isgenerated based on whether it is normal (within 2% ofthe normal value), above-normal (+), or below-normal(−), as described below:

• For each deviant output parameter Y, form a propo-sition formula: X1(+|−) ∨X2(+|−) ∨ · · · ∨Xn(+|−),where Xi(+|−)’s are changes in the component pa-rameters Xi ’s that are consistent with the observeddeviation of Y, i.e., PDC(Y,Xi(+|−)) is equal to thedeviation in Y. In our example, suppose the observeddeviation for Tho is+, the following partial explana-tion for Tho+ would be generated:

F(Tho+) = Rp+ ∨ Ef+ ∨ K− ∨ Rs− ∨ Ec ∨ Rcs− .

Notice that, based on previously established valueof PDC(Tho,Rs−) (+) and PDC(Tho,Rs+) (−) Rs−

is included in the formula while Rs+ is not. In other

words, only a decrease in the resistance of the senseline is consistent with the observed above-normaltemperature value. Further more, although Rs− isincluded in the explanation, the low probability as-sociated with the event (decreased resistance) willresult in it being dropped from the candidate list forfurther analysis.• For each measurement Y that is reported to be nor-

mal, form a proposition formula:

(¬X1 ∧ ¬X2 ∧ . . . ∧ ¬Xn)

∨(X1(+|−) ∧ X2(+|−)) ∨ (X2(+|−) ∧ X3(+|−)

) ∨ . . .∨(Xn−1(+|−) ∧ Xn(+|−)

)Each pair of (Xi,Xj) is included if their influence onY are complementary (i.e., if PDC(Y,Xi(+|−)) is+,then PDC(Y,Xj(+|−)) is−, and vice versa). This for-mula suggests that the Xi ’s are either all normal orat least two of them are deviant and their combinedeffect on Y is null. In our example, assuming the out-put parameter Pho is normal, the following formulawill be generated:

F(Pho) = (¬Kp ∧ ¬Rp ∧ ¬Ep ∧ ¬Rpt)

∨(Kp+ ∧ Ep+) ∨ (Kp− ∧ Ep−) ∨ . . .

Note that each¬Xi implies both¬Xi+ and¬Xi−.

Step 2. Generate and update the candidate setbasedon the current set of partial explanations. Our systemuses a best-first search algorithm that generates candi-dates in order of their prior probabilities until either (i)the number of candidates reaches a preset threshold k1,or (ii) the prior probability of the best candidate is k2

times greater than the prior probability of the last can-didate. (Both k1 and k2 are predetermined constantsand are set at 25 in the current system.) The follow-ing table shows the prior probabilities of failure of thecomponents in the pneumatic system:

Ef+ Ef− Ec+ Kc− Kp+ Kp− K+ K− Rp+

0.2 0.1 0.18 0.01 0.15 0.18 0.15 0.15 0.2

Ep+ Ep− Rpt+ Rpt− Rcs+ Rcs− Rs+ Rs− Rp−

0.1 0.2 0.2 0.01 0.1 0.05 0.2 0.001 0.001

For each component parameter, two probability valuesare used, one indicating the likelihood of its increas-ing, the other indicating the possibility of its decreas-ing. This use of prior probabilities allows the system


to take into account that components are more likelyto fail in one direction than the other. For example, theresistance of a pipe used for fluid transfer may increaseover time but almost never decreases. In our example,given thatTho is above normal and all other measur-able parameters are normal, the following candidatesare generated:

Cand = ((Ef+), (Ec+), (K−), (Rcs−), (Rp+ , Rpt+),

(Rp− , Ep−), (Kp+ , Rp+), (Kp− , Rpt+),

(Kp− , Ep−), (Ep+ , Rpt+), (Ep+ , Kp+))

Notice thatRs− (the resistance of the sense line usedfor fluid transfer is decreasing) is not included in theinitial set even though it is consistent with the currentobservation because its extremely low probability.

Step 3. Perform measurement selection based on theestablished relationship between measurable parame-ters and individual components (i.e., the sets of outputequations) using an information-theoretic method sim-ilar to the one used in GDE [12]. For each possiblemeasurementOi , we calculate1 He(Oi ) to evaluatethe expected changes in the entropy of the system ifthe measurementOi is made, using the formula:

1He(Oi) =m∑

k=1

p(Oi = Vik) log p(Oi = Vik)

+p(Ui ) log p(Ui )− np(Ui )

mlog

p(Ui )

m.

In the above formula, each Vik (1≤ k≤m) is a possibleoutcome of measurement Oi,Ui is the set of candidatesthat do not predict a value for Oi. In the qualitativeframework, a measurement can take one of three val-ues: above-normal (+), normal (0), and below-normal(−). Give the current set of candidates C, the probabil-ity P(Oi = Vik) can be calculated using the formula:

P(Oi = Vik) =∑Cl∈C

p(Oi = Vik | Cl)p(Cl),

where p(Cl) is the current probability for the candidateCl. P(Oi = Vik | Cl) (the probability that parameter Oi

will have value Vik given that the candidate is Cl) can beeasily calculated using qualitative analysis on the equa-tions for Oi. When Vik is either+or−, P(Oi = Vik |Cl)has value l if Cl contains only components that are inthe corresponding partial explanation of Ol. It has value1/3 when C1 contains components in partial explana-tions for both Oi+ and Oi− . It has value 0 when Cl does

not contain any components in either of the partial ex-planations. When Vik is 0, P(Oi = Vik |Cl) has value 1if Cl does not contain any components in either of thetwo lists. It has value 0 when Cl only contains com-ponents in one of the partial explanations. It has value1/3 when Cl contains components in both partial ex-planations. For example, given the two possible partialexplanations for Pro+ and Pro− :

F(Pro+) = Kp+ ∨ Ep− ∨ Rpt+ ∨ Rp−

F(Pro−) = Kp− ∨ Ep+ ∨ Rpt−

Since Ep− is only in F(Pro+ ) and Kp− is only in F(Pro−),(Ep− ,Kp− ) supports, with equal probabily, Pro+ (withEp− ), Pro− (with Kp− ), Pro normal (using both Ep− andKp− ). Therefore, we obtain p(Pro = + | (Ep− ,Kp−)) =1/3. Similarly, p(Pro = + | Ecs−) = 0 because Ecs− isnot included in the partial explanations for Pro.

After 1He(Oi) is calculated for all the remainingpossible measurements Oi, the one with the smallest1He(Oi) value is selected. In our example, the follow-ing1He’s are computed:

Test Pvc Fc Vc Pro Phv Pprc Tcs Op

1He −0.909 −0.890 −0.727 −0.676 −0.457 −0.457 −0.362 −0.175

Based on this information,Pvc (The output power at thevalve controller) was chosen as the next measurement.The initial probability of a candidateCL is calculatedfrom the prior probability of its components using theformula:

p(Cl) =∏c∈Cl

p(c)∏c/∈Cl

(1− p(c)).

After each measurement, the probability of a candidateis updated using Bayes rule:

p(cl | Oi = Vik) = p(Oi = Vik |Cl)p(Cl)

P(Oi = Vik).

We do not compute p(Oi =Vik) because it is the samefor all candidates, and, therefore, would not affect theirrelative order. Continuing with our example, given thenew measurement Pvc, was recorded as being abovenormal, indicates that the fault is in the pre-cooler sub-system. As a result, the new candidate set isCand=((Ef+), (Ec+), (Rcs−)). By calculating1He, the sys-tem identified that the measurementVc (the voltagesignal sent by the controller) would provide the most


information.Vc was reported to be normal, and that leftEf+ as the only single candidate. However, the systemalso noticed that a double fault involvingRcs+ andEc+

could also explain the symptoms observed so far. As aresult, (Rcs+ , Ec+ ) was also generated as a candidate.A measurement atTcs was then suggested, and since itwas normal, the system concluded that the actual faultycomponent isEf (the valve controller).

6. The Diagnostic Controller

The diagnostic controller directs diagnostic activitieswithin the system and communicates information fromthe MBD module to the associational module wheneverthe associational module fails. This involves two pri-mary tasks: (i) controlling the interaction among thetwo modules to solve particular diagnosis problems,and (ii) updating and refining the associational modulefrom results derived from the MBD module when theassociational module is found to be incomplete or inerror. Specifically, the task of the diagnostic controllerincludes:

1. Diagnostic control: invoking the appropriatemodule at the appropriate time with the rightinformation,

2. Problem characterization: identifying and charac-terizing the problem in the associational modulewhen it produces an incorrect conclusion or failsto draw a conclusion, and

3. Knowledge base refinement: updating the knowl-edge base of the associational module dependingon the type of problem identified.

6.1. Diagnostic Control

A high level description of the overall control algorithmis shown below:

Step 1: Diagnose using the Associational Module;Step 2: If faulty components are found

Then{Invoke MBD module to verify theconclusion;If conclusion is verified, then done;Else{Diagnose using the MBD module;

Update the associational module;}}Step 3: Else{Invoke MBD module for further diagnosis;

Update the associational module;}

A diagnostic session begins with the associationalmodule, and terminates in one of the following

situations:

1. A confirmed candidate (single or multiple faults) isfound.

2. All the candidates generated initially are eliminated(or no candidate is generated at all).

3. More than one candidate still remains and cannotbe further discriminated.

In situation 1, the MBD module is invoked to ver-ify the conclusion, if it has not been verified before.This can often be done offline, especially in situationswhen the mechanic faces a busy schedule. If the con-clusion is found to be correct, the diagnostic sessionis completed, and the faulty component(s) is (are) re-ported. However, if the conclusion cannot be verifiedto be correct, the system resumes diagnosis in an at-tempt to derive the faulty components using the MBDmodule. If the MBD module is successful, the entirediagnostic record is then sent back to the diagnosticcontroller to further identify and characterize problemsin the associational module. Situations 2 and 3 can becaused by incomplete and/or inconsistent knowledgein the associational module. In both cases, the MBDmodule is invoked to perform diagnosis. As in situa-tion 1, the results from the MBD module are sent backto the diagnostic controller for problem identification.When control switches to the MBD module, diagnosisinformation from the associational module is transferto the MBD module. Specifically, this includes:

• Results of tests conducted in the associational mod-ule. They fall into one of the following categories: (i)those that directly establish the status of individualcomponents (working/faulty), (ii) those that can beinterpreted as directly measurable parameters (e.g.,pressure, temperature) on individual components inthe MBD module, and (iii) those that use heuris-tics to confirm or eliminate candidate components.In the MBD framework, tests in category (i) and (ii)are considered reliable, whereas test results in cate-gory (iii) are considered ad hoc, and therefore, notused to eliminate any candidates.• Partial diagnosis results derived by the associational

module. This occurs when the associational modulehas narrowed down the problem to a smaller set ofcandidates but could not derive more specific results.This information assists the MBD module in rank-ing the candidates during itscandidate generationphase.Specifically, candidates flagged by the asso-ciational module are given additional weights, while


candidates that were eliminated by ad hoc tests (cat-egory (iii)) will have their prior probabilities reducedfor this particular diagnosis.

6.2. Problem Characterization and KnowledgeBase Refinement

As discussed in the previous sections, knowledge inthe associational module is represented in two forms:(i) production rules of the form (LHS BF RHS BV),and (ii) the list of available tests.Problems in the asso-ciational knowledge base can be attributed to inconsis-tency, which can be classified into:

1. Incorrect test specifications: the implications of atest are incorrectly specified.

2. Incorrect rules: either the LHS or the RHS of a ruleis incorrect.

or incompleteness, similarly categorized as:

3. missing tests.4. missing rules.5. under-specified tests: possible conclusions are miss-

ing from the implications of a test.

A problem is identified when the associational mod-ule fails to reach a definite conclusion. Whenever thishappens, the diagnostic controller characterizes theproblem in terms of one of the five categories listedabove. This is based on a step-by-step comparison ofthe candidate sets at each step of the problem solv-ing process, the measurements made, tests conducted,and the final conclusions drawn. The characterizationprocess is summarized below:

Case (i): the associational module eliminated allcandidates.

• If the actual faulty component(s) identified by theMBD module were initially generated as candi-dates by the associational module and then elimi-nated, the problem isincorrect test specifications.The tests that caused this elimination can be identi-fied by comparing the two different candidate setsgenerated by the associational module at varioussteps.• If the candidates were never generated, then there

aremissing rulesin the knowledge base.

Case (ii): multiple candidate sets remain, but no furthertests are applicable.

• If the candidates that remain unverified are alsogenerated by MBD module, and were retained af-ter candidate testing, then identify the set of mea-surements that confirmed or eliminated them dur-ing the candidate discrimination phase. Check ifthese measurements were in the test list of theassociational module. If they are,under-specifiedtestsis the cause. Otherwise, the cause ismissingtests.• If these candidates were not generated by the MBD

module, or were initially generated but later dis-carded during candidate testing, the associationalmodule has generated spurious candidates fromthe initial symptoms. The rules that caused thegeneration of these candidates areincorrect rules.

Case (iii): the components declared faulty by the as-sociational module are verified to be normal by theMBD module. This can be looked upon as a com-bination of cases (i) and (ii) since the real compo-nent(s) was (were) not confirmed, and candidate(s)that should be eliminated remained. After the prob-lem is characterized, the next step is to update theknowledge base.

6.3. Knowledge Base Refinement

Knowledge acquisition and refinement are difficultproblems. Recently, many methods have been devel-oped for the verification and validation of existingknowledge bases (e.g., [24, 30]). Knowledge acqui-sition and refinement tools have been developed forgeneral applications (e.g., [31–33]), and particular ex-pert systems [34]. These tools often guide the user inmaking modifications to correct observed problems ina knowledge based system. Methods have also been de-veloped for automated knowledge acquisition that useinduction of decision trees (e.g., [35]), rule inductionmethods (e.g., [36]), and rough set theory (e.g., [37])to extract knowledge from databases.

As a step toward automating the knowledge base re-finement task, our current system focuses on improv-ing the completeness of an existing knowledge base byanalyzing diagnostic cases where the MBD mod-ule performed better than the associational module.Specifically, the diagnostic controller starts the re-finement process when the associational module failswith a problem that is later solved by the MBDmodule, indicating an incompleteness problem withinthe associational module. After characterization, the


diagnostic controller deals with each one of theincompleteness problems as follows:

1. Missing tests: When the problem of missing tests(or measurements) are identified, new tests need tobe added to the knowledge base. The effect of thesetests, in terms of the candidates they confirm or elim-inate, can be identified by comparing the two can-didate sets that the MBD module maintained beforeand after the tests were made. Information about thesubjective evaluative criteria for the tests as well ashow the tests should be presented are obtained fromdomain experts. Therefore, addition of the new testsinvolves the joint efforts by the system and the do-main expert.

2. Under-specified tests: When under-specified testsare found, these tests are updated automatically. Ef-fects of the tests on additional candidates are addedto the specifications of these tests. Again, these ef-fects can be found by comparing the different can-didate sets the MBD module generated during prob-lem solving. The evaluation information on tests re-main unchanged by default, but the domain expertmay change them on his own initiative.

3. Missing rules: When a missing rule situation oc-curs, new rules are added to the associational mod-ule. These rules link initial symptoms to candidatesthat were generated by the MBD module, but weremissing from the candidate set of the associationalmodule.

Inconsistent rules and tests are reported to the ex-perts, along with detailed descriptions of the exactproblem encountered by the system. For each incor-rect test specification, the diagnostic controller reportsthe name of the test, the candidates it had incorrectlyconfirmed or eliminated, and the test results that arerelated to it. As for incorrect rules, the diagnostic con-troller reports the rule number and the candidates it hadincorrectly included in its RHS. In both cases, the bur-den of actually correcting the knowledge base is placedon the domain experts.

6.4. Example

We illustrate the working of the overall diagnosis sys-tem with an example. Consider the pneumatic systemwith a malfunctioningcontroller. The initial symptomsreported were: output temperatureToutabove normal,input temperatureTin, input pressurePin, and output

pressurePoutnormal. Since the problem appears to bein the temperature regulation part, the diagnosis sys-tem focus was on the pre-cooler subsystem. The as-sociational module was invoked first, and it generatedfive candidates: (i)sense line, (ii) heat exchanger, (iii)valve controller, (iv) valve, and (v)control sensor cir-cuit wire. Note that thecontroller was not listed; weare probably dealing with an incomplete associationalmodule. The system generated thepartial decision tree(the leaf nodes are exclosed in<>): (Fig. 4).

The user can choose tests from the tree, or followhis or her intuitions. In this case, the user followed thetree and reported the following test results: (i)sensorcircuit—the resistance difference between the controlsensor circuit and the indicating sensor circuit was lessthen 10 ohms, (ii)valve circuit(this include the valveand the valve controller) was found to be operatingnormally, (iii) sense line—no leakage or blockage de-tected, and (iv)heat exchanger(a child node ofsenseline in the initial decision tree and was not shown in thepartial tree)—tested to be normal. Given these results,the associational module eliminated all candidates. Atthis point, the MBD module was invoked to continuethe diagnosis. Test results were transferred to the MBDmodule with the following implication: (i) thesenseline andheat exchangerwere considered normal sincethey were tested directly, (ii) the correctness of the re-sistance of the sensor circuit was interpreted as an indi-cation that the temperature from the control sensor (Ts)is normal since the temperature reading is a function ofthe resistance, and (iii) thevalve circuittest checks thecurrent at Pin 49 of the circuit and considers the circuitok when it is properly grounded. However, this inter-pretation by the associational module was consideredad hoc. Consequently, components of the valve circuitwere not eliminated. However, the test did indicate thatboth thevalveandvalve controllerwould be less likelycandidates than what its prior probability indicated.Given this information, the MBD module generatedthree candidates:{controller}, {valve-controller} and{valve}, with the{controller} ranked as the most likelycandidate. It then suggested that the voltage signalVCsent to thevalve controllerbe measured. Since theoutput temperature is higher than normal, this voltageshould be below normal. When that measurement didnot concur with expectations, the MBD module con-cluded that the controller was actually the faulty com-ponent, which was later confirmed by the mechanics.

At this point, the diagnostic controller took overagain to initiate the knowledge refinement process.


Since the faulty component was not generated initiallyas a candidate by the associational module, amissingrule situation was identified, and the diagnostic con-troller added the following temporary rule to the asso-ciational knowledge base:

(|rule200| ((((system)(pneumatic))((templight) (off))((stagelight) (normal)) ((pneutemp) (high))((pneupressure) (normal)) ((pressurelight) (off))((sensorcircuit) (<10)) ((valvecircuit) (normal))((senseline) (normal)) ((heatexchanger) (normal))((valve controller valtage) (low)) 0.5)

((((hyp) (controller))) 0.1)))

Notice that the belief value of the new rule is assigneda small initial value, which will be increased each timethe same conclusion is derived for a similar case. Suf-ficient number of occurrences of the same fault willcause the belief value to eventually exceed the thresh-old (currently set at 0.4) and allows the new rule tobecome permanent. The missing testVc was also re-ported and the appropriate information about the testwas requested from the domain experts.

6.5. Implementation

The Associational module is implemented in CommonLisp and C, and runs on Unix-based workstations. Thecurrent knowledge base contains about 130 rules and30 tests for troubleshooting the pneumatic system ofthe DC-10 aircraft. Rules and tests can be entered intothe system using theKB Editor that was extended fromtheRule Editorused in the MIDST system. (MIDST isan expert system shell used for geological exploration.Details about MIDST system can be found in [29]. AGraphical User Interface that displays partial decisiontrees, tests information, and conclusion(s) has also beenimplemented. This software runs in parallel with the in-ference mechanism of the associational module, and isimplemented in C using X-Windows. A model builderhas been implemented in X-Windows and C with asimple graphics and menu-based interface. It providesusers with tools for creating equation models of phys-ical systems [7, 9]. Models created can be stored assubsystems (e.g., the pre-cooler or the pneumatic sys-tem) or as mechanisms. The MBD Module and the Di-agnostic Controller were both implemented in C usingX-Windows. The MBD module also calls subroutinesfrom Mathematica to perform symbolic manipulationand calculate partial derivatives in order to generatepartial explanations.

7. Discussion and Conclusions

In this paper, we have discussed the design and imple-mentation of MDS, an integrated diagnosis system thatcombines associational and model-based approaches

to diagnosis. The design and implementation of theassociational module is tailored towards achievingefficiency in routine diagnostic problem solving andsatisfying the needs of the users that the system was de-veloped for (i.e., aircraft mechanics). The MBD mod-ule is developed to achieve completeness and consis-tency in performing diagnosis on complex systems andto avoid the brittleness that often occurs in associa-tional approaches, especially when dealing with un-usual and novel faults. It employs qualitative causalanalysis of the system equations. By analyzing theeffects of changes in component parameters on a par-ticular output parameter and comparing the resultswith the observed deviation of the output parameter,our method can effectively eliminate a large numberof candidates during the initial candidate generationphase and produce a more focused result. Coupled withthis, we use information theory-based methods (e.g., deKleer and Williams [12]) to compute the informationgain for each possible additional measurement, and,therefore, are able to focus the measurement selectiontask for further refinement of candidate components.

An important issue addressed in our integrated diag-nosis framework is how to use the “deeper” knowledgefrom system models to improve the completeness andconsistency of the “shallow” (or associational) knowl-edge base. Our hybrid scheme develops a methodol-ogy for automated knowledge refinement. The MBDmodule is used to identify incompleteness and incon-sistencies in the associational module, and, through thediagnostic controller, perform knowledge refinement toupdate the associational knowledge base.

There are similarities as well as differences betweenMDS and other existing integrated approaches to diag-nosis (e.g., [21, 25–28, 38]). Major differences include:(i) the type of individual modules used [25, 26, 38], (ii)how the modules interact [21], and (iii) the amount and


type of information exchange among the modules [27,39]. Perhaps our system is most similar to the systemsby Portinale [27] and Someren [39]. In all three sys-tems, the associational component is designed and usedto “speed up” the diagnostic process and the Model-Based Reasoning (MBR) module is used for complete-ness. However, the MBR components in their systemare not used to help improve its associational compo-nent (in their case, a case-based reasoning module) asour system does. Our knowledge acquisition methodalso differs from many existing approaches. Instead ofderiving new knowledge and rules from databases us-ing induction methods [35–37], our approach extractsknowledge from the model-based subsystem by analyz-ing new diagnostic cases, either automatically (whennew rules are added), or semi-automatically (when itguides the human expert to modify existing rules andtests). Currently, we are working on the premise thatthe existing model-based diagnosis module is accurateand complete. For complex systems, this may not al-ways be the case. In the future, we will be looking intodeveloping techniques where unusual diagnostic casesmay be employed to refine both model-based and asso-ciational modules. Updating of the system model willnecessarily be performed with the help of human ex-perts.

Notes

1. Our original target users are the mechanics at Federal ExpressCorporation.

2. The TAFI manual is a troubleshooting manual for DC-10 aircraft,developed by McDonnell Douglas Corporation.

3. Users are not restricted to perform only the tests that appear onthe decision tree. They may choose to make additional and/oralternative tests and report results that they consider relevant.

References

1. R. Davis and W.C. Hamscher, “Model-based reasoning: Trou-bleshooting,” inExploring Artificial Intelligence: Survey Talksfrom the National Conferences on AI, edited by H.E. Shrobe,Morgan Kaufmann: San Mateo, CA, pp. 297–346, 1988.

2. R. Davis, “Form and content in model based reasoning,” inPro-ceedings of Workshop on Model Based Reasoning, IJCAI-89,Detroit, MI, 1989, pp. 11–33.

3. T. Bylander and B. Chandrasekaran, “Generic tasks forknowledge-based reasoning: The ‘right’ level of abstraction forknowledge acquisition,”International Journal of Man-MachineStudies, vol. 26, pp. 231–243, 1987.

4. B. Falkenhainer and K. Forbus, “Compositional modeling: Find-ing the right model for the job,”AI Journal, vol. 51, pp. 95–143,1991.

5. J. deKleer, “Focusing on probable diagnoses,” inProceedings ofthe 9th AAAI, 1991, pp. 842–848.

6. S. Weiss, C. Kulikowsi, and A. Safir, “A model-based consul-tation system for the long-term management of glaucoma,” inProceedings of the 5th IJCAI, 1977, pp. 826–832.

7. G. Biswas and X. Yu, “A formal modeling scheme for contin-uous systems: Focus on diagnosis,” inProceedings of IJCAI,Chambery, France, 1993, pp. 1474–1479.

8. G. Biswas, R. Kapadia, and X.W. Yu, “Combined qualitative-quantitative steady state diagnosis of continuous-valued sys-tems,” IEEE Transactions on Systems, Man, and Cybernetics,vol. 27, no. 2, March 1997.

9. X.W. Yu, “Multi-level reasoning and diagnosis,” Ph.D. Disser-tation, Computer Science Department, Vanderbilt University,December, 1992.

10. E.H. Shortliffe, Computer-based Medical Consultations:MYCIN, Elsevier/North Holland, New York, 1976.

11. Y. Peng and J.A. Reggia, “Plausibility of diagnostic hypothesis:The nature of simplicity,”AAAI-86, 1986, pp. 140–145.

12. J. de Kleer and B.C. Williams, “Diagnosing multiple faults,”Artificial Intelligence, vol. 32, pp. 97–130, 1987.

13. D. Dvorak and B. Kuipers, “Model-based monitoring of dynamicsystems,” inProceedings of 11th IJCAI, 1989, pp. 1238–1243.

14. P. Struss and O. Dressler, “Physical negation: Integrating faultmodels into the general diagnostic engine,” inProceedings ofIJCAI-89, Detroit, MI, 1989, pp. 1318–1323.

15. M. Gallanti, M. Roncato, R. Stefanini, and G. Tornielli, “A diag-nostic algorithm based on models at different levels of abstrac-tion,” in Proceedings of 11th IJCAI, 1989, pp. 1350–1355.

16. F. Lackinger and W. Nejdl, “Diamon: A model-based trou-bleshooter based on qualitative reasoning,”IEEE Expert, vol. 8,no. 1, pp. 33–40, 1993.

17. L. Palowitch, “Fault diagnosis of process plants using causalmodels,” Ph.D. Thesis, Massachussets Inst. of Technology, 1996.

18. B.J. Glass, W.K. Erickson, and K.J. Swanson, “TEXSYS: Alarge-scale demonstration of model-based real-time control of aspace stations subsystem,” inProceedings of the Seventh Con-ference on Artificial Intelligence Applications, 1991, pp. 378–384.

19. P. Dague, O. Raiman, and P. Deves, “Troubleshooting: Whenmodeling is the difficulty,” inProceedings of 6th National Con-ference on Artificial Intelligence, Seattle, WA, August, 1987, pp.600–605.

20. P.J. Mosterman and G. Biswas, “Diagnosis of continuous valuedsystems in transient operating regions,”IEEE Transactions onSystems, Man, and Cybernetics, vol. 29, no. 6, pp. 554–565,1999.

21. P.K. Fink and J.C. Lusth, “Expert systems and diagnostic ex-pertise in the mechanical and electrical domains,”IEEE Trans.on Systems, Man, and Cybernetics, vol. SMC-17, pp. 340–349,1987.

22. R. Canton, F. Pipitone, W. Lander, and M. Marrone, “Model-based probabilistic reasoning for electronics troubleshooting,”in Proceedings of 8th IJCAI, 1983, pp. 207–211.

23. R.S. Patil, “Causal representation of patient illness for elec-trolyte and acid-based diagnosis,” Technical Report, no. 267,Massachussetts Institute of Technology, Laboratory for Com-puter Science, Cambridge, MA, 1981.

24. G.W. Rosenwald and C. Liu, “Rule-based system validationthrough automatic identification of equivalence classes,”IEEE


Transaction on Knowledge and Data Engineering, vol. 9, no. 1,pp. 24–31, 1997.

25. Y. Huang and R. Miles, “Using case-based techniques to en-hance constraint satisfaction problem solving,”Applied Arti-ficial Intelligence, an International Journal, vol. 10, no. 4,1996.

26. R.C. Rosenberg and D.C. Karnopp,Introduction to PhysicalSystem Dynamics, McGraw-Hill, New York, 1983.

27. L. Portinale and P. Torasso, “ADAPtER: An integrated diagno-stic system combining case-based and abductive reasoning,”Topics in Case Based Reasoning, Proceedings of the First Inter-national Conference on Case-Based Reasoning, 1995, pp. 277–288.

28. M.H. Sqalli and E.C. Feuder, “Diagnosing interoperability prob-lems by enhancing constraint satisfaction with case-based rea-soning,”Ninth International Work on Principles of Diagnosis,1998, pp. 266–273.

29. G. Biswas and T.S. Anand, “Using the Dempster Shafer schemein a mixed-initiative expert system shell,” inUncertainty in Arti-ficial Intelligence, edited by L. Kand, T.S. Levitt, and J. Lenamer,Elsevier Science, New York, pp. 223–239, 1989.

30. G. Guida and G. Mauri, “Evaluatiing performance and quality ofknowledge-based systems: Foundation and methodology,”IEEETransaction on Knowledge and Data Engineering, vol. 5, no. 2,pp. 204–224, 1993.

31. S. Craw and R. Boswell, “Representing problem-solving forknowledge refinement,” inProceedings of the Sixteenth NationalConference on Artificial Intelligence Eleventh Innovative Appli-cations of AI Conference, 1999.

32. D. Ourston and R.J. Mooney, “Theory refinement combininganalytical and empirical methods,”Artificial Intelligence, vol.66, pp. 273–309, 1994.

33. M. Tallis and Y. Gil, “Designing scripts to guide users in modify-ing knowledge-based systems,” inProceedings of the SixteenthNational Conference on Artificial Intelligence Eleventh Innova-tive Applications of AI Conference, 1999.

34. P.M. Murphy and M.J. Pazzani, “Revision of production systemrule-bases,”Machine Learning: Proceedings of the 11th Inter-national Conference, 1994, pp. 199–207.

35. J.R. Quinlan,C4.5—Programs for Machine Learning, MorganKaufmann: CA, 1993.

36. R.S. Michalski, I. Mozetic, J. Hong, and N. Lavrac, “Multi-purpose incremental learning system AQ15 and its testing ap-plication to three medical domains,” inProceedings of the FifthNational Conference on Artificial Intelligence, 1986, pp. 1041–1045.

37. S. Tsumoto and H. Tanaka, “Automated discovery of medicalexpert system rules from clinical database on rough sets,” inProceedings of conference on Data mining Applications, 1997,pp. 63–69.

38. C. Tudorie, C. Segal, and E. Pecheanu, “Human operator obser-vations elicitation in a hybrid (neuro-symbolical) Diagnosis,” inProceedings of the Ninth International Workshop on Principlesof Diagnosis, 1998, pp. 282–285.

39. M. Someren, J. Surma, and P. Torasso, “A utility-based approachto learning in a mixed case-based and model-based architecture,”in Proceedings of the Second International Conference on CaseBased Reasoning, 1997.

mds: an integrated architecture for associational and model-based diagnosis

Documents