Abstract

Previous research on real-time qualitativereasoning lias focused on making reasoningfast . Little work has been devoted to the moreimportant issue ofmaking real-time qualitativereasoning predictable . Thispaper describes anarchitecture for qualitative reasoning thataddresses both speed andpredictability. Exten-sions to the Qualitative Reasoning System(Hamilton 1988) to support predictable real-tinte performance are described.

1 . Introduction

39

An Architecture for Real-Time Qualitative Reasoning

Development of qualitative, or model-based,reasoning systems is motivated by a number ofwell-documented benefits . These benefits in-clude device independence of knowledge andreasoning techniques, clear definition of thescope of a system's competence, and the abilityto diagnose faults with novel symptoms (Davis1984) . The importance of research on qualita-tive reasoning is substantiated by applicationsexperience . In the HELIX program (Hamilton1988), for example, it was discovered that ex-perts - in this case veteran helicopter test pilots-do, in fact, base their diagnostic reasoning onan understanding of the underlying structureand function of the physical system .

Recently, research efforts have been aimed atapplying qualitative reasoning to real-timeproblems . To date, these efforts have focusedprimarily on improving run time performancein qualitative reasoning (i.e ., making qualita-

Thomas P. HamiltonUnited Technologies Research Center

Silver LaneEast Hartford, Connecticut, USA 06108

TPH@a UTRC .UTC.COM

tive reasoning fast) . Hamilton (1988) uses hier-archical modeling to focus the diagnosis andprunc the stanch space . Abbott (1988) expluiesthe use ofmultiple representations and levels ofabstraction to focus attention during reasoning .Doyle et . al. (1989) use a causal analysis tochoose a subset ofthe predicted events to moni-tor from a potentially large numberof availablesensors .

As Stankovic (1988) points out, however, real-time computing is not equivalent to fast com-puting . "Rather than being fast (which is a rela-tive term anyway), the most important propertyof a real-time system should be predictability"(Stankovic 1988) . Optimizations such as thosedescribed above are clearly important to meet-ing stringent timing specifications . They donot, by themselves, guarantee that timing con-straints will be met. Emphasis now must beshifted from making qualitative reasoningfastto making it predictable - guaranteeing thattiming specifications will be met in real-timeenvironments .

If the emphasis in real-time AI should be onpredictability rather than speed, what are thebarriers to building predictable AI systems?Fundamentally, the answer is complexity.Tasks typically assigned to Al programs arecomplex ones. As a result, the amount of pro-cessing that might be done to produce the bestanswer is frequently greater than that which canbe done in the time available . Furthermore, the

_r

r

primary mechanism for dealing with complex-ity in AI systems -search -is inherently unpre-dictable . The next section describes approachesto building predictable real-dime Al systems .

2 . Approaches to RealTime Al

The goal of real-time AI is to get the best an-swer possible in the time available. Approachesto achieving real-time performance with AIsystems may be broadly classified into threecategories : Re-engineering, performance engi-neering, and time-constrained search .

2 .1 Re-Engineering

The goal of re--engineering an Al system i,5 toreproduce its functionality using a more tradi-tional algorithmic approach . The benefit of us-ing AI techniques comes from the understand-ing of the problem gained through rapidprototyping . Re--engineering the system usingmore traditional software techniques suppliesthe predictability required for guaranteeingreal-time constraints are met- In this sense, theAI techniques may be considered a systemsanalysis tool .

2 .2 Performance Engineering

Performance engineering on a knowledge baseis a second method for achieving real-time per-formance in an AI system . The objective ofthisapproach is to guarantee that the worst-caseperformance on a particular knowledge basesatisfies timing requirements . This involvescarefully analyzing and partitioning the knowl-edge base to bound the search process . For ex-ample, in a rule-based system, knowledge ofthe maximum number of rules that could fireand the time required to fire arule can be used todetermine the system's worst-case perform-ance .

Ho2 .,3 Tune-Constrained Inference

