CA1267223A - Method for obtaining information in an expert system - Google Patents

Abstract

ABSTRACT

A method for use in an expert system which selectively allows the system to avoid asking the user a question by providing the answer to that question based on related information that may have been previously attained in the system. The method involves providing an action attribute that can be attached to any node in the rule tree. The attribute is assigned to a node in the tree which provides an answer to a class question based on processing various other dependent nodes. When the answer is obtained, the action attribute then causes all other Dodes in she rule base referencing the same class question to be set to the same answer. The user is therefore only requested to supply information as a last resort.

Description

~T9^86-007 METHOD FOR OBTAINING INFORMATION IN AN EXPERT SYSTEM

Field of Invention:
This invention relates in general to methods for obtaining information in an expert system and, in particular, to an improved method in which answers to questions solicited from the user may be obtained indirectly from related information previously collected by the system.

RELATED_AP?LICATIONS:
10 U.S. Patent Mo. 4,209,219 issued on February 28, 1389, in the name of and entitled "Method for Dynamically Collecting Current Data for Use in an Expert System From Specified External Processes and Procedures," is directed to an expert system in which the rulebase is segmented to permit use in computing systems having limited memory capacity. CA Application Serial No.
507,393,entitled "Method for Dynamically Collecting Current Data for Use in an Expert System From Specified External Processes and Procedures," filed April 23,1986 and assigned to the assignee of the present invention is directed to a method of collecting 20 data in which an independent external process or procedure can be initiated under the control of the expert system and results specified and generated by the process or procedure are ret~rned to the expert system for use in concluding specific Goal nodes.

~5 Back~round Art:
Expert systems is a term applied to a special kind of problem solving computer program. The general function of expert systems is to solve (or assist in the solution of) problems normally addressed by highly trained and experienced human experts. This 30 is not a new goal; in fact, many successful computer programs have acbieved notable success in providin~ expert levels af performance ` ~n certain problem areas. What is different about expert system type programs is the approach taken, and the resulting form of the pro~ram itself.
35 Expert Svstems vs. Problem Solving_Svste~s As explained in th~ cross-referenced applications, the principal distinction between expert systems and traditional problem solving - programs is the way in which the prohlem related expertise is coded. In traditional applications, problem expertise is encoded 40 in both program and data structures. -In the expert system approach all of the problem related expertiseis encoded in data structures only. None is in programs. Several benefits immediately follow from this organization.

I r ~

` ' 7,~3 An example may help contrast the traditional problem solving program with the expert system approach. The example is the problem of tax advice. In the traditional approach data struc-tures describe the taxpayer and tax tables, ana a program in which there are statements representing an expert tax consultan~'s knowledge, surh as statements which relate information about the taxpayer to tax table choices. It is this representation of the tax expert's knowledge that is dificul~ for the tax expert to understand or modify.
In the expert system approach, the information about taxpayers and tax computations i~ again found in data structures, but now the knowledge describing the relationships between them is encoded in data struotures as well. The programs of an expert system are independent of the problem domain (taxes) and serve to process the data structures without regard to the nature of the problem area they describe. For example, there are programs to acquire the described data values through user interaction, progra~s to represent and process special organizations of de-scription, and programs to procPss the declarations that representsemantic relationships within the problem to~ain and an algorithm to control the processing sequence and focus.

The general architecture of an expert system involves two princi-pal components: a problem dependent set of data declarations called the knowledge base or Rulebase, and a problem independent (although highly data struct~re dependent~ program which i9 called the inference engine.

Individuals Involved wi E~e~3~ stems There are generally three individuals having an interaction wi~.h expert systems. Primary among these is the end-user; the individ-ual who uses the system fsr its probleM solving assistance. In the building and maintenance of the system there ar~ two other roles: the problem domain expsrt who builds the knowledge base, and a knowledge engineer who a~sists the exper~s in deter~ining the reprssentation of their knowledge and who defines the infer-ence technique required to obtain useful problem solving activity.

The End User The end-user usually sess an expert system through an interartive dialog, an example of which follows:

Q. Do you know to which restaurant you want to go?
A. No Q. Is thers any ~ind of food you wouId particularly like?
A. Unknown Q. Do you like spicy food?
A. No Q. Do you usually drink wine with meals?
A. Yes Q. When you drink wi~e, is it French wine?
A. ~hy As can be seen from this dialog, the system is leading the user through a set of questions, the purpose of which is to determine a suitable set o restaurants to r~com~end. This dialog begins ~ith the syst~m aqking if the user already krlows the r~staura~t choice (a common feature of expert systems) and immediately illustrates a characteristic of expert systems; users may choose not to respond to any ~uestion. In expert systems, dialogs are not pre-planned.
There is no fixed control structure. Dialogs are synthesized from the current information and the con~ents of the knowledge base.
Because of this, not being able ~o supply the answer to a particu-lar questions does not stop the consultation.

Another majur distinction bstween expert sys~ems and traditional systems is illustrated by the following answer given by the system when the user answers a question with the question "why," as occurred in the ~bove example. The answer is;

A. I am trying to determine the type of restaurant to su&gest. So far 5hinese is not a likely choice. It is possible that French is a likely choice. I know that if the . diner is a wine drinker, and the preferred wine is ~rench, then there i5 strong evidence that the restaurant choice should include French.

It is v~ry difficult to implement a general expl~nation system (answering questions like Why and How) in traditional systems. ~he response of the expert 5ystem to the question WHY is an ~xposure ~, .~. , , AT9-~6-007 of the underlying knowledge structure. It is a rule; a set of antecedent conditions which, if true, allow the assertion of a consequent. The rule references ~alues, and te~ts them against various constraints or asserts constraints onto them. $his, in fact, is a significant part of the knowledge structure. There are values, which may be associated with some organizing entity. For example, the individual diner is an entity with various attributes ~values) including whether they drink wine and the kind of wine.
10 There are also rules, which associate the currently known values of some attributes with assertions that can be made about other attributes. It is th~ orderly processing of these riles that dictates the dialog itself.

15 The Knowledge Engineer The knowledgs engineer is concerned with the representation chosen for the expert's knowledge declarations and with the inference engine used to process that knowled~e. There are several chara-20 ceeriStics known to be appropriate to a good inference technique.

l. A good inference technique is independent ofthe problem domain.

In order to realize the benefits of explanation, knowledge transparency, and re-usability of the programs in a new problem domain, the inference engine must contain domain specific expertise.

2. Inference techniques may be specific to a particular task9 such as diagnosis of hardware confi~uration. O~her techniques may be committed only to a particuIar processing ~echnique.

3. Inference techniques are always specific eo the knowledge structures.

4. Succes~ful examples of Rule processing techniques include:

(a) Forward chaining (b) Backward chalnin~

The .7~3 An understanding of the "Inference Rule" c~ncept is important to understand expert systems. An Inference Rule is a statement that has two parts~ an if-clause and a then-clause. An exampl of a~
Inferenc~ Rule is:

If the restaurant choice includes French, and the occasion is romantic, Then the restaurant choice is definitaly Paul Bocuse.

An expert system's Rulebase is made up of many such inference Rules. They are ente~ed as separate Rules and it is the inference engine that uses them to~ether to draw conclusions. Because each Rule is a unit, Rules may be deleted or added without affecting 15 other Rules (though it should affect which conclusions are reach-ed). One advantage of inference Rules over traditional p~ogramm-in~ is that inference Rules use reasoning which more closely resemble human ~easoning.

20 Thus, when a conclusion is draw~l, it is possible to understand how this conclusion was reached. Fur~hermore, because the expert system uses knowledge in a form similar to the expert, it may be easier to retrieve this information fro~ the expert~

25 ChaininR
There are two main methods of re~soning when usin~ inf2rence Rules: backward chaininR and forward chaini~.

Forward chaining starts with the data available and US8S the 30 inference Rules to conclude more data until a desired goal is reached. An inference engine using forward chaining searchss the inference RU1PS until it finds one in which the if-clause is known to be true. It then concludes the then-clause and adds this information to its data. It would continue to do this until a 35 goal is reached. Because the data available determines which in~erence Rules are used, ~his method is also called 'data driven.' ~ackward chaining starts with a list of ~oals and works backwards 40 to see if there is data which will allow it to c~nclude any of these goals. An infPrence engine using backward chaining would search the inference Rules until it finds on~ which has a then-clause that matches a desired ~oal. If the if-clause of that .~. , , ~:

inference Rule is not known to be true, then it i5 added to the list of goals. For example, suppose a Rulebase contains two Rules:

~1) If ~ritz is green then Fritz is a fro~.
(2) If Fritz is a frog then Fritz hops.

SuppGse a goal is to conelude that ~rit~ hops. The Rulebase would be searched and Rule (2) would be selected because its conclusion 10 (the then clause) matches the goal. It is not known that Fritz is a frog, so this 'lif" stàtement is added to the goal list. The Rulebase is again sea~ched and this time Rule (1) is selected because its then clause matches the new goal just added to the list. This time, the if-clause ~ritz is ~reen) is known to be 15 true and the goal that E~itz hops is concluded. Because the list of goals determines which Rules are selected and used, this method is called 'goal driven.' CDnfide=ces 2~ Another advantage of expert systems over traditional methods of programming is that they allow the use of Confidences. When a m hwman reasons he does not always conclude things with 100% confi-denc~. He might say, "If Frit~ is green, then he i5 probably a frog'i ~after all, he might be a chameleon); or, that Fritz's l~g z5 is broken, but not much). This type of reasoning can be imitated -by using numeric values called Confiden~es. Por example, if it is known that Fritz is green, it might be concluded with .85 Confi-dence that he is a frog; or, if it is known tha~ he is a frog, i~
might be concluded with .95 Confidence that he hops. These 30 numbers are similar in nature to probabilities, but they are not the same. They are m~ant ts imitate the Confidences humans use in reasoning rather th3n.~0 follow the mathematical definitions used in calculating probabilities.

35 The following general points about expert systems and their architecture ha~e be~n illustrated.

1. The sequence of steps taken to reach a conclusion is dynamically synthesized with each new case. It is n~t explicitly programmed when the system is built.

2. Expert systems can process multiple valuec for . : .
: .

ATg-86-007 ~2~ 3 any problem parameter. This permits more than Dne line of reasoning to be pursued and the ~esults of incom-plete (not fully determined) ~easoning to be presented.

3. Problem solving is accomplished by applying ~pecific knowledge rather than specific technique.
This is a key idea in expert systems technology. Xt reflects the belief that human experts do not process their ~nowledge differently from others, but they do possess di~f~ren~ knowledge. With this philosophy, when one finds that their expert system does not produce the desired results, work begins to e~pand the knowledge base, not to re-program the procedures.
The prior art has disclosed various expert systems in which a "Rulebase" and an "inferen~e engine" cooperate to si~ulate the ~asoning process that 3 hum~n expert pursues in analyzing a 20 problem and a~riving at a conclusion. In these prior art systems, in o~der to simulat~ the human reasoning process, 3 ~ast amount of knowledge needed to be stored in the knowledge base. Generally, the knowledge base of a prior a~t expert system c~nsisted of a relatively lar~e number of "if then" type of statements that were 25 int~rrelated in a manner that, in theory at least, resembled the equence of mental steps that were involved in the human reasoning process.

Because of the need ~or large stora~e capacities an~ ~elated 30 programs to store the Rulebaseg most e~pert systems ~ave, in ~he past, been run only on large infor~tion handling systems.
Recently, the storage capacity of personal computers has increased to a point where it is becom~ng possible to consider running some types of si~ple expert systems on personal computers. A number of 35 such prog~ams and the~r applicatlons are discussed in PC Maga71ne, dated April 16, 1985 beginning on page 108. Another ar~icle en~itled "Artificial Intelligence" appears on page 34 of PC World Magazine, Vol. 2 1~1, dat~d January 1984.

~ 4~ Additional publications of interest that describe Expert Systems ; of the type represented by the present invention include;

1. "A User's Manual for Construct and Consult in the GPSI
Environment" authored by Paul Ni~lsen, c~rrently available from the Univarsity of Illinois ~BPA Project.
.~

7~2~3 2. Gordon, Robert R., A Rule Editor for an Expert Sy~tem Environment : Towards Automating Xnowledge Acquisition. M.S.
Thesis, Vni~ersity of Illinois, Urbana, IL 1984.

3. Harandi, Mehdi T., A General Purpose System for Infer-encing, Proceedings of the IBM University Study Conference, Raleigh, NC, Oct. 1983.

4. Laursen, Andrew L., GPSI : An Expert System to Aid in Program Debugging, M.S. ~hesis, University of Illinois, Urbana, IL, 1981.

In some applications of expert systems, the nature of the ~ppli-cation and the amount of stored information necessary to simulate 15 the human reasoning process for thae applicatlon is just too vast to store in the active memory of a computer. In other applica-tions of expert systems, the nature of the application ls such that not all of the information is always needed in ~he reasoning process. ~n example of this latter type application would be the 20 use of an expert syster~ to diagnose a data processing system comprising many separate csmponents, some of which are optional.
When that type of expert system employs a single integrated RulebasP to diagnose the minimum system configuration of the data processing system, much of the Rulebase is not required since many 25 of th~ components which are optional units of the system will not be present in the system. Nevertheless, prior art expert systems require the entire Rulebase to be stored since all the Rules were, in effect, chained or linked together by the structure of the Rulebase.

