1 / 44

Model Based Reasoning and Qualitative Reasoning

Model Based Reasoning and Qualitative Reasoning. Yuhong Yan NRC-IIT Yuhong.yan@nrc.gc.ca. Overview. About what? MBR, MBD, QR History and state of art Examples: give you first feel What is the content? Content of this part

afya
Download Presentation

Model Based Reasoning and Qualitative Reasoning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Model Based Reasoning and Qualitative Reasoning Yuhong Yan NRC-IIT Yuhong.yan@nrc.gc.ca

  2. Overview • About what? • MBR, MBD, QR • History and state of art • Examples: give you first feel • What is the content? Content of this part • How to study this part? Reading papers, reference books, assignments I reference Luca Console’s slides in the first part. If most of the content of a slide is from his original one, I label his name on the slide.

  3. My Expectation in this Course • Formal methods • Only a few main important topics • Consistent-based diagnosis • Multiple fault modes • Select observation points • ATM • Qualitative modeling and reasoning • Examples • More thinking, more pleasure, less pressure

  4. 2 Mult1 3 Add1 A 2 Mult2 3 Add2 B 2 Mult3 3 Begin with an example

  5. 2 Mult1 3 Add1 A 2 Mult2 3 Add2 B 2 Mult3 3 Observation vs. Prediction 10 (12) 12 (12)

  6. 2 Mult1 3 Add1 A 2 Mult2 3 Add2 B 2 Mult3 3 What’s wrong 10 (12) 12 (12) Diagnoses {Add1}, {Mult1}, {Mult2, Add2}, {Mult2, Mult2}

  7. 2 Mult1 3 Add1 A 2 Mult2 3 Add2 B 2 Mult3 3 Model Behavioral model 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) ... Structural model: Multiplier(Mult1), Multiplier(Mult2), Multiplier(Mult3), Adder(Add1), Adder(Add2) out(Mult1) = inp1(Add1) out(Mult2) = inp2(Add1) = inp1(Add2) out(Mult3) = inp2(Add2)

  8. 2 Mult1 3 Add1 A 2 Mult2 3 Add2 B 2 Mult3 3 Prediction: A=12, B=12 Observation A=10, B=12 12 • A=10 generates two conflicts: • {Add1, Mult1, Mult2} • {Add1, Mult1, Mult3, Add2} 10 12 12 conflict = set of components involved in the discrepancy; they cannot be all working properly • diagnosis = (minimal) hitting set of the conflicts; • intersection between the conflicts provides single-fault diagnoses

  9. diagnosis = removing discrepancies between the nominal predicted behaviour and the observed one Diagnosis on models of structure and function .... design textbook first principles actual model device of the device observed predicted model of the structure behaviour behaviour of the device and of the (nominal) behaviour of each type of component diagnosis From Luca Console

  10. A Little Bit on History • 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 From Luca Console

  11. 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 symptoms faults (diseases) • knowledge derives from experience • knowledge can be elicited from domain experts and represented using suitable KR languages From Luca Console

  12. domain expert (and knowledge engineer) K.A. interface inference K.B engine control K.B. work. mem. user interface final user Diagnostic expert systems: conceptual view From Luca Console

  13. 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 From Luca Console

  14. Critiques to the heuristic approach • 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 • it is impossible to deal with cases not considered a-priori • it is difficult to deal with multiple faults • it is impossible to reuse knowledge in similar devices or even in new versions of the same device • limited explanation capabilities From Luca Console

  15. 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” From Luca Console

  16. What is model-based reasoning (MBR) • an inferring process using models abstracted from the reality of a system. MBR is the symbolic processing of an explicit representation of the internal working of a system in order to predict, simulate and explain the resultant behaviour of the system from the structure, causality, functional and behaviour of its components

  17. Model-based Diagnosis (MBD) • A main application task for MBR • MBD = finding malfunctions (faults, diseases ...) in a system starting from a set of observations (measurements, tests, symptoms, examinations ...) and system description.

  18. .... design textbook first principles actual system model of the system observed behaviour predicted behaviour diagnosis Model-based diagnosis • “knowledge level” view: • Different approaches • different types of models • different definitions of diagnosis From Luca Console

  19. 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 From Luca Console

  20. causal models of the behaviour (correct and/or faulty) diagnosis = covering (explanation) of the observations via causal chains originated by the faulty behaviour Diagnosis on causal models .... design textbook first principles actual model system of the system observed predicted behaviour behaviour diagnosis From Luca Console

  21. oil_cup radiator normal holed normal holed oil_loss oil_level water_level oil_below_car normal low normal low oil_gauge water_temp normal red normal high engine_on normal high engine_temp Example • Obs1 = {engine_temp(high)} Two minimal candidate explanations • E1 = { oil_cup(holed) } • E2 = {radiator(holed)} From Luca Console

  22. oil_cup radiator normal holed normal holed oil_loss oil_level water_level oil_below_car normal low normal low oil_gauge water_temp normal red normal high engine_on normal high engine_temp Example • Obs2 = {oil_gauge(red), engine_temp(high)} One minimal candidate explanation • E1 = { oil_cup(holed) } From Luca Console

  23. 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

  24. Comparing abduction, deduction and induction A=>B A -------- B Deduction: major premise: All balls in the box are black minor premise: These balls are from the box conclusion: These balls are black Abduction: rule: All balls in the box are black observation: These balls are black explanation: These balls are from the box Induction: case: These balls are from the box observation: These balls are black hypothesized rule: All ball in the box are black Induction: from specific cases to general rules Abduction and deduction: both from part of a specific case to other part of the case using general rules (in different ways) A=>B B -------- Possibly A Whenever A then B but not vice versa --------- Possibly A=>B

  25. Abduction-based diagnosis • Originally, diagnostic systems were abductive ones and relied on fault models AB(c) => symptom B. • They are able to give explanations of symptoms from the diagnosis: if diagnosis AB(c) is inferred by abduction, it explains (in the sense implies or entails) symptom B.

  26. Diagnosis on models of structure and function • Models of structure and function • 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 • diagnosis = (minimal) hitting set of the conflicts From Luca Console

  27. diagnosis = removing discrepancies between the nominal predicted behaviour and the observed one Diagnosis on models of structure and function(II) .... design textbook first principles actual model device of the device observed predicted model of the structure behaviour behaviour of the device and of the (nominal) behaviour of each type of component diagnosis From Luca Console

  28. 2 Mult1 3 Add1 A 2 Mult2 3 Add2 B 2 Mult3 3 Model Behavioral model 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) ... Structural model: Multiplier(Mult1), Multiplier(Mult2), Multiplier(Mult3), Adder(Add1), Adder(Add2) out(Mult1) = inp1(Add1) out(Mult2) = inp2(Add1) = inp1(Add2) out(Mult3) = inp2(Add2)

  29. Modeling • 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 From Luca Console

  30. Dimensions in modeling (not exhaustive !) process oriented component oriented causal models process models structural models functional models behavioural models teleological models (similar to comp. oriented.) ... ... ... ... crisp probabilistic correct behaviour fault models .... intensional extensional time- varying quantitative qualitative static dynamic hierarchical flat discrete state change landmarks orders of magnitude ... derivatives intervals From Luca Console

  31. Qualitative Model • 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

  32. + neg 0 pos neg neg neg ?? 0 neg 0 pos pos ?? pos pos * neg 0 pos neg pos 0 neg 0 0 0 0 pos neg 0 pos One Example on Qualitative Model • Exampel: qualitative sum f = f1 + f2 • (notice that there are ambiguous cases) • Similar to define qualitative multiple

  33. Qualitative Modeling • Capture the fundamental aspects of a system or mechanism • Suppress much of the detail • Abstraction and Approximation • Simulating (process)

  34. Qualitative Reasoning • An inferring technique using qualitative model to derive new knowledge of, and gain insight into a system • An approach used by human being’s thinking and reasoning

  35. Limitation of QR • Ambiguous • Less accuracy • More compact or more volume?

  36. Research topics in MBD and QR • Modeling: • New modeling methods • Model reuse • Model checking, verification • Diagnosis methods on: • Hybrid system • Dynamic system • On-board system • New application areas: • Biometrics • Ecology • E-business

  37. The ’00: Who in this area • Crucial Missions: satellites, nuclear plants, chemistry plants, space shuttle, Rockets • E.g. NASA, Thales, Ontario power • Manufacturing: automobile • E.g. all car makers, Bosch • Technique suppliers for the above two • Academic and research institutes • Other areas: • Biomedical • Education • Business

  38. Application: Business system modeling and performance analysis • Causal-effect relation modeling and reasoning • Explanation on the reasons of one performance indicator • Hybrid system: both qualitative and quantitative relation

  39. Application: distributed business application modeling and diagnosis • B to B applications: • supply chain management; • vendor matching on marketplaces; • cooperative project; • virtual organizations/enterprises • B to C applications: through web services • distributed business process modeling: • Workflow network • Business description language • Communication protocol and semantic management • Knowledge management (inside/outside) • Features: • Dynamic environment; • Distributed environment

  40. Workflow network Pic from F.Laymann and D.Roller, “Workflow-based Applications”, IBM Systems Journal, Vol 36, No. 1, 1997

  41. Workflow-based Application WFMS WFMS Execution Execution

  42. Research issues • How to model: design phase • Features of the model • Deadlock • Loop • Resources sharing • Diagnosis: executing phase • If the performance is abnormal, where is the fault? Inside/outside? Recovery actions? • Distributed diagnosis?

  43. Application: Logic in NBON • Initial: logic expression to describe vendor • Review: manually check false positive, false negative • Adjust: more accurate logic expression Not a typical diagnostic problem • The constraints are independent • No constraint propagation, no deduction • No cause-effect relation if don’t exploit business pattern • Need to modify the “model”, not deduce from the model • Can solve with simple algorithm

  44. Prepare yourself to read the proofs • Deduction theorem, which is known to the ancient Greek For any sentences  and ,  |=  if and only if the sentence ( =>) is valid • Reductio ad absurdum (proof by refutation, proof by contradiction)  |=  if and only if the sentence (¬) is unsatisfiable

More Related