A third method for achieving real-time per-formance in an AI system is to bound the searchprocess by directly imposing time constraints .Unfortunately, many problem-solving ap-proaches are structured in such a way that par-tial solutions present little or no useful inform,--tion to the user. That is, the result ofreasoning isonly of value if the search runs to completion .

Reasoning algorithms that offer the greatestbenefit in dynamic real-time environments arethose that are able toreturn a useful partial solu-tion even if unable to run to completion. Thus,desirable characteristics of a real-time pro-blem-solving algorithm are :

1) partial solutions to the problem repre-sent useful approximate answers,

2) processing may be interrupted and par-tial solutions rcturned when a time limitis reached, and

3) if additional processing time becomesavailable, it should be possible to con-tinue the unfinished search to further re-fine the answer.

The approach to achieving real-time qualita-tive reasoning described here is based on thetime-constrained inferencing approach . The

remainder of this paper presents a brief over-view of the Qualitative Reasoning System(QRS), extensions to QRS to support real-timeoperation, and a real-time testbed for QRS .

3. QRS Overview

The Qualitative Reasoning System (QRS) is asoftware system designed to support the devel-opment of qualitative reasoning applications .QRS consists of two primary components - aQualitative Model Builder and a QualitativeRe*oner. A brief overview of the capabilities

. ., .

.

.

.

. . .

.

. , ,

,

. . " ,

.:

. . " .

. .

. . . .

ofQRS is presented below. A detailed descrip-tion ofQRSmay be found in Hamilton (1988) .

3.1 Qualitative Model Builder

Th . Quaktativ* Mo4ol Builder providoo an interface for conotruction, 3torago, and testing ofqualitative models. Qualitativomodels in QRSare Qfv.),u Manic typeoi Elarrnontary Modclt, representing devices without substructure, andCompound Models, representing devices com-posed of components. Elementary models are

vying a cvriec ef mvnun for opooifj -ingthe device's variables and constraints.

Compound models are constructed graphicallywith the model-building interface depicted inFigure 1. Icons corresponding to model proto-types are selected from the menu at the rightand moved into the model-building window atthe left . With the mouse, conduits are createdspecifying the interconnections between com-ponents . Using the Qualitative Model Builderin this way produces collections of hierarchical

model representations that may stored into andretrieved from model libraries .

TheQualitative ModelBwilder also provides an111telluLe ttl 111u ftiastltllilg R1gnr11m u1 1118Qualitative xea,tuuct . This allows interacrivetesting of elemenrary and compound i'Yfbde11 .

3.2 Oualitative Reasoner

The Qualitative Reasoner provides utilities forreasoning over aqualitative model. These utili.-ties may be accessed in an interactive, menu-tltiveii fdshiuu ui way Ut" called tlllecdy by aproblem-solving application. The QualitativeReasoner operates on models to perform thefollowing operations :

State Generation - determining all pos-sible assignments of qualitative valuesto variables that are consistent with amodel and zero or more observations .

" Fault Detection - determining if ob-wivP.rl valne..,q ccinflirt with a m.x c)�

"

Diagnosis - determining, using hierar-chical constraint suspension (Davis

J9onocr~s~ "c M

nodett MOdtifUndekte Ma1Q~Qcar ken Mo,n

COPY Modc1 Library1"A MoAd Library(TOP-T,rvcl M-nu)

Future 1 . The QRS Qualitative Model Builder. The Qualitative Model Builder provides a graphical interface forbuilding, testing, and modifying qualitative models.

. .,

. .

,

Q-1 ,

q.".>,ia~,

."0' . .. .

" ) " . .

>a~, .

, ., .

.

. .

. . . . " ) . . . . .

" .

.

.

.

,. .

1984), what component failures ac-count for a detected fault .

+ Sequential Diagnosis - interactivetroubleshooting based on system-gen-erated test recommendations (de Kleerand Williams 1987).

4. pQRS - Parallel QRS