The invention described in cross referenced U.S. Patent r,`~. 4~809~219 is directed to an expert system in which the Rulebase is segmented, preferably into contextual segments or units. When the Rulebase is segmented, it is then possible to eliminate portions 35 of the Rulebase containing data sr knowledge that is not needed in a particular application. The segmenting of the Rulebase also allous the ~xpert system to be run with systems or on systems having much smaller memory capacities than was possible with prior art arrangsments since each segmene of the Rulebase can bs paged 40 into and out of the system as need8d. The segmenting of the Rulebase into contextual se~ments requires that the expert system manage various intersegment relationship5 as segments are paged into and out of memory during ~xecution of the progr~m. Since the ' systam permits a Rulebase segment to be called and executed ~t a~y time during the processing of the first Bulebas~, provision must be made to store the data that has been accumulated up to that point so that at some time later in the process, when the system returns to the first segment, it ca~ proceed from the last point or RULE node that was processed. Also, pro~ision must be made so that data that has been collected by the system up to that point can be passed to thc second segment of the Rulebase after it has been paged into the system and data collected during the processing of the second segment can be passed to the first segment whPn the system returns to complete processing that segment.

The embodiment of the invention described in that application employs a segmented Rulebase that has been established for the ; primary purpose of diagnosing the faulty hardware operation of a data processing syste~ such as a personal computer. The overall objective of the system is therefore to identify a Field Xeplace-able Unit (FRU) that is ~ost p~obably the cause or source of the problem.
.
In $he second referenced application, the embodiment was substantially the same except that the system could perform a elf-diagnosis on its own hardware since it had the ability to initi~te external procedures or test units on specific components which, when concluded, would return the results to the expert system. Information was therefore collected by these systems by asking questions of the user or running so-called test units or external processes.
The User interface and the Procedure interface are two important fun tions in the information collection process of the systems describsd in the cross-referenced applications.
~ 35 The User Interface The function of the user interface i5 to present questions and information to the operator and supply the operator's responses to the Inference EngiDe.

Any values entered by the user must ~e received a~d interpreted by ~he user interface. Some responses are res~ricted to a set of possible legal answers, others are not. The user interface checks all responses to insure that they are of the correct data type.

Any responses that are resericted to a legal set of answers are compared against these legal answers. Whene~er the user enters an illegal answerr the user interface informs the user that his answer was invalid and prompts him to correct it. As explained in the cross-referenced application, communication betw~en the user interface and the Inference En8ine is performed through the use of a User Interface Control Block (UICB) which is passed between the two.

Procedure Node Interface The function of the Procedure node interface is to receive information from the Procedures coordinator and create the appropriate Procedure Call. The ability to call a Procedure and receive information from that Proredure can be viewed as simply a genesalization of input from the external world. While in some prior art expert systems external information has been obtained, that information was obtained only in a predetermined ~anner so only certain information could actually be acquired. This expert system, disclosed in the cross-referenced application, through ~he knowled~e base, is permitted to invoke any Procedure allowed on its host system. This makes the expert system useful in a much wider class of knowled~e domains than if it had no external access ~ or only limited external access.

; 25 In the area of machine diagnostics using expert systems, particularly self-diagnostic applications, it is not possible to conclude the current state of "health" of a machine witho~t som~
information. The best source of information is the machine itself, for it contains much detailed information that could not reasonably be provided by the operator.
;

As explained in the prior art, the knowled~e that is repsesented in the system appears in the Rulebase. In the Rulebase described in the cross-referenced applications, there are basically four different types of objects, with associated infor~ation present.
~.
-~ 1. Classes - these are questions asked to the user.

2. ~3E9~ 3~ ~ a Parameter is a place holder for a character string which may be a variable tha~
can be inserted into a Class question at the point in the question where the Parameter is positioned.

:: .
: . .:

~f72~2i3 3. Procedures - these are definitions of calls to external Procedures.

4~ e~e - The inferencing in the system is done by a tres strueture which indicates the Rules or logic which mimics human reasoning. The nodes of these trees are called RULE nodes. There are several different types of RULE nodes.

The Rulebase comprises a forest of many trees. The top node of the tree is called the Goal node, in that it contains the con-clusion. Each tree ~n the forest has a different Goal node. The leaves of the tree are also referred to as RULE nodes, or one of the types of RULE nodes. A leaf may be an EVIDENCE node, an EXTERNAL node, or a RE~ERENCE node.

An EVIDENCE node functions to obtain inform~tion from the operator by asking a specific question. In responding to a question presented by an ~VIDENCE node, the operator is generally instructed to answer "yes" or "no" represented by nu~eric values 1 and 0 or provide a value of between 0 and 1, represented by a "maybe."
,. ~
Questions which require a response fro~ the operator other than yes or no or a value between 0 and 1 are handled in a different manner.

A lea~ that is an EXTERNAL node indicates that data will be used which was obtained from a Procedu~e Call.
~ 30 '~ A REFERENCE node functions to refer to ano~her tree or subtre0.

A tree may also contain intermediate or minor nodes between the Goal node and the Leaf node. An intermediate ~ode can represent logical operations liks And or Or.

. The inference logic has two functions. It selects a tree to trace and then it traces that tree. Once a tree has been s~lected, that tree is traced, depth-first, left to right.

The word "tracing" refers to the action the system takes as it traverses the tree, asking Classes (questions), calling Pro-cedures, and calculating Confidences as it proceeds.

AT9-86-007 ~7 As explained in the cross-referenced applications, the selection of a tree depends on the ordering of the trees.~ The original ordering of the trees is the order in which they appear in the Rulebase. This order can be changed, however9 by assigning an EVIDENCE node an attribute "initial" which is described in detail in these applications. Th~ first action taken is to obtain values for all EVIDENCE nodes which have been assignad an "initial"
attribute. Using only the answers to these initial Evidences, the Rules are ordered so thae the most likely to succeed is evaluated first. The trees can be further re-ordered since they are constantly being updated as a selected tree is being traced.

It has been found that the type of information that is solicited by the sys~em from the user by means of questions or classes should be tailored to the level of knowledge of the user. In many applications, the group of prospective uses is nicely defined and the knowledge level can be estimated so that the questlons can be ~0 presented at a level which corresponds generally to the average user. However, in other applicationst knowledge of the specific domain of the expert system might vary considerably among the ~roup of prospective users.

One application where this is particularly true involves the use of an expert system, operating is a self-diagnostic mode on a personal computer to assist the operator of the personal computer to diagnose the cause of a fault or error in either ~he hardware or software. In general, asXing the opera~or for infor~ation is the most straightforward way for the expert system to gather informatio~ assumingt of course, that the information is or should be within the operator's understanding. For example, in dia nosing a per~onal computer, the expert system must know thP
major functional components of the system. I~ could ask the operator, for instance, if the display is a monochrome or color display. The operator should, in all probability, be able to proYïde the correc~ answsr 100~ of the time. The expert system could, on the other hand~ cause a test unit to be run to determine the type of display. The accuracy of the data collected by either approach in this instancæ probably would not be that different so the Xnowledge engineer could employ either approach without affectin~ the accuracy of the diagnosis. However, in m3ny instances, becausa of the na~ure of the information being solicitPd, it is better to obtain the information from the system rather than asking the operator, 72~

because the accuracy of the data supplied by the operator was so low that the system could not effectively process it to a meaningful conclusion.

It has been found in ac~ordanc~ with the present invention that in many situations the information is already in the system,in a form of which permits the correct answer to a question to be obtained through a process of induceive or deductive reasoning. The data previously collected by the system could be answers provided by the user to less complex questions that were asked for a different - reason or results returned from test units that were previously run.

~or example, in testing diskette drives there are certain tests which require that a scratch diskette be present i~ dis~tte drive A. These tests may cause data to be written to the diskette or the diskette to be reformatted. Data on the disket~e may be destroyed, so it is imperative that the diskette with the diagnostics routines not be insertet in drive A. Rather than relying on the usar to be sure that a scratch diskette is present, there are certain things that may indicate to the system that such is the case. If drive A is a low capacity diskette drive and a diskette is present, then the diskette must be a scratch diskette.
If the drive is a high capacity diskette drive, and the procedure, READ VOLUME_LABEL returns ~a nonzero return code, then the dlagnostic disk~ete is not in drive A, and a scratch diskette must be. In ~he case that the drive is hi~h capacity and READ VOLUME LABEL returns a zero return code, then the user must be told to insert a scratch diskette in A.

. ~ .
In the ~ulebase of the exp~rt system, action aetributes can be associated with any node. One of these actions, the SET action, indicates that if this node is evaluated to be true, then the answer to ~ specified questioD can be set to a specified value.
' 5 In this way, answers to questions can be obtained without directly asking the user the question. If the node with the action attribuee is invalidated, then the question specified in the action attribute will not be affected.

These SET a~tions ase equivalent to adding rules to the rulebase which would resemble the IF~o~TEEN rules as follows:

IP drive A i's low capacity ~
~ , ~7Z~3 AND there is a diskette present THEN the answer to "Is thPre a scratch diskette in A?" is "yes."

I~ driv~ A is high ~apacity AND the return code of ~EAD VOLUME LABEL is not 0 AND there is a diskette present THEN the answer to "Is there a scratch diskette in A?" is "yes."
It is therefore an ob~ect of the present invention to provide an improved method of collecting information in an expert cystem.

A further object of the present invention is to pro~idP an expert system in which prior to asking a question of the user, other ~vailable methods of determinin~ the answer by the system are ~onsidered.

A stall further objact of the present invention is to provide a method in which answers to questions can be set in accordance with the logical combination of data obtained from other Rule nodes in the system.

Objects and ~dvantages other than those mentioned above will be apparent from the following description when read in connection with the drawing.

Brief Dascriptlon_of the ~rawin~:
Fig. 1 illustrates the overall functional relationships of the components of an expert system in which the present invention is advantageously employed.
~ig. 2 illustra~es schematically, a sa~ple Rule ~ree.
Fig. 3 illustrates the data for a sample Rulebase.
Fig. 4 is ~ Rule tree constructed from the input data shown i~
~i~. 3.
Fig. 5 is another tree construc~ed for the input data shown in in Fig,. 3.
Fig. 6 ~llustrates the records of tha ~ajor linked lists.
Fig. 7 illustrates the general format of the variable field of the records shown in Fig. 6.
Fig. 8 illustrates the relationship of the link lists to tha , AT9-86-007 - ~ ~ r~f~

~ashtable structure.
Fig. 9 illustrates the relation of the Class lihked list, the member list, the Hashtable, and RULE nodes ~hat are members of the Class.
FiB. 10 illustrates the relation of the Procedure linked list, ~he Membership list of a Procedure object, the Hashtable and the RULE nodes that are members of the Procedure object.
Fig. 11 illustrates the organization of the Parameter linked list.
Fig. 12 illustrates the organization of the Rulenode linked list Fig. 13 illustrates the or~anization of the various programming modules employed in the Expert Syst~m Fig. 14a and 14b illustrate examples of Rulenodes in which answers to class questions that are obtained ~rom the system, and tbe questi~n is there~ore never presented to the user.

~
The preferred embodiment of the present invention to be described employs a segmented Rulebase that has been established for the primary purpose of diagnosing the faulty hardware operation of a data processing system such as a personal computer. The overall objective of the embodiment is therefore to idPntify a ~ield Replaceable Unit tFRU) that is most probably the cause or source of the problem. The applicstion of an expert system that employs a segmented Rulebase in accordance with the teachings of the cross seferenced and in which procedures are run to collect data for use by the expert sys~em is but one example of an application for this ~ype of expert system. Other applications employing data collected by running external procrdures and not using an segmented Rule base ~ay readily be de~eloped based on the follow-ing description. The ability to assign an action at~ribute to the Rulenode, as described generally in the cross-referenced application is employed in connection with the present invention, ~~ in that a specific action attribute, "SETC" per~its the answer to be set to a class question that would always be presented to the user.

SYSTEM OVER~IEW
The main components oi the expert system shown dia~rammatically in Fig. 1 are an Inference Engine IE 10 and a Rulebase file 11. The Inference Engine 10 includes a supervisor pso~ram 12, inference losic 13, ant a procedural call coordinator 14. Procedures ~-N
1~

AT9-86-007 ~7,~3 are interfaced to the coo~dinator 14 through the Procedure node interface 15. The operator interfaces with the supervisor through the operator or user in~erface block 16. The knowledge represent-ed by the compiled Rulebase is generated by the file co~piler 17, based on Rule inputs from Rule writers.

The supervlsor program 12 controls the flow of Rulebase calls.
Its job includes storing the current Rulebase when suspension occurs, reading in the called Rulebase, knowing which Ruleb~sP to load in next when a Rulebase is exhausted, and recognizin~ when all Rulebases are exhausted. When tbe appropriate Rulebas~ is read in, the superv$sor 12 calls the Inferenc~ng logic 13 to trare the Rulebase. When tracing is suspended, either because of a Rulebase call or because a Rulebase is exhausted, control is passed back to the supervisor 12, which determines the appropriate action to ta~e. Reading in a Rulebase and deciding where to get the information is also handled by the supervisor.

l~ 5L::L ~-~
- The function of the user lnterface 16 is to present questions and information to the operator and supply the operator's responses to the Inference Engine 10.

2S Expert systems generally require frequent interaction with a user through question and answering sessions, the presentation of conclusions, help-giving inte~changes, and indic~tions of errors.
The method e~ployed to provide this interaction can vary among the t~pe of sy tems being employed. The user interface is gener-ally dependen~ on the hardware and operating system being utilizedin the host computer configuration.

In order to isolate all ~achine and application dependent code into separate modules which can be replaced fo~ different hardware configurations or applications, all ~nput and ~utput routines formerly imbedded in the logic of the Inference Engi~e lO in prior art expert systems have been e~tracted and combined into a general purpose user interface dule 16 in the present arrangement. The usar interface 16 has the capabllity of perfos~l~g all the input and output functions previously processed insida the Inference En~in2. ~he functions pro~ided includ~ the following, 1. Query the keyboard and return any keystrokas 1~
, AT9-86^007 7,'~3 which the operator enters.
2. Display error messages.
3. Clear the display screen.
4. Present text and request keyboard input which must fall within a specified range and of a specified data type.

5. Present text and request keyboard input which must be of one or ~ore of a set of specified character strin~s.

6. Present text and request input which may be any valuP of a specified data type.

7. Present t~xt and return i~ediately to the inference engin~ (no response from the user required).

8. Present text and wait until the operator responds by hitting the "Enter" key on the keyboard.

Any values entered by the us~r must be received and interp~eted by Z the user interface 16. Some responses are restricted to a set of possible le~al answers, others are not. The user interface 16 checks all responses to insure that they are of the correct data type. Any responses that are restricted to a legal set of ans~ers are compared against these legal answers. Whenever the user enters an illegal answer, the user interface 16 informs the user that his answer was invalid and prompts him to correct it. In re-sponse to any question, the user ~ay request help from the expert sy~tem in ~he form of explanation, review of consultation, or a trace of the Rule tree being processed. In addition, the user may request to discontinue the process entirely. In this ease, the user i~terface 16 must reco~nize ~his and communicate this fact to the Inference Engine. Com~unication betwe~n the user interface 16 and the Inference Engine 10 is perfon~ed through the use of a User In~erface Control Block (UICB) which is passed between the two.

The UIC~ in the preferred embodi~ent contains the following , fields:
.
A. Action Flags. This field is e~ployed to indieate the action to b~ taken by the user interface.
B. Status Flags. This field indicates the action to be taken by the system.
C. Response Number. This is a value indicating the number of responses required.
D. Response Pointsr. This is a pointer to a length list of possible legal a~swers.
~. High Field. Contains the hi~h ranga for range S ~esponses, the data value depends ~n the response value action flags.
F. Low Field. Contains the low ran8e fo~ range responses. The data value depends on the response value action fla~s.
1 G. Answer Pointer. This field contalns a pointer to a len~th list of answers given by the user.
H. File Name. This field contains the name of the file containin~ text and character string values.
I. File Index. C03taiDs the logical record number in the text file of records to be displayed.

Enumeratin~ the actions to be taken by the u~er interface 16 and the Inference EnBine 10 makes it possible to replace the entire user interface msdule 16 wiehout impacting the code of the infer-ence engine 10 in any way. As a result, any changes in the user interface`method, operatin~ system display routines, or display hardware are transpasent to the inference engine.

