Control and Integration of Diverse Knowledge in a Diagnostic Expert System

ABSTRACT

Though current expert system technology has become a major success, existing expert systems often fall short of human expertise in many ways. One important area is in the use of more basic, deep knowledge as an enhancement to the shallow, surface knowledge commonly employed. The Integrat­ ed Diagnostic Model attempts to exploit the use of both types of knowledge by fitting the appropriate knowledge representation and utilization techniques to each. The result is two separate and indepen­ dent expert systems which are then integrated and controlled by a higher-level module called the exe­ cutor.

CONTROL AND INTEGRATION OF DIVERSE KNOWLEDGE

IN A DIAGNOSTIC EXPERT SYSTEM

Pamela K. Fink

Southwest Research Institute 6220 Culebra Rd. San Antonio, Texas 78284

have deeper knowledge [1,2,3,4,5,7,8,12,13,15). There are recognized benefits in being able to pro ­ vide a deeper understanding of the problem, such as better performance at the periphery of the knowledge base and improved explanation capabili­ ties. However, shallow knowledge must also be available for solving the more common problems and for situations where human understanding of the domain is not extensive· enough to include a deeper model. Therefore, it would be best for an expert system to integrate at least these two often diverse types of knowledge and be able to use them appropriately and efficiently.

I INTRODUCTION

In solving a problem, human experts often draw on many different kinds of knowledge. What usually makes an expert an expert is the "shallow" [6), "surface" [11), "compiled" [1), "low-road" [9), 11 em­ pirical"[2), or "experiential" [4) knowledge. Such knowledge is acquired from other experts in the field or by first-hand experience in solving domain problems. It consists of rules-of-thumb that con­ nect characteristics of a problem with its possible solutions. However, this type of knowledge is often just a short-cut through, or a compilation of, a more detailed and deeper understanding of the problem domain. This other kind of knowledge, re­ ferred to as "deep", "high-road", "functional", or "physical" knowledge, allows an expert to "reason from first principles" in trying to solve a partic­

ularly difficult or unfamiliar problem.

The human expert has no apparent difficulty in converting from one kind of knowledge to another. He/she may begin solving a problem by using the ex­ periential knowledge which leads to an isolation of the problem and then convert to using the deeper knowledge to analyze the problem further. If the initial hunch proves to be wrong upon closer exami­ nation, the expert easily goes back to employing the more shallow, experiential knowledge. Should all experience fail, he/she can still revert back to the deeper knowledge in attempting to solve the problem.

Though current expert system technology relies heavily on shallow knowledge in solving a problem,

some work has been done in developing systems that The Integrated Diagnostic Model (IDM) [4), shown in Figure 1, is an expert system that con­ tains both a shallow and a deep knowledge base. It was designed to work in the area of mechanical/electronic diagnosis and repair. It consists of three main modules: 1) the experien­ tial expert, 2) the physical expert, and 3) the executor. Knowledge representation and utilization techniques have been developed to fit the two diverse types of knowledge in these spec ialized mechanical/electronic diagnostic experts. In addi­ tion, the higher level control module, the execu­ tor, has been designed to direct the entire problem solving process.

II KNOWLEDGE REPRESENTATION IN THE IDM

Each of the three parts of the IDM has its own knowledge base. The knowledge representation tech­ niques used in the experiential and physical ex­ perts attempt to depict the type of knowledge that each embodies. The knowledge base in the executor provides a link between the two.

The experiential expert contains a knowledge base implemented as a three-level semantic network where each level is a semantic network in its own right. Its general structure is shown in Figure 2 and resembles that of Casnet [15]. This structure attempts to model some of the initial experiential, causal reasoning that an expert does while solving a familiar problem. The lowest level in the seman ­ tic network, the 'information' level, contains any concrete, observable facts that can be obtained from the user. This could be information on how tight the generator belt is, a voltage measurement

in an electronic circuit, or the stain of an organ­ ism in a lab culture. The middle level, the hy-

....

potheses' level, contains knowledge that is not ob­ servably apparent but that can be deduced from the observable facts based upon experience. It usually concerns physical or physiological states of the device. Examples of this type of knowledge are that the generator is not recharging the battery, that a wire is shorted in the circuit board, or that the patient is suffering from an infection of pseudomonas bacteria. The 'solutions' level in the semantic network contains knowledge about how to fix the deduced problem. Thus, it would suggest tightening the generator belt, repairing the wire, or placing the patient on a drug therapy of colis­ tin.