The hierarchical approach to model representa-tion and diagnosis used in QRS is ideally suitedto parallelization . As a diagnosis proceeds top-down through the model hierarchy, valid hy-potheses are identified . Each valid hypothesisthat contains substructure is expanded into anew set of finer-grained hypotheses. The eval-uation of these new expanded hypotheses canbe distributed to available processors and ex-ecuted in parallel .

The architecture for parallel QRS, or pQRS, isshown in Figure 2. pQRS is made up of threecomponents . The Diagnosis Manager acceptsobservations, detects faults, initiates fault iso-lation, and returns the diagnosis . The Hypothe-sis Scheduler m aps hypotheses to be tested ontoremote processors for execution. Hypothesis

Figure 2. The pQRS Architecture . Hypotheses to be tested are distributed to available processors by the HypothesesScheduler to perform aparallel hierarchical diagnosis.

Servers, residing on remote processors, evalu-ate hypotheses and return the results . Each ofthese three components is discussed in turn.

4.1 The Diagnosis Manager

When the Diagnosis Manager receives a set ofobservations, the first step is to run the FaultDetector to determine if the observations areconsistent with the normal behavior of the de-vice . Observations are propagated through theconstraints of the root model to detennine ifthere exists a state consistent with the modeland observations . If a state consistent with themodel and observations can be generated, theobservations are considered normal and theDiagnosis Manager returns this result.

If there is no state consistent with the root mod-el and observations, then a fault is detected . TheDiagnosis Manager then initiates fault isolationby creating hypotheses and submitting them tothe Hypothesis Scheduler. Each hypothesiscreated by the Diagnosis Manager correspondsto a test whether the observations can be ex-plained by a failure in one o£ the components ofthe root of the model hierarchy.

Each hypothesis consists of amodelview and aset of observations . The model view specifiesthe level ofdetail with whichtoevaluate thehy-pothesis .Th.e model view contains two lists: thefirst is the list of components assumed to beworking; the second contains the componentsto suspend. Together, these lists determinewhich constraints are in themodel when the hy-pothesis is evaluated. The observations arepairs, each consisting of a modelparameterandits measured qualitative value.

4 .2 The Hypothesis Scheduler

TheHypothesis Scheduler's duty is to maintaintwo queues . The first is aProcessor Queuecon-taining the processors currently available toevaluate a hypothesis . The second queue,called the Hypothesis Queue, contains the hy-potheses waiting to be evaluated.

The type of search performed by pQRS can becontrolled conveniently by assigning prioritiesto the hypotheses in the Hypothesis Queue. As-signing priorities according to a hypothesis'position in the hierarchy produces a standardbreadth- or depth-first search. Forexample, ifeach hypothesis is given a lower priority thanits parent, abreadth-first parallel search will beperformed. Assigning higher priorities to chil-dren than parents will produce a depth-firstsearch .

As pointed out by Lesseret . al . (1988), it is pos-sible to avoid computation costs by avoidingwork on low-certainty alternative interpreta-tions. This can have an impact on the type ofsearch performed. The more conservative thescheduler, the more breadth--first the searchwill tend to be to avoid missing better alterna-tives. The less conservative the scheduler, themore depth first the search will be to avoid ex-pending computingresources on low-certainty

43alternatives . Other factors, such as the critical-ity of failures in different branches of the hier-archy, may also influence the type of searchperformed.

TheHypothesis Scheduler distributes hypothe-ses, one per processor in the processor queue.Each valid hypothesis may create additional,more-specific, hypotheses . These are added tothe Hypothesis Queue with a priority deter-minedby the search scheme. The highest prior-ity process is created on the first available pro-cessor. That processor is removed from theProcessor Queue; it gets enqueued again afterits process completes.

4.3 Hypothesis ServersA Hypothesis Server is a process, running on aremote processor, whosejob is to evaluate hy-potheses . Each Hypothesis Serverperforms thefollowing duties :

"

Accepts requests to test hypotheses"

Evaluates hypotheses"

Returns result"

Creates new hypothesesKeeps track of its availability and in-forms the processor scheduler