Procedure Node Interface The function of the Procedure node interface 15 is to receive ~nformation from ~he coordinator and create the appropriate Procedure Call. The ability to rall a Procedure and receive information from that Procedure can be Yiewed as simply a ~eneral-ization ~f input from the external world. While in some prior ar~expert syst~ms, informa~ion from a procedure has been obtained, that infonmatîon was obtained only in a predetermined ~anner so only certain informatioD could actually be aequired.This expert system, through the knowledge b~se, ~s permitted to invoke any Procedure allowed on its host system. This might seem somewhat s~raigh~forward, but the natu~E of Rulebase progræ~ming is such that this is both somewhat foreign and difficult. Creating a ~ ~`
linkage mechanism for the running of arbitrary Procedures allows the exper~ system to be truly independent of the ~nowledge base that is used. This, in turn~ makss the ~xpert system useful in a much wider class of knowledge domains than if it had no external access or only limited external access.

~.2~72~3 An example of the usefulness of such a function follows. Assume a consultant operator is to determine ~he optimal itinerary for air travelers. Substantial information will be re4yired con~erning the airline schedules between ~he points of departure and arrival so that an optimal choice may be made. While it would be possible for an operator to enter the information~ it is not at all reason-able. It would be easier for the operator to ~ake ~he decision himself. Alternatively, the information could be coded into the knowledge base of the expert system. Unfortunately, the flight information changes so rapidly that this ~lso would not be practi-cal. The required in~ormation concerning flights should beresolved instead by reference to a data base by the calling of the Procedure in accordance with tha present in~ention. Uhile this is not a reasoning step, the reasoning process could not ~ontinue without this information.

Similarly, in the area of machine diagnostics using expert sys-tems, it is not possible to conclude the current state of "health"
of a ~achine without some information. The best source of information is the machine itself, for it contains ~uch detailed information that could not reasonably be pro~ided by the operator.
.
The ability to call external Procedures is useful also to send messages or post specific information on highl7 formatted displays under control of the knowledge base and without custom tailoring of the basir expert system. ~150~ any action permissible on the host ran be caused to occur. Specifically, the system permits the loading of other Procedures and their dynamic binding to existing routines, the exercising of hardware, and the display of messages. The details of the impiementation of how Procedures are called are set forth later on in the specification.

The Rulebase The knowledge tha~ is represented in the syste~ appears in the Rulebase 11. There are basically four diffsrent types of objects, with associated information present in this espert systen's Rulebase 11: -1. Classes - these are questions as~ed to the user.
The information associated with a Class is its name, the answer or answers which the user gives to the q~estion, and the Confidence associated with that ~nswer. The Confidence ~s a nufflber between 0 and 1 that indi~ates how likely it is that the answer is correct.
2. Parameters - a Parameter is a place holder for a character string which may be a variable that can be inserted into a Class question at the point in the quEstiOn where the Parameter is positioned. The data that is variable may be obtained by also asking the user a question. For -example, a Paramster, "Vs~r_Name" may represant the name of the user and be cbtained by asking the user, "What is your name?" The information used by the system is the Parameter name and the associated character string. The response provided by the user ls inserted as the variable in the Class when it is displayed.
3. Procedures - ~hese are definitions of calls to external Procedures. The information associated with the Procedure is the name of the Procedure definition, the val~es passed, and the valu2s returned. This area of the Rulebase provides the basis for the lmprovad method of collecting data from external sources other that the operator.
4. RuIe Node: - The inferencing in the system is done by a tree structure which indicates the Rules or logic which mimics human reasoning.
The nodes of these trees are called RULE nodes.
There are se~ral different types of RULE nodes, the tetails of which are described lates in the ~specification. The node designated External is employed to specify the procedure call.
; 30 Fig. 2 shows ~ sample Rule tree greatly simplified. The Rulebase comprises a forest ~f many such n-ary trees. The top node 21 of the tree is called the Goal node, in that it contains the con-clusion. Each tree in the forest has a different Goal node. The leaves of the tree are also referred to as RULE nodes, or one of the types of RULE nodes. A leaf may be an EVIDENCE node, an EXTERNAL node, or a REFERENCE node.

An ~VIDENCE node f~nctions to obtain information from the operator by asking a specific question such as EVIDENCE node 22. In responding to a question presented by an EVIDENCE node, the operator is generally lnstructed to answer "yes" or "no"

, 20 represented by numeric values 1 and 0 or provide a value of between 0 and 1, represen~ed by a "maybe."
Questions whi h require a response from the ope~ator other than yes or no or a value ~etween 0 and l are handled in a different manner which i described later in the specification.
A leaf that is an EXIERNAL node such as 23 indlcates that data will be used which was obtained fro~ a Procedure Call. In the preferred embodiment of a diagnostic application, 2 Procedure Call could, for example, cause a specific data pattern to be written on a diskette and read to provide an indication if an error was detected.
A REFERENCE node such as 24 functions to refer to another tree or subtree.

A tree may also contain intermediate or minor nodes between the Goal node and the Leaf node. An inter~ediate node can represent logical operations like nodes 27 and 2B in Eig. 2.

If a node B is i~mediately below node A, then node B is called A's child and A is the parent of B. In this case, the tree of which B
is the top node is called a subtree of A. Since a subtree may be ~ust a single node, saying A has two children is equivalent to saying A has two subtrees.

~he Rule compiler 17, shown in ~ig. 1, takes the Rule input that the Rule writer provides and compiles it into the Rulebase file 11 which serves as input that the Inference Engine 10 uses. This input includes the Rule logic as well as the definition for Procedure Calls.
The Inference Lo~ic The inference logic 13 in Fi~. 1, referred to as CO;.SULT has two functions. It selects a tree to trace ant th~n it traces that tree; How CONSULT selects a tree is described later. Once a tree has been selected, CONSULT traces thae tree depth-first, left tD
; 35 right.

; The word "tracing" refers to the action the ~yste~ takes as it traverses the tree, asking Classes ~questions), calling Pro-cedures, and calculatin~ Confidences as it proceeds. Thus, in order to obtain a Conf~dence for node B, the system traces the subtree of which B is the top.
Each of ths various types of nodes has a Confidence value assoc-iated with it. The manner in which the Confidence value is ~7~3 obtained depends on the type of node involved. The Confidence value for an external node depends on the values returned by the Procedure that was called. The CoDfidence value for an EVIDENCE
node is based on the answer provided to the question that was posed to the operator. A REFER~NCE node has a Confidence value based on the Confidence value af the tree to which it refers.

As the Confidenoe of a node is updated, CONSULT goes through all the trees and changes the Confidence of any node that refers to the updated node or depends on the evidence obtained by that node.
CONSULT also immediately propagates those new Confidences up the trees as far as it can before it finds a node that it has not evaluated. Once it has completed this, it continues to trace the selected tree. CONSULT will continue to trace a selected tree until a Confidence has been calculated for its GOAL node. It then selects the next tree to be traced.

The selection of a tree depends on the ordering of the trees. The original ordering of ~he trees is the order in which they appear in the Rulebase. This order can be changed, howeYer, by assigning an EVIDENCE node an attribute "initial" which is described in detail later. The first action taken by CONSULT is to obtain values for all EVIDENCE nodes which have been assigned an "ini-tial" attribute. Using only the answers to these initial Evi-; 25 dences, CONSULT orders the Rulas so that the most likely tosucceed ls evaluated first. It does this by propagating up the tree Confidences that are calculated based only on these initial Lvidences. It then uses the Confidence calculated for a GOAL node as an indication that that tree will succeed. The trees can be further re-ordered since they are constantly being updated as a selected tree is bein~ traced.
A SAMPLE RULEBASE STRUC~URE
The Rule compiler 17 in ~ig. 1, also called CONSTRUCT, takes as input a file provided by the Rule writers. From this input file, it constructs the trees that are used as Rules. CONSULT traverses these Rule trees to ma~e deductions about the proble~ being ' investigated. It is helpful to an understanding of the invention to first havP a brief overview of the Rulebase and to follow an example. A sample input for a Rulebas2 is, therefore~ described and shown in Fi~. 3, and a drawing of the Rule trees generated by this input is shown in Figs. 4 and 5. Also provided i~ an intro-ductory explanatian of the input syntax.

AT~-86-007 7~

Look first in Pig. 3 at the section of the Rulebase that starts with the word "Rules." The text "Z Rule 1 %" is a comment. The input for Rule 1 follows this comment. The tree that corresponds to Rule 1 is shown in Fig. 4.

The structure shown in Fig~ 4 is indicated in Fig. 3 in the input by the order of the input and by the nu~bers appearing to the left. These nu~bers indi~ate the level of the node being describ- -ed. For example, A GOAL node is the top node of this tree and this is indicated by the text "1 GOAL." The word following the number specifies the type of node, e.g., GOAL, AND, OR, EVIDENCE, etc. The nodas appear in thQ osder def~ned by a depth-first, left tv riBht traversal of the tree. In this exa~ple, each node has been given a name ~indicated by "name =") so that the relation is clear between the structure of the tree and the ordering of the nodes in the input file.

Immediately followin~ the GOAL node is the te~t to be presented to the user if this goal ls concluded. This is indicatsd by "text 20 =. " The text itsQlf is enclosed in single quotes.

There are three EVIDENCE nodes in the tree shDwn in F~g. 4. An EVIDENCE node must have two things deflned for i~: the question to be asked to the user, and the answer(s) that will cause this evidence to be true. This information is contained in the line:
class ~ ~'yes') of printer 'yes' is the one answer that will ~ake this evidence true. Tbe question is specified by regerring to one of the items in the Class section of the Rulebase.
In this case, the Class is named printer.
: .
;; In ehis example, Class definitions are located in the very first section of the Rulebase inpu~ file as shown in Fig. 3. This section star~s with the word "Classes." The first Class defined is the Class named "printer." Followin~ the na~e of the Class is the text for the question associat~d with this Class.
; This is indicated by "TEXT ~." The string enclosed in single quotes is presented ~o the user so he can respond with an answ~r. ~ `~
The line: ~alues = 1 of ('yes' 'no') gives two pieces of informatlon. It indicates by the phrase "1 of'l that exactly one answer will be accæ~t~d from the user. It also lists in parsnthesis all possibie answer~ with which the user ;~ltf~ ~2;~3 ~ay respond. In this case, yes ~nd no are the only two allowabl~
answers.

Since it is mor~ than likely that the Rulebase will have many E~IDX~C~ no~es t~at ask the same question, the ~un~ti~n of a C~ass item beoomes obvious. The question merely has to be included once in the Class section, with an appropriate na~e that can be re-ferred to by an EVIDENCE node that needs to ask that question.

The section headed Procedures in Fig. 3 defines Procedure Calls.In this example, there is one Procedure Call definition with an ID
of "printertest." This definition specifies that the Procedure to be called is "printertu," that one value is passed (32767), a~d that there is one variable returned called "statusbit."
An EXTERNAL node uses information obtained from a Procedur~ Call.
In the second Rule tree, shown in Fig. 5, under the OR node is an EXTERNAL node. It refers to the Procedure Call definition by its ID, "printertest." This node is ~valuated true if th comparison it specifies is true; na~ely, if the return variable "statusbit"
is not equal to ~ero.

One other section is presene in this sample Rulebase shown in Fig.
25 3: the section named Parameters. In this example, there is one Parameter, "printernumber." This ParaNet~r shows up as 'i$printernumber" in the text for the Goal of Rule Tree 2 shown in Fig. 5. When the Goal text is presented to the use~, the Para-meter name will be substituted by a string that the use~ psovides.
The string will be obtained by asking the u~er, "What is the number o~ your printer?," which is the question given in the ; Par~met2r definition. If no answer is provided by the user, the default answer, 'IBM,' will be substituted.

Briefly, the Rules section describes the Rule trees. EVIDENCE
nodes refer to Classes specify questions along with possible answers to those questions. Parameters allow a strin~ to be ; substl~uted in te~t b~fore that text is presented to the user.
Many of the details of the Rulabase are described later in the ~0 sperif~cation.
CALCULATING CONFIDENCES
As discussed above, the system suppores a number of different node types. These nodes vary in purpose and evaluatlon. All nodes, except those ound at the leavss of the trees, ha~e Confidenc~
values passed to them by their chlldrenJ A nod~ uses the ~7,'~3 children's Confidences to compute its own Gonfidence. Further adjust~ents ~ay be made to the computed Confidence before passin~
this Confidenc~ up to the parent node. The general features of Confidences and threshold values and how they work will first be described. The attrlbutes or properties which can be specified for a node that affect the Confidence the node passes up will then be described. The different node types and how they compute their Confidences is also described.
, As a Rule tree is tr~ced, a Confidence value is associated with ~ach node. This v~lue is a number between -1 and 1, inclusive, and is an indication of how likely it is that a node is true.
These Confidence values are me~nt to help mimic the kind of heuristic reasoning a human does. For e~ample, a statement be~inning, "It is very likely that .." would have a higher Con-fidence associated with it than ~ statement which b~gins, "There is some chance that...." By associatin~ different Confidenc~s with different Evidences and inferencesg different goals will be concluded with diffzrent weights. This means that when a Rulebase is traced, there will not be just one Goal concluded as true;
instead, several Rules may be concluded with varying Confidences.
The added power and fl~xibility of Confidences is one advantage to expert systems over traditional programming approaches.

Confidences can be associated with EVIDENC~ node~ in two ways:
elther the user provides a Confidence or the Rulebase pro~ides lt.
If the user is providing ~he C~nfidence, then after answering a question, he is prompted eO also provide a Confidence to associate with that answer. When the Rulebase provides the Confidence, the }

de~auIt value is provided in the Rulebase. The user answers the question and the Confidence stated in the Ru~ebase is associate~
with that answer.

CONFIDENCES FOR EXTERNAL NODES
The Confidence to be given to an EXIE$NAL node is provided by the ;;
Rulebase. This is done using a WEIGHT attribute which is discuss-ed later in the specification.

While there are four ~ajor sections to the Rule file, Classes, Procedures, Parameters, ~nd Rules, the only required section is Rules.
T~RESNOLDS

AI~-8S-007 72~3 Each node has a property list which contains data about the node including a number of attributes. Each node has associated with it two threshold attributes: a hi8h threshold and 3 low thres-hold. If the hi~h and low thresholds are not specified in the Rulebase, then they default to 1 and 0, respectively. If a Confi-dence computed for a node falls above the high threshold, the node is consid~red to be true or concluded. If the Confidence computed for a node falls below the lower threshold, the node is considered to be false or rejected. These thresholds are useful for several purposes. If a GOAL node is concluded, that goal is presented to the user. It is the hi~h threshold that determines if it ~ill be concluded true. Thresholds are used to perform the Normalize funceion for a node. This function is described next.

NORMALIZATION FUNCTION
Any node can be given the attribute "normal." If a node has this attribute, then its Confidence is normalized before it is passed up the tree. If LOW = the low threshold defined for the node~
HIGH ~ the high threshold defined Por the node, and C ~ the Con~idence computed for the node, then the Normalize function is defined as:
if C >= HIGH
then NORMALIZE~C) = 1 else if C ~= LOW
25then NORMALIZE(C~ = O
else NORMALIZE(C) = ~C - LOW) / (~IGH - LOW) ASSOCIATIVE_~ACTOR
A node has assigned to i~ an Associative fac~or which defaults ~o 1 if it is not explicitly set in the Rulebase. The Associative factor lDdicates how strong the a~sociation is between a node and it~ parent. After the Confidence~for a node has been computed, this Confidenre is multiplied by the Associati~e factor, and the product is passed up to the parent node. As an exa~ple, if a node has a Confidence of .9 and an Associative factor of .8, .72 is passed to the parent node.

ATTRIBUTES OR PROPERTIES
In general, the ordering of attributes within a Class or node dafinition does not matter. ~here can be as many a~ described for each type of node and they ~ay occur in any order. The use and function of the attributes ar~ as described below.

~i7~

ASSOCIATION
USE: The ASSOCIATION attribute may be used with any RULE node.
FUNC$ION: The ~SSOCIATION attribute is used to specify the value for the Associative factor discussed above. Once a Confidence for a node is obtained, the Confidence is multiplied by the Associa- -tive factor before it is passed up to the par~nt node as explained in detail earlier. If no Associative attribute is specified, then the ASSOCIATIO~ attribute defaults to l; that is, it does not affect the Confidence for that Dode. The Association factor is multiplied after the Dode has received its final weight. It affects the wei~ht the parent node rereived, but not the weight ~f the given node. If a REFERENCE node references a node ~ith the ASSOCIATION a~tribute, the value given the RE~ERENCE node is the weight before multiplication by the Association factor.

CALL
USE: The CALL attribuee is used with sny RULE node. I~ is not required.
FUNCTION: The CALL attribute is an 'action' attribute. It causes another Rulebase to be called. This action ocrurs only if the wei~ht of the node ls evalwated to be gre ter than or equal to the high ~hreshold for that node. If another Rulebase is called, the Rulebase presently bein~ traced is stored, and execution of the new Rulebase is begun. It is assumed that the called Rulebase has lready been compiled (constructed). When ths called Rulebase completes, eontrol returns to the ori~inal Rulebase and the system continues processing this-Rulebase from where it l~ft off.

SLASS
USE: The CLASS attribute is only used with an EVIDENCE node. I~
is not required.
FUNCTION: The CLASS attribute specifies the Class referred to by an EVID~NCE node. It tells the na~e of the Class and also tells which answers to that Class w111 cause the EYIDENCE node to be evaluate~ TRUE. The EVIDENCE noda was deseribed earlier.

