+ All Categories
Home > Documents > Diagnostic problem solving: history and state of the art

Diagnostic problem solving: history and state of the art

Date post: 07-Jan-2016
Category:
Upload: teryl
View: 19 times
Download: 0 times
Share this document with a friend
Description:
Diagnostic problem solving: history and state of the art. Luca Console Dipartimento di Informatica Università di Torino e-mail: [email protected]. Summary. Introduction to diagnostic problem solving The ‘70s: heuristic approaches to diagnosis The ‘80s critique to the heuristic approach - PowerPoint PPT Presentation
86
Diagnostic Problem solving: 1 Luca Console Luca Console Dipartimento di Informatica Università di Torino e-mail: [email protected] Diagnostic problem solving: history and state of the art
Transcript
Page 1: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 1Luca Console

Luca Console

Dipartimento di Informatica

Università di Torino

e-mail: [email protected]

Diagnostic problem solving:history and state of the art

Page 2: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 2Luca Console

Summary

Introduction to diagnostic problem solving The ‘70s: heuristic approaches to diagnosis The ‘80s

critique to the heuristic approach model-based diagnosis: the beginnings and the basic techniques

The ‘90s: state of the art The ‘00: opportunities for the future

Page 3: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 3Luca Console

Diagnostic Problem Solving

A definition::

diagnosis = finding malfunctions (faults, diseases ...) in a system starting from a set of observations (measurements, tests, symptoms, examinations ...)

A fundamental area for AI from the ‘70s: Many AI methodologies originated from diagnosis and then spred

to other areas of AI An area of experimentation of different ideas and techniques A meeting point for many methodologies A blend of theoretical and experimental research

Page 4: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 4Luca Console

The ‘70s: heuristic diagnosis

the ‘70s: the expert systems age

diagnosis is one of the main experimentation areas for expert systems a well-defined problem with definite boundaries

specific domain knowledge to be represented specific reasoning and problem solving strategies

Basic assumptions: diagnosis = heuristic process experts rely on associational knowledge of the form

symptomsfaults (diseases) knowledge derives from experience knowledge can be elicited from domain experts and represented

using suitable KR languages

Page 5: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 5Luca Console

diagnosis = heuristic classification

“heuristic classification” [Clancey, 85] “hierarchical classification” [Chandrasekaran, 83]

Data abstraction

data (observations)

data abstractions

Refinement

solutions

solution abstractionsHeuristic match

domain expert

heuristic - associational knowledge

Page 6: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 6Luca Console

Diagnostic expert systems: conceptual view

domain expert (and knowledge engineer)

K.B

K.A. interface

control K.B.

final user

user interface

work. mem.

inferenceengine

Page 7: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 7Luca Console

Diagnostic expert systems (II)

many different implementation of the conceptual scheme E.g.: heuristic 8associational) knowledge represented using

production rules frames hybrid formalisms integrating rules and frames

Many of these formalisms originated from diagnosis (the use of rules, integrating frames and rules...)

many different applications medicine, industrial processes, mechanics, aereonautics, ...

Page 8: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 8Luca Console

Case study 1: Mycin [Stanford Univ. 72-79]

Diagnosis and therapy of bacterial infections Knowledge base: production rules (original proposal)

if (1) the stain of the organism is gram-negative

(2) the morphology of the organisms is coccus

(3) the growth configuration of the organism is chains

then there is a suggestive evidence (0.7)

that the identity of the organisms is streptococcus

Inference strategy: backward chaining Approximate reasoning: ad-hoc heuristic approach Explanations: HOW, WHY, WHY-NOT ... Meta-rules for control from Mycin to Emycin and many other applications

Page 9: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 9Luca Console

Case study 2: DELTA-CATS1 [General Electric]

Diagnosis and repair of diesel locomotives goal: support the technicians’ work Knowledge representation: production rules with forward

chaining Sophisticated approach to uncertain reasoning graphical interface for providing explanations on drawings

of the devices; the repair sequences (stored on the disk) are shown to the technician

[Bonissone et al. 84]

Page 10: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 10Luca Console

Case study 3: PIP [MIT, 72-78] Diagnosis of spleen diseases Knowledge base: stereotypical descriptions based on frames

Triggers: <set of symptoms used to evoke the hypothesis>

Decision Criteria is-sufficient: < set of symptoms >

must-have: < set of symptoms > must-not-have: < set of symptoms >

Complementary relation to other diseases

caused-by: <set of diseases> cause-of: < set of diseases >

complicated-by: < set of diseases > complication-of: < set of diseases >

associated-with: < set of diseases >

Competing Hypotheses alternative-to: < set of diseases >

Score evaluation functions

Inference: triggering, match and depending on the degree of match, activation of

associated or alternative hypotheses

from PIP to a shell and to other applications

Page 11: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 11Luca Console

Case study 4: hierarchical classification

many systems: Internist/Caduceous/QMR [CMU, 77 ...], MDX [Ohio State, 81-85] LITO [Torino, 79-86]

Hierarchy of diagnostic hypotheses (specialists) Each specialists: frame and rules Hierarchical visit based on match and specialization Experiences are fundamental for many expert system shells of