To evaluate a hypothesis, a Hypothesis Serverneeds to have a model instance for the devicebeing monitored. This instance enables anysingle or multiple fault hypothesis to be eva-luated . When a hypothesis is received, the spe-cified model view is created. The model viewdetermines which constraints of the model areto be reasoned over. The observations are theninput to the state generation algorithm . Ifastateconsistent with the observations and con-straints in the modelview is found, then the hy-pothesis is valid. Otherwise, the hypothesis isinvalid . Theresult of this test is returned to theDiagnosis Managerand stored with the CurrentDiagnosis.

If a hypothesis is valid, the Hypothesis Servermust also determine if additional, more-de-tailed hypotheses need to be created. Any validhypothesis representing a failure in a compo-nent with substructure must be expanded .These expanded hypotheses are submitted tothe Hypothesis Scheduler to be enqueued in theHypothesis Queue.

4.4 Benefits ofpQRS

Benefits of pQRS include the following:

Improved response time,Flexible control of search,Ability to dynamically change priori-ties,

"

Fault tolerance, and" Support for time-constrained infer-

ence.

As discussed previously, fast response does notmake pQRS a real-time system . What is stillmissing is predictability. The architecture forpQRS does, however, provide the foundation

44

on which to build apredictable real-time quali-tative reasoning system. Section 5 describeshow the pQRS architecture can be extended toensure predictable performance.

5. QRSt -Time-constrained QRS

The hierarchical representation of QRS is wellsuited to time---constrained inference . Eachsuccessive level in the hierarchy represents afiner-grained analysis . A partial solution forthe QRS diagnostic process might correspondto isolating a fault down to the system or sub-system level. Such a partial solution, thoughless detailed than it might be given additionalcomputing resources, can still be of great valuein deciding how to respond to the failure.

Extensions to QRS to support time-constrainedinferencing result in adding two components tothe pQRS architecture . As shown in Figure 3,these components are the Time Manager andthe Interrupt Manager. These components aredescribed in the following two sections .

Figure 3 . The QRSt Architecture . The Time Manager ensures chattime constraints on processing are met. The InterruptManager allows the diagnosis to be interrupted when other, highcr,p4ority, processing requirements occur

5.1 Mme-Constrained Diagnosis

The basic time-constrained QRS architecturerequires only a few modifications to pQRS .First, pQRS is modified to accept a time limit asone of its inputs, along with the set of observa-tions. This time limit is the amount of time thatqualitative reasoning may execute on a set ofobservations before a diagnosis is required .

Second, aTimerProcess is added to the ControlProcessor. The Timer Process is essentially analarm clock that is set to the allotted time whenobservations arrive. When the time limit isreached, the alarm clock goes off.

Both the Diagnosis Manager and HypothesisScheduler listen to the alarm clock. When thetime limit is reached, the Diagnosis Managerreturns the most detailed diagnosis that is cur-rently available.

The Hypothesis Scheduler responds to thealarm by reclaiming processing resources. Thefirst action it takes is to dequeue all pendinghy-potheses for that set of observations . Second, itissues interrupts to each of the active Hypothe-sis Servers that are evaluating hypotheses forthis set of observations . As each HypothesisServer terminates, it informs the HypothesisScheduler of its availability and is returned tothe Processor Queue. The hypothesis processesmay either be suspended for future use orkilled, dependingon storage constraints andtheexpected value of saving the processing state.

With these extensions to pQRS, QRSt will re-spond predictably. It accepts observation andreturns its best assessment of the situation with-in the prescribed time limit.

qs

52 Interruptible Diagnosis

in addition to supporting time-constrained in-ferencing, QRSt must also be interruptible .Qualitative reasoning may bejust oneofanum-ber of resources available in an overall statusmonitoring/diagnostic system . Thus,QRS maybe in competition with other software modulesfor computing resources . Situations may arisein which resources allocated to QRS need to beapplied to other more urgent processing needs .By making QRSt interruptible, it can stop workon a problem when another, higher priority,processing requirement occurs .