D FAULT ~ `
USE: The DEFAULT attribute is used only with a Parameter.
FUNCTION: The DEEAULT attribute specifies a text string for a Parameter. If no other string i~ provided by the user, t~en this default string will be used as the Parameter's value.

DELETE

,,, ;: .
.:

USE: The DELETE attribute is usad only with a Procedu~e Call definition. It ls not required. If no function (EXECUTE, LOAD, or DELETE) is specified, the default is EXECUT~.
FUNCTION: The DELETE attribute is specifiçd for a Proced~re node definition to delete that Procedure from memory. If the DELETE
attribute is specified, the PASS and RETURN attributes are not required.

E~ECU rE
USE: The EXECUTE attribute is used only with a Procedure Call definitlon. It is no~ required. If no function (EXECUTE, LOAD, or DELETE) is specified, the default is EXECUTE. See also the DELETE and LOAD attribute.
FUNCTION: The EXECUTE attribute is specified for a Procedure noda definition whsn that Procedure is to be sxecuted ~rathe~ than loaded or deleted~.

EXPLANATION
USE: The EXPLANATION attribute can be used with a Class, a Parameter, or an EVIDENCE node. It is not required.
PUNCTION: The EXPLANATION attribute specifies a text strin~. Its pu~pose is to supply explanatory text to help the user. If the user does not understand a question presented to him, he may ask for further explanation by entering ?e. This causes the text provided by the EXPLANATION attribute to be presented to him. If a Class qu~stion is being asked ~Xen ?~ is entered, the user is presented the EXPLANATIO~ text pro~ided by that Class. If a Parameter question is being asked, ?e will cause ~hat Para~eter's explanatory text to be presented. If an EY m ENCE node has a question in the node (rather than ræferring to a Class), then ?e wi~l psesent explanatory text provided i~ that nod~. In any case, if ?e is entered by the user when there is no EXPLANATION attri-bute present, the system responds with "~here is no explanation provided" and re-asks the questions.
; GLO~AL !'', Onc of the main Yehicl~s employed by this syst~m for p~ssing collected data between different seg~ented Rulebases during one session or the same Rulebase if the session was in~errupted, involves the assignment of 2 GLO~AL or LOCAL attributa to each node. A GLOBAL attribute may be as~igned to any node in a Rule tree. As an example, suppose the f~rst Rulebase exeouted by the syst~m determines the hardware confi~uration by ~unning some tast ' 28 ;`

~67.~3 units. If the operator wanted to diagnose several components of the system, i.e., the printer, the disk drive, and the keyboard, a new session could be started for every component. It is, of course, more efficient to run the configuration test just once for all the sessions and then pass the informatlon on to the various se~mented Rulebases. Similarly9 if each component to be tested required a separate Xulebase9 the configuration information must be passed to all the Rulebases. As mentioned previously, any node may be given a GLOBAL attribute. If an EVIDENCE node is GLOBAL, the question is asked only once during multiple sessions. The answer the operator gives is retained as the value throughout all sessions. Similarly, a Procedure or test unit is executed only once during multiple sessions~ Parameters are evaluated the samc as GLOBAL EVIDENCE nodes. A node assigned a GLOBAL attribute retains its weight or value between sessions. If an EVIDENCE node or EXIERNAL node is GLOBAL, the question or Procedure it refer-ences may be asked or execu~ed, but the node will not be updated or re-evaluated. If an intermediate node (such as an "and/Gr" or "not") is assigned the GLOBAL attribute, then the underlying tree is not re-evaluated betw~en sessions.

The GLOBAL attribute is also used to pass values between Rulebases when multiple Rulebases are executed in the same session. A
session is defined as the execution of the Rulebase to determine the solution to a unique problem.

The GLO~AL attribute is also used to pass values between Ruleb~ses when multiple Ruleba~es are executed. If a value either for an EVIDENCE node, Parameter, or test unit result is needed between Rulebases then that answer, test unit, Procedure, or Parameter is assigned the GLO~AL attribute in both Rulebases. When a node having a GLOBAL attribute is given a value in one Rulebase, that value will be retained in both Rulebases. The nodes assigDed a GLOBAL attribute will not be re-asked or re-executed, but will be given the same value.

A node in a Rule tree can reference another tree with ths use of a REFERENCE node. The node to be referenced is given a unique name at~ribute. The referencing node refers to the named node and is ~iven the value of ~he referenced node. It is possible to re-ference ~ node in another Rulebase by ~iving both the RE~ERENCE
node and the referencing node the GLO~L attribute.

. .
..

7,'~23 In summary, the GLOBAL attribute enables the system to retain the value ~f a question, Procedure, Parameter, or RULE node between sessi~ns and to pass the value assigned to the RULE node between Rulebases. Both of thPse capabilities are necessary for an expert system with Rulebases that have been segmented into contextual units.

LOCAL
The LOCAL attribute enables the system to continually update dat~
and EVIDENCE nodes as data changes during a consultation session.
The system has the ability to oollect static or dynamic da~a and to distinguish between the two types of informatioD.

If the question at the EVIDENCE node is to be asked every time, the question must be assigned the LOCAL attribute. Si~ilarly, if a test unit is executed every time, it is seferenced in a~ EXTER-NAL node and must be assigned the LOCAL attribute. The LOCAL
attribute is tifferent from the RE-ASK attribute to be described later on. The RE-hS~ attribute specifies tha~ a Class be re-asked only when the node with the RE-ASK attribute is evaluated. The L~CAL attribute, on the other hand, indioates that the question be re-asked every ~ime it is referenced in aD EVIDENCE node. The same difference holds between the assignment of the LOCAL attri-bute t~ a Procedure node and the RE-EXECUT~ attribute, which is des~ribed later on.

If an EVIDENCE or EXTERNAL node is assigned the LOCAL attribute, that node is not updated when the question or test unit it refer-ences is asked or executed from another node. Instead, the node is updated only ~hen selected by the syste~.

The LOCAL attribute is used, for example, to ask a question to thP
operator many times during the diagnosis of a printer. If the system continually dir~cts the user to adjust the hardware, ~t then becomes necessa~y to ask the user the same questioD, "Does the test line print out ~n the priDter?" every time the user has ~' completed an adjustment of the hardware a~ the answer may ohange with any steps that the u~er takes. ~hat EYIDENCE node or ques-~on would be assigned the LOCAL ~ttribu~e.
HIGH/LOW
_ ~ ~.

USE: The HIGH and LOW attributes are used for RULE nodes. Th~y are not required. If not specified, default values are assumed of 1 and 0, respectively.
FUNCTION: High and low thresholds for a node are specified using the HIGH and LOW at~ributes, respectively. If a Confidence computed for a node is greater than or equal to the HIG~ thres-hold, then that node is considered TRUE. If the Confidenoe is less than or equal to the LOW threshold, then the node is consid-ered FALSE. Thresholds are also important when applying the NORMAL attribute. ~hese thresholds and how they work were des-cribed in detail earlier.

INITIAL
USE: The INITIAL attribute can be specified for a Class, a Parameter, a Procedure Call, or a RULE node. It is not required.
FUNCTION: Before ordinary Rule processing is started, objects given the INITIAL attsibute are evaluated. Procedures d~signated as INITIAL are ~xecuted firçt; next, BULE nodes which are INITIAL
are evaluated; thirdly, Classes assi~ned an INITI~L attribute evaluated; lastly, Parameters with INITIAL attributes are evaluated. Afte~ all ~nitial ~bjects with INITIAL attributes have been evaluated, the rest ~f the Rulebase is then processed.
.
LOAD
USE: The LOAD attribute is used only with a Procedure Call definition. It is not ~eq~ired. If no function (EXECUTE, LOA~, or DELETE) is specified, the default i5 EXECUTE.
FUNCTION: The LOAD attribute is specified for a Procedure Call definition when that Procedure is to be loaded (rather than executed or deleted).

NAME-IN RULE NODE
US~: The NAME attribute can be givan to either a RULE node or a Procedure Call definition. It serves a tistinctly different funotion in the two cases. This discusses the NAME attribute applied to the RULE node. This is not a required attribute for a , RU$E node.
~UNCTION: The NAME ~ttribute allows a node to be given a nE~e.
This name allo~s the subtree headed by the named node to be ref~renced by a REFERENCE node. The NAME attribute iD the RE~ER-ENCE node specifies which node i5 being referenced. Having nodeswith names is also useful when debugging a Rule flle.
NAME-IN PROCEDURES SECTION

: .

AT9-86~007 7'~.3 USE: This discusses the NAME attribute applied to the Procedure Call definition. This attribute is a required attribute for a Procedure Call definition.
FUNCTION: The NAME attribute in a Procedure Call definition specifies the name of the Procedure to be called.
.

NORMAL
.__ USE: The NORMAL attribute i~ used only with RULE nodes. It is not required.
FUNCTION: If the NORMAL attribute is specified for a node, then the node's Confidence is normalized before it is passed up to its parent node. The no~malize function was discussed earlier.
Though the normalize function does not require a high or low threshold, it has no effect on the node if the default values for the thresholds are assumed. The normalize function is the last step when computing a node's value. If another node referenc2s a node with a NORMAL attribute, it receives the normalized value.

PASS
USE: The PASS attribute is used only with a Procedure Call definition. It is not required.
FUNCTION: The PASS attribute specifies what is to be passed to the Procedure when it is called. Ths PASS attribute may spe~lfy the actual value ~o pass, a Class name, a return value from another ProcPdure, or the type of the value to be passed. If thP
type only, is speoified, then the value must be set in the EXTER-NAL node. Parameters passed can be: fullword ~Dteger, hexa-decimal, real, binary, or character strin~.

USE: The POWER OF~ attribute is used onIy with a Class. A Class having the POWER_OPF attribute should not have a VALUES attribute.
PUNCTION: The POWER OFF attribute indicates ehat the text of this Class will request the user to power off the machine. This attribute must be included to let the e~p~rt system know that it must ~ave the state ~f the Rulebase befvre the text is displayed.
; A Class wlth a POWER_OFF attribute should not ha~e a VALUES
attribute. Since the ~achine will be powered off, any answer that the user gi~es to this Class would not b~ saved by the expert system.
~, PROC
USE: The PROC attribute is used in an EXTERNAL node only.

, ~;'7~

FUNCTION: An EXTERNAL node must specify a Procedure Call defiDi-tion. This is done using the PROC attribute. ThP- ID specified is the name of the Proced~re Call definition as opposed to the name of the Procedura itself.

~SE: The RETURN attribute is used only with a Procedure Call definition. It is not required.
FUNCTION: The RETURN attribute is used to specify the variabl~s that will be returned when a Procedure is oalled. For each variable, a name is spe~ified. This allows an EXTERNAL node to refer to this returned variable. Also specified for each Yariable is the type of that variable sueh as fullword inte~er, real number, binary, hexadecimal, or string.
SETC/SETP
USE: The SETC or SETP attribute ~an be used with any RULE node.
They are not required. There ~ay be ~ultiple SETC and SETP
attributes in a RULE node. ~o~ever, in a sin~le node, there ~ay be only one SETC attribute for a given Class, and only one SETP
attribute for a given Parameter.
FUNCTION: The SETC and SETP attributas are 'action' attributes.
The SETC a~tribute causes a Class to be set to a specified value and the SETP attribute causes a Parameter to be set to a ~pecified value. This action ocours only if the node is eYaluated to have a weigh~ greater ~han or equal to the HIGH threshold for that node.
A Class can be set to a constant value. Also! if the SETC attri-bute is in an EXTERNAL node, a Class ~ay be set to a value return-ed from ~he Procedure invoked by this EXTERNAL node.
A Parameter can be set to a character string. Also, if the SETP
attribute is in an EXTERNAL node, a Para~eter may be set to a character string returned ~rom the Procedure in~oked by this EXTERNAL node.

USE: The TEXT attribute ~an b~ used with a Class, a Paramet~r, a Procedure Call definition, or with the following RULE ~odes:
GOAL, HYPOIHESIS, or EVIDENCE. If a Class or P~ramet~r may be evaluated by asking the user a qu~stion, then the TEXT attribute ls required fos that Class or Parameter. It ls not required i~
the Class or Parameter will always be set internally.

. -:

AT9-~6-007 2~3 FUNCTION FOR A Class, Parameter, OR EVIDENCE Node: In this case, the TEXT attribute supplies a question to be presented to the user. Text for a Class is presented to obtain value(s) for that Class. Text for a Parameter is used to obtain a text string value to be given the Parameter. In the case of an 2VIDENCE node, if the node does not refer to a Class, then it must provide a ques-tion usin~ th~ 5~XT attribute.
FUNCTION FOR A ~OAL NODE, HYPO~æSIS NODE, OR Procedure Call definition: In this case, the TEXT attribute provides information for the user, but no response is expected. Text for a ~OAL or HYPOT~ESIS node is a statement of the conclusion associated with that tree. This text is presented if the GOAL or HYPOTHESIS is evaluated TRUE; that is, if the Confidence computed for that node falls above the HIGH threshold. The text given for a Procedure Call definition is presented when the Procedure is called. This is to infor~ the user about what is happening. For example, 'Diskette test is being run' or 'Be patient -- this will take about 5 minutes.' VALUES
USE: The VALUES attribute is used only with a Class. For most purposes, it is a required attribute; however, if no response is expected from the user, it may be omitted.
FUNCTION: The VALUES attribute provides two types of information for a Class. It indicates the allowable answers for that Class and it specifies how many answers will be expected.

The~VALU~S specified can ~ake one of three forms:

1. A list of discrete string values.
('yes' 'no' 'maybe') 2. A ra~ge of numbers. The nu~ber can be integer, real, or binary.

