-
Für Diagnosezwecke
verwenden Softwaresysteme mit verschiedenen Komponenten häufig Protokollierungsdatenbanken,
welche den Betrieb des Systems und von Komponenten verfolgen. Mit
einer „Ereignisprotokollierung" kann man chronologisch
Ereignisse speichern, die von verschiedenen Softwarekomponenten in
dem System erzeugt werden. Softwarekomponenten können Ereignisse als Reaktionen
auf bestimmte Kombinationen ihres Anfangszustands und Stimuli zum
Beispiel aus anderen Softwaremodulen, der Hardware oder vom Benutzer
erzeugen.
-
Die
protokollierten Ereignisse fallen in der Regel in eine von drei
Kategorien: ein „Fehlerereignis" wird erzeugt, wenn
ein Fehler gefunden wurde oder ein außergewöhnliches oder unerwartetes
Ereignis auftrat; ein „Erfolgsereignis" informiert darüber, dass
ein Aspekt des Systems ordnungsgemäß läuft; und ein „Informationsereignis" informiert darüber, dass
bestimmte Informationsdinge auftreten.
-
Ereignissen
kann ferner ein Gewicht zugewiesen werden. Zum Beispiel können verschiedene
Fehlerereignisse verschiedene Gewichte aufweisen. Erfolgsereignisse
und Informationsereignisse werden gewöhnlich ein niedrigeres Gewicht
aufweisen als Fehlerereignisse.
-
Die
Ereignisprotokollierung kann auch verschiedene Zugangsberechtigungen
aufweisen. Zum Beispiel können
möglicherweise
nur Systemadministratoren Zugang zu bestimmten sicheren Protokollierungen („interne
Ereignisprotokollierung")
oder Teilen der Protokollierung oder Ereignissen (z.B. Sicherheitsverstöße usw.)
besitzen, während
Softwarekomponentenbenutzer Zugang zu verschiedenen Protokollierungen
(„Benutzerereignisprotokollierung") oder Protokollierungsteilen,
die den Betrieb der jeweiligen Softwarekomponente betreffen, besitzen
können.
-
Die
Benutzerereignisprotokollierung stellt eine für den Benutzer gefilterte Version
der internen Ereignisprotokollierung dar. Der Zweck des Filterns
der internen Ereignisprotokollierung besteht darin, zu vermeiden,
dem Benutzer irrelevante und redundante Informationen zu zeigen.
Die Benutzerereignisprotokollierung zeigt nur Ereignisse mit einem
bestimmten Kritizitätsgrad
(wobei dieser Grad ein konfigurierbarer Grad ist). Ereignisse werden
in der Benutzerereignisprotokollierung angezeigt, bis der Benutzer
sie bestätigt.
Die Benutzeroberfläche
kann ein spezielles Symbol anzeigen, so lange die Benutzerereignisprotokollierung
mindestens ein unbestätigtes
Ereignis enthält.
Die Benutzerereignisprotokollierung zeigt die gefilterten Ereignisse
in umgekehrter chronologischer Reihenfolge, so dass das neuste oben
in einer Liste angezeigt wird. In einer separaten Benutzeroberfläche kann
der Benutzer die vollständige
Benutzerereignisprotokollierung betrachten, das heißt, inklusive
der bestätigten
Ereignisse. Ereignisse in der Benutzerereignisprotokollierung können beim Empfang
von Erfolgereignissen automatisch bestätigt werden.
-
Sowohl
die interne Ereignisprotokollierung (für Systempersonal) als auch
die Benutzerereignisprotokollierung (für Benutzer) werden zur einfacheren
Diagnose von Problemen im System bereitgestellt.
-
Ein
Problem mit solchen Protokollierungsdateien besteht jedoch darin,
dass die Benutzerereignisprotokollierung zu viele Ereignisse oder
nicht die relevantesten zeigt. Jedes signifikante Problem, das den
Benutzer interessiert, kann mehr als ein Ereignis erzeugen. Da die
Ereignisse chronologisch gezeigt sind, befinden sich die wichtigsten
nicht unbedingt oben.
-
Außerdem kann
in solchen Systemen der für
jedes Ereignis gezeigte Erklärungstext
die Ursache des Problems beschreiben, aber der Ereignisursachentext
ist statisch und wird nicht durch andere Ereignisse beeinflusst.
Bestimmte Ereignisse können
verschiedene Ursachen haben. Da die Erläuterung statisch ist, müssen sie
dann entweder alle Möglichkeiten
beschreiben oder andernfalls bestimmte oder alle Ursachen auslassen.
Dies kann verwirrend sein, insbesondere wenn aufgrund von widersprüchlichen,
redundanten oder unzureichenden Informationen mehrere Ereignisse
in der Benutzerereignisprotokollierung vorliegen.
-
Der
für jedes
Ereignis gezeigte Erläuterungstext
kann eine angemessene Reparaturaktion zur Lösung des Problems beschreiben.
Das Problem besteht darin, dass der Ereignisaktionstext statisch
ist und nicht durch andere Ereignisse beeinflusst wird. Für bestimmte
Ereignisse ist es eventuell nicht möglich, eine einzige Reparaturaktion
zu spezifizieren, weil die entsprechenden Reparaturaktionen von
zusätzlichen
Informationen abhängen.
Da die Erläuterung
statisch ist, muss sie dann alle Möglichkeiten beschreiben oder
bestimmte oder alle Reparaturaktionen auslassen. Auch dies kann
verwirren, insbesondere, wenn aufgrund von widersprüchlichen,
redundanten oder unzureichenden Anweisungen mehrere Ereignisse in
der Benutzerereignisprotokollierung vorliegen.
-
Es
fehlt eine Software, die automatisch Reparaturaktionen durchführt. Bestimmte
Probleme können mit
Softwareprogrammen repariert werden. Entsprechende Reparaturaktionen
können
automatisch durchgeführt
werden, wenn eine Diagnose automatisch erfolgen kann, oder sie können vielleicht
erlaubt werden, wenn sie durch den Benutzer bestätigt werden.
-
Es
wird eine Software benötigt,
die versucht, durch Analyse mehrerer Ereignisse eine Diagnose durchzuführen. Bestimmte
Probleme lassen sich nur durch Betrachtung von mehr als einem Ereignis
oder von zusätzlichen
Informationen abschließend
feststellen.
-
Die
interne Ereignisprotokollierung enthält nicht immer genug Informationen
für eine
abschließende Diagnose.
Es wäre
nützlich,
wenn auch andere Informationsquellen für Diagnosezwecke verwendet
werden könnten.
Solche Informationsquellen könnten
Protokollierungsdateien, Daten oder Programm-Modul-Zustandsinformationen
sein.
-
In
bestimmten Fällen
könnten
für eine
abschließende
Diagnose notwendige zusätzliche
Informationen automatisch durch Aufrufen von Testfunktionen gesammelt
werden. Diese Möglichkeit
existiert zur Zeit nicht. Das technische Problem besteht darin,
herauszufinden, wann solche Testfunktionen aufgerufen werden sollten.
Aus Performance-Gründen
ist es nicht angemessen, diese z.B. für jedes empfangene Ereignis
auszuführen.
-
Es
ist nicht immer möglich,
automatisch ohne Intervention durch den Benutzer notwendige Informationen
für eine
abschließende
Diagnose zu sammeln. Bestimmte Dinge können nur oder am einfachsten
vom Benutzer geprüft
werden. Die Diagnosefähigkeit
des Systems könnte
verbessert werden, wenn die Diagnosesoftware nach manuellen Testergebnissen
fragen oder diese annehmen könnte.
-
Einige
Wizards moderner Microsoft-Produkte sind Beispiele für effiziente
Diagnosewerkzeuge. Der Benutzer wird durch eine Reihe von Dialogen
geführt,
die dazu dienen, Informationen zu sammeln und zu der Problemursache
zu kommen.
-
Es
ist bekannt, Ereignisprotokollierungen zu verwenden, bei denen Ereignisse
nach Gewicht klassifiziert und nur die wichtigsten oben in einer
Liste angezeigt werden. Ihre Bestätigung und – im Bedarfsfall – Verlagerung
in eine Verlaufsliste ist üblicherweise
möglich.
-
Eine
Aufgabe der Erfindung ist es, das Finden eines Hardware- oder Benutzerfehlers
in einer softwaregesteuerten Vorrichtung wie z.B. einer NMR-Vorrichtung
zu erleichtern. Die Erfindung löst
diese Aufgabe und die oben beschriebenen Probleme u.a. durch Hinzufügen einer
Diagnosefunktion zur Benutzerereignisprotokollierung. Die Erfindung
kann entweder das Filtern zwischen der internen Ereignisprotokollierung
und der Benutzerereignisprotokollierung ersetzen oder kann zusätzlich zu
der Benutzerereignisprotokollierung verwendet werden.
-
Es
wird eine Analyse von Informationsquellen durchgeführt: der
Verlauf der Ereignisprotokollierung wird nach Mustern durchsucht;
zusätzlich
können
Fragen/Tests weitere Information für erweiterte Muster ergeben;
ferner können
Reparaturaktionen vorgeschlagen werden.
-
Eine
optionale Ausführungsform
der Erfindung fügt
die Fähigkeit
hinzu, abhängig
von einer Realisierungsmethode den Benutzer nach manuellen Testergebnissen
zu fragen oder manuelle Testergebnisse anzunehmen. Eine andere Ausführungsform
der Erfindung ermöglicht
der Diagnosefunktion, automatisch Testfunktionen zum Sammeln weiterer,
für eine
abschließende
Diagnose notwendiger Informationen aufzurufen. Eine weitere Ausführungsform
der Erfindung besteht darin, es der Diagnosefunktion zu erlauben,
automatisch Reparaturaktionen zur Lösung des Problems aufzurufen.
-
Dieser
Ansatz der Fehlerfindung ist vorteilhafterweise auf ein breites
Spektrum technischer Geräte
anwendbar. Die einzige Vorbedingung besteht darin, dass die Systemsoftware
Ereignisse erzeugt und sie in einer Ereignisprotokollierung speichert.
Die Erfindung eignet sich besonders für Software von medizinischen
Systemen. Sie kann ohne viel Mühe
in existierende Software integriert werden; die erforderliche Software
ist klein und kann in einem separaten Softwaremodul implementiert
werden. Die Änderung
an der Benutzeroberfläche ist
klein und auf die Ereignisprotokollierung isoliert. Sie wird durch
ein leicht aktualisierbares Modell gesteuert. Da keine Änderung
von Programmcode notwendig ist, lassen sich aktualisierte Modelle
an Kundensysteme verteilen, auch wenn in diesen Systemen medizinische
Geräte
vorkommen. Die Modelle lassen sich von entfernten Standorten aus
aktualisieren, wodurch es möglich
wird, Verbesserungen schnell und kostengünstig weltweit zu verteilen.
-
Dieses
System kann auch in Verbindung mit unvollständigen Modellen nützlich sein
und könnte
sogar mit einem leeren Modell arbeiten; die Diagnosefähigkeit
würde sich
dann auf den Stand einer reinen Ereignisprotokollierung verschlechtern,
so als ob die Erfindung nicht benutzt würde. Die Qualität der Diagnose
lässt sich
durch Erweitern des Modells inkrementell verbessern. Mit wachsender
Erfahrung mit der Benutzung des Systems kann man das Modell erweitern,
um die Diagnosefähigkeiten
zu verbessern.
-
Weitere
vorteilhafte Ausführungsformen
der Erfindung sind durch die Merkmale der Unteransprüche gekennzeichnet.
-
Die
Erfindung wird ausführlicher
unter Bezugnahme auf verschiedene Ausführungsformen erläutert, die
in den Zeichnungen abgebildet und nachfolgend ausführlicher
beschrieben werden.
-
1 ist
ein Blockschaltbild von wesentlichen Komponenten des Systems;
-
2 ist
ein Blockschaltbild der Beziehung zwischen Mustern, Ursachen und
Reparaturen;
-
3 ist
ein Blockschaltbild des Ereignisflusses durch das System;
-
4 ist
ein Blockschaltbild der Zuweisung von Wahrscheinlichkeiten in Bezug
auf Ereignissequenzen, Diagnosen, Tests und Reparaturaktionen;
-
5 ist
ein Blockschaltbild der Verwendung der Ereignisfilter- und Diagnosesoftware
mit einem möglichen
Benutzeranzeige- und Abfragemechanismus; und
-
6 ist
ein Flussdiagramm einer Ausführungsform
der Erfindung.
-
1 zeigt
die bei Ausführungsformen
der Erfindung beteiligten Hauptkomponenten. Das System umfasst sowohl
Hardwarekomponenten 12 als auch Softwarekomponenten 14.
Ereignisse in Bezug auf Aktivitäten
von Hardware 12, Software 14 und Benutzer 16 werden
in einer Ereignisprotokollierung 20 gespeichert. In den
bekannten Systemen wird ein Verlauf der Ereignisprotokollierung 20 dem
Benutzer 16 teilweise (gefiltert) angezeigt, aber es besteht
praktisch keine Intelligenz in dem einhergehenden Filter, mit der
Ausnahme, dass, wenn ein Fehler später korrigiert und ein Erfolgsereignis
erzeugt wird, der ehemalige Fehler nicht mehr angezeigt wird. Fehler
können
Hardware-Fehler der Hardwarekomponenten 12 oder Benutzerfehler
bei der Eingabe durch den Benutzer 16 sein.
-
Die
folgenden Begriffe werden folgendermaßen mit Bezug auf die Figuren
für Bezugszeichen
definiert.
-
-
-
Es
wird ein „Kausalitätsmodell" (2)
benutzt, das Grundursachen" (26,
cause1, cause2, cause3) mit „(erweiterten)
auf Grundursachen bezogenen Mustern" (24, pattern1, pattern2, pattern3)
in Beziehung setzt. Um eine „Grundursache" 26 zu isolieren,
wird der Verlauf der Ereignisprotokollierung 20 mit den
Mustern 24 verglichen. Es werden Wahrscheinlichkeiten Pi-Pn
ausgewertet und dem Benutzer 16 zusätzliche „Fragen" gestellt, um die Suche so weit wie
möglich
einzuschränken.
Von der Hardware und dem Benutzer auf der Basis von Fragen und Tests 22 empfangene
Informationen werden bereitgestellt, um die Bestimmung durchzuführen. Als
letztes können „Reparaturaktionen" (28, repair1,
repair2, repair3) auf der Basis der empfangenen Informationen 22,
Muster 24, Ursachen 26 und Wahrscheinlichkeiten
Pi-Pn vorgeschlagen werden.
-
Anfragen
für den
Benutzer, die vorzugsweise ja/nein-Fragen umfassen, wären zum
Beispiel „Haben Sie
Stecker A in Port B gesteckt?" oder „Haben
Sie die Einrichtung während
des Abstimmens korrekt positioniert?".
-
Es
können
Hardwaretests durchgeführt
werden (z.B. aus einem Testmodell heraus, das in der US-Patentanmeldung
Nr. 2004/0153819 beschrieben wird), wozu Software-Testroutinen gehören, die:
1) zu ja/nein-Antworten führen
oder 2) aus anderen Protokollierungsdateien, die mit dem laufenden
System in Beziehung stehen und dieses beschreiben, weitere Informationen
extrahieren.
-
Einfache
Ereignisse in der Ereignis-Historie können ein Muster bilden, wenn
sie mit Antworten auf einige wenige Fragen zusammengekoppelt werden.
Zum Beispiel kann man ein Fehlermuster von Lokalspulen mit allen
Arten verschiedener Ereignisse in der Ereignisprotokollierungs-Historie
mischen, z.B.
- 1) „Spule unbekannt" – ein Fehlerereignis in der
Softwareschicht A;
- 2) „Kann
nicht messen" – ein Fehlerereignis
in der Softwareschicht B;
- 3) „Messung
durch NMR-Scanner gestoppt" – ein Fehlerereignis
in einer (oberen) Softwareschicht C.
-
In
diesem Beispiel wird dem Benutzer ein gefiltertes Fehlerereignis
präsentiert: „Lokaler
Spulenfehler – lokale
Spule nicht detektierbar".
Die möglichen
Gründe
lauten z.B.: Die Spule ist
- a) beschädigt;
- b) nicht richtig verbunden;
- c) dem System noch nicht bekannt (neue Spule des Herstellers).
-
Ein
möglicher
Test zur Bestimmung, ob die Spule verbunden, beschädigt usw.
ist, könnte
ein Spannungstest sein. Fragen wäre
zum Beispiel:
- 1) „Haben Sie die Spule eingesteckt?" – wofür eine ja/nein-Antwort angefordert
würde;
- 2) „Ist
dies eine Standardspule (Marke X)?" – wofür eine „ja"-Antwort die Reparaturaktion „Service
rufen" und eine „nein"-Antwort die Reparaturaktion „eine neue
Spule installieren" einleiten
könnte.
-
Es
folgt eine ausführlichere
Beschreibung. Nachfolgend beschriebene verschiedene Ausführungsformen
der Erfindung weisen zwei Teile auf: ein Datenmodell und einen Algorithmus.
Das Datenmodell speichert für
ein bestimmtes System spezifische Informationen. Der Algorithmus
ist dagegen generisch und bleibt auf allen Systemen gleich.
-
Ein
Datenmodell ist ein Netzwerkmodell mit vier Hauptknotentypen: Ereignissequenzen,
Tests, Diagnose und Reparaturaktionen. Die Ränder des Netzwerkmodells beschreiben
Abhängigkeiten
zwischen den Knoten. Die relevanten Abhängigkeiten lauten: Ereignis-Diagnose-Abhängigkeiten,
Test-Diagnose-Abhängigkeiten
und Diagnose-Reparatur-Abhängigkeiten.
-
Ein
Ereignissequenzknoten repräsentiert
einen Ausdruck, der entweder als true (1) oder false (0) ausgewertet
wird. Ein besonders geeigneter, für die Erfindung benutzbarer
Ausdruckstyp sind „reguläre Ausdrücke". Reguläre Ausdrücke werden
genau dann als true ausgewertet, wenn die Ereignissequenz in der
internen Ereignisprotokollierung mit dem Muster des Ausdrucks verglichen
werden kann. Reguläre
Ausdrücke
können sehr
effizient ausgewertet werden. Die Ereignissequenzknotenausdrücke werden
als true ausgewertet, sobald das erste Ereignis empfangen wird,
das das Muster des regulären
Ausdrucks vervollständigt.
Normalerweise wird der reguläre
Ausdruck so formuliert, dass er wieder als falsch ausgewertet wird,
sobald ein anderes Ereignis, zum Beispiel ein Erfolgsereignis empfangen
wird. Bei einer Ausführungsform
der Erfindung könnte
der reguläre
Ausdruck erweitert werden, um auch Zeiteinschränkungen zwischen Ereignissen
zu behandeln.
-
Bei
einer Ausführungsform
der Erfindung können
auch andere Informationsquellen in Ereignissequenzknoten ausgewertet
werden. Solche Informationsquellen sind zum Beispiel andere Formen
von Protokollierungsdateien, die das System führt, Konfigurationsdateien
und Datenbanken.
-
Der
Testknoten repräsentiert
Tests, die durchgeführt
werden können,
um Informationen zu sammeln, die die Möglichkeit einer ent scheidenden
Diagnose verbessern. Man kann auch sagen, dass Testknoten einen Ausdruck
aufweisen, der ähnlich
wie bei den Ereignissequenzknoten als true (1) oder false (0) ausgewertet wird. „True" bedeutet, dass der
Test positiv war, und „false" bedeutet, dass der
Test negativ war. Es gibt zwei Haupttypen von Tests: manuell und
automatisch. Manuelle Tests bestehen aus einer Frage für den Benutzer, die
mit „ja" oder „nein" beantwortet werden
kann. Abhängig
von dem Kontext muß man
spezifizieren, welche Antwort einem positiven Testergebnis entspricht.
Die automatischen Tests können
vom System selbst ohne Interaktion mit dem Benutzer durchgeführt werden.
-
Bei
einer Ausführungsform
der Erfindung könnten
der Ereignissequenzknotenausdruck und der Testknotenausdruck auf
einen Wert zwischen Null und Eins ausgewertet werden, der ausdrückt, zu
welchem Grad angenommen wird, dass der Ausdruck „true" ist. Ein Wert in der Nähe von Eins
ist dann „almost
true" und ein Wert
in der Nähe
von Null „almost
false". Der Wert
könnte
als die Wahrscheinlichkeit dafür
interpretiert werden, dass der Ereignissequenzknoten true ist.
-
Der
Diagnoseknoten enthält
eine Textbeschreibung, die spezifiziert, was falsch ist, wenn die
Diagnose korrekt ist. Ob eine Diagnose korrekt ist oder nicht, wird
unter Verwendung der Ereignis-Diagnose- und Test-Diagnose-Abhängigkeiten
ausgewertet. Das Ergebnis ist ein Wert zwischen Null und Eins, der
als die Wahrscheinlichkeit dafür
interpretiert werden kann, dass die Diagnose korrekt ist. Ereignis-Diagnose-
und Test-Diagnose-Abhängigkeiten
weisen jeweils zwei Eigenschaften auf, die in die Auswertung eingehen.
Die erste Eigenschaft ist die „Polarität" der Abhängigkeit,
das heißt,
ob das Ergebnis der Auswertung eines Ereignisknotens oder Testknotens
invertiert werden soll oder nicht. Die zweite Eigenschaft ist das
Gewicht der Abhängigkeit.
Bei bestimmten Implementierungen der Erfindung (unter Verwendung
eines Bayesischen Netzwerks) kann das Gewicht als die Wahrscheinlichkeit
dafür interpretiert
werden, dass der Ereignisknoten oder Testknoten als true ausgewertet
wird, wenn die Diagnose korrekt ist. Dabei ist zuerst die Polarität zu berücksichtigen. In
diesem Fall muss das Gewicht zwischen Null und Eins liegen.
-
Es
besteht gewöhnlich
mehr als eine Ereignis-Diagnose- und Test-Diagnose-Abhängigkeit für jede Diagnose.
-
Der
Reparaturknoten repräsentiert
eine Aktion, von der angenommen wird, dass sie das durch einen Diagnoseknoten
beschriebene Problem löst.
Es gibt zwei Haupttypen von Reparaturknoten, manuell und automatisch.
Der manuelle Reparaturknoten ist eine Textbeschreibung, die spezifiziert,
was zu tun ist, um das Problem zu korrigieren. Der automatische
Reparaturknoten repräsentiert
eine Funktion, die durch das System ausgeführt werden kann, um das Problem
automatisch zu korrigieren. Die Diagnose-Reparatur-Abhängigkeit hat
eine Gewichtseigenschaft. Bei bestimmten Implementierungen der Erfindung
kann das Gewicht als die Wahrscheinlichkeit dafür interpretiert werden, dass
der Reparaturknoten das korrekte Verfahren zum Lösen des durch die Diagnose
beschriebenen Problems repräsentiert.
Ein Reparaturknoten kann die Lösung
für mehr als
eine Diagnose sein.
-
Ein
Algorithmus für
die Erfindung kann durch ein Flussdiagramm beschrieben werden (siehe 6). In
einem Schritt S1 wartet der Algorithmus (z.B. in einer Schleife
oder asynchron) auf ein nächstes
Ereignis oder bis der Benutzer ein manuelles Testergebnis verändert. In
einem Schritt S2 wird, wenn das neue Ereignis bewirkt, dass irgendein
Ereignissequenzknoten seinen Wert ändert oder wenn ein manuelles
Testergebnis geändert
wurde, der nächste
Schritt S3 ausgeführt
und ansonsten kehrt der Algorithmus zum Schritt S1 zurück.
-
Im
Schritt S3 berechnet der Algorithmus die Wahrscheinlichkeit dafür, dass
jede der Diagnosen korrekt ist. Ein besonders geeignetes Verfahren
dafür ist
das Modell des Bayesischen Netzwerks. In einem Schritt S4 sucht
der Algorithmus, wenn keine einzige abschließende Diagnose gefunden werden
kann, nach unbeantworteten Tests für die Diagnosekandidaten; andernfalls
geht der Algorithmus zum Schritt S7 über.
-
In
einem Schritt S5 führt
der Algorithmus etwaige gewählte
automatische Tests durch und in einem Schritt S6 präsentiert
er dem Benutzer die manuellen Tests, die am wahrscheinlichsten zwischen
den Diagnosekandidaten unterscheiden werden.
-
In
einem Schritt S7 präsentiert
der Algorithmus dem Benutzer die Diagnosekandidaten, möglicherweise
mit ihrer jeweiligen Wahrscheinlichkeit. In einem Schritt S8 berechnet
der Algorithmus die Wahrscheinlichkeit dafür, dass jede der Reparaturaktionen
geeignet ist. In einem Schritt S9 führt der Algorithmus alle automatischen
Reparaturaktionen mit einer Wahrscheinlichkeit über einer bestimmten Schwelle
durch. In einem Schritt S10 präsentiert
der Algorithmus dem Benutzer die wahrscheinlichste Reparaturaktion,
möglicherweise mit
ihrer jeweiligen Wahrscheinlichkeit. Der gesamte Prozess wird dann
wiederholt.
-
Verschiedene
Ausführungsformen
der oben beschriebenen Erfindung werden am besten anhand eines Beispiels
erläutert.
-
3 zeigt
ein Beispiel dafür,
wie Ereignisse in dem System erzeugt und behandelt werden. Ereignisse
werden von Softwaremodulen 14 (m1, m2, m3, m5, m8) erzeugt
und chronologisch in der internen Ereignisprotokollierung 20A gespeichert.
Aufgrund der Softwarestruktur kann ein einziges Problem mehrere
Ereignisse verursachen. Wenn zum Beispiel ein Problem mit Ursprung
aus der Hardwarekomponente c1 (detektiert durch c5) besteht, könnte dies
zuerst durch das Softwaremodul m1 erkannt werden, das das Ereignis
e12 erzeugt. Das Softwaremodul m2 hängt von dem Ergebnis von m1
ab und kann bei dem gegebenen Problem seine Arbeit nicht verrichten;
deshalb erzeugt das Modul m2 dann das Ereignis e4. Ähnlich hängt das
Softwaremodul m3 von dem Ergebnis des Moduls m2 ab und erzeugt bei
dem gegebenen Problem das Ereignis e6. Alle diese Ereignisse werden
in der internen Ereignisprotokollierung 20 Agespeichert.
-
Das
Ereignisfilter 32 filtert die Ereignisse, bevor sie der
Benutzerereignisprotokollierung 20B zugeführt werden.
Wie in 3 dargestellt, lässt das Filter 32 zuerst
nur die Fehlerereignisse durch. Zweitens wurde das Fehlerereignis
c2 automatisch durch das Erfolgsereignis e5 bestätigt.
-
4 zeigt
ein Beispiel für
ein benutztes Modell. Unter der Annahme einer Implementierung mit
Bayesischem Netzwerk zeigt 4 zum Beispiel,
dass die Ereignissequenz en1 eine Auftrittswahrscheinlichkeit von
0,7 besitzt, wenn die Diagnose d1 korrekt ist. Ähnlich besitzt die Ereignissequenz
en2 eine Auftrittswahrscheinlichkeit von 0,8, wenn die Diagnose
d1 korrekt ist. Dafür,
dass die Diagnose d1 korrekt ist, hat der Test t1 eine Wahrscheinlichkeit
von 0,9, wenn der Test positiv ist, und der Test t2 die Wahrscheinlichkeit
0,9, wenn der Test negativ ist.
-
Ähnlich ist
die Reparaturaktion r1 mit einer Wahrscheinlichkeit von 0,8 angemessen,
wenn die Diagnose d1 korrekt ist. Bestimmte Reparaturaktionen können mehr
als einer Diagnose gemeinsam sein. Eine solche gemeinsam benutzte
Reparaturaktion ist besonders in Fällen relevant, wenn keine entscheidende
Diagnose gefunden werden kann, wenn aber die in Frage kommenden
Diagnosen dieselben Reparaturaktionen aufweisen.
-
5 zeigt
eine mögliche
Benutzeroberfläche,
die verwendet werden kann. Zusätzlich
zu der Benutzerereignisprotokollierung 20B ist eine separate
Diagnosetabelle 36 gezeigt, die Diagnosenachrichten d1,
d2 möglicherweise
mit der Wahrscheinlichkeit einer korrekten Diagnose und manuelle
Tests d1, d2, bereitgestellt werden können, um die Wahrscheinlichkeit
einer korrekten Diagnose zu verbessern, enthält. Die Tests t1, t2 können z.B.
direkt in der Tabelle 36 durch Auswählen der entsprechenden Auswahl
beantwortet werden. Die Diagnosetabelle 36 kann aktualisiert
werden, wenn Ereignissequenzknoten den Wert ändern oder wenn manuelle Tests
beantwortet werden.
-
Für ein besseres
Verständnis
der Prinzipien der Erfindung wurde auf die in den Zeichnungen dargestellten
bevorzugten Ausführungsformen
Bezug genommen, und es wurde spezifische Sprache zur Beschreibung
dieser Ausführungsformen
verwendet. Durch diese spezifische Sprache ist jedoch keine Einschränkung des
Schutzumfangs der Erfindung beabsichtigt, und die Erfindung soll
so aufgefasst werden, dass sie alle Ausführungsformen umschließt, die
normalerweise Durchschnittsfachleuten einfallen würden.
-
Die
vorliegende Erfindung kann im Hinblick auf Funktionsblockkomponenten
und verschiedene Verarbeitungsschritte beschrieben werden. Solche
Funktionsblöcke
lassen sich durch eine beliebige Anzahl von Hardware- und/oder Softwarekomponenten
realisieren, die so konfiguriert werden, dass sie die spezifizierten Funktionen
ausführen.
Zum Beispiel kann die vorliegende Erfindung verschiedene integrierte
Schaltungskomponenten verwenden, wie z.B. Speicherelemente, Verarbeitungselemente,
Logikelemente, Nachschlagetabellen und dergleichen, die unter der
Steuerung eines oder mehrerer Mikroprozessoren oder anderer Steuereinrichtungen
vielfältige
Funktionen ausführen
können.
Wenn die Elemente der vorliegenden Erfindung unter Verwendung von
Softwareprogrammierung oder Softwareelementen implementiert werden,
kann die Erfindung ähnlich
auch unter Verwendung einer beliebigen Programmier- oder Scripting-Sprache
implementiert werden, wie zum Beispiel C, C++, Java, Assembler oder
dergleichen, wobei die verschiedenen Algorithmen mit einer beliebigen
Kombination von Datenstrukturen, Objekten, Prozessen, Routinen oder
anderen Programmierelementen implementiert werden. Ferner könnte die
vorliegende Erfindung eine beliebige Anzahl herkömmlicher Techniken für Elektronikkonfiguration,
Signalverarbeitung und/oder Steuerung, Datenverarbeitung und dergleichen
verwenden.
-
Die
hier gezeigten und beschriebenen konkreten Implementierungen sind
veranschaulichende Beispiele für
die Erfindung und sollen den Schutzumfang der Erfindung ansonsten
auf keinerlei Weise einschränken.
Der Kürze
halber werden herkömmliche
Elektronik, Steuersysteme, Softwareentwicklung und andere funktionale
Aspekte des Systems (und der Komponenten und einzelnen Betriebskomponenten
des Systems) möglicherweise
nicht ausführlich
beschrieben. Die in den verschiedenen Figuren gezeigten Verbindungslinien oder
Verbindungen sollen beispielhafte funktionale Beziehungen und/oder
physische oder logische Kopplungen zwischen den verschiedenen Elementen
repräsentieren.
Es sollte beachtet werden, dass in einer praktischen Einrichtung
viele alternative oder zusätzliche
funktionale Beziehungen, physische Verbindungen oder logische Verbindungen
vorliegen können.
Kein Element oder keine Komponente ist für die Ausübung der Erfindung wesentlich,
wenn nicht das Element spezifisch als „wesentlich" oder „kri tisch" beschrieben wird.
Zahlreiche Modifikationen und Anpassungen werden Fachleuten ohne
weiteres ersichtlich sein, ohne vom Gedanken und Schutzumfang der
vorliegenden Erfindung abzuweichen.