To support interruptibility, an Interrupt Manag-er needs to be added to the QRSt architecture .The Interrupt Manager receives interrupts andrelays them to the Diagnosis Manager and Hy-pothesis Scheduler. These modules respond tothe interrupts in the same manner as to timer in-terrupts .

G. pQRSt Testbed

QRS has previously been used in a number ofdiagnostic applications . They vary in terms ofthe time scale at which a response is requiredand in the consequences of missing deadlines.Twomajor application areas illustrate these dif-ferences . The HELIX program (Hamilton1988) is a helicopter status monitoring anddiagnostic system designed for airborne use.HELIX is an example of an application inwhichthe time frame for response is rather tight(typical response times are on the orderof afewseconds) and the consequences for being latecan be quite severe.

In contrast, the Sherlock program (Hamilton,19&7), is a ground-based gas turbine enginediagnostic system . Timing constraints in Sher-

lock are far less stringent, both in terms of therequired response time and theconsequences offailing to meet the deadline . In both cases,though, there is a requirement to produce thebest assessment within some reasonable timefrainc .

QRS is written in Common Lisp and has beenhosted on a variety of hardware platforms(Symbolics, Sun, Compaq). The developmentenvironment for pQRSt is a network of Sym-bolics workstations (one XI-A00 and five3640s) . Both the HELIX and Sherlock applica-tions will serve as test applications for evaluat-ing the system.

7 . Discussion

The proposed architecture for pQRSt satisfies akey requirement for real-time computing thatis often missing in real-time AI applications :predictability. By supporting time-constrainedand interruptible operation, this architecturemakes the QRS hierarchical diagnostic processsuitable for use in real-time status monitoringand diagnostic systems . In addition, the exten-sions designed to support parallel evaluation ofhypotheses should provide both improved per-formance and greater flexibility in controllingsearch .

Implementation of the pQRSt architecture hasbeen initiated . Experiments with the systemshould help to answer questions about both thenumber and configuration of processors re-quired to achieve desired response times fordifferent applications . Further research mustbuild on related work on operating systems tosupport real-time AI (Stankovie et. al . 1989)and on planning the problem-solving process

L4 6

8. References

using approximate reasoning techniques (Less-er et. al . 1988) .

Abbott, K. H: Robust Operative Diagnosis asProblem Solving in a Hypothesis Space .Seventh National Conference on Artificial In-telligence, St . Paul, Minnesota, 1988 .

Davis, R. : Diagnostic Reasoning Based onStructure and Behavior. Artificial Intelligence,24, 1984, 347-410.

de Kleer, J . and Williams, B.C. : DiagnosingMultiple Faults . Artificial Intelligence, 32,1987,97-130 .

Doyle, R. I ., Sellers, S . M., and Atkinson, D. j . :A Focused, Context-Sensitive Approach toMonitoring. Eleventh International Joint Con-ference on Artificial Intelligence, Detroit.Michigan, August 20-25, 1989, 1231-1237.

Hamilton . T. P. : HELIX: An Application ofQualitative Physics to Diagnostics in Ad-vanced Helicopters . International Journal forAI in Engineering, Vol. 3, No. 3, pp 141-150,July, 1988 .

Hamilton, T.P: Applications of QualitativeReasoning to Aircraft Diagnosis and Mainte-nance. Artificial Intelligence and RoboticsSymposium, June 16-17, 1987, Norfolk, jru-

ginia.

Lesser, VR.,Pavlin, P, and Durfee, E. : Approx-imate Processing in Real-lime Problem Solv-ing . AI Magazine, Vol . 9, No. 1, Spring, 1988,49-61 .

Stankovic, J. A. : Misconceptions About Real-Time Computing . IEEE Computer, VoL 21, No.10, October, 1988, 10-18 .

Stankovic, J . A., Ramamritham, K., and Nie-haus, D. : On Using the Spring Kernel to Sup-port RealTime Al Applications, Proc . Euro-Miern Workshop on Real-Time Systems, June1989 .