(2.2 : 4.3) ('00'xb : 'EF'xh) When specifying a ~a~ge> open ended intervals can be indicated using an *.
(1 : *) (*: 10.0) The first exa~ple allows any positive lnteger (that is, any integer ~r~ater than or aqual to 1~.

, `34 , - "' The second example allows any real number less than or equal to 10Ø
3. A type, This form is used when the Cla~s will always be set internally by us~n~ the SETC attribute in a RULE node. Since it is being set internally, the user will not be asked for an answer. All that needs to be specified is the type of the answer. Valid types are: integer, real, binary, hexadecimal, or string.

The other information provided by the VALUES attribu~e is the number of answers allo~ed for a Class question. This number is indicated by a positive integer ~r ANY.' This tells the sy~te~
the number of times to prompt the user for an answer. If ANY' is specified, the system continues to prompt the use~ for an answer until ths user enters a ~ull llne. If the numbzr of allowed answers is not specified, it defaults to 1.

Classes ~ay eli~nate the VALUES attribute entirely. This in-dicates that no particular value will be entered by the user.
Instead, he should simply press the ENTER key. This option is used when text needs to be Pr~Sented but no answer is expected.
~or example, the user ~ay be informed: 'Please check to be sure your printer is plugged in. Press enter when you have done this.' ID this case, no answer is required from the user. When a Class has no ~ALUES attribute, EVIDENCE nodes using that Class will get a Confidence equal to the weight of ~hat ~lass (i.e., they will never ~et one ~inus the weight).
WEIGET/PREDEFINED WEIGHT
USE: The WEIG~T or the PREDEFINED W2IGHT attribute may be used with a Class, a Procadure Call definition, or an EVIDENCE node.
It is not required. If not ~pecified, it defaults to 1.
FUNCTION FOR A CLASS: Every Class has a wei~ht associated with it. This weigh~ is a number between -1 and 1, inclusive, and , . indicates ho~ much 'Confidence' should be associated ~lth the answers given for the Class. The WEIGHT or PRÆDEFINED WEIG~T attributes are used to set this weight. If nei~her attribute is used, the weiRht de-faults to 1. If the WEIGHT attribute is given to a node without the word P~EDE~INE~ precedin~ $t, the~ the user is first ssked to supply a weigh~. Only if he decl$nes to do so is the value , 35 -~72~3 specified by the WEIGHT attribute used. If the attribute PRE
DEFINED WEIGHT is given for a node, then the user is never asked for a weight. The value defaults to the value defined by PRE-DEFINED WEIGHT.
WEIGHT
FUNCTION FOR A PROCEDURE: Every Procedure Call definition has a weiRht associated with it. This weight ls a number between ~1 and 1, inclusive, and indicates how much 'confidence' should be associated with the return values. The WEIGHT or PREDEFINED
WEIGHT attributes are used ~o set this weight. If neither ~ttri-bute is used, the weight defaults to 1. If either WEIGHT or PREDE~INED WEIGHT is gi~en for a node, then the ~alue defined by this attribute is given to the Procedure Call definition. The user is never asked to supply a weight for a Procedure Call definition.
FUNCTION FOR EYIDENCE NODE: If an EVIDENCE node does not refer to a Class but provides its own question, ~t may have either the WEIGHT or the PREDEFINED W~IGHT attribute. If neither attribute is specified, then the user is prompted to supply a ~umber between 0.0 and 1.0 inclusive. If PREDEFINED WEIG~T is ~sed, the user is prompted to answer 'yesl or 7 no.~ If he a~swers 'yes,' then the predefined weight is given tD the node; ~f he answers 'no,' then on~ minus the predefined weight is given to th~ node. If WEIGHT
is specified (wi~hout PREDEFINED), then the user is prompted to enter 'yes,' Ino,' or a weight between O.O and 1.0, inclusive. If he enters Iyes,' the node is ~iven the weight; i~ he enters Ino, the~node is given one minus the weight; if he enters a number, then the node is given that weight.
RE-AS~/R~-EXECUTE
The RE-AS~ and RE EXECUTE attributes provide the system the ~bility to continually update data and evidence as it is gathered from the operator or fro~ the hardware. As conditions change, for example during dlagnosis of the hardwa~e, the evitence may change.
Goals are then reached based ~n the ~ost ~ecent evidence avail-; able.

It ~ay ~lso be necessary to selectively RE-AS~ a question to the opera*or or to selectively RE-EXECUTE a test unit on the hardware.
For example, a test unit which tests th~ cabls connection may be executed. If the test fails the first time, the operator may be requested to install a new cable. The test unit may then be ' 36 ~2~

executed a second time to Yerify the connection. Similarly, the system may ask the user "Is the printer turned on?" If not, the user may be requested to turn it on and the question will be reiterated. If a question is to be re-asked; the attribute RE-ASR
is assigned to ~he EVIDENCE node containing a refe~ence to the question. Similarly, if a test unit is to be re-executed, then the attribu~e RE-EXECUTE is assigned to the EXTE~NAL node con-taining a referenc~ to the test unit. The first time that the question is asked, only those EVIDENCE nodes that reference the same question and do not have the RE-ASK attribute will be eval-uated or updated "true" or "falsel" depending on the answer. When the system chooses the EVIDENCE ~ode marked RE-ASK, the question is asked again, even thou~h it was previously asked. An EXTERNAL
node with the RE-EXECUTE attribute is evaluated similarly to an lS EVIDENCE node with the RE-ASX attribute.

The need to pass information between Rulebases is obvious where the Rulebases are segmented. For example, a callin~ Rulebase may need to pass some initial information to the called Rulebase, such as a value to a Class or an answer to a Parameter. Also, the same Rulebase might be called multiple ti~es to test ~ultiple instances of the same it~m. This would be done, for example, to test several dis~ drives present on the same system. When th1s is done, certain Classes ~ust be set first, such as the dri~e speed so that the called Rulebase will test the correct device in the appropriate manner. Conclusions from one Rulebase ~ay influence conclusions in another Rulebase. Thus, it ~s necessary for a node in one Rulebase to reference a node in ano~her Buleb3se. Some Procedures should only be run once, but values re~urned by these Procedures might be used by several Rulebases so there must be a way also of passing procedural infor~ation between Rulebases. In the casa of the diagnostic application of the prefcrred embodi-ment, some information is gathered from the user before the expert system is called. An example oX this type of information is the type of testing to be done. There needs to be a way to pass this ; informa~ion to the system so that it will not have t~ re-ask this question.

Where information associated with any ob~ect needs to be passed between Rulebases9 that object is ~iven the attribute, "GLOBAL."
This alerts the system that this is information that may be used - : :

72~3 in more than one Rulebase. The GLOBAL attribute has been dis-cussed earlier.

THE GLOBAL LIST
The supervisor program 12 in ~ig. 1 functions to keep a 11st of Global objects, to maintain this list with the latest values, and to update Rulebases with values from this list. A single linked list is kept which stores information for any type of object defined to be Global. The list is referred to as the Global list.
Each record of the lPng~h list holds the following information:
1. The name of the object.
2. The object type, e.g., Class, Procedure, Parameter, or RULE n~de. This is uscd to double check that the correct object has been located and also allows objects of different types to be given the same name.
3. A Boolean variable IN CURRENT RULE BASE which is true if the Global object is in the current ~ulebase.
2~ 4. A Boolean variable used to indicate if a Class or Parameter has been asked or if a Procedure has been exeouted.
5. The Confidence associated with a Class, a RULE node, or a Procedure.
6. A pointer to a Response list which holds the answer for a Class or a Parameter or the rsturn values for a Procedure.
7. A pointer to the next Global record ~hich makes the li~t a linked lis~.

The supervisor program 12 maintains the Global list in the ;ollow-ing manner: As a Rulebase is bein8 read in~ when an object mar~ed ~s Global is encountered, the Global lis~ is searched to see if that object is on the list. If ~t is on ~he list, the information present on the Global list is obtained from the supervisor and the rest of the information is read in froM diske~te. If the objert ~- ; ic not on the Global list, it is added ~o the list fro~ the diskette. All i~formation for that object is read in from the diskette. ~n either rase the Bo~lean varlable IN_CURRENT_RULEBASE
is set to be true.

After a Ruleb~se is read in, the inferencing logic 13 is invo~ed.
When another Rulebase is called or when the ~urrent Rulebase ie 1~7~3 exhausted, co~trol is returned to the supervisor 12. Before storing the current Rulebase out to the diskette file, the Global list must be updated with the information ~ust obtained. The Global list is searched for any obje~t which has the Bool~an variable IN CURRENT RULE BASE set to be TRUE. Any such object is updated with current information and the Boolean variable is reset to be FALSE.

Thus, at this point, ~he Global list is current and the next Rulebase read in will Bet the latest information. One of the most complicated cases of passing information to the system is when a node in one Rulebase references a node in another Rulebase. The list of Global objects is used also for this function. In the ordinary case, when a node references another node in the same Rulebase, the referencin~ node has a pointer to the referenced node so that it can be located and its Confidence obtained. In the case when a node in the current Rulebase references a node in another Rulebase, the referenced node is not even present in the current Rulebase and is not in memory so it cannot have pointers to it. This obstacle is overcome using the Global list. The refereDcing node is given the GLO~AL attribute so that its Con-fidence is stored on ehe Global list. The supervisor 12 recog-nizes when a Rulebase is read in which references a node that is not in memory. The supervisor then creates a du~my node for the current Rulebase and gives that dummy node the Confidence and name of the referencing node stored on the Global list. In the current Rulebase, references to the out-of-memory node are pointed to this dummy node in the same manner as if it were actually the node in the current Rulebase. The inferencing logic 13 can then treat these Global referenoes just like Drdinary reXerences and per-ceives no differences.

The Global list is al~o used to pass values into the system. One of the Parameters passPd to the system when it is called is a 3S pointer to the Global list. If no information i5 passed then this pointer is null. If infor~ation needsi; to be passed in, the calling program puts the information on the &lobal list before the expert system is called.

The use of Global objects, i.e., objects assi~ned a GLO~AL a~tri-bute, increases flexibility of the syste~. Information can be passed into th~ system when it is invoked. Classes and Parameters can be evaluat~d in one Rulebase and used in another. A Procedure .
~ 39 ~72~3 need only be executed once, even if it is used in two different Rulebases, because the values can be stored and passed using the Global list. It is even possible, to referenre a node that occurs in a different Rulebase. Global objects provide many advantages to a segmented Rulebase without losing the advantages of a single Rulebase structure.

As discussed earlier, the Rulebase 11 has four major sections;
Classes, Procedures, Parameters, and Rules which ars also referred to collectively as objects. A summary description of each of these sections was presented earlier. A more detailed descrip-tion9 together with a sample and example of how each section is arranged follows.

CLASSES SECTION
A sample Classes Section follows:
CLASSES
printer text = 'Does your problem seem to involve your printer?' values = 1 of ('yes' 'no') predefined weight = 0.8 ibm5215 text = 'Are you usin~ an IBM 5215 printer?' explanation =
'On the front of the machine in the top ri8ht hand corner there should be a silver metal square with IBM logo on it. In the bottom left corner of this square there is a four digit ~umber which is the numbar of the IBM
printer you are using. If this number is 5215, then you are using an IBM 5215 printer.' values = ('yes' 'no') initial weight = 1 global symptom text = 'Do you notice any of the following symptoms:
(1) chararters missing (2) characters ~isprinting (3) charaoter ~mudged (4) paper feed crooked (5) none of the above' values - any of (1:S) printerlite t~xt 3 1 Is the light blinking on the front of your printer?' values = 1 of ('yes' 'no') predefined weight = 1 local The above example illustrates how ~he Classes section is organi~-ed. The first word is CLASSES. Following this the Classes are defined. The general form of a Class is: an identifier ~which is the Class name) followed by the attributes for that Class (e.g., TEXT~ INITIAL, etc.). In this example, the Classes are: printer, ibm5215, symptom, printerlite. The attributes for a Class may appear in any order. The definition of a Class is terminated by ~he next Class na~e. The beginning of another section terminates the Classes section.

PARAMETERS SECTION
Parameters, as discussed earlier, are used as a place holder for a text string value. This value is provided by ~he user or from a Procedure Call. When Parameter~ are used within text, the Para-meter name must have the character i~' affixed to the beginning of the n~me. This allows it to be recognized as a Parameter name. A
Parameter will be replaced by the character strin~ it represents before the text is displayed to the user. Parameters can be used within any text string.

2 A sample Parameters Section follows:
s Note that the Parameter PRINTERNUMBER is referenced using $PRINTERNUMBE~ in both the Class "printer" and in the goal TEXT of RU1Q tree 1.
~ CLASSES
~printer text - 'Does your problem seem to involve your $PRINTERNUMBER printer?' values ~ 1 of ('yesl ' no ' ) predefined weight = 1 PARAMETERS

printernumber text = 'What is the number of your printer?' explanation = 'The number of your printer is a four digit number.
This can be found in the upper right corner of the front of your ~achine.' RULES

7~ ~

% Rule Tree 1 %

text = 'Report service rlquPst number 151 018 for the $PRINTERNUMBER printer.' class - ('yes') of printerlits 3 evidence class a 2 of symptom The above example illustrates the organization of the Parameters section. The first word in the section is the key word PARA-MET B S. Eollowing this are the names of the Parameters. Under each Parameter name are the key words for the attributes given to that Parameter.
When appropriate, the attribute is followed by the value for that attribute. The ordering of the attributes within a Parameter definition does not matter. A Parameter definition is terminated by the next ParamQter name. The Parameters section is terminated by the beginning of another section.

PROCEDURES SECTION
The Procedures section of the Rulebase proYides the Procedure Call definitions. These provide information such as the Procedure to call, variables to pass, and name and type of variables returned.
Procedure Calls are invoked by EXTERNAL nodes and the ~alues returned from the Procedures are used in these nodes. When a Procedure is ~alled, EXTERNAL nodes referring to that Procedure Call definition are evaluated to IRUE or FALSE. This e~al~ation depends on the values returned from the Procedure and the compari-sons given in the EXTERNAL node.

; ~ 30 A sample Procedures Section follows. The following shows a Rulebase file with a Procedure Call definition. It also includes a Rule node which refers to this Procedure Call with an EX$ERNAL
node.
CLASSES
3~ ...
PROCEDURES
printertestl name ~ printertu p~ss 32767 Z SVC number return statusbit hex(l) end printertestl name = printertu pass 99999 % SVC nu~ber %
return status hex(l) error number integer end diskettetest name = diskettetu pass 666890 return address integer status hex(l) end RULES

$~xt = 'Report Service Request Number 151 018 for your printer.' 3 EXTE~NAL
proc = printertest reexecute status NE '00'XB
error num LE 5 3 evidence class = 'yes' of printerlite The first word in the Procedures section is PROCEDURE5. Following that are the IDs of the Procedure Calls defined ~in the example, printertest 1 dis~ettetese)~ Followins each Procedure Call ID, are the attributes for the Procedure Czll being defined. Ordering of attributes within a Procedure Call definition does not matter.
A Procedure Call definition is terminated by the word 'end.' The beginning of another section terminates the Procedures section.
,:
ES SECTION
Rules is the section of the Rulebase file which defines the Rule trees. ~or each tree, each node of the tree is defined and ~he attributes for it are specified.
A de-finition for a Rule tree is ended by the be8inning of the next Rule tree.
A sample Rules section follows.
rule Tree 1 text = 'Report service request number 151 ~17.' high ~ .7 name ~ goall :: ~
asso = 0.8 normalize 4 EVID~NCE
n~e p~interl class ~ l'yes') of printer name 5 ribbons class = ('no') of ribbon name = symptoml class = 1 of symptom ~ Rule Tree 2 text = 'Report service request number 151 018 for the $printernumber printer.' 3 ~OT

name = ribbon class - ('yes') of printerlite class - 2 of symptom The above examples illustrates how the Rule se~tion is organized.
The level of a node is indicated by an integer number at the beginning of the node definition. rne ordering of the nodes is defined by a depth-first, left to right search. The order in which the trees appear is important becauss this influences the order in which they are traced.
SYMBOLS SECTION
The Symbols section is the sec~ion of the Rulebase which defines the Symbols used in the text of Classes, ~arameters, Proced~res, and Rules. A symbol represents a text string. Symbols are assigned a text string value in the Symbols section. Elsewhere in text, the Symbol name is used rather than having to key in the whole text string. SymboIs are use~ul when text strings may frequently change or when the same text string appears in many different texts~ Symbols also make it easier to guaran~ee that text is consistent betwee~ Rulebases. The Rule writers can ~ include a Symbols section in their Rulebase and then use these ; 30 Symbols in their text. One person can be responsible for writing the text strings for the Symbols, maXing the text consistent and easy to modify.

When Symbols are used within text, the Symbol na~e must have the character '~' affixed to the beginning of the name. This allows the system to recogni2e it as a Symbol name. A Sy~bol will be replacet by the character string it represents before the text is displayed to the user.
A sample Symbols section follows:
SY~OLS
printer = 'I~M5215 printer' part2 = 'the back of the electronics board' FRU13 = 'the &printer ribbon' .

ii7.'~3 ~RN = '~'010 234 " ' tools -~ '(1) vol~meter (23 screwdriver (3) solder RULES ~4) soldering iron' 1 ÇOAL
text ~ 'l~e &printer is defective. Call your customer servics representative and report number &SRN.. The hpart that needs to be repla~ed is &frul3. . ' 0 3 ~YIDENCE
1 cl~ss = ('yes'~ of buzzing proc ~ printertest return code <> 'OO'xb The above example illustrates how the Symbols section is or~anized. ~he first word is SYM3OLS. Eollowlng this are thQ
names of the Symbols defined: printer, partZ, PRU13, SRN, and tools. Each Symbol name is assigned a string in single quot~s.
~verythi~g that is contained within the quotes is substituted for the Sy~bol nam~ in the te~t. If a single quote is used within the text it ~ust be preceded by a backslash or another ~ingle quote.
The b~ginniDg of another section terminates the Symbols section.
There can be m~re than one Symbol se~tion and th,~y can be inter~
spersed among all the other Rulebas~ sections in any order.
If some of the Symbols to b~ used by the R~le ~riters are co~mon then a c~m~n "symbol include" file may be used. This file would c~ntain a Symbol se~tion like the one des~ribed above. The file would be ''included" in the beginnin~ of the Rule flle.

To use a Symbol within a text the symbol name is preceded by an "~" (ampersand) and inserted in the text ~herever the substitution should be made. Note that the "&" is not used in the Symhol definition, ~ut is pre~ent when the Symbol is used. The Symbol ~ame can be terLinated with a blan~ or a period. If the Sy~bol is terminated w~th a blank, the blank is tseated as a ~ormal input 3S charact~r and is left in th~ inp~t line. If a Symbol ~s termanat-ed with a period, the Symbol name is concatenated with the next inp~t character and the period is removed. In the example, the G4AL text wo~ld be displayed ~s: -The IBM* 5215 printer is defective. Call your customer service representative ancl report number '013 234. ' The ~part that needs to be replaced is the IBM* 5125 printer ribbon.
* Registered Trademark , ~;72~3 Note that the Symbol SRN is concatenated with a period and the Symbol printer is not concatenated with anything but is followed by a blank. If a Symbol is undefined or misspelled when used in text, there will be no substitution perfo~med and the Symbol name preceded by an "~" will be displayed instead. For example, there is no symbol definition for "part" so instead of substituting a string "&part" is displayed.

TH~ CONCLUDED GOALS LIST
The subdivision of the knowledge into several contextual units requires that several Rulebases, rather than just one, be traced.
The same Rulebase might be traced several times in order to draw conclusions about multiple devices of the same type. Therefore, names of the Rulebases had to be tracked, not only for final lS reporting purposes, but also for stack maintenance in order to page Rulebases in and out.

- Another requirement is that all Rulebases called be completely traced and all possible ~oals concluded.
~ 20 ; Also ? all concluded Goals have to be remembered and presented to the user in an organized fashion after completion. This means storing goals internally in a list. This concluded Goals list is passed back to the ~alling program so it can sort and or~aDize the conclusions before presenting them.
The Rulebases are tracked usin~ a linked list of control blocks.
This linked list is called the RBCB List. Each control block is a record with the five fields as indicated below.
~ield A is the Rulebase name;
Field B has a return code which is zero if the Rulebase is executed successfully;
Field C has a Boolean variable which is set to true when this Rulebase is completely traced;
Field D is a pointer to the list of goals concluded for this Rulebase which is passed back to the supervisor;
Field E is a pointer to the next control block on the list;

When the supervisor lZ is called, it is passed a pointer to the RBCB list. At this point, the list has only one control block on it aDd this control block contains the name of the lnitial Rule-base to be processed. The supervisor maintains this list and ~6 ., returns it to the calling program at completion. By that time, the list should have several control blocks on it, one for each Rulebase which was called. The list may even have several control blocks for the same Rulebase if this Rulebase was called more than once.
Each control block on the list has a pointer in Field D to a Goals List concluded for that Rulebase. Each Goal List record in the individual Goals List has the following fields.
1. The text for the goal concluded, 2. The Confidence with which that ~oal was concluded;
3. A pointer to the nsxt goal.
Due to memory constraints, most text to be used by the system is stored on diskette. The concluded Goal List, however, must hold the goal text internally. The same Rulebase may be run for two different devices and character strings will be substituted into the goal text Field A to show for which devices the goal was concluded. There is only one text file on diskette for this Rulebase even though it is called multiple times. If the goal text with the substitution is written back to that fils, then only the last device tested would have the correct goal information.
Also, the particular application may be large enough that two diskettes will be required. If the ~oal text fields was written back to the currently loaded diskette, then part of the te~t would be written on one diskette and part on the other.
The fact that the system remembers the Rulebases it calls, aloDg with all the concluded Goals, increases its usefulness. This makes the system useful for applications which need to call an expert system and then return to continue processing. Because the system stores its acquired knowledge and makes it accessible to a calling program, it can become a subset of a bigger, problem solving system, unli~e other expert systems.

DATA STRUCTURES OVER~IEW
The storing in memory of Rules, Classes, Procedures, and Para-meters is done through the use of major linked lists of records.
The detailed organi~ation of major linked lists will be described in connection with Figs. 9,10,11 ~nd 12 which ~llustrate the ~ 40 various relationships of the linked lis~s for the objects.
:
First, however, a general overview is provided of the data struc-tureS. A conventional hashtable as shown in Fig. 8 is used in which the index into the hashtable is computed from the object's 7.'~3 name. Each entry in the hash~able is a pointer to a linked list of records, called hashbuckets, each of which contains a name of the object that hashed to that location in the hashtable.

Each hashbucket has a pointer to the corresponding object, whether it be a RULE node, a Parameter, a Procedure, or a Class. Each object has associated with lt a linked list of property records which hold property names and values for the associated object.
The term "property" is used interchangeably with the term "attri-bute." Examples of data stored ln property nodes are: high andlow thresholds for RULE nodes, indices into the text file for Class questions or Goal text, or a property indicating the name of the Rulebase to call if the RULE node having this property eval-uates to true.
Each EVIDENCE node is a member of some Class. A pointer is stored on the RULE node's property list under the property na~e 'Evid-source.' Evidsource points to the hashbucket which contain~ the name of the source Class. This hashbucket also has a Classref pointer to the corresponding Class node.

When the Class is evaluated, all members of this Class are up-dated. These members (all of which are EVIDENCE nodes) are located in the data seructureS as follows. The Class node has a rulelink pointer to the first RULE node which is a member. On this RULE node's property list is a property named 'member.' The member property points to the Dext RULE node which is a member of the Class bein~ considered. On this new RULE node's property list is a-property member pointing to the next member of the Classt and so on. When the last member is found~ lts property member will have a null pointer. ~hus any member of a Class has a pointer to the Class (through the Evidsource property). A11 members of the Class are linked together by a membership linked list (throu~h th~
"member" property).
EXTERNAL nodes, their relationshlp to their source Prooedure, and the membership list for that Procedure are handled in thz same way as Evidences and Classes.

When a REFERENCE node is encountered, the node it references must be located so its Confidence can be obtained. The refarencing ~ode and the referenced node must have the same name; therefore, ; they hashed to the same place in the hashtable. The REFERENCE

. .. .

;7~3 node has a pointer called 'name' which points to a hashbucket containing the node's name. This hashbucket has a Rulelink pointer, pointing to the RULL node being referenced. Once a node is evaluated, all nodes referencing it are updated. These are linked together by use of the 'Cousin' pointer in the RULE node.
Cousin points to the next node which references the RULE node at the head of the list. Thus every REFERENCE node points to the node it references (usin~ the pointer 'name'). All nodes re-ferencin~ a given node are linked together by the Cousin pointer declared in the RULE node. When the system locates a REFERENCE
node, it follows the name pointer to the original node. It then evaluates this node and updates all references to this node by following the Cousin linked list.

THE LINKED LISTS
The Rulebase comprises four major linked lists and a plurality of minor associated linked lists. Each major linked list corresponds to one of the four objects types of the Rulebase.

Tbe first ~ajor link list is for Class objects and includes a separate record for each Class oontained in the Rulebase. The Class records have the format of fields shown in Fig. 6.

The general format of the records shown in Fig. 6 depends, to some extent, on the programming language employed to code the Rulebase.
As shown each record in the Class seetion is a fixed length rscord and each has the same number of fields. The records in the other sections are also fixed length records but the length is not necessarily the same for all sections. lt may be assumed that the 3~ general for~at of the records in the other minor linked lists associated with the majos linked lists, e.g. the Property linked lists, permit a variable number of fislds in each record with each ~ield having a variable number of characters. The Pascal pro-Bra~ming language has a record struoture shown in ~ig. 7 which is employed in the preferrad embodiment of the present invention for these other associated linked lists. It should be assumed that in the following discussion, all records fo~ the minor linked lists are in the general format shown in Fig. 7 unless stated otherwise.

THE CLASS RECORD
Referring again to Fig. 6, the format of the Class records in-cludes a file index field which functions to identify the sequen-tial position of the ~eoord in the Rulebase relative to the other records. The next field is the initial weight assigned to the Class, while the third field is ~he current weight assigned to that Class. As discussed earlier, WEIGHT is an attribute or property assigned to an object that reflects on how the Confidence is calculated for that node. The flag field for a Class consists of a number of attributes or properties that can be represented in a binary 1-0 fashion. Each attribute is assigned a predetermined bit position in the ilag field. These attributes include the INITIAL attribute, the UPDATED attribute, the POWER-OFF attribute, the LOCAL and GLOBAL attributes, the SETC attribute, and the RE-ASK attribute, all of which have been described in detail earlier in the specification.

The next field, designated MLP, contains a member list pointer.
The function of this pointer is to pro~ide a vehicle to access a linked list of RULE nodes, i.e., EVIDENCE nodes that ask this question, so that when the question is asked for the first time, that answer is available to all other nodes. The details of how -the Class membership linked list (CMLL) is established and how the MLP pointer is used to obtain access will be described later on in connection with the hashtable and the property list description for the RULE node objects.

The next field in the Class record is the property list pointer which points to a linked list of properties or attributes for the Class. As indicated previously, a Property List is ~ssociated with each object in the Rul~base and while each list is not identical, there are sufficisnt similarities to warrant describing them together in order to understand and contrast the differences.
That description appears later on in the specification.

The last field in the Class record is the NCP field which contains the next Class pointer to the following Class and, hence, link the individual records into a linked list. The Class section ends with the NCP ~ield of the last Class record containing a pointer to the Procedure section of the Rulebase, specifically to the irst record in the Procedures section labeled PR1 in Fig. 6.

Since several fields in the Procedure list records are identical to the fields h3ving the iden~ical names in the Class list re-cords, they are not described again. The PF field is the Pro-cedure function field and indicates if the Procedure is to be '''. .`' ' ~7~.~3 loaded into the system from diskette, executed, or deleted from the memory of the system. The NAME field contains the name assigned to this Procedure. The following five fiPlds, Prior, Weight, Flags, MPL, and PLP fields are identical to the fields in the Class record. The field titled AP contains a pointer to the list of arguments that are passed to the Procedure being called.
Each argument to be passed is contained in a different record which has a field format that characterizes the nature of tha variable in terms of it being an inte~er or a character string, its size, etc.
In addition, a field is provided for a pointer to point to the location for the values returned by the Procedure , and a field designated NARG for a pointer to the next argument to be passed.
The record of the last argument to be passed would have a null pointsr in the NARG field.

The next field in the Procedure record is the RP field which contains a pointer to a linked list of records, each of which contains a specific value that has been generated and returned by that Procedure. The last field of the Procedure record is desig-nated NPRP and contains a pointer to the next Procedure in the linked list. The last record in the NPRP field contains a pointer to the major Para~eter list, MPAL.

The major Parameter list is, again, a linked liCt of records having a format shown in Fig. 6. Briefly, it will be recalled that a Parameter is basicallq a question that is asked of the user to obtain an answer which can be inserted into a Class-type question at a point which permits the same basic Class question associated with an EVIDENCE node to be asked in differPnt sit-uations, merely by chan~ing the variable insert.

T~E PARAMETER _ ST R CORD
The Parameter record contains ~he index field, a name field, a flag field, a property list pointer field, and a next Parameter pointer field whioh functions like their counterparts in the records previously described. The default field is unique to the Parameter recor~, in that it allows a default answer to be pro-vided by the syst~m to the question being asked by the Parameterin the event the user does not provide an answer.

TXE PROPERTY LIST

I~e property list pointer (PLP) points to a linked list of pro-perties or attributes for that object. As shown in ~ig. 6, a property list pointer (PLP) field is associated with a Class record, a Procedure record, and a Parameter record, as well as a Rule to be discussed later. When a variable piece of text is to be used with that object the attribute or property called Text Parm is assigned to the object. The variable text is obtained, for example, by previously asking the user a question such as "What is your phone number?" The question would take the form of a Parameter named "phone number," and the answer would be stored on the property list of that Parameter object under the property entitled, "Response." The name of the Parameter, "phone number,"
would also be on the property list in the "name" field. When another object, e.g., a Class, Procedure, or Parameter needs to insert the response provided by the Parameter named "phone number", the property "Text Parm" is added to the property list for that object. The "Text Parm" property points to an Associated Par~meter list which names the Parameter "phons number" whose answers are required in place of the variable text. The "Text 2~ Pa~m" attribute points to the first name in the associated pro-perty list. The first name is hashed to provide an entry into the hashtable (described next) to find the pointer to the Parameter named "phone number." Once the record named "phone number" is found on the linked list of Parameter records, its Property list is scanned. The attribute, "Response," is located, since it was assumed the question has been previously asked.

The data (408-462-4325) prsviously provided by the user was stored on the property list under the attribute Response. That stored 30 sesponse, 408-462-4325 D is then inserted for the variable text in the ob;ect.
~ ~ ' If, in scanning the property list, the system finds that the question was not asked, as indicated by a flag bit, then the attribute Text is located which provides a pointer to a list of ~ text records for this Parameter. The text record contains a ; message pointer into a message file which is a file of records containing all of the text phrases that are used in the Rulebase.
The message pointPr points to the appropriate text for the ques-tion to be asked which is then prese~ted to the ~ser.

T~E HASHTABLE

The details of the hashtable referred to earlier will now be discussed in connec~ion with Fig. 8. The hashtable 80 is stored in a predetermined area of memory and consists of a series of sequential memory locations 81 which store pointers ~2. It will be recalled ehat each object, e.g., Class, Procedure, Paramater, and RULE node has a name which is, for e~ample, eight characters long. A hashing algorithm involving a calculation is employed to convert each name to an address in the hashtable section of the memory. The hashtable, for example, may include 100 different memory addresses. The hashing algorithm would operate to convert, for example, 1,000 different object na~es, so that more than one name gets converted to a given hashtable location. Each location in the hashtable contains pointer 82 to a different linked list 83 of records having a field format as shown in Fig. 8. These linked lists of Records 84 associated with the hashtable are referred to as hashbucXets, and the pointer 82 in the hashtable ~0 is referred to as the hashbucket pointer (XBP). The record 84 includes a field 85 for the name that was hashed, a series of 86 fields for pointing to the location in memory where the object or objects are stored, and a field 87 referred to as the next hashbucket pointer, for storing a pointer to the next hashbucket on thP list. Ihe memory location reference pointer fields 86 contain either the Class reference, the Procedure reference~ the Par~meter reference, or the Rule reference pointer, depending on the type of object whDse name was hashed to the corresponding entry in the hashtable.

It should be understood that one of the main functions of the hashtable ~0 is involved in associating a name that has been assigned to an EVIDENCE node or an EXTERNAL node on a Rule tree in the Rulebase , whose ~oal has been selected to ba concluded, to a pointer. ~Since the node has a name, the location of the object having that name on one of the ma~or linked lists is obtained through the hashing process to obtain the reference pointer to that object. The hashtable 80 also functions to locate an object using the object name for other reasons, to be discussed later.

The records for the major Class list and for the major Procedure list as shown in fig. 6 include a field MLP for storing a member-ship list pointer MLP. It will be recalled ~hat, whîle the samequestlon (Class) ~ay appear in many different RULE nodes throughout the Rulebase, it will only have to be asked once, the first time it is referenced in an EVIDENC~ node. After that, all - `: . ~ .

~,9-86-007 7~3 other nodes that ask the same question are automatically updated by the system. A similar situation exists for Procedures, in that all nodes h~ving that Procedure name and a GLOBAL attribute are updated with results that are obtained from running the Procedure the ~irst time.

The vehicle for updating the Class ~bjects or Procedure objects is the Membership Linked List that is pointed to by the Class MLP
pointer or Class objects and a Proced~re ~embership linked list for the Procedure objects.

MEMBER HIP EIST-CLASSES
The relationship of the Class object's membership linked list pointer to the RULE nodes that are members of the Class can be seen by reference to Fig. 9. In Eig. 9, the first record 90 in the ~ajor Class linked list contains the membership list pointer 91 ~n the field 9~ MLP. This pointer, represented by line 91, points to a field 93 in the hashtable called, "X~le Reference."
Rule reference contains a pointer 94 to the first RULE node in the Rulebase using this Class. That RULE node is in the major Rule linked list and, as such, is represented by a record having a field 96 called "PLP," which contains the property list pointer 97 that points to the linked list of properties 98 for RULE node 95. The linked list of properties 98 for RULE node 95 includes a record 99 having the property name, "Member." The record entitled "Membsr" includes a field 100 called "Next Member Pointer," and a field 101 called, "Next Property Pointer." The next member pointer 102 points to the RULE node (not shown) in the major RULE
node linked list whioh is the second Member of the Class. This second RULE node also includes a property list which, in turn, includes a record named, "Member," which includes a field called, "Next Member Pointer." As before, the Next Member field contains a pointer to the third RULE node, located at some point in the ~ajor Rule linked list which i5 a member of this Class.
The above described chaining process is repeated until the last m~mber of the Class is reached, which is si~nified by the next ~ember propeFty pointer being a null pointer.

The Class m~mbership linked list for a Class object may therefore be viewed as a selected subset of RULE node objects from the major RULE node linked 11st, the top RULE node of the subset being selected for the subset by the Rule reference pointer 94 in the .

~2~ 3 hashtable that is addressed by the membership list pointer 91 from the Class objert 90. Subsequent RULE nodes belonging to the Class are selected for the subset by a nex~ mæmber pointer 102 located on the property list 98 of the ~ULE node 95 in a record 99 named "member."

MEMBERSHIP LIST -_PROCEDURES
The membership linked list for a Procedure object is related to the Rrocedure objects, the hashtable, and the RULE nodes in a manner identical to the membership linked list for a Class des-cribed above. As illustrated in ~ig. 10, the first Procedure record 110 in the major linked 11st of Procedure ob~ects includes a field 111 called the membership list pointer field which con-tains a pointer llZ to the Rule reference field 113 of the hash-buc~et associated with Procedure 110. ~ule reference fieldcontains a pointer 114 which points to the first RULE node 115 that uses this Procedure. RULE node 115 has a field 116 which contains the Property List pointer 117. Pointer 117 points to the linked list 118 of properties. The property 119 named "member"
includes a next member iield 120 having a pointer lZl which points to the ~ext or second RULE node that uses this Procedure.
The chaining procegs described above is repeated until all RULE
nodes that are members have been identified. The last RULE node of the membership list has a null pointer in the next member field PARAMETER LINKED LIST ORGA~IZATION
The organization of the Parameter linked list and the relation-ships o~ ~he Parameters to the hashtable a~d RULE Dodes is shown in Fig. 11. Entry into the Parameter list 132 is required pri-marily in two different situations, both of which originate durin~
the processin~ of either an EVIDENCE node or an EXTERNAL node such as node 133. As described in connection with the property list, the attrib~te TXT Parm is assigned to an object that uses text that includes a variable piece of data which is provided by the user (or Procedure) in response to the-question asked by the Parameter. The Parameter name appears on the Property list of the Class or Procedura associated with the RULE node. The variable to be inserted in the text of the RULE node 33 being processed has previously been stored in memory at a locatlon that is pointed to by a pointer in the "Response" field. The Response field is on the Property list of the Parameter whose answer is to be inserted as the variable. The problem is to find the location of the -: . ;. , ~7~ ~

Parameter on the linked list so that the answer can be inserted into the text to be displayed by the node currently being pro-cessed. An associated ParamPter list is developed for a node that requires the answer from a Para~eter. The list includes, for each entry, the name af the Parameter, a pointer to the location of the Parameter, and a pointer to the next entry since more than one Parameter may be required. By pointing to thz first entry in the associated Parameter list with a pointer in the TXT Parm attribute - 135 of the node bein8 processed, the system is able to locate the answer to the question which is to be inserted.

The other situation is shown in Fig. 11 and involves locating the Parameter which is named so that the actual text can be presented to the user as a question to obtain the response. The text of the question to be presented is in a message file. The location of this message file is pointed to by the message pointer located on the property list of the Parameter in an attribute field called TEXT. The Param2ter is located by the Paramref pointer in a hashbucket that is located by hashing the name of the Parameter that is obtained from the node 33 being processed.
.

The Rule List The last major section of the rulebase to be described is the Rule List whieh is shown in Fig. 12. The Rules List is basically 2X similar to the other linked list in the rulebase, in that each node or record points to a succeeding node. However, since each node generally points to more than one other node in the list, it is more easily visualized as a tree type structure, as shown in Fig. 12.
Each node, as shown iD ~ig. 12, includes a plurality of fields such as the fields, fileindex, node type, ass~ciation, wait, flags, and name, in addition to a numb~r of fields for pointes~ to other related nodes in the rulebase. These pointers are shown next to the top dummy node 1~0, and are named following a "family tree" convention such as Father, Brother, Cousin, First Son, and Last Son, to convey a relative relationship to other nodes. The 9rother pointer points to node havin~ the sa~e Father node and positioned at the same level in the rule tree. The Cousin pointer points to a noda that i5 being referenced. Each node also has a pointer to a property list which functions in a manner that is identical to the property lists associated with the other linked lists, as described previously.

7,'~3 Each leaf node in a rule tree has a relationship to a node in the Class linked list or on the Procedures linked lists. As a node is being processed, the node t~pe is identified. If an evidencP node is identified, the property "EVIDSOURCE" is locat2d on the prope~ty list of ~he node. This property contains the n~me of ~he Class with which ~he rule node is associated. That name is hashed to provide an entry into the hashtable and hashbucket for locating the related Class object on a linked list of Classes, as described previously.

If the leaf node is identified as an external node which identifies a procedure to call, a similar series of steps are taken to locate the associated Procedure definition on the linked list of Procedures.
lS The internal nodes of the trees are involved primarily in the logical calculation of confidences and passing these calculated values of the confidences up to the GOAL node following some prescribed algorithm. These functions are handled by specific programming modules which are part of the inference engine.

OPERATION OF SYSTEM
A summary of the operation of the system will now be described in connection with Fig. 13.

Fig. 13 illustrate the organization of ~he various programming routines that are includ2d in the CONSULT function referred to earlier in the specification.

CONSULT has a SUPERVISOR routine which interfaces to the program calling the Expert System and returns to it the list of concluded goals. SUPERVISOR is responsibl~ for keeping a list of t~e rulebases called and a list of the goals concluded for each of the~e r~lebases. It loads in the initial rulebase. When another rulebase is called, it stores out the calling rulebase along with the information Bathered for it so far (e.g., answers to class questions, values returned from procedures, and confidences obtained for goals) and loads in the called rulebase. It is also responsible for passinS between rulebases information such as an answPr to a class or values returned from a procedure.
SUPERVISOR calls the rout~ne INFERENCE which contains the infer-encing logic. INFERENCE performs the main consultation routines.
It will select goals to be tested and then backchain through the nodes under the selected goal to find evidences or external nodes ': .

2~

to evaluate. INFERENCE, along with the procedures it calls, causes questions to be asked and procedures to be run, and draws conclusions based on this information. INFERENCE returns to SUPERVISOR when a ~oal is concluded, a rulebase is exhausted9 a new rulebase is called, a severe error oocurs, power is about to be turned off, or a break key is entered.

When the INFERENCE routine is called by the SUPERVISOR, its first action is to run the routine GOAL SELECTOR to select a goal to trace. That goal will be the root of a tree which is then search-ed in a postorder traversal until the first unasked leaf node is found. This searching is done by the BACKCHAIN routine. When an evidence or external node is found the rsutines EVALEVID or EVALEXTERN are run, the property list is scanned until the pro-perty name "evidsource' is found. This property contains a pointer to the hash table which, in turn, points to either the class node (for ~he question which needs asking) or the procedure list entry (for the procedure which n eds calling) when the data is obtained by running the ASK CLASS routine or the PNI routine.
The weight of that node is updated by routines UPDATE CLASSES or UPDATE PROCS followed by the updating of all references to that node. As soon as a refe~ence node ls updated, its weight is passed as far up the tree in which it is located as possible.
Once all referenees to a node are updated and passed up, the : 25 weighe of the ori~inal evidence or e~ternal node will be passed up. During all passing up routines, references to any node established along the way will be updated and passed up recur-sively. Finally, any other nodes which are members of the sa~e class or procedure definition will be evaluated in the same manner by the UPDATE MEMBER routine.

At any time durin~ this processing 9 a rulebase call c~n be en-countered. To resume processing iD the original rulebase after the exhaustion of the called rulebase, several things need to be determined. First, the tree or goal which was selected needs to be locatedO Second, the question or procedure which was asked or ~xecuted should be isolated. ~hird, ths e~idence or external node a~ked or executed shou~d be i olatet. ~ina~ly, if all of the references ~o tha~ node were updated and passes up, the node above the evidence should be found and e~amined. Eventually, the node n which the rul~base call was initiated will be found.

, .

As discussed earlier, to mark nodes for resumption, two Boolean values are associated with each node: an 'asked' fla2 and an 'updated' flag. Each class, procedure, and rule node has a flag to indicate whether or not it has been asked, and a flag to indicate whether or not it has b~en updated. Rule nodes also have a 1ag for indicating if the rulebase call associated with it has been performed. A class is marked asked' as soon as it has been presented to the user. A procedure is marked 'asked' as soon as its procedure call has been executed. A rule node is marked asked as soon as its evaluation function is performed and the node is given a weight. The updated' flag is used to find the node in progress. A class or a procedure is marked updated' as SQon as all evidence or external rule nodes which are me~bers of this class or procedure have been evaluated, updated, and passed up. A
reference node is marked updated' once its weight has been passed up the tree as far as possible! All other rule nodes are marked updated' as soon as all references to them have been updated and passed up. Since it i5 necessary to insure that a rulebase is not called more than once from the same node, each rulenode has a third Boolean flag associated with it. A ~ulenode is marked re-ported' as soon as its call is found and invok~d.

When a rulebase i~ re-entered followin~ a call to another rulebase or after powering off the machine, the S~PERVISOR program passes a single Boolean value to INFERENCE routine indicating that tnis is not the first time this rulebase has been encountered. If this Boolean value is true, a routine is called which looks through the list of classes for a class which has been marked 'asked,' but not marked 'updated.' If an asked but not updated class is found, its members are examined until an asked, but not updated evidence node is located. The references to this evidence node are checked to see that all have been asked and updated. If so, the nodes above the evidence node are examined; otherwise, the nodes above the asked but not updated reference node are examined. Finallyl a node whicb was asked, but not updated is found. It is the node at which the tracing of the rulebase was suspended. If there arç no ~uestions which are asked but not updated, then the list of proceduses will be examined for procedure calls which are asked but not updated in the same man~er. Ev~ntually, the location of 40 the node which caused the intesruption is isolated, and processin~
can rçsume from the point at which it left off.

Al`9-86-007 Following is a short description of the routines shown in Fig. 13 including pseudocode programming statements for many of the more involved rou~ines.

PROGRAMs: SUPERVISOR
FUNCTION: Supervising program;
This program calls INFERENCE. It handles multiple rulebase calls and the passing of information between rulebase calls. It re-ceives the pointer to the initial linked list.

PSEUDO CODE:
begin program.initialize variables and pointers for call to initial rulebase;
.. loopl:while (rule bases to be processed) do ...loop2: while (continue on current rule base) do ....call INFERENCE:
... case of ..... (goal concluded) ....... add goal to list;
..... (rule based finished) ....... If no more rulebases to do ........ then leave loopl ........ else ......... pop rulebase stack to uncover next rulebase;
......... leave loop2;
..... ~call to new rulebase) ....... store current rulebase for future use;
....... push new rulebase nzme on stack;
....... leave loop2;
..... (turn ~ff power) ....... store current rulebass~ for future use;
....... prompt uss~r to turn the machine off;
....... change action if he does ~sOt;
...end loop2;
...set variables for next rulebasz from current place on stack;
..end loopl;
end program;
INPUT: s Pointer to system control block containing initial rulebase name.