The physical expert contains a physical/functional model of the device under diag­ nosis . This model is based on a set of functional primitives that allows the device under considera­ tion to be simulated qualitatively [8]. Examples of such primitives are:

1. transformer

an object which converts given substances into others; examples are: a generator converting mechanical energy into electricity (mechanics), a solar cell converting photons into electrici­ ty (electronics), the collection of enzymes that converts glycogen into carbon dioxide and water (physiology).

1. regulator

an object which controls the activity of anoth­ er object, usually as a function of the regulator's inputs; examples are: a turbo­ charger increasing the amount of fuel in the cylinder based upon the pressure of exhaust gasses (mechanics), a transistor controlling the current flow as a function of the base current (electronics), white blood cells regu­ lating the amount of foreign objects in the blood stream (physiology).

3) reservoir an object which stores a substance for release at a later time; examples are: a spring stor­ ing mechanical energy (mechanics), a capacitor storing a charge (electronics), mitochondria storing chemical energy in a cell (physiology).

4) conduit

• an object which transports various substances throughout the system; examples are: a piston transferring thrust from a cylinder to the camshaft (mechanics), a wire transporting elec­ tricity (electronics), arteries carrying oxygen to cells (physiology).
• joint

an object which provides a connection between two or more of the other primitives; examples are: the meshing of gears (mechanics), the wire nut that connects two wires (electronics), the synapse between neurons in the brain (phy­ siology).

These primitives are implemented using a semantic network. The first three are represented by frame-like [10] nodes while the last two are represented by arcs.

This set of primitives is by no means com­ plete. For example, it was necessary in the electrical domain to divide 'regulator' into 'switch' and 'relay' because their behavior differ­ ences were important in representing how a circuit functions. Such a set provides an integrated way of representing the structure and behavior of a device. Both physical and functional aspects can be represented within this one model. Depending on the substance, such as electricity or water, that is being transported from node to node via the con­ duits and joints, an electrical, mechanical, etc. representation can be provided.

The system knowledge base for the executor consists of a conversion table that indicates what node or nodes in the experiential knowledge base are associated with what functional primitive nodes or arcs in the physical knowledge base and how they are related. The conversion table is essentially a set of registers that represent the nodes i n the experiential knowledge base and the functional primitive nodes and arcs in the physical knowledge base. These registers contain values that indica te the state of the system's knowledge about that part of the problem. Each register is also associated with a conversion equation or equations that tell how to convert the information in a register or re­ gisters associated with one knowledge base into in­ formation in a register or registers associated with the other knowledge base. The correspondence between registers associated with the two knowledge bases is not necessarily one -to -one, but could be many-to-one, one-to"111any, or many-to"111any.

III CONTROL IN THE IDM

Each of the three modules of the IDM has its own control mechanism. The inference engi11es of the two experts were designed to best take advan­ tage of the knowledge available to each. Since the two types of knowledge have independent knowledge representations and inference engines, they create completely autonomous expert systems. These two expert systems are then i·ltegrated by the control mechanism of the executor.

The inference engine for the experiential ex­ pert is model~riven using a best-first search strategy. Initial data is acquired at the informa­ tion level ·which then suggests hypotheses to con ­ sider. The hypotheses may then suggest more data that needs to be acquired from the information lev­ el. On each arc there is a set of ratings, includ­ ing probability, cost, and difficulty, that are combined to form a confidence factor for the asso­ ciation between the two nodes that the arc con­ nects. The highest factor is followed first. The search back and forth between hypotheses and infor­ mation continues until a hypothesis has been veri­ fied with enough confidence. Then the arcs between the hypotheses and solutions are followed. Should the solution fail to solve the problem, others can be tried or the search for another cause of the problem can continue.

The inference engine for the physical expert uses some very general diagnostic reasoning rules to examine the physical model and isolate the prob­ lem to a specific functional unit or units, represented by the appropriate functional primi­ tive. These rules are based upon the values of the inputs and outputs of the functional units. They are:

1. If an output of a functional unit is unknown, ask the user.
2. If an output from a functional unit appears in­ correct, check its input.
3. If an input to a functional unit appears in­ correct, check the source of the input.
4. If the input of a functional unit appears to be correct, but the output is not, assume that something is wrong with the functional unit be­ ing examined.

