1 / 42

Framework for Diagnosing Multiple Faults Using General Diagnostic Engine (GDE)

This article provides an overview of a General Diagnostic Engine (GDE), which employs model-based diagnosis methods to identify multiple faults within systems. It outlines the key processes in GDE, including symptom detection, conflict recognition, and candidate generation using an assumption-based truth maintenance system (ATMS). The article also describes incremental candidate generation strategies and methods for selecting the most effective subsequent measurements for fault discrimination based on entropy minimization. The GDE framework addresses the challenge of diagnosing with incomplete observations by leveraging structured models.

garland
Download Presentation

Framework for Diagnosing Multiple Faults Using General Diagnostic Engine (GDE)

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. College 11 + 13 (1) General Diagnostic Engine (GDE) Artikel: Diagnosing multiple faults J. de Kleer, B. Williams (2) Raamwerk voor diagnostische methoden Artikel: A spectrum of logical definitions of model-based diagnosis L. Console, P. Torasso

  2. werkelijk systeem geobserveerd gedrag observeren discrepantie model normaal gedrag voorspeld gedrag voorspelling General diagnostic engine • GDE is een algemeen diagnostisch systeem • diagnose op basis van structuurmodel en correct gedragsmodellen van componenten DNSB-model

  3. Belangrijke aspecten van GDE • “Multiple fault” diagnosesmethode: Assumption-based Truth Maintenance System (ATMS) • bepalen van de volgende meting voor discrimineren van mogelijke diagnosesmethode: minimum entropy(nodig: a priori kans van falen van een component)

  4. Taken in GDE • symptoom-detectie • conflict-herkenningdoel: bepalen van de complete set van minimale conflicts • candidaat-generatiedoel: bepalen van de complete set van minimale candidaten

  5. Candidaat-generatie • diagnose-proces is incrementeel • set van conflicten neemt monotoon toe • set van candidaten neemt monotoon af (vergelijk hittingset-algoritme en implica(n)ten-aanpak) Idee:incrementele generatie van candidaten:oude minimale candidaten + nieuwe minimale conflicten ==> nieuwe minimale candidaten

  6. Candidaat-generatie nieuw conflict: • als oude minimale candidaat het nieuwe conflict verklaart dan blijft het een minimale candidaat • als oude minimale candidaat het nieuwe conflict niet verklaart dan wordt de oude candidaat vervangen door 1 of meer supersets (nieuwe min. kandidaten).(=uitbreiden met 1 element uit de nieuwe conflict set) NB: exploiteer de minimale-diagnose-hypothese!

  7. A=3 M1 A1 M2 A2 M3 X F Voorbeeld C=2 Y B=2 G D=3 Z E=3 • geen observaties, min. candidaat {} • F = 10, geen 12 --> conflict {A1,M1,M2} • uitbreiden min. candidaten met 1 element uit conflict setmin. candidaten: {A1},{M1},{M2} • G = 12 --> nieuw conflict {A1,A2,M1,M3}candidaten {A1}, {M1} blijvencandidaat {M2} uitbreiden naar: {M2,A1},{M2,A2},{M2,M1},{M2,M3}subset-minimale: {A1},{M1},{M2,A2},{M2,M3}

  8. Conflict-herkenning-strategie • C(Obs,Env)test of de aannames (Env) inconsistent is met de observaties (Obs): • ja: Env is een conflict set • nee: Env is geen conflict setVerfijning strategie: exploiteren van subset-minimaliteit • start bij {}, breidt uit naar Env, stop bij eerste conflict, want dan is Env een conflict • kijk naar eerdere conflicts (als Env superset is dan is Env ook een conflict) methode: P(Obs,Env) Zodra X en ~X voorspeld worden, dan is er een conflict.

  9. Conflict-herkenning-strategie verfijning meet-strategie: monotoniciteit van metingen P(OBS U M, ENV)  P(OBS,ENV) Caching waarden van P(OBS,ENV), zodat alleen de inferenties van M nog gedaan moeten worden.

  10. Conflict-herkenning-strategie verfijning berekeningsstrategie: monotoniciteit van aannames P(OBS, ENV U E)  P(OBS,ENV) Caching waarden van P(OBS,ENV), zodat alleen de inferenties van E nog gedaan moeten worden.

  11. Conflict-herkenning-strategie verfijning berekeningsstrategie: voorkomredundante (identieke) inferenties • vaak overlappende Env’s • voorkomen dat dezelfde regel vaker dan 1x uitgevoerd wordt

  12. Supporting omgeving Nodig: supporting omgeving van de voorspelling • ENVS(V) == {env | V  P(OBS,env)} • Als een supporting omgeving verandert, dan veranderen ook zijn consequenties. • X=6 (M1: A=3, C=2)

  13. In database • [F=12, {A1,M1,M2}] • [A=3, {}] • [B=2, {}] • .. • [X=4, {A1,M2},{A1,A2,M3}][ =6, {M1}] • [Y=4, {A1,M1}][ =6, {M2},{A2.M3}]

  14. Sequentiele diagnose • methode voor het selecteren van de volgende meting om de “beste” candidaat te onderscheiden. • mogelijke metingen baseren oprecords[xi=vik, eik1, eik2, ...] • Als xi gemeten (dus [xi=v,{}]) dan zijn de supporting omgevingen xi<>v conflict sets.

  15. Voorbeeld [X=4,{A1,M2},{A1,M2,M3}] [ =6,{M1}] • metingX=4: {M1} is een conflict {M1} is een (deel-)candidaatX=6: {A1,M2}, {A1,A2,M3} zijn conflicten {A1},{M2,M3},{M2,A2} zijn (deel-)candidatenx<>4 en x<>6: {M1},{A1,M2}, {A1,A2,M3} zijn conflicten {M1,A1},{M1,M2,M3},{M1,M2,A2} zijn (deel-)candidaten

  16. Extra meting Candidaten die blijven (Rik) bij meting xi=vik = • candidaten die de waarde xi=vik moeten hebben (Sik)  • candidaten die niets voorspellen over xi(Uik)

  17. Extra meting • GDE gebruikt kostenfunctie uit beslissing/informatie-theorie:Shannon Entropy H: H = -  pi log pipi= kans op candidaat ci gegeven de observaties. onwaarschijnlijke candidaten: pi nadert 0 waarschijnlijke candidaten: pi nadert 1

  18. “beste” meting Beste meting: degene die de verwachte entropy van de nieuwe set van candidaten minimaliseert: k=1..k=mp(xi=vik) log p(xi=vik) + p(Ui) log m Waarbij • m: aantal mogelijke waarden • p(xi=vki) = p(Sik) + p(Ui)/m • p(Ui)= cj  Ui pj • p(Sik)= cj  Sik pj

  19. GDE • Motivatie van GDE: onmogelijk alle fouten te modelleren GDE: • gebruik correct-modellen • fout = niet correct werkende component Alleen correct-modellen gebruiken is ook niet ideaal....

  20. batterij lamp1 lamp2 lamp3 Probleem! • observaties: lamp1 en lamp2 zijn uit, lamp3 is aan • voorspelling:lamp1, lamp2, lamp3 zijn aan • minimale conflict sets: {B,L1}, {B,L2} minimale candidates: {B}, {L1,L2} kapotte batterij is onmogelijkbij branden van lamp3!!

  21. SHERLOCK (opvolger GDE) • Modelleer ook mogelijke fouten • Voorbeeld: • batterij: leeg  stroom • lamp:  stroom  licht • Aantal mogelijke diagnoses groeit van 2n tot kn • k: aantal modes van een component • n: aantal componenten

  22. samenvatting • GDE algemeen diagnose-systeem op basis van correct-modellen • Motivatie van GDE: • geen foutmodellen gebruiken, maar correctmodellen(fout = niet correct werkende component) • multiple faults • minimaliseren van metingen (Shannon Entropy) • efficient diagnose-systeem • SHERLOCK uitbreiding van GDE met foutmodellen

  23. Raamwerk voor diagnostische methoden Artikel: A spectrum of logical definitions of model-based diagnosis L. Console, P. Torasso

  24. Raamwerk Waarom een raamwerk? • beschrijven van diagnose-methoden • vergelijken van diagnose-methoden • voor analyse van verschillende diagnose-methoden Raamwerk voor logische definities van diagnose.

  25. Onderwerpen • het raamwerk • instanties van het raamwerk= specifieke diagnose-definitie • richtlijnen voor gebruik van diagnose-definities

  26. Diagnose-probleem • contextuele data (CXT)voorbeelden: geslacht, leeftijd • contextdata helpt bij bepalen van de diagnose • contextdata hoeft zelf niet verklaard te worden • observaties (OBS) voorbeelden: een bloedtest • voor de observaties zoek je een verklaring • gedragsmodel (BM) • onderscheid tussen abducibles en non-abducibles • componenten (COMP) • componenten van het systeem • systeemmodel (SD) = (BM,COMP)

  27. Oplossing voor een diagnostisch probleem • verklaring als “consistentie”= zwakke notie van verklaren= diagnose spreekt de observaties niet tegen • verklaring als “covering”= sterke notie van verklaren= diagnose geeft directe support voor de observaties Beide noties te beschrijven in het raamwerk.

  28. Abductie-probleem met `consistency constraints’ • AP<<BM,COMP>,CXT,<+, ->> • +  OBS • - = {f(x) | f(y)  OBS, voor iedere mogelijke waarde voor x van f anders dan y} Merk op: OBS |- - Diagnose: • “cover” de+ (was steeds: foutgedrag) • “is consistent” met de- (was steeds: correct gedrag)

  29. Diagnose bij deze definitie • W is een `toekenning’ van COMP • BM U CXT U W |= + (sterke eis) • BM U CXT U W U - is consistent (zwakkere eis)(BM U CXT U W |=/= m, m  -) • minimaliteit:subset-minimaal in de foute componenten uit de alternatieve W’s • diagnose bestaat uit de foute componenten in W

  30. Idee raamwerk Eisen: • BM U CXT U W |= + • BM U CXT U W U - is consistent • parameters + en - • Verschillende definities van deze parameters representeren verschillende diagnose-methoden

  31. Instanties van het raamwerk Twee eisen van het raamwerk: • BM U CXT U W |= + • BM U CXT U W U - is consistent • Abductief (plus constraints): + = OBS- = {f(x) | f(y)  OBS, voor iedere mogelijke waarde voor x van f anders dan y} • Puur consistentie-gebaseerd: - = {f(x) | f(y)  OBS, voor iedere mogelijke waarde voor x van f anders dan y} + = {}

  32. Instanties van het raamwerk Twee eisen: • BM U CXT U W |= + • BM U CXT U W U - is consistent • abnormaal versus normaal gedrag: + = OBS die abnormaal gedrag weergeven (foutgedrag)+ = OBS die normaal gedrag weergeven (correct gedrag) • mogelijke uitbreiding: neem - ook als parameterindeling + en - gebaseerd op: • geobserveerd • niet geobserveerd • onbekend

  33. Voorbeeld • holed(oil_cup) -> oil_below_car(present) • holed(oil_cup) -> oil_level(low) • correct(oil_cup) -> oil_level(normal) • oil_level(low) & engine(on) -> engine_temp(high) • oil_level(normal) & engine(on) -> engine_temp(normal) Probleem: COMP: {oil_cup} OBS: {oil_below_car(present)} CXT: {engine(on)} Abductieve definitie, met + is foutgedrag: + = {oil_below_car(present)} - = {}, want geen andere oil_below_car(..) aanwezig Oplossing: {holed(oil_cup)}

  34. Voorbeeld • holed(oil_cup) -> oil_below_car(present) • holed(oil_cup) -> oil_level(low) • correct(oil_cup) -> oil_level(normal) • oil_level(low) & engine(on) -> engine_temp(high) • oil_level(normal) & engine(on) -> engine_temp(normal) Probleem: COMP: {oil_cup} OBS: {oil_below_car(present)} CXT: {engine(on)} Consistentie-gebaseerde definitie, met - correct gedrag: + = {} (dus we hoeven het foutgedrag niet te verklaren!) - = {}, want geen andere oil_below_car(..) aanwezig Oplossingen: {holed(oil_cup)}, {correct(oil_cup)} dus {correct(oil_cup)} is hier ook een minimale oplossing!

  35. Voorbeeld • holed(oil_cup) -> oil_below_car(present) • holed(oil_cup) -> oil_level(low) • correct(oil_cup) -> oil_level(normal) • oil_level(low) & engine(on) -> engine_temp(high) • oil_level(normal) & engine(on) -> engine_temp(normal) Bij de aanname:`model voor oorzaken van “oil_below_car(present)” is compleet’ lijkt de verklaring “holed(oil_cup)” aannemelijker. Ontbreekt er een causale relatie? : correct(oil_cup) -> oil_below_car(absent) CBD-definitie zou dan ook “juiste” oplossing geven. • + = {}, - = {oil_below_car(absent)} • {holed(oil_cup)} blijft oplossing • {correct(oil_cup)} is geen oplossing meer (inconsistent)!

  36. Incomplete modellen • Vaak niet alle oorzaken aanwezig in het model: mogelijk “onbekende” oorzaak • i.d.g.: abductie-definitie te strikt • consistentie-gebaseerde definitie wel gerechtvaardigd NB: model niet compleet dan dus niet juist om toe te voegen correct(...) -> ....

  37. Representeren van incompleetheid • incompleetheid expliciet in model • oorzaak • mogelijke causale relatie • conditie is “onbekend” • conditie is niet gespecificeerd • expliciet modelleren van incompleetheid is interessant als het model voor het merendeel compleet is.

  38. Keuzes voor de parameters • compleet foutmodel + sommige delen correctmodel • + = alleen abnormale observaties uit OBS • - = {f(x) | f(y)  OBS, voor iedere mogelijke waarde voor x van f anders dan y} • compleet correctmodel + sommige delen foutmodel • + = alleen normale observaties uit OBS • - = {f(x) | f(y)  OBS, voor iedere mogelijke waarde voor x van f anders dan y}

  39. Richtlijn • bij een compleet model gebruik + • bij een incompleet model gebruik - Belangrijkste is dat er een keus gemaakt moet worden voor + en -.

  40. Representatie diagnose-methode • verschillende instanties van het raamwerk geven mogelijk dezelfde oplossingen • Voorbeeld:als in iedere context een voorspelling voor alle observeerbare parameters isdan abductie-methode = CBD-methode

  41. Zoekruimte • Diagnose gebaseerd op correctmodellen geeft een grote zoekruimte voor mogelijke oplossingen • Noodzakelijk om deze zoekruimte in te perken • abductie is een manier om dit te doen

  42. Samenvatting • raamwerk gebaseerd op parameters: • observaties die “gecovered” moeten worden • raamwerk geeft een heel spectrum van diagnose-definities • extreme van het raamwerk zijn: • puur abductieve diagnose • puur consistentie-gebaseerde diagnose

More Related