the ‘80s (e.g. KEE/kappa, Nexpert Object, CLIPS ...) Example: Internist/QMR

Internal Medicine

Lung diseases Liver diseases ......

cirrhosis hepatitis tumours....

...........

Page 12: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 12Luca Console

A summary of the approach: diagnosis of devices

Physical device to be diagnosed (e.g. electronic device)

Device

(e.g. circuit)

inp1inp2

inpN

out1out2

outM

• Heuristic knowledge elicited from a domain expert: associtions

symptoms faults• rules: if inpi1=x1 and ... and inpik= xk and outj1=Y1

and ... and outjl=Yl then (0.75) fault=P

• stereotypical descriptionsfault P: trigger: outjm=ym

symptoms: necessary ( ...) sufficient (....) ...

Page 13: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 13Luca Console

Critiques to the heuristic approach

The heuristic approach allows one to build diagnostic systems suitable for many problems and applications well consolidated approach many tools available many validated applications in use

Some serious problems difficulties in acquiring and maintaining the knowledge base experience knowledge

it is not easy to find experts who are usually not available subjective knowledge dependent on the specific expert how to diagnose “new” devices? how to deal with “new” cases?

Page 14: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 14Luca Console

Critiques to the heuristic approach (II)

some serious problems (contd) approach based on classification

it is impossible to deal with cases not considered a-priori it is difficult to deal with multiple faults brittleness

Knowledge base specific for diagnosis and not reusable in other tasks

lack of generality and strict dependence on the specific device it is impossible to reuse knowledge in similar devices or even

in new versions of the same device limited explanation capabilities

Page 15: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 15Luca Console

The ‘80s: model-based reasoning

New tendency (late 70s - beginning of the 80’s)

experience heuristic knowledge model of the system to be diagnosed

“objective” model, not specific for diagnosis (task independent)

New approach to knowledge-based systems based on “deep knowledge” based on “first principles” second-generation expert systems “model-based”

Page 16: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 16Luca Console

Model-based diagnosis

Different approaches different types of models different definitions of diagnosis

predictedbehaviour

actualsystem

observedbehaviour

diagnosis

modelof the system

design textbook first principles ....

• “knowledge level” view:

Page 17: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 17Luca Console

Genesis of the model-based approach

Two different evolutions Diagnosis on causal models

“process centered” approach born in medical domains, then application to diagnosis of

industrial processes and devices model: causal description of the behavior of the system, in

normal and/or faulty conditions Diagnosis on models of structure and function

“component centered” approach born in technical domains, then other applications model: description of the structure of a device (components

and their connections) and of the function of each type of component

Page 18: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 18Luca Console

Diagnosis on causal models

Born in medical applications from the need of modeling physiological and pathophysiological processes for avoid knowledge which is too heuristic and based on experience being able to provide causal explanations need of separating different types of knowledge that are often mixed

in the heuristic approach (e.g., domain and control knowledge) Casnet [Weiss, Kulikowski, 78], ABEL [Patil, 81], SC [Reggia, 83]

HEART_FAILURE [Long, 83], CHECK [Console, Torasso, 86] MDX-II [Chandrasekaran, Sticklen, 87]

Similar techniques also in other domains, mechanics: IDM [Fink et al. 85], DIVA [David et al. 88] CHECK

[Console, Torasso, 87] industrial processes: IDS [Pan, 84] geology, GTD [Simmons, 88]

Page 19: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 19Luca Console

Diagnosis on causal models (II)

actualsystem

observedbehaviour

modelof the system

predicted behaviour

diagnosis

design textbook first principles ....

causal modelsof the behaviour(correct and/orfaulty)

diagnosis = covering (explanation)of the observations via causal chainsoriginated by the faulty behaviour

Page 20: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 20Luca Console

A simple example

oil_cup

normal holed

oil_level

normal low

oil_loss

oil_below_car

oil_gauge

normal red

radiator

normal holed

water_levelnormal low

water_tempnormal high

engine_tempnormal high

engine_on

Model:

oil_cup(normal) oil_level(normal)oil_cup(holed) oil_loss(present)oil_loss(present) oil_below_car(present)oill_loss(present) oil_level(low)oil_level(normal) oil_gauge(normal)oil_level(low) oil_gauge(red)oil_level(normal) water_level(normal)

engine(on) engine_temp(normal)oil_level(low) engine(on)

engine_temp(high)...

Page 21: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 21Luca Console

Defining and computing diagnoses

Diagnosis: Given a set of observations determine a (minimal) set of faults whose consequences cover the

observations

“Knowledge level”: diagnosis = abductive process determine an explanation of the observations using the model as

the domain theory Abduction:

Given a theory T and a set Obs of observations to be explained Determine a set E such that

• T E |= Obs

• T E consistent Diagnosis as set covering

Page 22: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 22Luca Console

Example

Obs1 = {engine_temp(high)}

Two minimal candidate explanations E1 = { oil_cup(holed) } E2 = {radiator(holed)}

oil_cup

normal holed

oil_level

normal low

oil_loss

oil_below_car

oil_gauge

normal red

radiatornormal holed

water_levelnormal low

water_tempnormal high