This resembles the "discrepancy detection" metho­ dology discussed by Davis [2]. Once the problem has been isolated, more specific analysis can proceed in the same manner at a lower level, since the knowledge representation can be hierarchical.

The control at the executor level determines when each expert system is to be used. It also controls the transfer of information about the state of parts of the device under diagnosis between the expert systems and directs the interac­ tion between the system and the user.

Currently, top level control over which expert to use when is very simplistic. The experiential expert is run first and if it fails to find a solu­ tion to the problem, the physical expert is run. This appears to be how an expert would reason about a problem, checking out all reasonable, familiar possibilities first, before resorting to a more basic "first principles" analysis.

A human, however, can use the knowledge gained during the experiential phase to help in the more detailed analysis. At the same time, knowledge ac­ quired while doing a detailed analysis is not lost to the human expert when he/she goes back to the experiential type of reasoning. An expert system should be able to do the same. Thus, while the ex ­ periential expert is running, all information gained is passed to the executor for conversion to a form useful to the physical expert, when ap­ propriate. In this way the physical expert can monitor the progress and make certain inferences about the state of the device that is not available to the experiential expert. Through this mechan­ ism, it acquires all of the information that the experiential expert acquires, thus allowing it t o begin diagnosis where the experiential expert leaves off, should the need arise. By this same mechanism it can communicate inferences it makes back to the experiential expert. These capabili­ ties will be demonstrated by an example in the next section.

The executor controls communication of i nfor­ mation between the user and the two expert systems. Any request for information needed by one of the expert systems is given to the executor which then determines whether the information is already known by the other expert system, or whether to ask the user. If the information is already available from the other expert system, the executor simply re­ turns the information in the proper form to the re­ questing expert system. Otherwise it asks the user. Should the user request an explanation at any point in the dialogue, the executor determines which expert should answer it. Currently, only "how" and "why" are legal questions. The answer t o "how" is associated with the node that resulted i n the last output to the user. The answer to "why" is currently always answered by the physical expert since the experiential expert could only offer a very shallow explanation.

IV AN EXAMPLE

To illustrate how the system works, a simple heating system will be used as au example. The ex­ periential and physical knowledge bases are shown in Figures 3 and 4, respectively. During a ses­ sion, the physical representation appears in the top two-thirds of the screen to graphically portray the progression of the problem solution. The bot­ tom third contains the dialogue.

Suppose that the user enters the initial prob­ lem that the house is too cold. The experiential expert begins by checking out the possibility that the heating system is disabled in some way. This is chosen first because it is very inexpensive and easy to check and it is necessary to know if the heating system is even set to be on. This leads to questions to the user concerning the state of the thermostat and, when it is established that the thermostat is on, set correctly, and working, a re­ gister in the executor associated with the ex­ periential knowledge base is set to indicate that the thermostat is alright. This information is useful to the physical expert in a different form. Thus, a conversion takes place that sets registers associated with the power supply, the coil, and the contacts to correct. This causes the nodes on the display screen representing these units to turn dark, giving some indication to the user of the progress being made. This part of the example demonstrates how the system handles a many to many conversion of information. There is no such unit as a thermostat with all of its settings in the physical knowledge base, just as there is no power supply, coil, or contacts in the experiential knowledge base.

The experiential analysis continues by check­ ing the blower and then the furnace itself. The first thing that the experiential expert wants to know under the hypothesis that the furnace is not producing enough heat is if the pilot light is on. If the answer to this question is yes, a register associated with the pilot light of the experiential knowledge base is set, which triggers a conversion to set a register associated with the pilot light of the physical knowledge base. In this case, the conversion is one -to -QUe and therefore straightfor­ ward. However, the physical expert can assume from this information that the liquid propane gas (lpg) tank has gas in it (at least as a first cut)J that the lpg tank valve is working, and that all of the conduits from the lgp tank to the pilot light are alright. The fact that the lpg tank is not empty again triggers a conversion to set the register for the lpg tank of the experiential system. Like the previous conversion, it is one -to -QUe and therefore straightforward. However, this i nformation proves to be useful to the experiential expert because the next question it would ask is if the lpg tank is empty. Rather than asking the user an apparently redundant question, the experiential expert can ac­ quire the information through the registers in the executor. I n this way, the IDM is capable of pro­ pagating knowledge acquired by one expert to the other expert, thus avoiding asking possibly dumb or repetitive questions.

