Post on 07-Jan-2016
description
transcript
Diagnostic Problem solving: 1Luca Console
Luca Console
Dipartimento di Informatica
Università di Torino
e-mail: lconsole@di.unito.it
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
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
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
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
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
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, ...
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
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]
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
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....
...........
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 (....) ...
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?
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
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”
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:
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
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]
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
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)...
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
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
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
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
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
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
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
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
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}
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
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}
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,
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}
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)
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]
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!!!!!
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
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
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
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)
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)
Diagnostic Problem solving: 42Luca Console
Example
Candidates single faults {Add1} {Mult1}
Mult1
Mult2
Mult3
Add2
23
23
23
Add1 A
BMeasurement
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
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)
-
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
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
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
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
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
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
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
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
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
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
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)
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
.....
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
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
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
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
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
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
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
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
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
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)
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 }
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
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
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}
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
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]
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
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
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
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”
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
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
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
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]
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
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
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
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)
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
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, ...