Expert systems. Diagnosing the cause of problem AAS data

%stems Diagnosing the Cause ‘or Sharbari Lahiri and Martin J. Stillman Department of Chemistry University of Western Ontario London, Ontario, Canada N6A 5B

Expert system technology is an essential new tool for the analytical chemist. In the future, expert systems will play an important role in developing new methods and procedures, i n enhancing productivity, and in maintaining complex quality assurance programs. However, today the most important roles carried out by these systems in the analytical laboratory a r e i n d a t a analysis, method development, and fault diagnosis. In this A/C INTERFACE we describe the design and implementation of a n expert system used to diagnose problems that arise during analysis by atomic absorption spectrometry (AAS). We have designed a multimodule expert system named AAexpert (Figure 1) to demonstrate how a single analytical problem is solved by a series of interacting expert systems. AAdiagnosis is one module in this large program. Its design and implementation illustrate how an inductive shell is used to code heuristic information that describes the symptoms and causes of problems frequently encountered during metal determinations.

Expert system basics Although computers can perform knowledge - intensive tasks according 0003- 2700/92/0364 -283&$02.50/0 0 1992 American Chemical Society

to the decision-making logic of conventional programs, it is difficult to encode heuristic human knowledge into procedural programs consisting of algorithms and databases. The algorithm determines how best to solve a specific kind of problem; the database characterizes the parameters of the problem a t hand. However, human expertise does not fit this model. Expert system techniques have been developed t h a t can apply human knowledge to solve more complex problems-those for which human experts are in short supply and for which the domain of expertise is well focused. An expert system is defined as a reasoning system that uses a knowledge base to capture and replicate the problem - solving ability of human experts (1).The basic components of a n expert system (Figure 2) involve quite different design specifications.

that each module addresses a single, limited domain of expertise within the overall domain of analysis by flame AAS (Figure 1). Individual modules include method selection (AAmethods), sample solution handling and measurement (AAcontrol), and diagnosis of errors resulting from instrument malfunction and interfering sample chemistry (AAdiagnosis). These three examples each involve different applications of expert system technology-database access, real-time control, and rule-based programming, respectively.

The domain knowledge is a database that contains the facts and rules of the problem domain as described by the human expert. The inference engine solves problems and can deduce results based on user input and information contained in the knowledge base. The user interface channels information between t h e inference engine and the expert system user. AAexpert h a s been designed so

chemical laboratory have been writ ten in procedural languages. For example, the expert system for organic synthesis (SYNLMA), with a theorem prover as its inference engine, is based on PASCAL routines (2). In expert systems, separation of the knowledge base from both the inference engine and the user interface allows t h e knowledge base to be maintained and even expanded without changing the control structure

Conventional versus expert system programming Although it is possible to construct a n expert system in a conventional language such as PASCAL or C, subsequent development and expansion of the knowledge base are difficult. Several expert systems used in the

ANALYTICAL CHEMISTRY, VOL. 64, NO. 4, FEBRUARY 15,1992

283 A