engine_tempnormal high

engine_on

Page 23: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 23Luca Console

Example

Obs2 = {oil_gauge(red),

engine_temp(high)}

One minimal candidate explanation E1 = { oil_cup(holed) }

oil_cup

normal holed

oil_level

normal low

oil_loss

oil_below_car

oil_gauge

normal red

radiatornormal holed

water_levelnormal low

water_tempnormal high

engine_tempnormal high

engine_on

Page 24: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 24Luca Console

Example

Obs3 = {oil_gauge(red),

water_temperature(high)}

One minimal candidate explanation E1 = { oil_cup(holed),

radiator(holed)}

oil_cup

normal holed

oil_level

normal low

oil_loss

oil_below_car

oil_gauge

normal red

radiatornormal holed

water_levelnormal low

water_tempnormal high

engine_tempnormal high

engine_on

Page 25: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 25Luca Console

Diagnosis on models of structure and function

Originated in technical domains (hardware diagnosis) from difficulties in gaining experience with devices (short life cycle) need of diagnosing “new” devices” need of reusing models Three main projects at the beginning of the ‘80s

Sophie (MIT U. Cal Irvine, BBN, poi XeroX)

• seminal paper “How Circuit works“ [deKleer, 76]

• tutoring system for HW diagnosis HT project at MIT [Davis, 83, 84]

• models of structure and function, reasoning techniques DART project at Stanford [Genesereth, 84]

• logical languages for modeling for diagnosis and design

Application to other domains

Page 26: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 26Luca Console

Diagnosis on models of structure and function(II)

actualdevice

observedbehaviour

modelof the device

predicted behaviour

diagnosi

design textbook first principles ....

model of the structureof the device and of the (nominal) behaviourof each type ofcomponent

diagnosis = removing discrepanciesbetween the nominal predicted behaviourand the observed one

Page 27: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 27Luca Console

A simple (classical) example

Function of each type of component:

Adder(X) not AB(X) out(X) = inp1(X) + inp2(X)

Multiplier(X) not AB(X) out(X) = inp1(X) * inp2(X)

...

Structure (functional structure):

Multiplier(Mult1), Multiplier(Mult2),

Multiplier(Mult3), Adder(Add1),

Adder(Add2)

out(Mult1) = inp1(Add1)

out(Mult2) = inp2(Add1) = inp1(Add2)

out(Mult3) = inp2(Add2)

Model

Mult1

Mult2

Mult3

Add2

23

23

23

Add1 A

B

Page 28: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 28Luca Console

Defining and computing diagnoses

Generating prediction starting from the model of the correct behaviour (and the inputs)

Analysis of the discrepancies between predicted and observed behaviour; for each predicted value that differs from the observed one: conflict = set of components involved in the discrepancy; they

cannot be all working properly generating all conflicts (actually only the minimal ones) at least one component in each conflict must be faulty

Page 29: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 29Luca Console

Example

Mult1

Mult2

Mult3

Add2

23

23

23

Add1 A

B

Prediction: A=12, B=12

12

12

Observation A=10, B=12

10

12

A=10 generates two conflicts:{Add1, Mult1, Mult2}{Add1, Mult1, Mult3, Add2}

Page 30: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 30Luca Console

Defining and computing diagnoses (contd.)

Generating prediction starting from the model of the correct behaviour (and the inputs)

Analysis of the discrepancies between predicted and observed behaviour; for each predicted value that differs from the observed one: conflict = set of components involved in the discrepancy; they

cannot be all working properly generating all conflicts (actually only the minimal ones) at least one component in each conflict must be faulty

Generating diagnoses from conflicts diagnosis = (minimal) hitting set of the conflicts intersection between the conflicts provides single-fault diagnoses

Page 31: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 31Luca Console

Esempio

Mult1

Mult2

Mult3

Add2

23

23

23

Add1 A

B

10

12

Candidates (minimal hitting sets)single faults {Add1} {Mult1}double faults {Mult2, Mult3},

{Add2, Mult2}

Prediction: A=12, B=12

Observation A=10, B=12

A=10 generates two conflicts:{Add1, Mult1, Mult2}{Add1, Mult1, Mult3, Add2}

Page 32: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 32Luca Console

Defining and computing diagnoses (contd.) Generating prediction starting from the model of the correct

behaviour (and the inputs) Analysis of the discrepancies between predicted and observed

behaviour; for each predicted value that differs from the observed one: conflict = set of components involved in the discrepancy; they cannot be

all working properly generating all conflicts (actually only the minimal ones) at least one component in each conflict must be faulty

Generating diagnoses from conflicts diagnosis = (minimal) hitting set of the conflicts intersection between the conflicts provides single-fault diagnoses

(optional) corroboration principle exonerate all the components involved in each concordance between

observed and predicted behavior,

Page 33: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 33Luca Console

Esempio

Mult1

Mult2

Mult3

Add2

23

23

23

Add1 A

B

10

12

Applying cooroboration from B=12exonerate Add2, Mult2, Mult3candidates: {Add1}, {Mult1}

Candidates (minimal hitting sets)single faults {Add1} {Mult1}double faults {Mult2, Mult3},