OUTPUr: ' Same pointer, list now complete.

PROGRAM: INFERENCE
FUNCTION: Main inference engine;

AT9^86-007 ,3 This procedure performs the main consultation rout~nes. It will select goals to be tested, backchain through tha nodes of a goal to find evidences or external nodes to e~aluate. It will return to the extended supervisor with concluded goals, rulebase calls, goals to be removed from the soal list after resets from the user, or when the rule-base is exhausted.

PSEUDO CODE:
firsttime then .reset the weights of classes, nodes, and procedure 0 calls ask classes and execute procedures designated initial ..else if last action was not goalconcluded then ...CONTINUEPASSINGUP
..while not timetoreturn then repeat ...~OALSELECTOR(currentgoal) ....if goal asked then O.O.... timetoreturn = true;
..... action = rulebaseexhausted ....else ..... currentnode = currentgoal .~..... BAGKcHAIN(currenenode) ..... case of currentnode .nodetype of ...... evid : EVALEVID(currentnode) ....,.extern : EVALEXTERN(currentnode) .. until timetoreturn to systemreset end;
.

INPUT:
Rulebase pointers, flag for firsttime and resume, etc.

O~TP~:
Action - action to be taken by Supervisor Goalinformation - text and confidence of concluded goal Rulebasename - filename of rulebase to call MODULE NAME: ASKCLASS
FUNCTION: Ask a class question;
This procedure accepts as input a pointer to the class currently of interest. It determines whether or not that class should be asked or re-asked based on the current values of the class' attributes. It asks the question when appropriate and calls UPDATECLASSES to update nodes that are ~embers of that clas~.

