ebook img

NASA Technical Reports Server (NTRS) 19920014129: Combining factual and heuristic knowledge in knowledge acquisition PDF

18 Pages·0.85 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview NASA Technical Reports Server (NTRS) 19920014129: Combining factual and heuristic knowledge in knowledge acquisition

N92-23372 Combining Factual and Heuristic Knowledge in Knowledge Acquisition* f_ Femando Gomez, Richard Hull, Clark Karr sF _ Department of Computer Science University of Central Florida Orlando, F1 32816 gomez_cs.ucf.edu (407) 823-2764 Bruce Hosken, William Verhagen Grumman Abstract is a distributed computer network, which in- tegrates software, microcode, display switches A knowledge acquisition technique that and hardware interface devices. OPERA is combines heuristic and factual knowledge rep- intended to function as a consultant to the resented as two hierarchies is described. These operations staff assigned to each CCMS task. ideas have been applied to the construc- Two basic expert systems form OPERA: the tion of a knowledge acquisition interface to Real Time System Error Manager (RTSEM) OPERA (Expert System Analyst). The goal and the Problem Impact Analyst (PIA). When of OPERA is to improve the operations sup- an error occurs, RTSEM displays information port of the computer network in the space on this error obtained from a data base of shuttle launch processing system. The knowl- errors. This information, although based on edge acquisition bottleneck lies in gathering the CCMS message catalog information, con- knowledge from human experts and transfer- tains experiential knowledge that "resides in ring it to OPERA. OPERA's knowledge acqui- the head of tile human experts, not in texts." sition problem is approached as a classification The knowledge acquisition bottleneck that the problem-solving task, combining this approach designers of OPERA are presently experienc- with the use of factual knowledge about the ing is in gathering this knowledge from the hu- domain. The interface has been implemented man experts and transfering it to OPERA in in a Symbolics workstation making heavy use a form assimilable by the data structures and of windows, pull-down menus, and other user- algorithms of the expert system. OPERA con- friendly devices. tains about one hundred thirty of these errors, but the actual number of errors in the com- puter network is greater than one thousand. 1 Introduction Hence, OPERA is short in its knowledge base by a factor of ten. The goal of this project The goal of OPERA (Expert System Ana- is to build a knowledge acquisition interface lyst; Adler, 1989) is to improve the operations by means of which a domain expert without support of the computer network in the space knowledge of OPERA or expert systems will shutt/le4a_nch processing system. The check- be able to transfer his/her knowledge about out, controI_-and monitor subsystem (CCMS) the computer network errors to OPERA. "Thisresearchisbeingfunded by NASA-KSC Con- tract NAG-10-0058_ 195 OPERA is not a diagnostic expert system or $CLAI existing FEP again. whose task is to identify or recognize a prob- 3. $SPRCVE lem or error from a set of symptoms and other 4. If redundancy isn't available, data. When an error occurs the computer net- and original FEP fails to work identifies the error with a code number. $CLAI, then troubleshoot per Then, OPERA's task is not one of deciding follo,ing diagnostic advisory. which error has taken place, but rather one of S. Lookup the MICAS in the printing the pertinent information concerning microcode listings, and verify that error. This information basically consists the operation being executed of the probable causes of the error, diagnos- at the time of the anomaly. tic advisories (actions to be performed to find out the causes of the error in case they are un- Diagnostic advisory: clear) and the steps to be taken to correct it, 1. $DPLORT LI 5 called operational advisories. Table 1 depicts 2. SEQ FEPIDI, If errors occur, the information about a typical error. I/O Adapter thumbin may assist troubleshooting. Table 1. Information about a typical 3. GSE NO2 error. 4. SEQ FEVTRI (loop T/R via RCVS). } Message depicted on the firing room consoles When malfunctions occur, messages like this { FEP 141 ($$$$) MICROCODE DID NOT one (in the figure it is displayed in the first set RECEIVE AN ACKNOWLEDGE SIGNAL FROM of braces) appear on the firing room consoles THE I/O ADAPTER, DATA ACQUISITION of the system engineers monitoring launch ac- HAS BEEN INHIBITED. MICAS-$$$$, tivities. The error message designator, FEP NSB=$$$$ } 141, indicates the sub-system of the prob- lem (in this case, the Front End Processor), { ** TERMINAL ERROR FOR THE GSE FEP. and the error number. Dollar signs are used THE IlO ADAPTER DID NOT SEND AN as place holders for actual hexadecimal ad- ACKNOWLEDGE SIGNAL TO THE dresses. This error occured because the FEP's MICROCODE DURING THE OPERATION Input/Output adapter did not send an ac- INDICATED BY MICAS. knowledgement to the microcode during the operation indicated by the address in the MI- Probable cause(s): CAS register. OPERA's response to this mes- I. IlO Adaptor failed. sage is as follows (OPERA output is the text 2. GSE Option Plane failed. in the second set of braces). The text, denoted 3. I/O Adapter port on 4-port by two asterisks, is a note field obtained from controller failed. the network system's documentation. This is 4. FF2 T/R failed. provided to the system engineer as a conve- nience so that that he/she does not need to take the time to consult the manuals. Operations advisory: I. Halt CPU, and record CPU registers. Push CPU through Probable causes for this error are listed recovery. next. Causes axe listed such that the first 2. If redtmdant FEP hasn't taken probable cause is the most likely, the second over, configure another FEP, is the second most likely, etc. More than one 196 problem cause may apply to the error. For this try program that will transform the English particular error, the probable cause is a failed text about the errors given by the experts into piece of hardware; from the most specialized the data structures of OPERA. This clearly piece of hardware, the I/O Adapter, down to will not affect the operation of OPERA. But the most general, the FEP's transmit/receive if the information about the errors is incom- circuitry. plete or incorrect, OPERA would be of very little use to the humans monitoring the com- After the probable causes, the operations puter network. It is clear that the acquisition advisory is listed. This set of advisories de- of the correct knowledge from the experts is tails what should be performed to remedy the essential, if OPERA is to serve a credible role situation while the launch is currently under- as consultant. way. Because of this requirement, any action that would jeopardize the launch can not be Although OPERA has not been designed included in this advisory. Step 4 mandates as a classification task (Gomez and Chan- that if a redundant FEP is not available, the drasekaran, 1984; Clancey, 1985), and, as a potentially failing FEP is taken off-line and is result, there is not a hierarchy of concepts me- given a more thorough examination using the diating the knowledge about the errors, the diagnostic advisory. knowledge for each error gathered by human experts and printed by OPERA clearly con- The diagnostic advisory consists of a se- stitutes a classification task. In classifica- ries of actual diagnostic programs to execute tion problem-solving, knowledge is organized that may determine the cause of the problem. into a hierarchy of concepts. Top concepts in These procedures can not be run on any equip- the hierarchy represent the most general con- ment that is necessary to the continued success cepts. Lower concepts in the hierarchy are re- of the launch. finements of the upper concepts. The main idea behind this methodology is that concepts, However, OPERA has nothing to do with rather than lower level constructs such as rules the content of this information. This has been or procedures, provide the criteria to analyze gathered by human experts who are familiar and organize domain knowledge and acquire with the computer network. Experts may dis- knowledge from experts. This translates into agree strongly about the content of this in- the following knowledge acquisition maxim: formation, but, again, OPERA does not help "Do not ask a domain expert for the rules or the experts to gather this information, or to procedures he/she uses in analyzing an error choose between disparaging information. Of or problem, ask him/her for the concepts that course, the value of OPERA as a consultant he/she uses to conceptualize or classify the er- to the humans who are monitoring the net- ror, and 'then you can ask him/her for the work depends directly on the appropriateness rules or procedures." From a problem solv- and correctness of the information printed by ing point of view, the hierarchy forces the ex- OPERA. pert to make explicit the high level concep- tuai steps (nodes in the hierachy) which he/she 2 OPERA: A Classification will have to consider in determining the proba- Problem-Solving Task ble causes, advisories, and diagnostic steps for a given error. From a knowledge acquisition At first sight, one may think that the task point of view, approaching this task as a classi- of building a knowledge acquisition interface fication task becomes a necessity if the knowl- for OPERA is just one of building a data en- edge acquisition interface is going to go beyond 197 a data entry program, which would merely quisition within the domain of the CCMS net- prompt the user for the probable causes, ad- work. visory, etc. The knowledge acquisition inter- face uses the hierarchy to automatically depict 3 A Factual Knowledge Hi- knowledge stored in the upper concepts upon request of the human expert. Then, while a erachy for the CCMS Net- human expert is adding knowledge about an work error, he/she may decide to consult knowledge that he/she has stored in the upper concepts. In the domain of CCMS network errors, The detailed way in which this is done is ex- a taxonomy of errors may be built based on plained in section 5. the structural components of the network. This classification hierarchy is based on "hard" The knowledge of most domains may be knowledge and does not follow any heuristic divided into .factual or hard and heuristic or principles. It reflects the way things are. Fig- soft. Heuristic knowledge is problem-solving ure 1 depicts a portion of this hierarchy. The knowledge about a domain. In most cases, three children of the root node, stand for Front there is no concensus among experts about End Processor Messages, Input/Output Sys- how this knowledge should be organized, what tem Messages and Operating System Integrity constitutes this knowledge, its activation, etc. Messages. The FEP Messages are in turn di- This situation is reflected in the saying: "each vided into four categories: Ground Support expert has her/his own book." The trouble Equipment, Launch Data Bus, Pulse Coded shooting knowledge that diagnosticians have Modulation and UpUnk messages. These in clearly falls within this type of knowledge. In turn are subdivided into further categories. contrast to heuristic knowledge, factual knowl- The IOS2 submessages listed are not termi- edge reflects the way things are. There is little nal nodes, but instead are categories that in disagreement among experts about what con- turn are subdivided into other categories. Fi- stitutes this type of knowledge. The knowl- nally, the terminal nodes of this hierarchy will edge that a pathologist has about the human consist of individual error messages. body clearly falls within this category. These two types of knowledge are not dichotomous The relevance of this hierarchy for knowl- ones, but rather there is a rich interrelation edge acquisition is that knowledge stored un- between them. The heuristic problem-solving der the nodes of this hierarchy may be used knowledge of a diagnostician may have need of by the human expert while she/he is in the the factual knowledge, especially in those cases process of adding experiential/heuristic knowl- in which the solution of a problem cannot be edge about individual errors. The knowledge obtained directly by applying some right-at- stored under these concepts are causes, advi- hand rules. sories and corrective steps. This knowledge, as we have been reiterating, is factual and resides The object of this paper, however, is not to in the manuals describing the CCMS network. explore the relation between problem-solving Some of this knowledge may be very relevant on one hand, and heuristic and factual knowl- to a domain expert when he/she is entering edge on the other hand, but rather to inves- the causes, advisories, etc. for a specific error. tigate the relation between knowledge acquisi- This is similar to the situation of a physician tion and these two types of knowledge. In the who finds it necessary to consult a medical text next two sections, we show the role that these book about the functions of organs, while di- two types of knowledge play in knowledge aA:- agnosing a patient. 198 chies vary from expert to expert. Figure 2 de- picts an elaborated heuristic hierarchy. When a domain expert starts using the Interface, he/she has at her/his disposal the factual hi- erarchy and an initial heuristic hierarchy sim- ilar to the one depicted in Figure 2 but much less detailed. This initial heuristic hierarchy is provided to the expert as a basis for him/her to start building his/her own hierarchy. Of course, he/she may disagree with the struc- ture a_d/or content of the hierarchy, and as a consequence he/she may decide to change this initial hierarchy to conform to his/her view of _SYSINTG-MSG} the problem-solving knowledge. In building this hierarchy, an expert is in- structed to proceed in a top-down manner. Figure 1: A Portion of the Hard Knowledge The Interface walks a domain expert who is Hierarchy of the CCMS Network unfamiliar with the interface through the fol- lowing steps: The knowledge in the hierarchy is organized following strict inheritance rules. That is, ev- What are the most general categories ery piece of knowledge in an upper-concept is (software, hardware, etc.) that come to true of all its subconcepts. As concepts ap- your mind when the error, say, FEP-132 proach the tip nodes, the knowledge becomes occurs _? more specific. The user may traverse this hi- erarchy by using the mouse either in a top- Once you have determined that the error down or in a bottom-up fashion. Or he/she is, say, a software problem, which subcat- may visit any concept without following any egories within the software do you think about? predetermined order. The knowledge will be displayed to him/her by the interface. Then, • Which advisories and/or causes are she/he may decide to consult the knowledge or known for a given category? use that knowledge in its entirety or partially (see section 5). Once the domain expert has acquired some familiarity with the interface, the knowledge 4 A Heuristic Knowledge Hi- acquisition process concentrates on entering advisories about individual errors. During erarchy for the CCMS Net- this process, the domain expert may decide work to modify the heuristic hierarchy, by adding new links, altering existing links or deleting or The place of the concepts in this hierarchy, adding advisories stored under the nodes. But, and the knowledge stored under each concept, in most cases, the expert may use the knowl- do not obey strict or hard rules; rather, they edge stored by him/her in the heuristic hier- depend on the way in which a given human ex- archy and in the factual hierarchy in order to pert approaches the solution of a problem. As build knowledge about individual errors. This a consequence, heuristic classification hierar- is explained in detail in the section below. 199 Tj "-JCOMPONENlT -tNE&I-OPSYS/FIRMW_RE] INCORRECT-BI_MAPJ WITHIN-DESIGN-SPECI INCORRECT-BOOT-PROC] 151MILAR-PRbB] 3MI-USAGE-SHORTCUTI DEBUG-SCENARIO] QRONG-CDBFRIE:AC/CP_ IEXPLAINED-CONDITION i Figure 2: A Portion of an Elaborated Heuristic Hierarchy for the CCMS Network 5 A Walk Through The In- work. While initial interviews require some terface instruction and typically last several hours, a given interview session can be accomplished in as little as 30 minutes, depending on the The interview process has two phases; the amount of information to be elicited. first is the construction or modification of the domain expert's error classification hierarchy, and the second is the generation of OPERA 5.1 Creating and Editing OPERA advisories. These two phases need not be Advisories strictly ordered and can be interleaved, i.e., domain experts are not forced to construct The primary goal of the interface is the ac- their final classification hierarchies before any quisition of knowledge about error messages. advisories are created, but rather they are free Currently the data collected are exported to to change their hierarchies at any time. To the OPERA system in the form of advisories minimize the amount of startup time and to enumerating the probable causes, operational give the domain expert an idea of what we are advisories, and diagnostic advisories for spe- after, we provide an elaborated error classifi- cific errors generated by the CCMS network. cation hierarchy designed from Grumman sys- The first step in creating an advisory is choos- tems engineer Bill Verhagen's hierarchy (see ing the error message to describe. The user is Figure 2). This hierarchy provides systems en- presented a menu of error messages that were gineers unfamiliar with the interface a starting previously specified by the Knowledge Engi- point from which they can begin to coalesce neer. The error messages on this menu reflect their experiential knowledge of the CCMS net- those errors that the Knowledge Engineer is in- 200 terested in collecting information about. The from default information contained in the fac- user is free to choose any message on the menu. tual and heuristic hierarchies. Figure 4 shows the interface screen during the entry of prob- able cause data for the FEP 132 error. 5.1.1 Placing Errors in the Heuristic Hierarchy 5.1.$ Using the Default Information Once an error message has been chosen, the As mentioned above, the user may cre- user is asked to place the error within his cur- ate advisories by selecting text, via the mouse, rent heuristic hierarchy. To aid the user in this from the factual and heuristic hierarchies. The task, the interface provides help in the form of texts available to be selected are those de- status register decodings and notes provided fault advisories constructed by the domain ex- by the Knowledge Engineer. pert and knowledge engineer and stored in the heuristic and factual hierarchies. When the Given this help, the user should be able to user is to the point of entering in a line of place the error in his heuristic hierarchy. Plac- text of the probable causes, operational advi- ing the error within the heuristic hierarchy is a sorT, or diagnostic advisory, the system dis- matter of specifying which node is to become plays the default advisories in the lower right the error's parent. If a suitable parent does window pane of the interface screen (see Fig- not exist in the hierarchy, the user is given a ure 5). How the interface determines which chance to create and place the parent in the default advisories are displayed in this pane is hierarchy at that time. It may be, however, described below. that the parent of the parent (grandparent of the original error message) does not exist in First, the interface must determine whether the hierarchy. Again, the user may create and the user has chosen to display information place the grandfather in the hierarchy. This from the factual hierarchy, from his own process can continue as long as necessary un- heuristic hierarchy, or both. This determina_ til the chain of new error categories can be tion is based on the option the user has chosen linked to a node in the hierarchy (see Figure 3). Once the error has been inserted into the hi- using the Select Inheritance command (the de- fault option is to show both). If the user has erarchy, the interface gives the domain expert chosen to display both or has simply taken the the opportunity to create the llst of probable default, the interface will collect default ad- causes, operational advisories, and diagnostic visories from both hierarchies, displaying the advisories associated with the error. user's own defaults at the top of the window. This is done under the assumption that the 5.1.2 Causes, Operational Advisories, expert will feel that his own default advisories and Diagnostic Advisories are more relevant than those of the knowl- Adding and editing cause and advisory in- edge engineer. If the user chooses one or the formation is quite simple. A pop-up menu other type of knowledge, the interface will col- is presented that allows the user to pick be- lect only the default advisories from the corre- tween changing probable causes, operational sponding hierarchy. advisories, or diagnostic advisories. Once an area has been selected the interface allows the Given that the system knows which hierar- user to: add new lines of information, edit chy or hierachies to collect the default advi- specific lines, rearrange the order of lines, or sories from, the interface then uses the hier- delete lines. Each line consists of free-form archy's structure to decide which advisories to text keyed in by the user or mouse-selected display. For example, suppose the FEP 132 201 f N Heuristic Hierarchy Error node New error New error In hierarchy Category 2 Category I FEP - 132 •.-I H I--I I J Figure 3: Adding Error Message to the Heuristic Hierarchy !Probable Cau|eg: 1: HIfl Nester Control Card fat|ed. 2: HIM BUS Card fatlad. 3: Intarn4ttent lo9t¢ failure. 4: Internal HIM Card fatled. I [d!t Line" I i DeleteLine I I Hove Line I ! InserLLine I I _CCCpt I Figure 4: Entering Probable Cause Information 202 errorused above was classifieads a mechan- may have childrenthat are the actualsub- icalanomaly and theuser had chosento use tests.For example, the diagnosticsequence defaultadvisoriesfrom hisown hierarchy.The SEQ CP1 -CPU DIAGNOSTIC PART I,has interfacewould begincollectingdefaultadvi- thefollowingninesub-tests: soriesfrom the mechanicalanomaly node in "TST02 - XORB TEST" the hierarchy.These advisoriesarethe most "TST03 - REGISTER ADDRESSING TEST" specificand willbe displayedatthetopofthe "TST04 - R2 DATA INTEGRITY TEST" window pane.The interfacethen traversesup "TST05 - BLM/BRX TEST" thehierarchyto theancestorsof themechan- "TST06 - R3-R15 DATA INTEGRITY TEST" icalanomaly node. The defaultadvisoriesfor "TST07 - ABRB TEST" each ancestorarecollectedand added to the "TST08 - NOP TEST" listofadvisoriestobe displayedaftertheadvi- "TST09 - LDX TEST" soriesfound inmechanicalanomaly. Thispro- "TSTIO - IBR TEST" cesscontinuesuntilthe root node isreached alongeach ancestralpath.The by-productof The user can chose the string"SEQ CPI - thisprocessisa listofalltheadvisoriesfrom CPU DIAGNOSTIC PART I" to includein theparentoftheerrorwe aredescribingup to his advisory by clicking the left button of the therootof thehierarchyin orderfrom most mouse when the mouse cursor is above this specifictomost generic. text, or he can see the associated sub-tests by clicking the right button. If there were sub- sub-tests, these could be viewed by clicking Once the advisories have been collected, the the right button again. Returning to a higher user can select them using the mouse and in- level is accomplished by clicking the middle clude them, as is, in his description, or modify button of the mouse. In summary, clicking them in anyway he chooses. This means that the left mouse button selects the text under the domain expert does not need to store "per- the mouse cursor, clicking the middle button fect" advisories, but can store advisory tem- takes the user up one level in the advisory hi- plates that can be modified as necessary. This erarchy, and the right button takes the user greatly enhances the flexibility of the interface. down one level in the advisory hierarchy. When the user has finished entering his de- Another enhancement stems from the fact scription of an error, he may choose to save that the default advisories themselves are it in his hierarchy or simply abort. Saving the stored in a hierarchical structure. This allows information amounts to creating the necessary different levels of default information to exist frames and their fillers in the expert's hierar- and be used by the domain expert. One exam- chy. If the user does not abort, the expert's hi- ple we encountered where this was useful was erarchy is redisplayed with the new error node in the specification of diagnostic advisories. included. This concludes the discussion of the Typically, a diagnostic advisory includes refer- error description process. ence to sequences of diagnostic programs that should be executed. The case may be, how- 5.2 Modifying the Structure of ever, that an entire diagnostic sequence need Heuristic Hierarchies not be run but only several of its sub-tests. To accommodate this situation the domain expert Maintaining the domain expert's error may specify that a default advisory has its own classification hierarchy is one of the most im- children. This allows the system to recognize portant tasks of the interface. Several power- that an advisory detailing a sequence of tests ful options have been implemented to allow the 2O3 Opera Knowledge Acquisition Interface Clear Screen Delete Error Hessage Help Nlererchy Relntenance Operlt|onll Rdvtlor4e! |, |F llnl Dr|nter 18 |hop= esli9n reportl or lylte_ _el=m8 es to the other prtnter vt= $$SPOOL IISSICM, f'-I .............. _=="L2_"_'_:_:_ _71 ................. Line Options k _ODeretio_,mZ Categories Add Line B Itghten up solonold ecreus tf Doper ur(nkles or doesn't teed. EOdietletLeineLine _ 0CeOpnlatlccet MhefllOntteMnHaDnc/BeDSK ¢northreeplaceevent heOadfs • epnndeu_eptlecck Inlos$th.e event of H0v¢ Line insert Line _ccept B _ |f 11ne orlnter Is 1nOD, assign reports or s_-sten nesse9ee to t Reje ct Figure 5: Interface Main Screen with Default Advisories user to quickly and easily change the structure interface redisplays the hierarchy reflecting the of his/her hierarchy. These options include addition of the new category. adding new error categories, adding and delet- ing links between errors or error categories, 5.2.2 Adding and Deleting Links and moving sub-hierarchies from one place in the hierarchy to another. Links or inheritance paths can be added to and deleted from the expert's hierarchy using 5.2.1 Adding New Error Categories the Add New Link and Delete Li,k options. In the case of adding a new link, the user is New error categories are added to the do- prompted for a child category and a parent main expert's error classification hierarchy us- category. The system checks to see if the par- ing the Add Error Category option. This op- ent node is a descendant of the chihl node, and tion allows the user to create a new error cat- if it is, the attempt is aborted. This constraint egory and place it in the hierarchy. The user guarantees that cycles will not be created by is prompted for the name of the new category adding new links. Deleting a link is similar and the category that is to be its parent. The to adding a new one. The user is prompted parent category must exist in the hierarchy for the parent and child nodes that define the and may be given either by typing its name end-points of the link. Assuming that the par- via the keyboard or by clicking on its graphical ent and child nodes given indicate an existing representation using the mouse (all the nodes link, the system proceeds to remove the link in the domain expert's hierarchy are mouse se- a,d redisplay the lu.erarchy.• Because the er- lectable). After this information is given, the ror classification hierarchy is a tangled hier- 2O4

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.