{Add2, Mult2}

Prediction: A=12, B=12

Observation A=10, B=12

A=10 generates two conflicts:{Add1, Mult1, Mult2}{Add1, Mult1, Mult3, Add2}

Page 34: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 34Luca Console

Defining and computing diagnoses (II)

diagnoses: extensions of a default theory whose logical theory is the models and whose defaults are as above [Reiter, 87]

Consistency-based diagnosis

• use of the Assumption Based Truth Maintenance System (ATMS) for computing diagnoses

• “Knowledge level”: diagnosis = form of default reasoning– default: each component behaves normal, if this is consistent:

: AB(C)

AB(C)

Page 35: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 35Luca Console

Exploiting models of correct/faulty behaviour

Goal of model-based diagnosis: using models that are easy to acquire reusable

for diagnosing different devices (having the same components) for different tasks (e.g. simulation, FMEA, ..)

Initial proposal: using only models of correct behaviour They are those that are in strict accordance with the goals but unfortunately they are not always sufficient need of exploiting also fault models of some form

predictive models [Struss, Dressle, 89] [de Kleer, Williams 89] “weak” models of physical impossibility [Friedrich et al. 90] behavioural models [Console, Torasso, 91]

Page 36: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 36Luca Console

Example

Model of the correct behaviour

battery(S) not AB(S) voltageOut(S,ok)

bulb(B) not AB(B) voltageIn(B,X) light(B,X)

wire(W) not AB(B) voltageIn(W,X) voltageOut(W,X)

B-1S

B-2 B-3

W-1

W-2

W-3

W-4

W-5

W-6

• Fault models are needed– predictive: bulb(B) AB(B) voltageIn(B,X) light(B,off)