PSRUDO CODE:
if class should be asked ~depending on local, global and reask attributes) .then begin ..if parameter(s) in text ...then obtain parameter text and merge into ques~iOn text;

"~'`, . ~' AT9-86-00t ~.~6'~3 ...... ..........~et answer property;
...... ..........get number of choices p~operty;
...... ..........call UIO (the user interface routlne) to display question and obtain answer(s);
...... ...........if class not local then asked = true;
...... ...........if (class is looal) or (class is settable) or (class ~hould be updated) ..... then UPDATEMEMBER(current class) ..... else UPDATECLASSES(current class);
....end then;
.elsP UPDATECLASSES(current class);
INPUT:
Pointer to current class;
Pointer to current rulenode;

OUTPUr:
Timetoreturn may change to TRUE indicating that contro]. should pass back to the supervisor.
MODULE NAME: BACKCHAIN
FUNCTIONo BacXchain in preorder through tree to get next node to evaluate;
This procedure returns the next node to evaluate in the current rule tree. This node will be either:
1) Unasked evidence 2) Unasked or reexecutable extern 3) Asked but nonupdated node of any other type after resumption from another rulebase call.

PSEUDO CODE:
outoftree := false;
.while not outoftree and not foundnode do .. if nodetype = alternate then REPORTALT
..else if nodetype = reference then switch to 3Q referrenced node ...else if unasXed ....then if firstson = nil ..... then runtimerror(4); outoftree = true ..... else cùrrent node z first son ....else if brother = n~l ..... then runtimerror(l2); outof~ree = true .. O.~else rurrentnode := brother .end while INPUT:
Pointsr to a node at the top of a tree found by GOALSELECTOR
.
OUTPUT:
Pointer to the next node to evaluate in establishing that original node.

~2~223 MODULE NAME: CONTINUEPASSINGUP
FUNCTION:Continue passingup weights from point in which inter-ruption occurred;
This procedure is called from the main inference routine after bein~ invoked by the Supervisor following a call to a new rulebase. It will resume updating classes, procedures, or pass-ingup from the point at which the rulebase call was made.
Class and procedure nodes which have been asked will be marked either updated or not updated. If they are updated, all members of that class or procedure have been evaluated and weights passed up the tree. If they are not updated, then interruption to the normal update and passin~up routines to members of this class occurred.
Interruption of processing could have occurred while updating references to a particular node. If this has happened, the node in question will be asked, but not updated. If a non-reference node is updated, all references to it have been updated and weights passed up. A reference node will be marked updated as soon as its weight is passed up.

PSEUDO CODE:
currentclass - classhead while currentclass <> nil and not (currentclass asked ~ not updated ~ not settable) .currentclass = currentclass next if currentclass <> nil then .UPDATECLASSES (currentclass, timetoreturn) else .currentpr~c - prochead .while prochead <> nil and not (current proc asked and not updated) do ..currentproc - eurrentproc_.next .~f currentproc <> nil then O.UPDATEPROCS(currentproc, timetoreturn) .else ..nodeinprogress = current~oal ..BACKCHAIN(noteinprogress) ..UPDATEREFS(nodeinprogress,timetorsturn) ..if not timetoreturn and father <> toprule then ...PASSIN W P(nodeinprogress, ti~etoreturn) INPUT:
Pointer to current~oal, classhead, prochead, and toprule OUl'PU~:
Rulebase updated as much as possible after evaluating last evidence or external timetoreturn will be true if a call to another rulebase is encountered during the continuation ~f pass-ingup.