(3). Settle and Pleva recently discussed the expert system development tools available to a chemist (4). Using shells can greatly reduce the task of developing a new expert system. An expert system shell contains an inference engine and various interface and knowledge acquisition aids but lacks the rules and facts contained in the knowledge base (3, 5). A good example of an expert system shell is the selection of HPLC conditions for pharmaceutical analysis ( 6 ) . The structure and components of a n expert system shell are shown in Figure 3. Applications of expert systems to analytical chemistry include diagnosing the cause of chemical problems from a list of symptoms, interp r e t i n g spectroscopic d a t a t o determine a possible chemical structure, planning an analysis scheme, and teaching operators and technicians how to use equipment correctly. Specific examples include structural interpretation using NMR (7), mass (81, and IR (9, 10) spectro-

scopies as well as method development in chromatography (11, 12). One of the best understood rulebased expert systems is the program for the interpretation of IR spectra (PAIRS) by Woodruff and Smith (13). Today many expert systems are written using declarative languages such as PROLOG (14, 15). There are limitations when expert systems are developed based on the input of expert knowledge i n t h e form of rules. PIRExS, written in PROLOG, is designed to predict inorganic reactions using both rules and a database of facts (16).

Inference strategies Inference strategies in an expert system a r e based on either forward chaining o r backward chaining. In a forward chaining system, data are placed in the dynamic database and the inference engine reports on any conclusions it can make by taking the ifpart of an g . . then rule and inferring that the then part of the rule is true. The if part of the rule is the

subject, and the then part is the predicate of the rule. A forward chaining systdm is said to be data driven. In a backward chaining system, the inference e n g i n e works backwards through the conclusions, trying to determine whether the subject of a rule is true for a particular goal. Backward chaining systems are said to be goal driven ( 1 ) . The forward or backward chaining system can be combined with either a depth-first or a breadth-first search. Depth-first searches require a search through all levels of a decision tree branch until a conclusion or a contradiction is reached. In a depth-first search, the inference engine continues to pass from level to level based on a single affirmative answer. However, if the system gets stuck along a path on which there is no solution, it will never reach a conclusion because the search strategy involves follow ing that path as far as possible from level to level and not across each level. I t is possible to combine a depth-first search with other heuristic methods for choosing which path to explore and which rules to use to solve subgoals. Breadth-first searches require a thorough search of all branches at each level, followed by a new search of the next level of positive responses only. This process is repeated until a conclusion i s reached. T h u s t h e breadth-first search is a complete strategy: If the problem posed by the user has a solution within the know-

Figure 1. Structure of AAexpert.

Figure 2. Structure of an exper system.

AAexpert provides interactive assistance to the analyst during the determination of metal concentrations by flame AAS. The flow of information or the movement of sample is illustrated by the arrows.

The double- headed arrows represent the exchange of information between the modules.

284 A

9


ledge base, a breadth-first search will find it (17, 18).A significant advantage of the breadth-first search is that the user can be given a summary of related rules that led to a particular conclusion. This strategy allows the user to select alternative conclusions based on data not available to the inference engine.

Automated analysis using AAex pert The AAexpert development project is part of a large, multicomponent expert system named ACexpert, which is concerned with all aspects of instrumental analysis (17, 19). ACexpert acts as an adviser in selecting appropriate analytical procedures. The system is subdivided into a set of individual expert systems designed to perform specific tasks. On receipt of the sample, the manager consults with both the customer and the regulatory agency to determine the criteria to be used in the analysis. AAassurance is the expert system used by the manager and the analyst to execute the laboratory quality assurance program. The analyst’s role is to supervise the expert system. AAanalyst is the process and quality control expert system. AAanalyst will complete the required analyses using the AAmethods module for method selection, AAcontrol for process control, and Mdiagnosis for diagnosing faults associated with instrument operation and data acquisition. (AAteach is the instruction expert system that tells a novice how to operate the instrument. AAanalysis carries out quality control, AAreport provides LIMS access, and AAtrends provides database trending of past analyses.) Building AAdiagnosis AAdiagnosis solves instrumental and chemical problems associated with flame AAS. At this point we will begin to describe how chemical information may be coded to form a set of rules that delineate a narrow domain of expertise. In our method, chemical knowledge, in the form of case histories (i.e., cause and effect), is encoded at three different levels. At the primary level, symptoms are associated with a specific single cause. At the secondary level, logical relationships are established between symptoms and causes that were not initially related at the primary level. The tertiary level handles situations i n which one cause can give rise to more t h a n one possible combination of symptoms. A series of interconnect ing rules are generated from the sec-

Knowledge acquisition interface

Figure 3. An expert system shell contains four structural elements that are necessary for the development of a functional expert system. The knowledge acquisition interface is used to develop the knowledge base that contains information in the form of facts and rules that describe the knowledge domain of a particular problem. The inference engine verifies the logic of the rules within the knowledge base and then uses these rules to draw conclusions based on input from users through the user interface or directly from instruments through the instrument interface. The explanation system helps the user understand the reasoning involved in reaching a particular conclusion.

ondary level of knowledge. Encoding chemical knowledge at three levels provides a robust technique that is generally applicable to encoding chemical knowledge for use in any other advisory expert system. As with other expert systems, development and delivery of the AAexpert system proceeded through the stages of problem determination, prototype design, testing, and delivery of the completed system.

Choosing the building tool In the design of a diagnostic expert system, the developer may choose a software system that requires expert knowledge to be entered in the form of rules or case histories. The software system chosen by our group requires knowledge to be encoded in the form of conditions and case conclusions (essentially case histories). The conditions may be thought of as symptoms of a problem, and the conclusions can be related to the likely causes. We chose the expert system shell KDS 3 (KDS Corp., 934 Hunter Rd., Wilmette, IL 60091) as the shell within which our expert system was developed. KDS 3 is a n inductive expert system shell comprising development and run time components. The development component allows information to be entered in the form of case histories broken down into conditions and conclusions. The run time component permits the distribution of a

compiled version to users. KDS 3 builds its knowledge base in the sequence of facts to rules to knowledge. This approach may be contrasted with subjective systems that evolve as rules to knowledge. Facts are generally objective, whereas explicitly entered rules are subjective, because they consist of the opinions of one or more people. It is often difficult to input logically correct rules in a knowledge base that requires chemical information to be entered in the form of rules. Compilation of the facts in the KDS 3 knowledge base results i n conditional if: . . then rules. Other capabilities of the KDS 3 shell include the following: The problem - solving skill of the program increases at a rate proportional to the enlargement of the knowledge base; solutions to a wide range of complex problems are possible by using the inductive nature of the fact matrix and the deductive nature of the rules, combining the results in appropriate ways; and conclusions are explained by retracing the lines of reasoning. The first condition entered into the shell is called the watershed condition or symptom. I t is very important that the user find this symptom easy to understand with no uncertainty. The watershed symptom must be able to divide the causes identified by the developer into major categories. We have chosen “the relative standard deviations (RSDs) of the

ANALYTICAL CHEMISTRY, VOL. 64, NO. 4, FEBRUARY 15, 1992

285 A

Rule 3: If the calibration curve is sigmoidal (true),then there is a change in abs sensitivity between recalibration (true). Rule 4: If the pressure in the cylinder is e 70 psi (true), then abnormally noisy

absorbance signal (true). Rule 5: If the pressure in the cylinder IS en drift in the baseline

tube (true),then the RSDs of the measurements are high (> 5%) and the absorbance values are not precise (true). Rule 7: If bubbles form the capillary tube (true), then abnormally noisy absorbance signal (true).

.

Rule 9: If bubbles form in the capillary tube (true),then there is a change in absorbance sensitivity between recalibration (true). Rule 10: If display of lamp intensity fluctuates while optimizing lamp (true),then there is a change in absorbance sensi-

(true).

measurements are high (> 5%) and the absorbance values are not precise” as our watershed condition. When the watershed condition is entered, the system requires the developer to specify a cause or case conclusion t h a t could be true when the watershed condition was true. Next, the developer specifies a conclusion that could be true when the watershed condition was false. Knowledge is added when the developer adds a new cause followed by a symptom to discriminate between the existing causes and the new cause. This technique of encoding knowledge in the form of case histories enables the analyst to develop the system on paper. The knowledge base of 286 A

symptoms and causes and the resultant rule base is general for all flame AAS analyses, and these data can be applied to other systems. In our approach we connect the instrumental setup conditions and sample chemical properties to t h e symptoms through logical relationships estab lished at’the primary and secondary levels of knowledge development. We therefore identify information to be provided by the user as symptoms, instrument conditions, and sample chemical properties that the inference engine will analyze to select the predicted cause of the problem.

Encoding chemical knowledge for AAdiagnosis Through experiments, a series of unique symptoms that degrade the quality of data have been identified. In some cases a symptom can be observed only under specific conditions. For example, when a sample is aspirated into the flame, the real-time signal from the photomultiplier tube exhibits a characteristic shape and noise when plotted as a function of elapsed time. Deviation from this signature can be used as a sensitive diagnostic tool (Figure 4). We have evaluated the symptoms reported earlier (19, 20) and have adjusted entries in the knowledge base to include additional symptoms associated with noisy data in flame AAS. The new work described here is a general method for relating symptoms of poor analytical data to causes. Figure 5 shows the logical relationship between symptoms (on the left) and causes (on the right) encoded a t the primary level of the knowledge base. Symptoms that describe poor analytical quality (symptoms 1, 2, 3, 8, and 10) relate to the numerical data obtained for more than one replicate, and these data can be assessed statistically. Symptoms 4-7 are not treated statistically because these data represent the detector signal recorded in real time as the sample enters the flame. Processing these data is essential in a totally automated system because these measurements replace input from an operator who can examine overall system performance based on visual and aural inputs during sample introduction. (The box lists some rules that assist the user in diagnosing problems associated with flame AAS analysis.) For an automated system to operate over a wide range of instrument conditions and sample types, the diagnostic expert system must be able to assess the overall performance of the instrument on a continuing ba-


ll

Figure 4. Examples of signals resulting in poor data. The data represent photomultiplier tube response versus time curves that are obtained when the sample is aspirated into the flame. (a) Abnormally noisy signal. (b) Pulsating signal. (c) Occasional pulse. (d) Decaying signal.

sis. We believe that comparison between archival copies of the realtime absorbance versus time signal and the current signal-time trace can be used to identify instrumental problems not normally detected from

I

e -

False

Figure 5. Logic development at the primary level relating symptoms with single causes. Abs is absorbance.


287 A

statistical analysis of the data. Figure 4 shows photomultiplier tube traces recorded under different con ditions. These traces represent (a) noisy data because of abnormally high photomultiplier dynode voltage, (b) a pulsating signal, (c) occasional spikes, and (d) a decaying signal. In each case, the quality of the resulting analytical data is poor.

Inference strategies in AAdiagnosis In use, the compiled form of the fact m a t r i x is evaluated inductively against the facts supplied by the analyst. Each time the system learns a fact from the analyst’s answer to a question, t h e e n t i r e r u l e s e t is searched, all the applicable rules are activated, and the best possible solution is offered to the analyst. AAdiagnosis uses either of two inference strategies. The first is forward chaining combined with a breadth-first search. The analyst’s response starts with the watershed condition. For example, the conclusion “burner slot is partially blocked” is reached based on symptoms provided by the analyst: RSDs of the measurements are high (> 5%) and the absorbance values are not precise (true). Abnormally noisy absorption signal (true). Absorbance values are 60430% of the expected values in the calibration graph (false). Baseline drift (false). The uptake rate is < 5 mL/min (false). Change in absorption sensitivity between recalibration (true). The other strategy i s analyst directed chaining with breadth-first search. With this technique the analyst can select the symptoms that most closely match t h e problem; therefore, the solution is offered after fewer responses. For example, the conclusion “burner slot is partially blocked” is reached based on the following input from the analyst: Abnormally noisy signal (true). The uptake rate is < 5 mL/min (false). .Absorbance values are 20-60% of the expected values in the calibration graph (true). The flame has a ragged appearance (true). Construction of the knowledge base The most important feature of any expert system is the construction of the knowledge base. The KDS 3 knowledge base is represented as the 288 A

logical connections between facts labeled as conditions and conclusions. At the primary level, a condition is added to the knowledge base to distinguish it from existing knowledge. Figure 5 shows the logical connections between conditions and case conclusio,ns a t this primary level. At the secondary level, conditions and case conclusions not related at the primary level are connected logically. Thus knowledge is represented in the form of a matrix of facts in which columns are represented by case conclusions and rows are represented by conditions. The knowledge in the matrix is said to be completely “filled” when the developer does not leave any condition unrelated to a conclusion. The secondary level of encoding knowledge is crucial in the functioning of a diagnostic expert system, because the knowledge is expanded by this step. Rules connecting symptoms that result from a single cause are produced only after compiling the

secondary level of knowledge. The final level of knowledge is added to the module when the developer encodes “parallel cases,” which occur when one cause can give rise to two sets of symptoms. Table I shows the knowledge matrix in AAdiagnosis. Unexpected results may arise because of the lack of a particular combination of symptoms at the tertiary level. In such instances, the user is expected to report the new case history to the developer, who will encode the information. The tertiary level of knowledge helps to create an expanded knowledge base that takes into account more case histories than are possible based only on the primary and secondary levels of knowledge. Steps for encoding chemical knowledge are shown in Figure 6. In a diagnostic expert system, the symptoms of the problem and the causes represent the chemical information. At the primary level, we encoded that the cause “improperly posi-

Abs value 60-80%

Figure 6. Logic development in AAdiagnosis. (a) Symptoms and causes are related at the primary, secondary, and tertiary levels. (b) The cause “sample contamination” is a “parallel case” in which the logic of the symptom “ragged flame” is different at the primary and the secondary levels because more than one set of symptoms may result from a single cause. (Adapted with permission from Reference 21 .)


hRSD Noisy abs signal Abs values 60-80% of expected result Baseline drift Abs sensitivity changes Lalibration graph levels off Abs values 20-60% of expected result Calibration graph sigmoidal Ragged flame Pulsating signal Bubbles in capillary Occasional pulse Decaying signal

absorbance is lost. This percentage must be determined for each instrument. Figure 6 also shows that the cause “burner slot blocked” gives rise to the symptom “absorbance values are 2060% of the expected values in the calibration graph.” The role of a user interface is very important in these expert systems. Graphical images help the user understand the symptoms described by the program developer, and they also are also crucial in resolving the ambiguity often associated with the symptoms related to problems encountered during analyses (see Figure 4). At the secondary level, the symptom “ragged flame” can result from a number of different causes. It is possible t h a t a n initially unrelated cause can give rise to a “ragged flame.” Thus “ragged flame” can result from a set of causes that includes a contaminant, which means that the connection between “ragged flame” and “contamination from previous samples” could be true. At the primary level it is not difficult to exhaust the problems associated with the analysis. The secondary level is based on the primary level. In addition to allowing different combinations of symptoms resulting from a particular cause, the tertiary level allows a true/false relationship to be entered between symptoms and causes treated as unrelated a t the secondary level. Figure 7 shows how, in general, chemical information can be encoded in any diagnostic system.

1, 2, 5-1 1, 13, 14, 16, 18, 23,35-45 2, 4, 8-1 1, 14, 16, 18, 19, 21,23, 29-37 40-45 2, 5-7, 9, 10, 12-14, 20, 23, 35-37,39 10, 16, 19, 22, 24, 24, 29-36 1, 3-17, 19, 24-28, 30-41 5, 6, 8, 12-14, 21, 35, 40,41, 45 3, 8, 11, 16, 17, 21,40, 41,45 15, 24-28,36 5, 6, 10, 11, 38-40 7, 10, 29, 30, 39 23,35-37 1, 5, 38 b

Instrument conditions Pressure < 70 psi Oxidizing flame

18,29-34 12, 21, 30, 31, 45

Intearation time too low

18,32.33,42-44

N,O-acetylene

22, 24

flame

Burner > 8 vertical scale No display-hollow cathode lamp on Fluctuating display

20 17,20 16, “‘2 27

Chemical conditions Viscous sample Uptake rate .= E mL/min Refractory element present

I 3, 14, 27, 28, 31, 32, 44 6, 8, 13, 14, 23, 25-28, 31, 32, 40, 41, 43, 44 12, 33, 34, 37, 41, 42

Rule generation in AAdiagnosis

Note. A knowledge ba

which each cell IS true, listed should be consid existence of parallel cas Key: 1. Sample contami pansion too high; 5. Co ing of sample and fuel, in spray chamber, 11. 14. Blockage in capillar ntegration time to

tioned glass bead” gives rise to the symptom “absorbance values are 6080% of the expected values in the calibration graph.” Also, the cause “contamination from previous samples” does not result in a decline of absorbance values. Next, we defined the symptom “ragged flame” resulting from the cause “burner slot blocked.” At the secondary level, a relation-

ship is established between “absorbance values are 6 0 4 0 % of the expected values in t h e calibration graph” and “burner slot blocked,” and “ragged flame” and “improperly positioned glass bead.” Both are false. We have determined that when a b u r n e r i s clearly a n d visibly blocked, analytical performance is degraded and more than 50% of the

The simplest rule - based languages are similar in expressive power to propositional logic (22). The inference engine of a forward chaining expert system uses a theorem from propositional logic called modus ponens, which states if we know that A implies B and we are given that A is true, we can conclude that B is true. Thus the inference engine repeatedly applies modus ponens to a set of rules to solve a particular problem (23). The rules in propositional logic can reason about the value of variables. These rules also allow confidence fac tors to be associated with the variables. Rules in conventional languages such as C, PASCAL, and the artificial intelligence language LISP are based on propositional logic. PROLOG and OPS5 express knowledge in predicate logic, where the facts can be more complex than in a propositional logic system. In addi-


289 A

Figure 7. Sequence of entering information in AAdiagnosis. This method can be used to generate any diagnostic expert system based on the case history approach.

tion to the connections of propositional logic, predicate logic has the ability to break down a rule into a predicate and a number of arguments. Predicate logic includes propositional logic; therefore, a predicate logic system can run rules from a propositional logic system (22). In contrast to conventional programming environments that support only the Boolean logic operations, expert system shells offer various models for performing logical operations with uncertain information. For example, the mineral-prospecting expert system PROSPECTOR uses the probabilistic model based on Bayes’ conditional probability theorem of combining evidence (24). MYCIN uses probability-like measures of certainty and reliability as well as a specialized inexact reasoning mechanism for inference (25). The KDS 3 shell handles uncertainty by providing the option of entering a “?’ when the end user has doubts about what the correct answer should be. The KDS 3 shell uses a proprietary uncertainty -resolving algorithm to provide logically reliable results. 290 A

The KDS 3 inference engine analyzes the fact matrix and generates a set of rules. Of the modes available with the system, we chose the conservative mode, and the types of rules generated by the system are If the subject is true, then the predicate is false; If the subject is true, then the predicate is true; and If the subject is false, then the predicate is false. A rule such as “if the subject is true then the predicate is false” is generated when the two symptoms, namely the subject and the predicate of the rule, are not associated with any common cause. For example, “if the absorbance values are 20-60% of the expected values in the calibration graph (true), then the signal is pulsating (false).” The causes associated with a pulsating signal, namely improper mixing of the sample or liquid buildup in the spray chamber, do not specifically result in absorbance Val ues that are 20-60% less than the expected values from the calibration graph.


A rule such a s “if the subject is true, then the predicate is true” is generated when the subject and the predicate of the rule are associated with the same set of causes. For example, “if the flame has a ragged appearance (true), then the RSDs are high (> 5%) and absorbance values are not precise (true).” Contamination in the spray chamber or burner slot, and/or precipitation or blockage in the capillary tube or nebulizer will give rise to a ragged flame and high RSDs from the absorbance values. Another example is that “if bubbles form in the capillary tube (true), then abnormally noisy signal is observed (true).” The presence of dissolved gases and/or the improper insertion of the capillary tube into the solution being aspirated will also give rise to an abnormally noisy absorption signal. In the conservative mode of rule generation, any symptom unrelated to every cause cannot be the subject of a rule. In this mode, a rule such as “if the subject is false, then the predicate is false’’ is generated having the same logic as “if the subject is true, then the predicate is true,” provided that the predicate of this rule is completely filled in for all cases. For example, “if the RSDs of the measurem e n t s a r e high (> 5%) a n d t h e absorbance values are not precise (false), then occasional pulsating of the signal is observed (false).” The above rule is the same as “if occasional pulsating of the signal is observed (true), then the RSDs of the measurements are high (> 5%) and the absorbance values are not precise (true).” This rule with “occasional pulsating of the signal” as the subject is not generated because this symptom is not related to the cause “N,O valve icing up.” In analytical chemistry, expert systems are used to interpret experimental results and provide users with guidance in method selection and instrumental operation (26). We believe that expert systems can be very productive tools in the analytical laboratory. Because of the cons t r a i n t s involved in adding new knowledge to an expert system based on conventional language, we used a n expert system shell to develop AAdiagnosis. We chose a rule-based shell t h a t requires t h e chemical knowledge to be encoded in the form of case histories. AAdiagnosis treats symptoms and related causes as data. The symptoms are universal and together with

the causes represent our experimental results. We have described three levels for encoding chemical knowledge: primary, secondary, and tertiary. The primary level of knowledge relates symptoms directly to causes; the secondary level relates symptoms to symptoms. The rules in Mdiagnosis, generated after compiling the secondary level of knowledge, relate symptoms. The tertiary level deals with situations in which one cause can give rise to more than one combination of symptoms. IVc gratefully acknowledge the continuing financial support of this work by the Ontario Ministry of the Environment and the Acadrmic Development Fund at UWO. We thank William H rowe t t . Zb i g n i e w G a sy n a . a n d Moh a m cd Moussa for thcir contributions to the earlier stages of this pro,jcct.

(19) Browett, W. R.; Cox, T. A.; Stillman,

M. J. In Expert System Applications in C h ~ m i s t r y ;Hohne, R . A.; Pierce, T. H., Eds.; American Chemical Society: Washington, DC, 1989; p. 210. ( 2 0 ) Lahiri, S.; Zhu, Q.; Stillman, M. J . Proceeditigs oftlie MOE Technology Traiisfer Coiifereme; Environment Ontario: Toronto, Ontario, Canada, 1990, p. 672. (21) Stillman, M. J.; Huang, G.; Lahiri, S.; Zhu, Q. In Expert System World Congress Proceedings; Liebowitz, J . J . , Ed.; I’ergamon Press: New York, 1991; p. 2645. ( 2 2 ) Leaman, C. M. AI Expert 1989, 4 ( 5 ) , 28. (23) Brown, D. E. AI Expert 1990,,5(2), 32. (24) Furse, G. In Expert System Principles

aird Cas? Stirdies; Forsyth, I

Expert systems. Diagnosing the cause of problem AAS data

Recommend Documents