– weak: “physical impossibility” : not(AB(W) and voltageOut(W,ok)

•Observations: light(B-1,off), light( B-2,off), light( B-3,ok)

•Candidates:

{B-1, B-2},

{S, B-3}, {S, W-3}, {W1, W3} ..... NONSENSE!!!!!

Page 37: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 37Luca Console

Diagnosis on behavioural models: a spectrum of definitions

behavioural models [deKleer, Williams, 89]: set of modes of behaviour for each component set of constraints (rules) for each mode

Definition of diagnosis [ Console, Torasso, 91]: integrating abductive and consistency-based diagnosis

abduction and consistency are the two extremes of a spectrum of alternatives

abduction is the most restrictive definition• it requires “complete” models• it provides a strong (physical) notion of explanation

consistency-based is less restrictive• less constraints on the models• weaker notion of explanation

Page 38: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 38Luca Console

Diagnosis on behavioural models: a spectrum of definitions (II)

Criteria for comparing the alternatives Criteria for choosing the “right” definition, given the available model and

observability conditions

lattice of definitions

abduction

consistency-based

Lattice of sets of solutions

abduction

consistency-based

ordering:set inclusion

Page 39: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 39Luca Console

Diagnosis as a process

Diagnosi s is an iterative process

Different halting conditions for different goals: fault detection fault localization fault identification

Overall goal: repair the system, not only diagnose it

generation of the candidatesfrom initial observations

generates- probe- testfor disrimination

Stop?

No

update candidates

Yes

Page 40: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 40Luca Console

Generation of tests/probes

based on predictions generated by each candidate on unknown measurable

points cost/risk/benefits of the different tests/probes fault proability of the various components

Approach based on entropy [deKleer, 87, 92] a-priori probability of the faults (even a rough estimate) given set D1, D2, ... Dn of candidates to be discriminated

generate predictions from each candidate for each probe/test, compute the a-posteriori probability p(Di|

T(x)), for each possible outcome x of T select the test/probe for which the distribution p(Di|T(x)) has a

minimal entropy (this is the test that on average best discriminates between the candidates)

Page 41: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 41Luca Console

Example

Two candidates D1 e D2 with the same a-priori probability Two probes (tests) are possible

A with possible values 0 e 1 B with possible values 0 e 1

Prediction: D1 predicts A(0) e B(1) D2 predicts A(1) e B(1)

Discrimination: P(D1 | A(0)) = 1, P(D2 | A(0) =0, P(D1 | A(1)) = 0, P(D2 | A(1) =1 P(D1 | B(0)) = 0, P(D2 | B(0) =0, P(D1 | B(1)) = .5, P(D2 | B(1) =.5

Then A is the test that on average best discriminates (whatever is the outcome, only one candidate remains)

Page 42: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 42Luca Console

Example

Candidates single faults {Add1} {Mult1}

Mult1

Mult2

Mult3

Add2

23

23

23

Add1 A

BMeasurement

Page 43: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 43Luca Console

Integrating diagnosis and repair

Diagnosis is not the final goal: the goal is to repair the system Defining repair strategies

replacement of components reconfiguring the system taking into account the cost of the system breakdown, real time

constraints ...

Integrating diagnosis and repair planning repair strategies define criteria for halting the diagnosis loop (e.g. it is

useless to discriminate between faults that are repaired in the same way)

In some cases it is better to perform a repair action before a complete discrimination between the candidates

opportunistic reasoning strategies

Page 44: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 44Luca Console

Example

Power distribution Network (Siemens Austria, Friedrich et al.)

t2

t1

t4t3 t5

l1

l2g1 g2

l3 l4 ~

~

b

immediate reconfiguration action: switch breaker b to serve t3then discrimination between the candidates (measuring power in t1) and repair

candidates: {I1}, {I2}

-

Observation: no power in t2 (house) and in t3(hospital)

-

Page 45: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 45Luca Console

Models of real devices

Modeling is the critical aspect of model-based diagnosis Each model is an abstraction of the actual physical system

different choices and assumption in modeling different dimensions (aspects) are captured by different types of

models choosing the models depend on many factors

which pieces of information are available which are the goals of diagnosis which observations (and in which form) can be available which repair and test action can be made temporal constraints on the behavior of the device and on the

diagnostic process ....

Different dimensions in modeling

Page 46: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 46Luca Console

Dimensions in modeling (not exhaustive !)

component orientedprocess oriented

causal models process modelsstructuralmodels

functionalmodels

behaviouralmodels

teleologicalmodels

correctbehaviour

faultmodels

static dynamic time-varying

quantitative qualitative

discrete state change derivatives

intensional extensional

landmarksintervals

orders ofmagnitude

...

....

... ...

... ...

crisp probabilistic

(similar to comp. oriented.)

hierarchicalflat

Page 47: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 47Luca Console

Multiple models Usually combining different types of models (multi-

modeling) is a good choice each type of models captures some aspects and some types of

faults “pathways of interaction” [Davis, 84]

Example: electronic (electric) circuit Model of structure (functional) and function (see above)

captures faults to components pathways of interaction: input-output behaviour of the

components Model of the physical structure (layout)

captures layout faults (e.g. bridge faults) pathways of interaction: adjacency of components

teleological model capture faults in design or in the construction of the device

Page 48: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 48Luca Console

Analysis of some modeling techniques

Many techniques in use in real systems Analysis of some of the dimensions listed before

qualitative models landmarks e qualitative constraints orders of magnitude models based on deviations

temporal, dynamic and time-varying models hierarchical models probabilistic models

Page 49: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 49Luca Console

Qualitative models

Quantitative models: difficult to build (especially for fault models) usually they are not those on which experts rely for the analysis of

a device (of its behaviour, e.g. for diagnosis) in many cases imprecise knowledge makes numerical models

useless (e.g. model of the combustion in an engine) usually imprecision in the observations

Goal: building models that describe in a qualitative way the behavior of a physical system many approaches to qualitative reasoning a research area with very strong connections with model-based

diagnosis

Page 50: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 50Luca Console

Qualitative reasoning Many AI applications need models of real physical systems

Example: models of devices for simulations, diagnosis, monitoring, … models of processes for simulation, monitoring, …

Different types of models can be used Quantitative (numeric) models: based on mathematical equations

in some cases they are derived from physical laws but usually

they are difficult to use they are not what people use to solve problems

Qualitative models abstract models they need a “new mathematics”, that is “common-sense” forms of reasoning to solve

qualitative equations closer than numeric models to the way we reason problem: being more abstract they are less accurate and can be ambiguous

Page 51: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 51Luca Console

Origins Formalising “common-sense” human reasoning;

Example definition of a qualitative physics (“naïve physics manifesto”) that is close to

the way we reason on the world around us theories of causality (causal ordering)

Diagnosis (and more generally reasoning) model-based In the following

Some simple techniques of qualitative reasoning: landmarks equations and qualitative algebra qualitative differential equations order of magnitude reasoning reasoning on qualitative deviations

basic ideas of qualitative simulation for model-based diagnosis

Page 52: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 52Luca Console

Landmarks

Qualitative abstraction of a physical measure Consider a physical measure m and its domain D

isolating in the doamin D a set of alues corresponding to significant changes for m: landmarks

associating qualitative values to the points and intervals that have been isolated Example: flow

e.g. flow in a pipe (sign may indicate the direction of flow)

0 posneg

0 50

l/min

-50l/minbiglneg smallneg smallpos bigpos

Page 53: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 53Luca Console

Qualitative relations (constraints)

mathematical models are based on relations (e.g. equations or inequalities) Qualitative models: qualitative relations (equations or inequaalities)

Example: in physics F = ma: relation (mathematical equation) one of the quantity can be inferred as numeric values for the other two are known

Example in qualitative physics Let us consider the case of 1 landmark (the value 0) and thus 3 qualitative values

corresponding to the sign of a measure: -, 0, + (only 0 e + for m) Given the qualitative relation F=ma

we need new rules for inferring the qualitative value of a measure, given the qualitative values for the other two

Example: from m=+ and a=+ infer F=+

A new mathematics for solving qualitative relations definition of algebras for different qualitative domains

Page 54: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 54Luca Console

Exampel: qualitative sum

f = f1 + f2 (notice that there are ambiguous cases)

+ neg 0 posneg neg neg ??0 neg 0 pospos ?? pos pos

Similarly for other operations ...

…. and operations on other domains example sum on the domain {Neg, neg, 0, pos, Pos}

the ambiguous cases may augment: pos + pos = ??? (pos o Pos)

* neg 0 posneg pos 0 neg0 0 0 0pos neg 0 pos

Page 55: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 55Luca Console

Given a set of equations (and/or inequalities)

determining a solutions = solving a set of constraints reasoning based on constraint satisfaction and propagation techniques Example

x + y = z x=0, y=pos, z=pos or

from x 0 infer x=pos, y=0, z=pos or

z = pos x=pos, y=pos, z=pos{}

Differential qualitative equations Also derivatives assume only qualitative values

Example, pos, 0, neg Inference rules for inferring the new value of a quantity given its past qualitative value and

its qualitative derivative

Examplesfrom x=pos dx/dt=0 infer x=pos

from x=0 dx/dt=pos infer x=pos

from x=pos dx/dt=neg infer x=? (pos, 0 - , may be not - for continuity)

Page 56: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 56Luca Console

Orders of magnitude A useful representation for removing some of the ambiguities in qualitative

reasoning Example: the result of a summing a + and a - can be disambiguated in case of

different orders of magnitude Absolute and relative orders of magnitude An algebra for relative orders of magnitude [Raiman] [Dague]

4 basic relations

« (negligible wrt) ( close to)

distant from) ~ (comparable to) axioms, for example

A A

A BB A

A B, B C A C

A « B A (A +B)

A « B , B ~ C A « C

A B (A-B) ~ A or (A-B) ~ B

.....

Page 57: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 57Luca Console

An example of qualitative simulation

Given A physical system described by a set of qualitative relations initial conditions (possibly) external perturbations by means of exhogenous variables (variables

corresponding to interactions with the external world) Determine

the possible evolutions of the system State: description of the system at a given time point

defined as a vector of values for the qualitative variables Envisionment: graph characterized by

states state transitions, originated by

differential equations (feedback) exhogenous influences

Page 58: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 58Luca Console

Example

Pipe characterized by flow f (qualitative values 0, +) tank characterized by pressure p

qualitative values: 0, +, ++ derivative: qualitative values 0, +, - equation

pipe1 pipe2

tank

OUTIN ffdt

dp

Example of simulation instant t=0: p=0 fIN=+ fOUT=0

applying constraint propagation dp/dt=+

applying relation between values and derivatives instant t=1 p=+ fIN=+ fOUT=0

applying constraint propagation dp/dt=+

applying relation between values and derivatives: 2 possibilities for t=2p=+p=++ …. envosionment graph

Page 59: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 59Luca Console

Models based on deviations

In previous example: qualitative representation of absolute values of a quantity

In many applications it may be useful to reason in terms of deviations of a quantity from its reference value

Example Pipe in which the flow changes in time (e.g., as an effect of a

control system) In the model it is useful to reason in terms of f (deviation from

the correct value) rather than in terms of f not AB(pipe) f = 0 leaking(pipe) f = neg

The absolute value of the quantity is not necessary for diagnosis

model based on qualitative deviations

Page 60: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 60Luca Console

Diagnosis with qualitative models

Qualitative constraints associated with the modes of behaviour of a component

Qualitative simulation can be used to predict the behaviour of the device (correct and/or faulty behaviour)

Qualitative abstractions of the observations (if they are numerical, possibly with a measurement error)

Discrepancies (concordance) between predicted and observed behaviour may be more difficult to determine

Page 61: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 61Luca Console

Hierarchical models

many devices have a huge number of components Usually the structure of a device can be decomposed in a

hierarchical way macro-components with connections each macro-components can be exploded in a number of sub-

components (with connection only within the macro-component)

Interesting if one can provide a model for macro-components

Diagnosis: determine the faulty macro-components

this can be done efficiently if there are few macro components refinement focusing on the sub-components of the candidate

macro-component

Page 62: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 62Luca Console

Example

Circuit macro-components adder, multiplier (with a model) diagnosis at the level of logical gates

Add1 Mult1

Mult2Add2

• Diagnosis– determine which macro-component is faulty (e.g. Add1)

– consider the structure of an Adder in terms of logical gates and perform diagnosis on that component

Page 63: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 63Luca Console

Probabilistic models

Imprecise knowledge in many domains Representation of uncertainty by means of probability

distributions Bayesian networks [Pearl, 88] are a powerful tool for

representing and reasoning with probabilistic information Used for diagnosis in many different ways

probabilistic causal models

extension of causal models with conditional probabilities associated with the causal relations

reconstruction of the approaches based on structure and function as bayesian networks

Page 64: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 64Luca Console

A simple example

Given the observation fever one can compute the probability of cold and pneumonia as explanations of the symptom

if a observe also sneezing then the probability of cold will increase and the one of pneumonia will dicrease

coldcold pneumoniapneumonia

feverfeversneezingsneezing

p1p3

p2

Page 65: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 65Luca Console

Time-dependent models

The examples discussed before abstract from time, no time dependency in the models

Time is a fundamental dimension in diagnosis At least three important aspects in the behaviour of a

physical system [Console et al. AIJ 98] time-varying contexts: different sets of observations gathered at

different time points (e.g. test vectors) temporal behaviour: symptoms manifest themselves in time (for

some time and some time after the fault. usually dynamic behaviour: the device (component) has an

internal state (memory) on which the behaviour depends time-varying behaviour: the device (component) has different

faults across time

Page 66: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 66Luca Console

Time-varying contexts

Application of different test vectors to a device across time If static models are adopted (i.e., time is abstracted):

if C1 is the set of candidates for the test vector V1 if C2 is the set of candidates for the test vector V2 then the resulting set of candidates is C1 C2

Strategies for selecting the test vector in the most appropriate way

More complex if the model is not static, i.e., if temporal behaviour is taken into account (see next slides)

Page 67: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 67Luca Console

Temporal behaviour

representation of the temporal patterns corresponding to the manifestation of a fault 8abstracting dynamics)

Example (from [Long, 83] causal model in a medical domain):

waterRetention(T1), fluidTheraphy(absent,T2) bloodVolume(high,T3)

{ start(T1) atLeast 9 hours before start(T3)

end(T1) atMost 6 hours before end(T3)

start(T2) atLeast 48 hours before start(T1)

end(T2) after end(T3) }

Example (digital circuit)

inverter(X), not AB(X,I), input(X, In, T) out(X, not In, T1)

{ T, T1 during I, T1 = T+1 }

Page 68: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 68Luca Console

Diagnosis on temporal models

Diagnosis: explaining the symptoms, consistently with their temporal extents

Integration between diagnostic and temporal reasoning The diagnostic process becomes more complex from the

computational point of view Focusing and greater discrimination power

Example fault1 symptom1 and symptom2 {symptom1 before symptom2 } fault2 symptom1 and symptom2 {symptom1 during symptom2 }

If the observation is

symptom1[8.30, 16.30] symptom2[12, 14]

then only fault2 is a consistent diagnosis

Page 69: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 69Luca Console

Modeling dynamics

Almost all the devices have an internal state and their behaviour is influenced (and influences) such a state

Modeling dynamics is in most cases fundamental for performing diagnosis correctly but in some cases dynamics can be conveniently abstracted

Many approaches to dynamic modeling; they can be roughly divided into two groups models based on differential equations (usually qualitative)

approach suitable for states corresponding to physical quantities that can change in a continuous way

discrete representation of state changes

approach suitable in case of discrete states

Page 70: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 70Luca Console

Dynamic models with discrete state

Example: diagnosis of sequential circuits,

model of an SR flip-flop

SRFlipFlop(d) and ok(d,T) and inp(d,0,1,T1)

and state(d, empty,T1)

out(d,1,0,T2) and state(d,full,T2)

{T1 during T, T2 during T, T2 = T1 +1}

Page 71: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 71Luca Console

Continuous state and continuous change represented in a qualitative wayExample: model of a tank in which the fluid level depends on the balance

between input and output flow fluid level is the state

Qualitative state transformation may be ambiguousExample, landmarks 0, small, 50 medium 100, big if LivH20=0 in state s and positive derivative, then LivH20 = small in

s’ (assuming continuity in state change) if LivH20=small in state s and positive derivative, which value in s’?

After how long LivH20=50 (if ever ..)?

Dynamic models with qualitative differential equations

dLivH2O

dt fin fout

Page 72: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 72Luca Console

Diagnosis on dynamic models

same definition as in the case of temporal models (which is indeed an abstraction) but observations in different states reconstructing the state transitions of the system that allow to

explain the observations

Complex problem in case of partial observations (or observations only in some states) many alternatives in the possible evolution of a system, especially

in case of qualitative models in many cases the problem is underconstrained [Hamscher &

Davis, 1984]

Page 73: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 73Luca Console

Time-varying models

A device (component) may have different faults across time Not all the evolutions are possible; graph of the allowed

mode transitions for a device

Example: pump

ok partially occluded occluded

(partially occluded is a fault that may be reversible)

temporal constraints may be associated with the transitions

• time-varying behaviour is usually couple with dynamic behaviour

Page 74: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 74Luca Console

Diagnosis on time-varying models

Observations in different states (labeled) Diagnosis

Atemporal diagnosis in each state in which there are observations, it produces a set of candidates for each state

Determine the evolutions that are consistent with the graph of mode transitions (and, possibly temporal constraints on such transitions)

focusing techniques for using the mode transition graphs in an active way for generating predictions about future states

Page 75: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 75Luca Console

Which type of temporal model?

It depends on the goals of the diagnostic process and on the aspects (dimensions) that have to be modeled [Console et al. AIJ 98] Granularity of the phenomena is a fundamental parameter,

especially granularity of faults, observation, state change, .. Temporal window for diagnosis For example one may adopt a dynamic model abstracting time-

varying behavior if the modes (faults) change slowly wrt the dynamics of the system and the temporal window for diagnosis

on the other hand a model of the time-varying behaviour is needed in case the system has to be monitored across time

Page 76: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 76Luca Console

In conclusion

Modeling is the real issue in model-based diagnosis many different choices and assumptions Choosing the “right” model is not easy at all and require

“sensibility”

Page 77: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 77Luca Console

Advantages of the model-based approach

The model-based approach has significant advantages with respect to the heuristic one ... reusable models; a library of components model can be built and

the models in the library re-used for the diagnosis of different devices or for other tasks

building and maintaining models is less critical the models are “objective” and do not rely on experience possibility of diagnosing “new” devices it is natural to deal with dynamic and time-varying behaviour it is natural and simpler to deal with multiple faults and with fault

masking detailed explanations

Page 78: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 78Luca Console

Problems of the model-based approach

... but new problems arise building models is not easy at all

many dimensions have to be taken into account many alternatives have to be cconsidered along each

dimension each model is based on some assumptions and thus it may be

adequate in some cases and inadequate in other cases the diagnostic process is more complex from the computational

point of view (mainly if and because more complex aspects such as multiple faults, masking, time-dependent behaviour, … are taken into account)

There are not yet tools available for developing model-based applications

Page 79: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 79Luca Console

Efficient Algorithms

Many strategies for computing diagnses efficiently probabilistic focusing [deKleer 92]

a-priori probability of faults a-posteriori probability, given the observations computing only preferred (leading) conflicts and diagnosis [Struss,

Dressler] focusing on some classes of faults

e.g. Single fault, double-fault, only some types of faults focused ATMS

strategies for controlling the assumptions in the ATMS [Dressler] Working hypotheses [Struss, 92]

“meta-livello” techniques for controlling the diagnostic process

Page 80: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 80Luca Console

Efficient Algorithms: knowledge-compilation

Knowledge compilation: deriving a knowledge base (usually in some “operational” form) from other knowledge

various approaches in model-based diagnosis a-prior compilation: deriving heuristic systems from the model-based

ones model-based [Chandrasekaran] e.g. compiling rules, decision trees, … by running cases and using

machine learning techniques caching of solution generated by the model-based system (possibly

after some generalization) [Pazzani, Steels, …] coupling of model-based and case-based reasoning compilation of focusing condition for reducing the search space for

model-based reasoning [Console et al, 92, 96]

Page 81: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 81Luca Console

Applications

Many applications many application areas

electronic and electric components telecommunication systems power plants and power distribution Automotives Aereonautics and aerospatial industrail processes ….

different types of models different approaches to diagnosis

Moreover, application of the model-based technology to other problem solving problems

Page 82: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 82Luca Console

Fundamental role of tools for building applications many tools available for building “traditional” knowledge

based systems Tools for model-based reasoning

some starting experiences Occ’m Raz’r Rodon from Rose Informatica

need of engineered tools for building applications with a limited effort

Tools for model-based diagnosis

Page 83: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 83Luca Console

Relations with other research areas

As for heuristic diagnosis in the ‘70s, in the ‘80s model-based diagnosis has been an area with strong connections with other research areas in AI new methodologies originated from MBD and moved to other areas MDB has been the application area of other methodologies

Theories of diagnosis strict connection with non-monotonic reasoning

new methodologies, e.g. abduction, use of TMS, ATMS application of techniques for computational approaches to non

monotonic reasoning application area for probabilistic reasoning and Bayesian nets

Qualitative reasoning: a very strict connection Constraint-based reasoning

Page 84: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 84Luca Console

Knowledge representation strict relations for modeling techniques

Temporal Reasoning e theories of action and change in particular for per dynamic systems

Control Theory a parallel model-based approach to diagnosis in control theory; based

on mathematical models but interesting interchanges and relations

Case-based Reasoning Machine Learning

machine learning techniques for compiling knowledge from models new approaches to learning exploiting models

Cooperative problem solving:integration between tasks

Relations with other research areas (2)

Page 85: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 85Luca Console

... and the story continues ...

Heuristic diagnosis was one of the central areas for AI in the ‘70s

Model-based diagnosis inherited such a role from the mid ‘80s an area in which theories and application blended and grew in

parallel a lot of research work many project in North America, in the EU and in Japan many application in use on the field

an area with many research opportunities for the ‘00s

Page 86: Diagnostic problem solving: history and state of the art

Diagnostic Problem solving: 86Luca Console

To learn more Introductory chapters to heuristic diagnosis in books such as

Jackson: Introduction to Expert Systems, Second Edition, Addison Wesley 1990. M. Stefik: Introduction to knowledge systems, Morgan Kaufmann, 1995.

the former has a small section on model-based <diagnosis, the second a larger section with an introduction and case studies

A conceptual analysis of the heuristic approach can be found in W. Clancey: “Heuristic Classification”, Artificial Intelligence Journal, 25(3), 1985, pp. 289-350

A collection of seminal papers on model-based diagnosis with introductions and an annotated bibliography can be found in

W. Hamscher, L. Console, J. de Kleer: Readings in Model-based Diagnosis, Morgan Kaufmann 1992

Research papers can eb found in the main AI conferences (IJCAI, AAAI, ECAI, ...) and in Proceedings of the annual workshop DX (Intl. W. on Principles of Diagnosis) Interesting papers, especially on modeling, also in the proceeding of the annual QR (Qualitative

Reasoning) workshop

Moreover papers in the main AI journals Papers describing application in application conferences (such as IAAI or IEEE CAIA) and in

journals such as: IEEE Expert, AI in Engineering, Applied AI, ...


Recommended