Now suppose for this simple example, that the problem is with the lpg intake valve being stuck shut. The experiential expert will therefore ex­ haust all of its possibilities, since it knows nothing of the lpg intake valve, and the physical expert's knowledge base would appear as in Figure 5. Only the pilot light sensor, the safety switch, the lpg intake valve, the combustion chamber, and various conduits remain to be checked. These are parts of the system that the experiential expert knows nothing about.

The physical expert takes over diagnosis by systematically checking each of the nodes in the system to determine its input and output. It be­ gins with the initial problem itself, the house be­ ing cold, which is represented by the conduit between the vent and the coil. It moves backwards from the vent to the blower and finally to the combustion chamber using the rules discussed above to guide the search. The physical expert knows that its output is not correct since the air coming out of the vents is not warm, so it looks for the source of the combustion chamber's input, which is the pilot light and the lpg intake valve. The pi­ lot light is known to be alright but the lpg intake valve's state is unknown. The system therefore asks the user to check the valve. This is found to be stuck shut. Once the valve is loosened the fur­ nace begins working properly.

In this last sequence, where the physical ex­ pert finally diagnoses the problem, we have demon­ strated how a problem was found and solved that could not have been solved by the experiential ex­ pert because it lacked the proper knowledge. I n such a simple example, of course, it would be pos­ sible to include such knowledge in the experiential expert. However, in a larger system, such as the automotive electrical system that we are implement­ ing, the inclusion of every detail of the wiring diagram would be very difficult and diagnosing from it would not be straightforward in the experiential expert. It knows about such things as the battery, the generator, the fan belt, and certain prominent wire connections, but more detailed information on the components and wiring is left to a more coherent and useful representation in the physical expert.

V RELATED WORK

Over the past several years much work has been done in addressing the problem of employing more fundamental knowledge in an expert sys tem [1,2,3,5,7,8,12,13,15). However, most are con ­ cerned only with this deeper knowledge. Work by Patil et al. [12) is probably the most closely re­ lated to the work presented here because it is also concerned with integrating different level s of knowledge. In their work on ABEL, i n the domain of diagnosing and treating electrolyte and acid-base disturbances, Patil et al. demonstrate how three different levels of knowledge representing the patient's state can be used to diagnose and treat the problem. It differs from our model not onl y i n the number of levels of knowledge used but i n how closely these levels are linked. In ABEL, the lev­ els are designed to be compatible and consistent. The lower levels contain a more detailed version of the higher levels. Knowledge at one level can be passed consistently to another through a set of special functions. The IDM, on the other hand, does not necessarily require a consistent view of the problem between the experiential and the physi­ cal experts. Each expert is developed independent­ ly and integrated at completion. The experiential knowledge employed in the IDM resembles that used in the higher levels of ABEL. IDM's experiential knowledge is, in some cases, causal since the line between experiential and causal knowledge is some­ what indistinct. But the deeper knowledge employed in the IDM is more closely related to the device under diagnosis than is ABEL's. The physical ex­ pert of the IDM contains knowledge of the com­ ponents of the device and how they behave and in­ teract. Cause and effect is thus propagated via the physical and functional structure of the device rather than directly represented as in ABEL.

VI CONCLUSIONS AND FUTURE WORK

The IDM works well in the that it was designed mechanical/electronic diagnosis types of domains for, namely and repair. It even appears applicable to the medical domain, to debugging computer programs, and to failure modes and effects analysis of off-shore oil drilling platform!; (using a different set of functional primitives), However, it does not appear applica­ ble to such fields as mineral prospecting, speech recognition, and law. The experiential expert is most likely still viable, but the deep knowledge in these domains seems to require a different approach to representation than a set of functional primi­ tives. The concept of processes [14] may be one possibility.

The IDM exhibits a way of providing a well­ defined but flexible control over the propagation of knowledge between the different experts that em­ body the diverse types of knowledge about a problem domain. Future work will include efforts to gen­ eralize the approach so that the conversion table in the executor can be automatically generated from the knowledge bases of the experiential and physi­ cal experts. Currently it is built by hand. We also plan to examine different top -level control strategies with respect to when to use each of the experts . This is an extremely difficult but impor­ tant problem since it involves the question of how a human knows when to use each type of knowledge. Another area for research could be in identifying other types of deep knowledge that appropriately fit other domains such as the ones mentioned above. Finally, the use of several different kinds of deep knowledge that represent different aspects of the same device, such as electronic and mechanical, could be investigated.