7~

MODULE NAME: EVALEVID
FUNCTION- Evaluate evidence node;
If the current evidence node is a member of a class, then EVALEVID
call ASXCLASS which asks the question and sets the weight for that node. If the ~ext is in ~he evidence node, then EYALEVID asks *he question and computes the weight itself. If the node if not a member of a class nor is there text in the node, then the node is given the weight it had previously. EVALEVID then normalizes the node if it has the normalize property and marks the node as asked.
It then calls PASSINGUP to pass the confidence as far up the tree as possible. After returning from PASSINGUP, if it is not tims to return, it marks the current node as updated.

PSEUDO CODE:
If evidence node is a member of a class .then begin ..ASKCLASS~curntclass, curntnode, timetoreturn);
...if syste~reset then return;
...end .else if question text is in evidence node ..then begin .O.ask the question in the evidence node;
...compute the weight for the node depending on the answer;
~.end ..else curntnode.weight = curntnode.priorweight;
if curntnode.normal = true then normali~e;
curntnode.asked = true;
PASSINGUP(curntnode; timetoreturn~;
if not timetoreturn .then curntnode.updated = true;

INPUT:
Pointer to current node (an evidence node);

OUIPUT:
Evidence node evaluated and weight is set;
timetoreturn may change to true indicating that control should be passed bac~ to the Supervisor without further evaluation;

MODULE NAME: EVALEXTERN
FUNCTION:Evaluate external node ~ach extesnal node refers to a procedure by name. The external node is said to be a member o~ this p~ocedure.

An external node can make ~n indirect reference' to a procedure meanin~ that if the procedure has not already been executed~ this 6~

., . -- AlY-~o-uu, ~7~.3 external node will not cause it to be executed. Instead, it will pass up minweight (or false) to its parent node.
The function of procedure EVALEXTERN is to cause execution of ~he procedure which the current external node is a member. This is assuming that it is not an indirect reference. If this external node has the local or reexecute attributes or any parent i~ local, then the weight is passed up only in the current treP. Otherwise, any external node which is a member of this procedure i5 updated.
If the external node has an indirect reference to a procedure, then the procedure is not executed, the node is ~ivPn the minimum weight allowed, and that weight is passed up the tree.

PSEUDO CODE:
whichproc = procedure of which curntnode is member;
if curntDode is not an indirect reference to procedure .then if (whichproc is not asked) or (curntnode is reexecutable~ or (whichproc is local) ..then begin ...display associated text;
...if xtrace is on ....then display input parameters;
...call PNI(whichproc); (i.e.the procedure node interface routine *) ...if ~trace is on ....then display return parameters;
...if (whichproc is local) or (curntnode is local) or ~curntnode has a local father) or (curntnode is reexecuted) .... then UPDAT~MEMBERPROC(curntnode, whichproc 9 timetoreturn,) 25 .... else beBin ..... mark whichproc as asked and established;
..... UPDATEPROCS (whichproc, timetoreturn);
..... end else;
...end ...else if (whichproc is asked) and (whichproc is global) 30 .... then UPDATEPROCS(whichproc, timetoreturn);
..else (*curntnode is an indirect reference to ~rocedure ...begin ....mark curntnode asked and established;
....curntnode's weight - minweight;
....PASSINGUP(curntnode, timetoreturn);
....if not timetoreturn ..... then mark rurntnode updated;
35 ... end;
INPUT:
Pointer to current node (an external node);

OUTPUT:
External node evaluated and weight is set;
timetoreturn may chan~e to true indlcating that control should be passed back to th~ supervisor without further evaluation;

~7,~3 MODULL NAME: PASSINGUP
FUNCTION:Evaluate nodes and pass ~eights up the tree.
1) Save current node's wei~ht as the prior value.
2) Call a procedure to e~aluate the function asso~iated S with the code name to obtain a new current weight.
3) If the node is not asked or if was already asked and its weight did not change and it's not global and already updated then don't continue any further.
4) If the current node is asked and not reported yet, then if the weight is above the high threshold, set any classes or params specified for this node 5) If the current node is asked and not reported yet, then if the weight is aboYe the high threshold, see if any rulebase calls should be made.
6) If there was no rulebase call then update references to th~ current node.
7) If no rulebasecall encountered and the node is not at the top of the tree, then continue investigating parents.
PSEUDO CODE:
continu z true;
wasasked = curntnode .asked;
while continu do .priorweight ~ curntnode .wei~ht;
2 .case curntnode .nodetype of .. goal: EVALGOAL
.. hypothesis: EVALGOAL
evidence: if not reported then wasasked = false external: if not reported then wasasked = false .. and: EYALAND
.. or: EVALOR
.. not: EVALNOT
.. wand: EVALWAND
reference: ~VALREF
..pand: EVALPAND
..alternate: EVALALT
..preempt: EVALPREM
.end case: s .if node not just updated then continu = false;
.if continu and not reported ..tben if wei~ht > threshold ...then ....set classes;
set parameters call rulebases;
if rule~ase to call then continu = false;
.if continu .. then UPDATEREFS(curntnode, timetoreturn);
.if timetoreturn or curntnode at top of tree ..then co~tlnu = false9 .if continu ..then curntnode - curntnodP .father;

"
:

Z,~

.end; (*while continu = true*) end procedure;
INPUT:
Pointer to currentnode Ol~TP~
timetoreturn may change to true indicating that control should be passed back to the supervisor MODULE NAME: UPDATEREFS
PUNCTION:Update references to current node This module updates all references to the current node and calls PASSINGUP for each node updated. References to a node are called cousins' of that node.

PSEUDO CODE:
if (curDtnode is not a reference node) and ~curntnode is asked) and (curntnode is named) and ~curntnode is not updated) .then begin ..curntref = cousin of curntnode;
..while (curntref <> nil) and (not timetoreturn) begin ...if [ (curntref not as~ed) or (curntref as~ed but not updated~ and (no father is global) 3 ....then begin O...... PASSINGUP(curntref, timetoreturn);
..... if not timetor turn ...... theD curntref.updated = true;
..... end;
O.~.curntref = curntref .cousin;
.. end while;
..if ~(not evidence node) and (not external node) and ~ (not timetoreturn~ ]
... then curntnode .updated = true;
..end then .else if (curntnode is not referenced) and (curntnode is asked) ..then curntnode .updated~~ true;
INPUT:
Poin~er to currentnode OUTPUT:
timetoreturn may change to true indicating that control should be passed back to the supervisor The following modules which are also shown in Fig. 13, and are a part of the inference program, are only described in terms of their overall function and relationship to other de~cribed . :

modules. The pseudo code for these modules is considered trivial since it is ~ell within the skill of an average programmer to implement the described functions.

MODULE NAME: EVALALT
~UNCTION: Evaluate alternate node;
This procedure evalua~es an alternate node. An alternate node has two subtrees, where the left subtree is an evidence node. EVALALT
presents to the user the question for the evidence node. It asks the user whether he is able to answer the question. If the user responds with 'yes,' then the question is asked and the confidence obtained for that answer is the confidence given to the alternate node. If the user responds with 'no,' then and only then is the right subtree traced. In this case, the confidence calculated for that subtree is the onfidence given to the alternate node.

MODULE NAME: ~VALAND
FUNCTION: Evaluate and node;
This procedure evaluates an and node. It retri~ves the confiden-ces of its children nodes and computes its own confidence form ~hese. An and node takes the minimum confidence of its children.

MODULE NAME: EVALGOAL
FUNCTION: Evaluate ~oal node;
This procedure evaluates a goal node. It retrieves the confid-ences of its child node and computes its own confidence from this.
A goal node takes the weight of its single child and if it is abov0 the GOAL node's upper threshold, the goal is concluded to be true and its conclusion is added to the goal list.
.
MODULE NAME: EVALOR
~UNCTION: Evaluate or node;
This procedure evaluates an or node. It retri~ves the confidences of its children nodes and computes its own confidence from these.
An or node takes the maximum confidence of its children.

MODULE NAME: EVALNOT
FVNCTION: Evaluate not node;
This procedure evaluates a not node. It retrieves the confidences of its child node and computes its own confidence from this. A
not node takes one minus the weight of its child node.

. .

MODULE NAME: EVALPAND
FUNCTION: Evaluate pand node;
This procedure evaluates a pand node. It re~rieves the confid-ences of its children nodes and computes its own confidence from these. A pand node takes the sum of the weight of its children.

MODULE NAME: EVALPREM
FUNCTION: Evaluate preempt node;
This procedure evaluates a preempt node. A preempt node has two subtrees and an upper ~nd lower threshold. The confidence for the left subtree is first obtained. 'If it is above the upper thres-hold or below the lower threshold, then the right subtree is never traced and the preempt node is ~iven the confidence value of the left subtree. If, on the other hand, the confidence for the left subtree is between the lower and upper thresholds. The the confidence for the right subtree is the value given to the preempt node.

MODULE NAME: EVALRE~
~UNCTION: Evaluate reference node;
This procedure svaluates a ~eference node. A reference node GCCUrs only at the leaf of a tree. A reference node takes the, confidence of the node which i~ references.

MODULE NAME: E~ALWAND
~UNC$ION: Evaluate wand node;
This procedure evaluates a wand node. It retrieve the confidences of its children nodes and computes its own confidence from these.
A wand node takes the average of the wei~ht of its children.
MODULE NAME: GOALSELECTOR
PUNCTION: Select next goal;
This procedure chooses the nextjunas~ed goal in the rulebase.
Only goals or hypotheses nodes at the top of a tree will be returned. If all goals have been asked already, the goal returned will be marked asked.

MODUL~ NAME: PNI
FUNCTION: Procedure node interface;
PNI is passed a pointer to a procedure node when this procedurs is to be executed. From the definition in this procedure node, PNI
obta~ns the values to be passed and builds a call to thP proced-ure. The procedure was not bound in with the system before e~ecution. After the procedure returns control to PMI, PNI takes values returned from this procedure and puts them in~o the appro-priate places in the system data structures.

MODULE NAME: REPORTALT
FUNCTION: Investigate and report alternate node;
This procedura will investigate an alternate node in order to determine which branch of the subtree should be used for bacX-chaining. The node which is the root of that subtree is returned as curntnode. The node passed to this routine must ha~e been previously found to be an alternate node.

MODULE NAME: UIO
FUNCTION: User Input/Output interface;
The user ~nterface routine takes care of all interaction between the system and the display and between the system and the key-board. It displays questions, processes user input, recognizes when speclal keys are pressed (such as quit or escape), and is used to display the goals concluded.
MODULE NAME: UPDATECLASSES
PUNCTION: Update all evidence nodes which are members of the current classes;
This procedure is called after a class has been evaluated.
~5 UPDATECLASSES updates all evidences which are ~embers of this class (i.e., all evidences which refer to this class~ by calling VPDATEMEMBER. A node is NOT updated along with other members if it (1) ls not local, (2) does not have the reask attribute, and (3) does not have any local fathers.
MODVLE NAME: UPDATEMEMBER
FUNCTION. Updata single member of current clas~;
Once a c}ass is evaluated, thisjprocedure is called to update a sin~le member of that class. Then procedure PASSINGUP is called to pass the confidence obtained for that node up the tree.

MODULE NAME: UPDATEMEMBERPROC
YUNCT~ON: Update ~ingle member of current procedure;
Once a procedure call has been executed from the rulebase, this 40 procedure is called to update a single member of that procedure.
Then the procedure PASSINGUP is called to pass thP confidence obtained for that node up the tree.

' ~
. : :

MODULE NAME: UPDATEPROCS
PUNCTION: Update all members of the current procedure;
Once a procedure call has been executed from the rulebase, all external nodes which are members of this procedure have their weights updated and passed up the tree. UPDATEPROCS locates all external nodes which are members of this current procedure and for each member, UPDATEMEMBERPROC is oalled.

The manner in which Rulenodes of the rulebase are structured to obtain data that the user might also be asked for is illustrated and described in connection with Fig. 14a. The Rulenode shown in ~'ig. 14a is part of a process for testing a printer. It should be assumed that a number of different printers are supported by the system, but that only one printer is normally attached to the system at any gi~sn time. It should be further assumed that a test procedure can be run that is able to dstermine the printer type that is attached to the system, provided that the cable between the printer and the systeD is o.k.

The printer type is required because at external node K, shown in ~ig. 14a, "test 52" is only run if the attached printer is an IBM
Model 51S2 printer. The test type test is run at node F and the appropria~e F, G, H, or I node will be concluded. Nodes F~ G. and ~ each have an action attribute "SETC" (class) type equal (printer type) depending on the return code obtained from the test unit at th& conclusion of the test. Note that node I does not set the class "type." As a result, the class type is not set if node C
was false, i.e., the printer cable is dead or if node I was true, i.e., either the Models 5152, 5219, or Epson Model 20 were attached to the system under those oonditions. The class question at node J is thereLore asked of the user to obtai~ the printer type. However, since node F determined that the attached printer was an IBM 5219, the action attribute "SETC" type causes all nodes of this class to be set to the answer obtained by node F. All ev~dence nodes reerencing the class "type" will therefore bypass the user query since the answer has already been obtained.
.
Fig. 14b illustrates another example of the manner in which the rule nodes are constructed in accordance with the present invention. In this example a display is being tested. Node C is in an external test that runs a test unit that displays information on the screen of the display device. The user is then asked to compare the display with the known diagram that has .

2~3 previously been provided in the documentation. In some situations represented by node E, a test can be run to determine whether individual pels of $he display are on or off and whether thPy compare correctly to some pre-established standard. If so, the "SETC" attribute of node $ sets the class "match" equal to 1 in node H. As shown, node H belongs to a Rulenode headed by the goal node F. Thus, tests performed by nodes in one tree can set the answer to class questions to be entered by evidence nodes in other trees.

While the invention has been shown and described with reference to a preferred embodiment thereof, it should be-understood by those skilled in the art that various changes in the form and details may be made without departing from the scope and spirit of the ~5 invention.

Claims (9)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. In a method for collecting information by tracing a rule base of an expert system with a data processing system having a processing unit which functions with said expert system program as an inference engine, the improvement comprising the following steps in combination, a) establishing in said rule base, a rule tree having a goal node and at least one evidence node which functions to present a class question to a user of said system, and, b) selectively setting the answer in said one evidence node without obtaining said answer in response to asking said class question to said user, said step of setting the answer including the step of determining the answer to be set in accordance with information obtained from at least one other node in said rule base which does not ask the same class question.

2. The method recited in claim 1 in which said step of establishing said another node establishes said another node in the same said rule tree as said evidence node.

3. The method recited in claim 2, further including the step of providing for use in each node of said rule base that can obtain data, an attribute which functions selectively to set said answer for said evidence node.

4. The method recited in claim 3 in which said evidence node operates to present a class type question to said user only if the class question is designated "un-asked,"
further including the step of designating said class question "asked" in response to said step of setting said answer from said other node.

5. The method recited in claim 4 in which said step of establishing said another node includes the step of establishing an external node, further including the step of executing the external procedure specified by said external node in order to obtain said information.

6. The method recited in claim 5 in which said expert system is operating to diagnose said data processing system and said step of executing said external procedure n directed to determining a model number of a specific system component that is attached to said system.

7. The method recited in claim 6 in which said step of executing said external procedure is directed to determining the model number of a specific system component that is a printer.

8. The method recited in claim 7 in which said step of executing said external procedure includes the step of conducting a test unit for determining a type of printer attached to said system.

9. The method recited in claim 1 in which said step of establishing said another node establishing said another node in a different rule tree than said evidence node.