DE10161332A1 - Verfasserwerkzeug für diagnostische Systeme in Bayes-Netzwerken - Google Patents
Verfasserwerkzeug für diagnostische Systeme in Bayes-NetzwerkenInfo
- Publication number
- DE10161332A1 DE10161332A1 DE10161332A DE10161332A DE10161332A1 DE 10161332 A1 DE10161332 A1 DE 10161332A1 DE 10161332 A DE10161332 A DE 10161332A DE 10161332 A DE10161332 A DE 10161332A DE 10161332 A1 DE10161332 A1 DE 10161332A1
- Authority
- DE
- Germany
- Prior art keywords
- question
- action
- causes
- cause
- authoring tool
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0733—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a data processing system embedded in an image processing device, e.g. printer, facsimile, scanner
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2257—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using expert systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N7/00—Computing arrangements based on specific mathematical models
- G06N7/01—Probabilistic graphical models, e.g. probabilistic networks
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Artificial Intelligence (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- Evolutionary Computation (AREA)
- Computing Systems (AREA)
- Pure & Applied Mathematics (AREA)
- Mathematical Optimization (AREA)
- Mathematical Analysis (AREA)
- Algebra (AREA)
- Computational Mathematics (AREA)
- Probability & Statistics with Applications (AREA)
- Computational Linguistics (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Ein Verfasserwerkzeug unterstützt einen Verfasser beim Bauen eines automatisierten diagnostischen Systems. Das Verfasserwerkzeug umfaßt eine Ursachen-Editorschnittstelle, eine Aktions-Editorschnittstelle und eine Frage-Editorschnittstelle. Die Ursachen-Editorschnittstelle ermöglicht einem Verfasser, in einer Ursachendatenstruktur Informationen, die sich auf die Ursachen beziehen, anzuordnen. Die Aktions-Editorschnittstelle ermöglicht einem Verfasser, in einer Aktionsdatenstruktur Informationen, die sich auf Aktionen beziehen, die ansprechend auf die Ursachen vorgenommen werden können, anzuordnen. Die Frage-Editorschnittstelle ermöglicht einem Verfasser in einer Fragedatenstruktur Informationen, die sich auf Fragen beziehen, die einem Anwender des Produkts gestellt werden können, anzuordnen, um beim Identifizieren der Ursachen zu helfen.
Description
Die vorliegende Erfindung bezieht sich auf die Unterstüt
zung von Produkten und spezieller auf ein Verfasserwerkzeug
für diagnostische Systeme in Bayes-Netzwerken bzw. Bayes-s
chen Netzwerken.
Momentan ist es für Druckerhersteller äußerst kostspielig,
die Systeme für ihre Kunden zu diagnostizieren. Normaler
weise ruft ein Kunde einen Druckerrufbeauftragten beim Her
steller an. Dieser Beauftragte leitet den Kunden durch eine
Fehlersuch- und Beseitigungssequenz, die zur Auflösung des
Problems oder Identifikation der Ursache führt. Dieses Ver
fahren erfordert die Einschaltung eines Rufbeauftragten,
was zu hohen Kosten führt.
Beim Einsatz von Rufbeauftragten heuert der Druckerherstel
ler viele Rufbeauftragte an, die der Kunde wiederum anrufen
kann, wenn er Probleme mit seinem Druckersystem hat. Der
Rufbeauftragte versucht, so viele Informationen wie möglich
zu sammeln, indem er den Kunden über Telefon befragt. Wenn
er zu einer Schlußfolgerung gelangt ist, hat er entweder
das Problem gelöst, die Ursache identifiziert oder mußte
einen Außendienstmitarbeiter entsenden, der versucht, das
Problem am Standort des Kunden zu lösen.
Ein Nachteil des Einsatzes von Rufbeauftragten sind die Ko
sten. Zusätzlich können Probleme bei der Kontinuität bezüg
lich der Reihenfolge und Typen von Fehlersuch- und Beseiti
gungsschritten, die durch unterschiedliche Rufbeauftragte
verwendet werden, bestehen. Es ist ein Problem, wenn den
Kunden nicht näherungsweise die gleichen Fehlersuch- und
Fehlerbeseitigungsschritte in der gleichen Reihenfolge wie
bei ähnlichen Problemen gegeben werden, da sie dann ver
wirrt werden könnten. Die Lösung des Rufbeauftragten ermög
licht außerdem nur ein beschränktes Protokollieren von In
formationen, weist lediglich eine beschränkte Integration
von programmatischen Datensammeleinrichtungen und eine äu
ßerst beschränkte Integration von Multimediapräsentationen
auf. Der Einsatz von Rufbeauftragten ermöglicht jedoch den
Vorteil einer Mensch-zu-Mensch-Kommunikation zwischen dem
Rufbeauftragten und dem Kunden, da der Rufbeauftragte of
fensichtlich in der Lage ist, "weiche" Informationen zu er
fassen, die ein computerbasiertes System nicht so ohne Wei
ters erfassen kann, wie z. B. ob der Kunde über eine Be
fragungsmethode verärgert ist, das Erfahrungsniveau des
Kunden usw.
Entscheidungsbäume können verwendet werden, um eine automa
tisierte Diagnose von Druckersystemen zu liefern. Der Lö
sungsansatz mit dem Entscheidungsbaum spezifiziert die mög
lichen Fehlersuch- und Beseitigungssequenzen als einen so
genannten Entscheidungsbaum. Bei jeder Abzweigung des Bau
mes wird einer der Zweige basierend auf den Informationen
gewählt, die durch den Kunden beim letzten Schritt gelie
fert wurden. Die Entscheidungsbäume sind jedoch in dem Sin
ne statisch, daß sie aus praktischen Gründen nur eine be
grenzte Anzahl von möglichen Sequenzen der Fehlersuch- und
Beseitigungsschritte ermöglichen. Bei Entscheidungsbäumen
müssen alle Sequenzen, die dem Kunden zur Verfügung stehen
sollten, verschlüsselt werden; und, da sich die Größe des
Entscheidungsbaums exponential bei der Anzahl derselben
verhält, ist es nur möglich, eine beschränkte Anzahl der
selben zu verschlüsseln. Dies bewirkt im Durchschnitt, daß
der Entscheidungsbaum längere Fehlersuch- und Beseitigungs
sequenzen mit einer geringeren Wahrscheinlichkeit einer
tatsächlichen Diagnose des Problems liefert, da es nicht
möglich ist, alle möglichen Szenarien zu berücksichtigen.
Fallbasierte Schlußfolgerungen können ebenfalls verwendet
werden, um eine automatisierte Diagnose von Druckersystemen
zu liefern. Der fallbasierte Lösungsansatz sammelt eine
große Menge von anschaulichen Fällen aus den Fehlersuch-
und Beseitigungsszenarien, wo verschiedene Probleme erkannt
werden. Basierend auf den Informationen über die aktuelle
Situation, kann die fallbasierte Schlußfolgerungsmaschine
dann die Fälle auswählen, die sich am meisten ähneln. Die
sich am meisten ähnelnden Fälle werden dann untersucht, um
die bestnächste Aktion oder Frage zu finden, die über die
höchste Wahrscheinlichkeit verfügt, so viele Fälle wie mög
lich auszuschließen. Dies wird so lange fortgesetzt, bis
der einzelne Fall, der mit der aktuellen Situation am mei
sten übereinstimmt, bestimmt ist.
Fallbasierte Systeme sammeln Fälle, die die Fehlersuch- und
Beseitigungsdomäne beschreiben, und verwenden diese Fälle,
um Aktionen und Fragen vorzuschlagen, die die Möglichkeits
domäne so schnell wie möglich auf einen einzelnen Fall be
schränken. Die Qualität eines fallbasierten Systems hängt
von seiner Falldatenbank ab, die sehr groß sein muß, um ei
ne Druckersystemdomäne adäquat zu beschreiben. Die mögli
chen Konfigurationen/Fälle bei einem Druckersystem sind 2N
für N Variablen (1024 für 80 Variablen), wenn alle Varia
blen binär sind. Ein Teilsatz von Fällen von diesen müßte
äußerst umfangreich sein, um eine hinreichende Veranschau
lichung zu liefern, um einem fallbasierten System zu nut
zen. Daher ist es zweifelhaft, ob fallbasierte Systeme bei
der Darstellung des Drucksystems mit seinen vielen Varia
blen bezüglich eines optimalen Genauigkeitsniveaus erfolg
reich sein werden.
Regelbasierte Systeme können ebenfalls verwendet werden, um
die automatisierte Diagnose von Druckersystemen zu ermögli
chen. Regelbasierte Systeme kann man sich als einen Teil
satz von Bayes-Netzwerken vorstellen, da sie mit Bayes-
Netzwerken dargestellt werden können. Sie weisen einen
Teilsatz der Modelierungsfähigkeiten von Bayes-Netzwerken
auf, und die Überzeugungs-Aktualisierungsverfahren werden
nicht als korrekt garantiert, wie dies bei den Bayes-
Netzwerken der Fall ist.
Regelbasierte Systeme weisen jedoch Aktualisierungsverfah
ren auf, die nicht optimal sind, wenn im Modell Schleifen
vorhanden sind. Bei Modellen von realen Systemen sind
Schleifen sehr typisch (z. B. gewöhnliche Ursachen, Fehler
such- und Beseitigungsschritte, die mehrere Ursachen besei
tigen etc.).
Ein Fehlersucher basierend auf Bayes-Netzwerken wird durch
Heckerman, D., Breese, J. und Rommelse, K., (1995), Decisi
on-theoretic Troubleshooting, Communications of the ACM,
38: 49-57 (nachstehend bezeichnet als "Heckerman u. a.
1995") beschrieben.
Ein Bayes-Netzwerk ist ein gerichteter, azyklischer Graph,
der die kausalen Beziehungen zwischen Variablen darstellt,
der den Variablen angesichts ihrer Eltern konditionale
Wahrscheinlichkeitsverteilungen zuordnet. Wirksame Verfah
ren zum exakten Aktualisieren von Wahrscheinlichkeiten in
Bayes-Netzwerken sind entwickelt worden. Siehe z. B. Lau
ritzen, S. L. und Spiegelhalter, D. J., Local Computations
with Probabilities on Graphical Structures and their Appli
cations to Expert Systems. Journal of the Royal Statistical
Society, Reihe B, 50(2): 157-224 (1988), und Jensen, F.
V., Lauritzen, S. L. und Olesen, K. G., Bayesian Updating
in Causal Probabilistic Networks by Local Computations,
Computational Statistics Quarterly, 4: 269-282 (1990). Wirk
same Verfahren zum exakten Aktualisieren von Wahrschein
lichkeiten in Bayes-Netzwerken sind im HUGIN-Expertensystem
implementiert worden. Siehe Andersen, S. K., Olesen, K. G.,
Jensen, F. V. und Jensen F., HUGIN - a shell for Building
Bayesian Belief Universes for Expert Systems, Proceedings
of the Eleventh International Joint Conference on Artifi
cial Intelligence (1989).
Bayes-Netzwerke liefern eine Möglichkeit, Problembereiche
unter Verwendung der Wahrscheinlichkeitstheorie zu model
lieren. Die Bayes-Netzwerk-Darstellung eines Problems kann
verwendet werden, um Informationen über einen Teilsatz von
Variablen angesichts der Informationen von anderen zu lie
fern. Ein Bayes-Netzwerk besteht aus einem Satz von Varia
blen (Knoten) und einem Satz von gerichteten Kanten (Ver
bindungen zwischen Variablen). Jede Variable weist einen
Satz von sich gegenseitig ausschließenden Zuständen auf.
Die Variablen bilden zusammen mit den gerichteten Kanten
einen gerichteten, azyklischen Graph (DAG; DAG = directed
acyclic graph). Für jede Variable v mit den Eltern w1, . . .,
wn ist eine konditionale Wahrscheinlichkeitstabelle P(v|w1,
. . ., wn) definiert. Offenbar verringert sich diese Tabelle
auf die marginale Wahrscheinlichkeit P(v), wenn v keine El
tern hat.
Bayes-Netzwerke sind bei vielen Anwendungsdomänen mit einer
Unbestimmtheit, wie z. B. eine medizinische Diagnose,
Stammbaumanalyse, Planung, Schuldenerfassung, Engpaßerfas
sung etc. verwendet worden. Einer der Hauptanwendungsberei
che ist jedoch die Diagnose gewesen. Die Diagnose (d. h.
zugrundeliegende Faktoren, die Krankheiten/Fehlfunktionen
bewirken, die wiederum Symptome verursachen) eignet sich
sehr gut für die Modellierungstechnik von Bayes-Netzwerken.
Das derzeit wirksamste Verfahren für ein exaktes Aktuali
sieren von Überzeugungen von Bayes-Netzwerken ist das Ver
bindungsbaumverfahren, das das Netzwerk in einen sogenann
ten Verbindungsbaum transformiert, was bei Jensen, F. V.,
Lauritzen, S. L. und Olesen, K. G., Bayesian Updating in
Causal Probabilistic Networks by Local Computations, Compu
tational Statistics Quarterly, 4: 269-282 (1990) be
schrieben ist. Im Grunde bündelt der Verbindungsbaum die
Variablen, so daß ein Baum erreicht wird (d. h. alle
Schleifen entfernt werden) und die Bündel so klein wie mög
lich sind. Bei diesem Baum kann ein Nachrichtenweiterlei
tungsschema die Überzeugungen von allen unbeobachteten Va
riablen angesichts der beobachteten Variablen aktualisie
ren. Das exakte Aktualisieren von Bayes-Netzwerken ist NP-
Hart (Cooper, G. F., The Computational Complexity of Proba
bilistic Inference using Bayesian Belief Networks, Artifi
cial Intelligence, 42: 393-405 (1990)). Es ist jedoch im
mer noch für einige Klassen von Bayes-Netzwerken sehr wirk
sam. Das Netzwerk für das Drucksystem enthält mehrere tau
send Variablen und viele Schleifen, kann jedoch immer noch
in einen Verbindungsbaum mit einer angemessen wirksamen Ak
tualisierung der Überzeugung transformiert werden.
Heckerman u. a. 1995 stellt ein Verfahren zum Ausführen ei
ner sequentiellen Fehlersuche und Beseitigung basierend
auf Bayes-Netzwerken dar.
Für eine Vorrichtung zur Fehlersuche- und Beseitigung, die
n Komponenten aufweist, die durch die Variablen c1, . . ., cn
dargestellt sind, folgen Heckerman u. a. 1995 der Einzel
fehlerannahme, die erfordert, daß exakt eine Komponente
fehlfunktioniert und daß diese Komponente die Ursache des
Problems ist. Wenn pi die Wahrscheinlichkeit bezeichnet,
daß die Komponente ci angesichts des aktuellen Zustands der
Informationen unnormal ist, dann ist n|i=1pi = 1 gemäß der
Einzelfehlerannahme. Jede Komponente ci weist Beobachtungs
kosten, die als C 0|1 (gemessen in Zeit und/oder Geld) be
zeichnet werden, sowie Reparaturkosten C r|i auf.
Laut einigen zusätzlichen, weniger strikten Annahmen, die
hier nicht wiedergegeben sind (siehe Heckerman u. a. 1995
für mehr Informationen), kann dann gezeigt werden, daß es
bei den Ausfallwahrscheinlichkeiten pi, die mit aktuellen
Informationen aktualisiert sind, immer optimal ist, die
Komponente, die das höchste Verhältnis pi/C 0|i aufweist, zu
beobachten. Dies erfolgt intuitiv, da das Verhältnis die
Ausfallwahrscheinlichkeit gegen die Beobachtungskosten aus
gleicht und die Komponente mit der höchsten Ausfallwahr
scheinlichkeit und den geringsten Beobachtungskosten auf
zeigt. Nach der Einzelfehlerannahme wird daher eine optima
le Beobachtungsreparatursequenz durch den Plan, der in der
nachstehenden Tabelle 1 aufgeführt ist, geliefert:
Berechne die Wahrscheinlichkeiten der Komponen
tenfehler pi angesichts der Tatsache, daß die
Vorrichtung nicht funktioniert.
Beobachte die Komponente mit dem höchsten Ver
hältnis pi/C 0|i.
Wenn die Komponente fehlerhaft ist, dann muß
sie repariert werden.
Wenn eine Komponente repariert wurde, muß an
schließend beendet werden. Andernfalls gehe zu
Schritt 1.
Bei dem Plan, der in Tabelle 1 oben beschrieben ist, wenn
eine Komponente im Schritt 3 repariert wird, ist aus der
Einzelfehlerannahme bekannt, daß die Vorrichtung repariert
werden muß, und der Fehlersuch- und Beseitigungsprozeß kann
gestoppt werden. Der Algorithmus arbeitet einigermaßen gut,
wenn die Einzelfehlerannahme angehoben wird, wobei in die
sem Fall in Schritt 1 neue Informationen berücksichtigt
werden, die in den Schritten 2 und 3 erhalten wurden, und
Schritt 4 wird wie in Tabelle 2 unten ersetzt:
Berechne die Wahrscheinlichkeiten der Komponen
tenfehler pi angesichts der Tatsache, daß die
Vorrichtung nicht funktioniert.
Beobachte die Komponente mit dem höchsten Ver
hältnis pi/C 0|i.
Wenn die Komponente fehlerhaft ist, dann muß
sie repariert werden.
Wenn die Vorrichtung immer noch nicht richtig
funktioniert, gehe zu Schritt 1.
Heckerman u. a. 1995 führt eine Theorie zur Handhabung ei
nes Servicerufs ein, die verwendet wird, wenn die geschätz
ten Kosten der optimalsten Fehlersuch- und Beseitigungsse
quenz höher als die Kosten eines Servicerufs sind (z. B.
Anruf beim Hersteller, um um Unterstützung zu bitten). Die
Theorie wechselt zum obigen Plan über, der es ermöglicht,
Systeme mit mehreren Fehlern und Nichtbasis-Beobachtungen
näherungsweise handzuhaben. Nichtbasis-Beobachtungen sind
Beobachtungen über etwas, das keine Komponente ist, jedoch
potentiell nützliche Informationen für den Fehlersuch- und
Beseitigungsprozeß liefert. In einem Begleitpapier (Breese,
J. und Heckerman, D., Decision-theoretic Troubleshooting: A
Framework for Repair and Experiment, Technical Report MSR-
TR-96-06, (1996), Microsoft Research, Advanced Technology
Division, Microsoft Corporation, Redmond, USA) wird das
Verfahren weiterentwickelt, um auch Konfigurationsänderun
gen im System zu ermöglichen, um ferner nützliche Informa
tionen, die potentiell die Kosten der optimalen Fehlersuch-
und Beseitigungssequenz senken können, zu liefern.
Die Bayes-netzwerkbasierten Fehlersucher, die durch Hecker
man u. a. 1995 beschrieben sind, weisen jedoch eine Eins
zu-Eins-Entsprechung zwischen den Ursachen und Aktionen
auf, die der Realität nicht standhält, eine kurzsichtige
(einstufiger Vorgriff) Auswahl von Fragen und eine zu lang
same Auswahl von Fragen auf, wenn viele von denselben exi
stieren. Ferner präsentiert Heckerman u. a. 1995 kein Ver
fahren der Wissensakquisition für ihre Fehlersucher.
Es ist die Aufgabe der vorliegenden Erfindung, eine Vor
richtung mit günstigen Eigenschaften zu schaffen.
Diese Aufgabe wird durch eine Vorrichtung gemäß Anspruch 1
gelöst.
Gemäß einem bevorzugten Ausführungsbeispiel der vorliegen
den Erfindung unterstützt ein Verfasserwerkzeug einen Ver
fasser beim Bauen eines automatisierten diagnostischen Sy
stems. Das Verfasserwerkzeug umfaßt eine Ursachen-
Editorschnittstelle, eine Aktions-Editorschnittstelle und
eine Frage-Editorschnittstelle. Die Ursachen-
Editorschnittstelle ermöglicht einem Verfasser, bei einer
Ursachendatenstruktur Informationen, die sich auf die Ursa
chen beziehen, anzuordnen. Die Aktions-Editorschnittstelle
ermöglicht einem Verfasser, bei einer Aktionsdatenstruktur
Informationen, die sich auf die Aktionen beziehen, die an
sprechend auf die Ursachen ergriffen werden können, anzu
ordnen. Die Frage-Editorschnittstelle ermöglicht einem Ver
fasser, bei einer Fragedatenstruktur Informationen, die
sich auf die Fragen beziehen, die einem Anwender des Pro
dukts gestellt werden können, um bei der Identifizierung
der Ursachen zu helfen, anzuordnen.
Bei dem bevorzugten Ausführungsbeispiel weist das Verfas
serwerkzeug zusätzlich eine Bibliothek von Modulen auf, wo
bei zumindest eines der Module diagnostische Informationen
über eine Komponente eines Produkts enthält. Der Verfasser
kann Module aus der Bibliothek von Modulen auswählen, wenn
er das automatisierte diagnostische System für das Produkt
baut.
Zum Beispiel beziehen sich die Informationen, die sich auf
die Ursachen beziehen, auf die nachstehenden Kategorien:
Name der Ursache, Eltern der Ursache, Erläuterung der Ursa
che und Wahrscheinlichkeit, daß die Ursache vorhanden ist.
Die Informationen, die sich auf die Ursache beziehen, kön
nen sich z. B. zusätzlich auf die nachstehenden Kategorien
beziehen: Ursachenkategorie, Abhängigkeit von der Umgebung
und Hinweis, daß ein Kunde auf diese Ursacheninformationen
nicht zugreifen soll.
Die Informationen, die sich auf eine Aktion beziehen, be
ziehen sich z. B. auf die nachstehenden Kategorien: Name
der Aktion, Erläuterung der Aktion, Ursachen, die durch die
Aktion beseitigt werden, Wahrscheinlichkeiten, daß die Ak
tion spezifizierte Ursachen beseitigt, und einen Hinweis,
ob die Aktion zum Informationssammeln dient oder eine po
tentielle Lösung ist. Die Informationen, die sich auf die
Aktion beziehen, können sich ebenfalls z. B. auf die nach
stehenden Kategorien beziehen: einen Hinweis, ob die Aktion
vor anderen Aktionen ergriffen werden soll, einen Hinweis,
ob die Aktion eine Behelfslösung (Workaround) ist, die Ko
sten der Ergreifens der Aktion, die Vertrauenswürdigkeit
der Antwort auf die Aktion, zusätzliche Aktionen, die in
der Aktion enthalten sind, ob die Aktion nur ausgeführt
werden kann, nachdem eine spezifizierte Frage beantwortet
worden ist, und ob die Aktion nicht ausgeführt werden kann,
nachdem eine spezifizierte Frage beantwortet worden ist.
Die Informationen, die sich auf eine Frage beziehen, bezie
hen sich z. B. auf die nachstehenden Kategorien: Name der
Frage, Erklärung der Frage, Anzahl der Antworten, Namen der
Antworten und Kosten der Antworten. Die Informationen, die
sich auf die Frage beziehen, können sich auch zusätzlich z. B.
auf die nachfolgenden Kategorien beziehen: ob die Frage
nur ausgeführt werden kann, nachdem eine spezifizierte Fra
ge beantwortet worden ist, ob die Frage nicht ausgeführt
werden kann, nachdem eine spezifizierte Frage beantwortet
worden ist, einen Hinweis, ob die Frage vor anderen Fragen
gestellt werden soll, und ob die Frage eine symptomatische
Frage oder eine allgemeine Frage ist. Wenn sich die Infor
mationen, die sich auf eine Frage beziehen, speziell auf
eine Symptomfrage beziehen, können sich die Informationen
zusätzlich z. B. auf die folgenden Kategorien beziehen: Ur
sache des Symptoms, Wahrscheinlichkeit von Antworten auf
die Frage, abhängig von den Ursachen des Symptoms, und
Wahrscheinlichkeit der Fragen auf die Antwort, abhängig von
keiner der Ursachen, die das Symptom verursachen können.
Wenn die Informationen, die sich auf die Frage beziehen,
sich speziell auf eine allgemeine Frage beziehen, können
die Informationen sich zusätzlich z. B. auf die folgenden
Kategorien beziehen: frühere Wahrscheinlichkeiten von Ant
worten auf die Frage, Ursachen, die durch die Antworten auf
die Frage beeinflußt werden, und die Wahrscheinlichkeit der
beeinflußten Ursachen abhängig von jeder Antwort auf die
Frage.
Bei dem bevorzugten Ausführungsbeispiel ermöglicht die Ur
sachen-Editorschnittstelle einem Verfasser, neue Ursachen
einträge zu erzeugen und vorhandene Ursacheneinträge zu lö
schen und zu editieren. Die Aktions-Editorschnittstelle er
möglicht einem Verfasser, neue Aktionseinträge zu erzeugen
und vorhandene Aktionseinträge zu löschen und zu editieren.
Die Frage-Editorschnittstelle ermöglicht einem Verfasser,
neue Frageeinträge zu erzeugen und vorhandene Frageeinträge
zu löschen und zu editieren.
Ein Verfasserwerkzeug gemäß dem bevorzugten Ausführungsbei
spiel der vorliegenden Erfindung verringert in hohem Maße
die Zeitanforderungen der Wissensakquisition. Das Verfas
serwerkzeug ist so strukturiert, daß der Verfasser durch
eine Reihe von Fragen geleitet wird, die es ihm ermögli
chen, nur die absolute Mindestmenge von Informationen zu
spezifizieren. Das Verfasserwerkzeug ist so strukturiert,
daß Informationen der Domäne in einer Art und Weise spezi
fiziert sind, die für die Domänenexperten nachweislich na
türlich und intuitiv sind. Das Verfasserwerkzeug ist so
strukturiert, daß ein Wissen über Bayes-Netzwerke nicht er
forderlich ist, so daß ein Bayes-Netzwerk-Experte während
des Wissensakquisitionsprozesses (KA-Prozeß; KA = knowledge
acquisition) nicht mehr gegenwärtig sein muß. Eine anfäng
liche Konstruktion von diagnostischen Modellen für Fehler
bedingungen in der fraglichen Domäne verläuft ebenfalls re
lativ langsam, doch die Verfassergeschwindigkeit nimmt
durch die Wiederverwendung von Modulen zu, da mehr und mehr
Module in der Domäne gebaut werden.
Das Verfasserwerkzeug ermöglicht eine rasche Beibehaltung
von früher konstruierten diagnostischen Systemen. Vor der
Existenz des Verfasserwerkzeugs war eine direkte Manipula
tion des zugrundeliegenden Bayes-Netzwerks erforderlich, um
das Verhalten eines diagnostischen Systems zu modifizieren.
Die erforderlichen Veränderungen können jedoch mit dem Ver
fasserwerkzeug auf einer Repräsentation ausgeführt werden,
die dem Zweck viel besser dient. Ferner kann aufgrund der
Wiederverwendung von Modulen eine Veränderung an einem Mo
dul auf alle die Orte ausgeweitet werden, wo dieses Modul
verwendet wird. Daher werden die Zeitanforderungen für die
Beibehaltung von diagnostischen Systemmodellen in hohem Ma
ße verringert.
Das Verfasserwerkzeug ermöglicht eine rasche Migration von
einem Produkt zum nächsten. Da die diagnostischen Informa
tionen in modularer Weise angeordnet sind, ist es ein
schnelles und leichtes Verfahren, ein diagnostisches System
für ein Produkt durch einfache Berücksichtigung von nur den
Modulen, die verändert worden sind, auf das nächste zu mi
grieren. Bei vielen Produktserien bestehen nur wenige Ver
änderungen zwischen unterschiedlichen Versionen, unter
schiedlichen Revisionen oder unterschiedlichen Modellen.
Die erforderlichen Veränderungen sind gewöhnlich in klar
definierten Modulen vorhanden. Ferner können Informationen,
die sich wahrscheinlich mit dem nächsten Modell verändern
werden, beim Erzeugen von anfänglichen diagnostischen Mo
dellen für ein Produkt markiert (bzw. mit einer Flag verse
hen) werden. Daher kann das Verfasserwerkzeug beim Migrie
ren dieser Modelle die markierten Informationen zur Berück
sichtigung durch den Domänenexperten anzeigen. Auf diese
Weise können Zeitanforderungen für die Migration durch die
Anordnung von Informationen in Modulen und durch Markieren
von Informationen, die sich wahrscheinlich zwischen Model
len verändern werden, verringert werden.
Das bevorzugte Ausführungsbeispiel der Erfindung ermög
licht, daß die Wissensakquisition durch Personen mit dem
Wissen über die Domäne ausgeführt wird, d. h. Domänenexper
ten. Es ist kein Fachwissen über Bayes-Netzwerke, diagno
stische Algorithmen etc. notwendig. Daher ermöglicht das
Verfasserwerkzeug, das hierin beschrieben ist, einen ge
ringst möglichen Arbeitsaufwand, um diagnostische Systeme
zu erzeugen.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung
werden nachfolgend Bezug nehmend auf die beiliegenden
Zeichnungen näher erläutert.
Fig. 1 ist ein Überblick einer diagnostischen Umgebung
gemäß einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung;
Fig. 2 ist ein vereinfachtes Blockdiagramm eines Webser
vers gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
Fig. 3 ist ein vereinfachtes Blockdiagramm der Komponen
ten in einem Personalcomputer eines Kunden, der
bei dem diagnostischen Prozeß gemäß einem bevor
zugten Ausführungsbeispiel der vorliegenden Er
findung verwendet wird;
Fig. 4 ist ein Überblick über Schritte, um die Wissens
akquisition gemäß einem bevorzugten Ausführungs
beispiel der vorliegenden Erfindung auszuführen;
Fig. 5 zeigt eine Hauptschnittstelle für ein Verfasser
werkzeug gemäß einem bevorzugten Ausführungsbei
spiel der vorliegenden Erfindung;
Fig. 6 zeigt eine Schnittstelle für einen Ursacheneditor
gemäß einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung;
Fig. 7 zeigt eine Schnittstelle für einen Ursachenwahr
scheinlichkeitseditor gemäß einem bevorzugten
Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 8 zeigt eine Schnittstelle für einen Ursachenkate
gorieeditor gemäß einem bevorzugten Ausführungs
beispiel der vorliegenden Erfindung;
Fig. 9 zeigt eine Schnittstelle für einen Aktionseditor
gemäß einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung;
Fig. 10 zeigt eine Schnittstelle für einen Aktionswahr
scheinlichkeitseditor gemäß einem bevorzugten
Ausführungsbeispiel der vorliegenden Erfindung;
Fig. 11 zeigt eine Schnittstelle für einen allgemeinen
Frageneditor gemäß einem bevorzugten Ausführungs
beispiel der vorliegenden Erfindung;
Fig. 12 zeigt eine Schnittstelle für einen Wahrschein
lichkeitsveränderungseditor gemäß einem bevorzug
ten Ausführungsbeispiel der vorliegenden Erfin
dung;
Fig. 13 zeigt eine Schnittstelle für einen Symptomfrage
neditor gemäß einem bevorzugten Ausführungsbei
spiel der vorliegenden Erfindung;
Fig. 14 zeigt eine Schnittstelle für einen Erläuterungse
ditor gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
Fig. 15 zeigt eine Schnittstelle für einen Kosteneditor
gemäß einem bevorzugten Ausführungsbeispiel der
vorliegenden Erfindung; und
Fig. 16 zeigt eine Schnittstelle für einen Extrainforma
tionseditor gemäß einem bevorzugten Ausführungs
beispiel der vorliegenden Erfindung.
Fig. 1 ist ein Überblick einer diagnostischen Umgebung ge
mäß einem bevorzugten Ausführungsbeispiel der vorliegenden
Erfindung.
Fig. 1 zeigt einen Webserver 200, einen Personalcomputer
eines Kunden (PC) 205, einen Druckerserver 209 und einen
Drucker 210. Ein diagnostisches System 201 eines Druckersy
stems läuft auf einem Webserver 200.
Ein diagnostisches System wird z. B. zur Entscheidungsun
terstützung, Auswahl, Klassifizierung, Prognose und zum Ma
keln verwendet.
Bei der Entscheidungsunterstützung wird ein Anwender durch
eine Sequenz von Fragen geführt, die ihn zur optimalen Lö
sung für ein Problem führen. Zum Beispiel hilft die Ent
scheidungsunterstützung einem Anwender dabei, die richtige
Entscheidung im Hinblick auf ein bestimmtes Problem zu
treffen. Ein System verwendet z. B. für automatisierte Kun
dendienstoperationen (SACSO; SACSO = system for automated
customer support operations) einer Entscheidungsunterstüt
zungsmaschine eine Sequenz von Fragen, um das eigentliche
zugrundeliegende Problem zu bestimmen, und kann Lösungen
für das Problem vorschlagen.
Um die Wissensakquisition auszuführen, die angewendet wird,
um eine Entscheidungsunterstützung zu ermöglichen, wird ei
ne Domäne, in der die Entscheidungsunterstützung ausgeführt
werden soll, identifiziert. Es werden auch mögliche Situa
tionen in der Domäne, mögliche Teilsituationen der mögli
chen Auswahlen und Informationsschritte identifiziert. Die
Informationsschritte sind den möglichen Situationen und
möglichen Teilsituationen angepaßt. Die Wahrscheinlichkei
ten werden für die möglichen Situationen und die möglichen
Teilsituationen geschätzt. Es werden auch Wahrscheinlich
keiten für Aktionen und Fragen, die in den Informations
schritten aufgeführt sind, sowie Kosten für Aktionen und
Fragen, die in den Informationsschritten aufgeführt sind,
geschätzt.
Bei der Auswahl läuft ein diagnostisches System durch eine
Sequenz von Fragen, die dem Anwender dabei helfen, zwischen
einer Anzahl von Möglichkeiten auszuwählen. Mehrere Auswah
len können getroffen werden. Zum Beispiel verwendet ein
Schüler das diagnostische System, um einen optimalen Stun
denplan für den Unterricht zu entwerfen. Indem es ihm Fra
gen stellt, versucht das diagnostische System, die Bereiche
zu bestimmen, wo der Schüler Nachhilfe benötigt (Könnens
lückenanalyse), und das diagnostische System kann dann Un
terrichtsstunden vorschlagen, die auf diese spezifischen
Bereiche zielen. Dabei handelt es sich nicht vollständig um
eine allgemeine Entscheidungsunterstützung. Es ist eine
Entscheidungsunterstützung in der Weise, daß sie dem Anwen
der hilft, die Situation, auf die die Verwendung gerichtet
ist, zu identifizieren, und dann eine Lösung vorschlägt.
Ursachen entsprechen Situationen. Informationsschritte ent
sprechen diagnostischen Schritten. Bei diesem Fall liefern
Aktionen Lösungen, und Fragen sammeln Informationen wie bei
einem diagnostischen System.
Um die Wissensakquisition, die zum Ermöglichen der Auswahl
verwendet wird, auszuführen, wird eine Domäne, in der die
Auswahl ausgeführt werden soll, identifiziert. Es werden
auch mögliche Situationen in der Domäne, mögliche Teilsi
tuationen der möglichen Auswahlen und Informationsschritte
identifiziert. Die Informationsschritte sind den möglichen
Situationen und den möglichen Teilsituationen angepaßt. Die
Wahrscheinlichkeiten werden für die möglichen Situationen
und die möglichen Teilsituationen eingeschätzt. Die Wahr
scheinlichkeiten für Aktionen und Fragen, die in den Infor
mationsschritten aufgeführt sind, sowie die Kosten für Ak
tionen und Fragen, die in den Informationsschritten aufge
führt sind, werden ebenfalls geschätzt. Die Ursachen ent
sprechen den Auswahlen. Die Informationsschritte entspre
chen den diagnostischen Schritten und werden verwendet, um
Informationen zu sammeln, die zum Einkreisen der Möglich
keiten bei einer Auswahl nützlich sind.
Bei einer Klassifizierung kann ein diagnostisches System
verwendet werden, um etwas gemäß einer Anzahl von Kategori
en zu klassifizieren. Das diagnostische System kann z. B.
für eine Pfadanalyse verwendet werden, z. B. das Lenken von
Kundenfeedback-E-Mails an die richtige Person. Das Lenken
von Kundenfeedback-E-Mails zu der richtigen Person könnte
z. B. die Klassifizierung einer E-Mail in eine Anzahl von
Kategorien basierend auf Kennungen oder Schlüsselwörter,
die aus der E-Mail extrahiert wurden, mit sich bringen.
Bei der Prädiktion kann ein diagnostisches System verwendet
werden, um Prädiktionssysteme zu erzeugen. Im Grunde werden
potentielle zukünftige Ursachen anstelle von aktuellen Ur
sachen modelliert, und Fragen, die nach Symptomen von zu
künftigen Problemen suchen, werden modelliert.
Das Vermitteln ist eine Variante der Auswahl, wo ein dia
gnostisches System verwendet wird, um in einer Liste von
möglichen Lösungen zu vermitteln. Zum Beispiel kann ein E-
Sprach-Vermittler, der ein intelligenteres Vermitteln zwi
schen konkurrierenden E-Diensten ausführen muß, ein diagno
stisches System verwenden, um dies durch Ausführen eines
intelligenteren Vergleichs von E-Dienst-Parametern vorzu
nehmen.
Das diagnostische System 201 des Druckers wird hierin als
ein Beispiel eines diagnostischen Systems verwendet. Das
diagnostische System 201 des Druckers wird zum Diagnosti
zieren des Betriebs eines Druckersystems verwendet. Ein An
wender auf dem Kunden-PC 205 kann auf das diagnostische Sy
stem 201 über das Internet 202 zugreifen. Ein Webbrowser
206 im Kunden-PC 205 wird verwendet, um auf den Webserver
200 zuzugreifen. Ansprechend auf die Interaktion des Kunden
mit dem diagnostischen System 201, antwortet das diagnosti
sche System 201 mit Vorschlägen 203 für diagnostische
Schritte, die der Kunde ausführen kann. Das diagnostische
System 201 funktioniert im wesentlichen als ein Expertensy
stem, das eine künstliche Intelligenz nutzt. Der Kunde lie
fert Informationen 204 zurück zum diagnostischen System
201, die das diagnostische System 201 über das Ergebnis be
züglich des Handelns auf die Vorschläge 203 hin informiert.
Die Informationen 204 können Informationen 207 umfassen,
die der Kunde vom Druckerserver 209 erhält, und/oder Infor
mationen 208, die der Kunde vom Drucker 210 erhält.
Fig. 2 ist ein vereinfachtes Blockdiagramm eines Webservers
200. Das diagnostische System 201 wird in einem Speicher
301 des Webservers 200 ausgeführt. Das diagnostische System
201 nutzt sekundäre Speichergeräte 303 für die Speicherung
von diagnostischen Modellen. Eine Videoanzeige 304 kann
durch einen Techniker verwendet werden, um den diagnosti
schen Prozeß zu überwachen und um die diagnostischen Model
le beizubehalten. Der Webserver 200 umfaßt auch eine Einga
begerät 305, wie z. B. eine Tastatur, eine CPU 306 und eine
Netzwerkkarte 307, zur Kommunikation mit den Webbrowsern
206 im Kunden-PC 205.
Fig. 3 ist ein Überblick der Komponenten des diagnostischen
Prozesses. Der Webserver 200 ist gezeigt. Der Kunde kommu
niziert mit dem diagnostischen System 201 (in Fig. 1 ge
zeigt) im Webserver 200 durch den Webbrowser 206, der auf
dem Kunden-PC 401 läuft. Der Kunde empfängt Vorschläge 203
vom diagnostischen System 201 und liefert wiederum Antwor
ten 204. Der Kunde verwendet das diagnostische System 201,
wenn er im Druckersystem, das aus dem Druckerserver 209 und
dem Drucker 210 besteht, eine Störung erlebt. Im allgemei
nen geht die Druckaufgabe zuerst an einen Druckertreiber
407, dann eventuell durch einen lokalen Spooler 408 und
dann an eine Betriebssystems-Umleitung (O/S-Umleitung; O/S
= operating system) 409, wenn ein Kunde versucht, aus einer
Anwendung 406 zu drucken. Die O/S-Umleitung 409 ist der
Teil des Betriebssystems, der bestimmt, in welche Richtung
die Druckaufgabe geht, d. h. zu einer Netzwerkverbindung
413 über einen Netzwerktreiber 410 und eine Netzwerkkarte
411 oder zu einem lokalen Port 412 im Falle eines lokalen,
parallel geschalteten Druckers. Wenn die Druckaufgabe zu
einem lokalen, parallel geschalteten Drucker wandert, wan
dert die Druckaufgabe durch ein Parallelkabel 415, bevor
sie den Drucker 210 erreicht. Wenn die Druckaufgabe zu ei
nem Netzwerkdrucker wandert, wandert sie entweder durch die
Netzwerkverbindung 413 zum Druckerserver 209 oder durch ei
ne direkte Netzwerkverbindung 414 zum Drucker 210. Die di
rekte Netzwerkverbindung 414 kann für bestimmte Drucker
verwendet werden, z. B. den HP LaserJet 5Si, der bei der
Hewlett-Packard Company mit Geschäftssitz in 3000 Hanover
Street, Palo Alto, California 94304, erhältlich ist. Wenn
der Drucker 210 durch einen Druckerserver 209 gesteuert
wird, wandert die Druckaufgabe durch eine Druckerschlange
420 in den Druckerserver 209, und dann wird die Druckaufga
be entweder entlang einer Netzwerkverbindung 417 an den
Drucker 210 oder ein Parallelkabel 418 abhängig davon, wie
der Drucker 210 mit dem Druckerserver 209 verbunden ist,
geschickt.
Die Anwendung 406, der Druckertreiber 407, der Spooler 408
und die O/S-Umleitung 409 werden alle auf dem Betriebssy
stem 405 auf dem Kunden-PC 205 ausgeführt. Beim Drucken ei
ner Druckaufgabe aus der Anwendung 406 folgt die Druckauf
gabe abhängig vom System-Setup einem der zuvor beschriebe
nen Pfade auf ihrem Weg zum Drucker 210. Wenn etwas auf dem
Weg dorthin schiefläuft, kann dies dazu führen, daß es kei
ne Ausgabe oder eine unerwartete Ausgabe gibt. Das diagno
stische System 201 wird durch Tests an Komponenten im Sy
stem versuchen, zu bestimmen, welche Komponente(n) das Pro
blem verursachten.
Fig. 4 ist ein Überblick von Schritten, um die Wissensak
quisition auszuführen, um das diagnostische System 201 zu
implementieren. Der Wissensakquisitionsprozeß ist der Pro
zeß des Konstruierens der diagnostischen Modelle durch Sam
meln von ausreichend Informationen über die Domäne von so
genannten Domänenexperten. Die Domänenexperten sind mit der
Domäne, die modelliert wird, in diesem Fall den Druckersy
stemen, vertraut. Diese Domänenexperten verfügen über ge
naues Wissen über die in Betracht gezogene Domäne, da sie
bei der Konstruktionsphase, der diagnostischen oder unter
stützungstechnischen Phase des Produkts, assistiert haben.
Der Wissensakquisitionsprozeß muß durch jemanden geleitet
werden, der mit den Regeln und Anforderungen des Prozesses
vertraut ist. Die Teilnahme am oder die Leitung des Wis
sensakquisitionsprozesses erfordert kein Fachwissen im Be
reich von Bayes-Netzwerken. Um bei der Darstellung zu hel
fen, wird das Problem des "hellen Drucks" als ein Beispiel
in der Diskussion der Schritte, die in Fig. 4 offenbart
sind, verwendet. Der "helle Druck" ist das Problem des An
wenders, der eine Ausgabe aus dem Drucker empfängt, die
heller ist als erwartet.
Bei einem Schritt 900 werden die Belange, die zu diagnosti
zieren sind, identifiziert. Das Problem, das modelliert
wird, wird identifiziert, präzise definiert und von anderen
Problemen getrennt. Anfänglich ist es sehr wichtig, das in
Betracht gezogene Problem und die Anwendergruppe des dia
gnostischen Werkzeugs genau zu definieren, da dies einen
großen Einfluß auf die nachfolgenden Wissensakquisitions
schritte haben wird. Das Qualifikationsniveau der Anwender
gruppe ist beim Spezifizieren von sowohl Ursachen als auch
Schritten von Bedeutung, da es Ursachen und Schritte gibt,
die durch den Endanwender nicht manipuliert werden können,
jedoch durch erfahrene diagnostische Systeme manipuliert
werden können. Im folgenden wird davon ausgegangen, daß es
eine Anwendergruppe von Endanwendern gibt, die nur über ein
rudimentäres Verständnis des Druckersystems verfügen, je
doch angeleitet werden können, um komplizierte Schritte
auszuführen.
Bei einem Schritt 901 werden die Ursachen der Belange iden
tifiziert. In diesem Schritt identifizieren die Domänenex
perten die Ursachen des in Betracht gezogenen Problems. Die
Ursachen sind im Grunde alle unterschiedliche Komponenten,
Eigenschaften oder Ereignisse, die das Problem verursachen
können.
Es ist normalerweise unmöglich und/oder nicht notwendig,
alle Ursachen zu identifizieren und zu spezifizieren, da es
Ursachen gibt, die zu selten sind, um es Wert zu sein, in
Betracht gezogen zu werden, z. B. eine außerhalb des Spezi
fikationsrahmens befindliche Gravitation, die Druckprobleme
bewirkt, oder Ursachen, die durch den Anwender sowieso
nicht beeinflußt werden können, z. B. fortgeschrittene
technische Probleme mit Druckerkomponenten. Diese Ursachen
werden dann in einer Einzel-Leck-Ursache, die als "andere
Probleme" bezeichnet wird, gesammelt, die ferner zwei Tei
lursachen aufweist, die jeweils "temporäre Probleme", die
durch Leistungs-Ein-Ausschalten des Druckers gelöst werden
können, und "permanente Probleme", die nicht durch den An
wender gelöst werden können, darstellen.
Eine der Schwierigkeiten beim Identifizieren von Ursachen
ist die Entscheidung, ob Sätze von Ursachen als eine ein
zelne Ursache gruppiert werden sollen oder ob die Ursachen
separat gehalten werden sollen. Als Daumenregel ist es ein
facher, die Wissensakquisition für Aktionen vorzunehmen,
wenn die Ursachen, für die unterschiedliche Aktionen vor
handen sind, separat gehalten werden.
Zum Beispiel wurden für das Problem des "hellen Drucks"
nachstehende Ursachen und Teilursachen, wie sie in Tabelle
3 nachstehend aufgeführt sind, identifiziert:
Ursache/Teilursache | ||
Erklärung | ||
Medium | Wenn das Papier von einem Typ ist, daß der Toner nicht richtig daran haften bleibt, kann dies hellen Druck bewirken. | |
Papierpfad verschmutzt | Wenn der Papierpfad verschmutzt ist, besteht die Möglichkeit, daß dies einen helleren Druck bewirkt. Umweltbedingungen - Feuchtigkeit, Temperatur etc. - können insgesamt einen helleren Druck bewirken, wenn diese extrem sind. | |
Tonerkassettenprobleme | Probleme mit der Tonerkassette können einen helleren Druck bewirken, z. B. wenn die Kassette nicht genügend Toner enthält. | |
Übertragungsrollenprobleme | Die Übertragungsrolle ermöglicht, daß das Tonerbild auf der Trommeloberfläche auf das Medium übertragen wird oder auf demselben plaziert wird, und kann daher ebenfalls einen hellen Druck bewirken. Inkorrekte Anwendungseinstellungen - offensichtlich gibt es Einstellungen, die, wenn diese inkorrekt eingestellt sind, einen hellen Druck sowohl bei der Anwendung, dem Druckertreiber und auf dem Steuerbedienfeld des Druckers selbst bewirken können. | |
AL=L<Inkorrekte Druckertreibereinstellungen | ||
AL=L CB=3<Inkorrekte Steuerbedienfeldeinstellungen@ | Korrupter Datenfluß | Es gibt eine leichte Veränderung, daß die Druckaufgabe an einer beliebigen Stelle im Fluß von der Anwendung durch das Netzwerk zum Drucker korrumpiert werden kann, so daß er heller als erwartet ausdruckt. |
Falscher Treiber verwendet | Unter Verwendung des inkorrekten Treibers für den Drucker kann ein heller Druck bewirkt werden. | |
Andere Probleme | Wie vorstehend erwähnt, gibt es Ursachen für einen hellen Druck, die es nicht Wert sind, in Betracht gezogen zu werden, und sie werden unter dieser Überschrift zusammengestellt. |
Die Erfahrung hat gezeigt, daß das Modellieren der Ursachen
auf dieser Ebene stark der Denkweise ähnelt, die durch er
fahrene Drucksystem-Rufbeauftragte angewendet wird. Wenn
sie Druckerprobleme über das Telefon diagnostizieren, be
wahren sie in ihrem Kopf eine Liste der Ursachen und Tei
lursachen, die den vorstehenden ähnlich sind, und passen
die Überzeugungen der unterschiedlichen Ursachen basierend
auf dem Gespräch mit dem Kunden kontinuierlich an.
Bei einem Schritt 902 werden eventuelle Teilursachen iden
tifiziert. Häufig ist es praktisch, die Ursachen in Katego
rien zu organisieren. Diese Kategorien werden dann als Ur
sachen mit einer Anzahl von Teilursachen betrachtet. Es ist
nicht strikt notwendig, Teilursachen der Ursachen zu ver
wenden, da es völlig möglich ist, alle Teilursachen auf der
gleichen oberen Ebene zu lassen. Dieser Lösungsansatz führt
jedoch häufig zu einer hohen Anzahl von Ursachen auf der
oberen Ebene, was die Akquisition von Wahrscheinlichkeiten
schwieriger gestaltet. Das Organisieren der Ursachen in ei
ne Hierarchie ermöglicht dem Domänenexperten, weniger Ursa
chen auf einmal in Betracht zu ziehen, wenn er die Wahr
scheinlichkeiten einschätzt, wodurch akkuratere Informatio
nen geliefert werden.
Während in Fig. 4 nur zwei Ebenen der Ursachenstruktur dar
gestellt sind, können willkürlich viele Ebenen von Ursachen
und Teilursachen bestehen.
Die fertiggestellte Hierarchie von Ursachen für "hellen
Druck" ist wie in Tabelle 4 nachstehend aufgeführt:
- 1. Medium
- 2. Papierpfad verschmutzt
- 3. Umweltbedingungen
- 4. Tonerkassettenprobleme
- a) defekte Tonerkassette
- b) unzureichend eingepaßte Tonerkassette
- c) Tonerverteilung - dies umfaßt geringen Tonerin halt und andere Probleme mit dem Tonerfluid
- 5. Übertragungsrollenprobleme
- a) defekte oder schmutzige Übertragungsrollen
- b) unzureichend eingepaßte Übertragungsrolle
- c) abgenutzte Übertragungsrolle
- 6. Inkorrekte Anwendungseinstellungen
- a) Econo-Modus/Einziehmodus ein - Econo-Modus ist eingestellt, um Toner zu sparen, und bewirkt da her einen helleren Druck als gewöhnlich
- b) 300/600 dpi auf 300 dpi gesetzt - 300 dpi können einen helleren Druck als 600-dpi-Drucke bewirken
- c) andere Einstellungen falsch eingestellt - andere Einstellungen, die einen hellen Druck bewirken können
- 7. Inkorrekte Druckertreibereinstellungen
- a) Econo-Modus eingestellt
- b) 300/600 dpi auf 300 dpi eingestellt
- c) andere Einstellungen falsch eingestellt
- 8. Inkorrekte Steuerbedienfeld-Einstellungen
- a) Econo-Modus/Einziehmodus-eingestellt
- b) 300/600 dpi auf 300 dpi eingestellt
- c) Druckdichte zu niedrig eingestellt
- 9. Korrupter Datenfluß
- 10. Falscher Treiber verwendet
- 11. Andere Probleme
- a) temporäre Probleme
- b) permanente Probleme
In einem Schritt 903 werden die diagnostischen Schritte der
Belange identifiziert. Die Aktionen, die eine der Ursachen
des Problems lösen können, und Fragen, die Informationen
bezüglich der Ursachen liefern, sind aufgelistet.
Beim Auflisten der diagnostischen Schritte eines Problems
ziehen die Domänenexperten grundsätzlich die Schritte in
Betracht, die sie selbst ausführen würden oder dem Kunden
vorschlagen würden, daß dieser sie ausführt, wenn sie mit
dem Problem konfrontiert wären. Die Erfahrung zeigt, daß es
vorteilhaft ist, damit zu beginnen, die Schritte aufzuli
sten, ohne zuvor aufgelistete Ursachen in Betracht zu zie
hen, d. h. mit einem "leeren" Kopf, da dies gelegentlich
ansonsten vergessene Schritte wieder in Erinnerung bringt.
Anschließend, wenn diese ersten Schritte aufgelistet worden
sind, ist es nützlich, die Liste der Ursachen zu überden
ken, und alle Schritte, die potentiell diese Ursachen lö
sen, hinzuzufügen.
Beim Auflisten der diagnostischen Schritte sollten nur
Schritte, die durch die angenommene Anwendergruppe des dia
gnostischen Systems ausgeführt werden können, aufgelistet
werden, z. B. wenn die Anwendergruppe die Endanwender sind,
ist es irrelevant, Schritte vorzuschlagen, die ein höheres,
technisches Verständnis des Drucksystems erfordern, um er
folgreich ausgeführt werden zu können. Es gibt auch Schrit
te, die ein hohes Risiko bergen, andere Komponenten kaputt
zu machen, wenn sie von unerfahrenen Anwendern ausgeführt
werden, und die nicht enthalten sein sollten. Schritte, die
sehr kostspielige Voraussetzungen erfordern, sind auch
Schritte, die gewöhnlicherweise nicht enthalten sein soll
ten.
Der Domänenexperte ist wiederum mit dem Problem der Größe
und Abdeckung der Schritte konfrontiert. Es gibt diagnosti
sche Prozeduren, die in gleicher Weise wie ein einzelner
Schritt oder eine Serie von Schritten modelliert werden
können. Die Daumenregel hier lautet, daß es von der Anwen
derschnittstelle und dem Schritt an sich abhängt, wie ein
Schritt darzustellen ist. Wenn der Schritt bequem als eine
deterministische Flußdiagramm-Wenn-Dann-Struktur darge
stellt werden kann und die Anwenderschnittstelle des dia
gnostischen Systems die Implementierung von solchen deter
ministischen "Programmen" unterstützt, dann sollte der
Schritt als ein einzelner Schritt modelliert werden. Wenn
das Flußdiagramm des Schritts unbestimmte Entscheidungen/
Wahrscheinlichkeitsentscheidungen umfaßt, muß der Schritt
in mehreren Schritten dargestellt werden.
Es gibt zwei Hauptkategorien von diagnostischen Schritten,
Aktionen und Fragen. Bei der ersten Kategorie, Aktionen,
handelt es sich um Schritte, die erfordern, daß der Anwen
der eine Art von Eingriff in das System ausführt und dem
diagnostischen System Bericht erstattet, ob die Aktion das
Problem gelöst hat oder nicht. Daher weisen Aktionen das
Potential auf, das Problem zu lösen. Bei der zweiten Kate
gorie, Fragen, handelt es sich um Schritte, die erfordern,
daß der Anwender Informationen bezüglich des anstehenden
Problems durch mögliches Eingreifen in das System erhält
und dem diagnostischen System über das Ergebnis Bericht er
stattet. Die Fragen werden in zwei Teilkategorien grup
piert, Informationssammlungsaktionen und allgemeine Fragen.
Informationssammlungsaktionen sind Aktionen, die nicht das
Potential aufweisen, das Problem zu lösen. Sie liefern le
diglich Informationen, die bei der Lösung des Problems re
levant sind. Gewöhnliche Aktionen werden auch als Lösungs
aktionen bezeichnet, um sie von den Informationssammlungs
aktionen zu unterscheiden. Es ist von Bedeutung, zwischen
ihnen zu unterscheiden, da die zwei Typen von Aktionen in
den diagnostischen Algorithmen unterschiedlich gehandhabt
werden, wie nachstehend weiter beschrieben ist, wo Informa
tionssammlungsaktionen als Fragen behandelt werden. Um dies
zu verdeutlichen, heißt das, daß es aus algorithmischer Sicht
keinen Unterschied zwischen Informationssammlungska
tionen und Fragen gibt. Die Unterscheidung wird jedoch wäh
rend der Wissensakquisition beibehalten, da es für einen
Domänenexperten einfacher ist, Wahrscheinlichkeiten für In
formationssammlungsaktionen, wenn diese als Aktionen behan
delt werden, herauszuholen.
Die Unterscheidung zwischen Informationssammlungs- und Lö
sungsaktionen sollte ebenfalls geklärt werden. Lösungsak
tionen haben das Potential, das Problem zu lösen, wohinge
gen Informationssammlungsaktionen möglicherweise das Pro
blem nicht lösen können. Informationssammlungsaktionen wei
sen lediglich das Potential auf, das Problem vorübergehend
zu beseitigen, wohingegen versucht wird, an der Umgebung
eine Veränderung vorzunehmen.
Allgemeine Fragen sind die verbleibenden Fragen, die keine
Informationssammlungsaktionen sind. Die Fragen weisen nicht
das Potential auf, das Problem zu lösen, und können eine
beliebige Anzahl von Antworten aufweisen im Gegensatz zu
Aktionen, die nur zwei aufweisen: ja (es hat geholfen) und
nein (es hat nicht geholfen).
Beim Auflisten der diagnostischen Schritte eines Problems
müssen sie entweder als Lösungsaktionen (SA; solution ac
tion), als Informationssammlungsaktionen (IA; IA = informa
tion-gathering action) oder Fragen (Q; Q = questions) kate
gorisiert werden.
Für alle Aktionen und Fragen sollten Erklärungen so früh
wie möglich in den Wissensakquisitionsprozeß geschrieben
werden, da diese Erklärungen/Definitionen dabei helfen, zu
künftige Verwirrungen zu verringern und sicherstellen, daß
Fehler so früh wie möglich erkannt werden.
Für das Problem des "hellen Drucks" wurden die nachstehen
den Schritte identifiziert, die in Tabelle 5 nachstehend
aufgeführt sind:
- A) Sicherstellen, daß sich das Medium innerhalb der Spe zifikationen befindet (SA).
- B) Andere Tonerkassetbe verwenden, die sich innerhalb der Spezifikationen befindet (IA).
- C) Tonerkassette (SA) ausbauen, schütteln und wieder ein bringen.
- D) Übertragungsrolle erneut einpassen (SA).
- E) Unterschiedliches Medium verwenden (IA).
- F) Druckerwartungsset ausführen (SA).
- G) Drucker einem Leistungs-Ein-Ausschalten unterziehen (SA).
- H) Sicherstellen, daß sich die Umweltbedingungen inner halb der Spezifikationen befinden (SA).
- I) Reinigen Sie das Innere des Druckers gemäß dem Benut zerhandbuch (SA).
- J) Andere Übertragungsrolle, die sich innerhalb der Spe zifikationen befindet, verwenden (IA).
- K) Sicherstellen, daß sich Econo-Modus/Entwurfsmodus nicht mehr in der Anwendung befinden (SA).
- L) Sicherstellen, daß 300 dpi nicht in der Anwendung ein gestellt ist (SA).
- M) Andere Anwendungseinstellungen bezüglich des "hellen Drucks" untersuchen und beheben (SA).
- N) Sicherstellen, daß Econo-Modus nicht auf dem Drucker treiber ist (SA).
- O) Sicherstellen, daß 300 dpi nicht im Druckertreiber eingestellt ist (SA).
- P) Andere Druckertreibereinstellungen bezüglich des "hel len Drucks" untersuchen und beheben (SA).
- Q) Sicherstellen, daß sich der Econo-Modus/Entwurfsmodus nicht mehr auf dem Steuerbedienfeld des Druckers be findet (SA).
- R) Sicherstellen, daß 300 dpi nicht auf dem Steuerbedien feld des Druckers eingestellt ist (SA).
- S) Sicherstellen, daß die Druckdichte auf dem Steuerbedi enfeld nicht zu niedrig eingestellt ist (SA).
- T) Datenfluß diagnostizieren (SA).
- U) Sicherstellen, daß ein moderner Druckertreiber, der die Spezifikationen erfüllt, verwendet wird (SA).
- V) Ist das Druckerwartungsset fällig? (Q)
- W) Stammt die Tonerkassette von einem unterstützen Her steller? (Q)
- X) Erscheint auf dem Steuerbedienfeld die Frage "Toner aus"? (Q)
- Y) Ist die Druckerkonfigurationsseite hell gedruckt? (Q)
Einige der obigen Schritte sind als Informationssammlungs
aktionen klassifiziert, z. B. Schritt B "Andere Tonerkas
sette verwenden". Wenn nach Ausführen von Schritt B das
Problem beseitigt ist, ist das Problem immer noch nicht ge
löst. Die wahrscheinliche Ursache des Problems ist identi
fiziert worden, es gibt jedoch weitere Untersuchungen, die
vorgenommen werden könnten, und die andere Tonerkassette
muß wahrscheinlich an den Platz zurückgebracht werden, wo
sie herstammt, d. h. das Problem ist nicht gelöst. Dies
gilt im allgemeinen für Schritte, die eine Druckerkomponen
te durch eine andere ersetzen - sind sie erfolgreich, ist
der Umfang der Diagnostik erheblich verringert worden. Es
stehen jedoch immer noch Schritte aus, die ausgeführt wer
den können, um das Problem vollständig zu lösen.
Schritt F in Tabelle 5 schlägt das Ausführen des Drucker
wartungssets (PM) vor, das jedesmal ausgeführt werden muß,
wenn eine bestimmte Seitenmenge gedruckt worden ist. Wenn
der PM-Set ausgeführt werden muß, gibt das Steuerungsbedi
enfeld des Druckers normalerweise eine Mitteilung heraus,
jedoch nicht unbedingt immer. Es ist eine gute Idee, zu
fragen, ob dies auf dem Steuerbedienfeld vorgeschlagen
wird, bevor das PM-Set vorgeschlagen wird, da das PM-Set
nur ausgeführt werden sollte, wenn es absolut notwendig
ist.
Schritt T in Tabelle 5 ist ein umfangreicher und kompli
zierter diagnostischer Schritt, der aus einer Reihe von
Teilschritten besteht, die versuchen zu bestimmen, ob die
Druckaufgabe irgendwo im Datenfluß korrumpiert wird, und
die die Quelle der Korruption identifizieren. Grundsätzlich
paßt das gesamte Datenflußmodell für eine korrupte Ausgabe,
die nachstehend beschrieben ist, zu Schritt T und seine da
zugehörige Ursache.
Bei einem Schritt 904 sind die Ursachen und die diagnosti
schen Schritte einander angepaßt. Die diagnostischen
Schritte sind den Ursachen, die sie lösen können, angepaßt.
Zusätzlich werden die Ursachen, die den Fragen zugeordnet
sind, identifiziert.
Bei diesem Schritt sind die Ursachen den diagnostischen
Schritten so angepaßt, daß die Aktionen den Ursachen, die
sie lösen können, angepaßt sind, und die Fragen den Ursa
chen, denen sie zugeordnet sind (d. h. deren Wahrschein
lichkeiten sie beeinflussen), angepaßt sind.
Für jede Aktion Ai wird für jede Ursache Cj in Betracht ge
zogen, ob eine Nicht-Null-Wahrscheinlichkeit besteht, daß
das Ausführen von Ai Cj lösen wird. Wenn dies so ist, be
steht eine Übereinstimmung, die für eine spätere Verwendung
im Wissensakquisitionsprozeß registriert wird.
Die Informationssammlungsaktionen können in nahezu ähnli
cher Weise wie die Lösungsaktionen gehandhabt werden. Ob
wohl sie nicht in der Lage sind, das Problem zu lösen, sind
sie immer noch in der Lage, das Problem vorübergehend zu
beseitigen, obgleich eine bestimmte Veränderung in der Um
gebung versucht wird. Zum Beispiel bewirkt bei Schritt B in
Tabelle 5 oben "Andere Tonerkassette verwenden", daß das
Problem verschwindet, wenn die Ursache die Teilursache 4a,
4b oder 4c ist, wie in der Tabelle oben aufgelistet ist.
Daher werden für Informationssammlungsaktionen die Ursa
chen, für die die Aktion das Problem beseitigt, wenn sie
ausgeführt wird, immer noch registriert.
Für jede Frage Qi wird für jede Ursache Cj in Betracht ge
zogen, ob eine Antwort auf Qi direkt die Überzeugung in Cj
beeinflussen wird (d. h. bewirken wird, daß die Wahrschein
lichkeit ab- oder zunimmt).
Fragen müssen die Überzeugungen von beliebigen Ursachen
überhaupt nicht beeinflussen, da sie manchmal verwendet
werden, um Informationen über das diagnostische Szenario,
den Anwendertyp etc. zu liefern, um verwandte Aktionen zu
ermöglichen/zu verhindern. Ein Beispiel dafür könnte eine
Frage über den Typ oder Hersteller von bestimmten Komponen
ten sein, wobei die Antwort auf dieselbe steuert, ob die
Komponente bestimmte Aktionen unterstützt. Daher beträgt
die Wahrscheinlichkeit, daß diese Aktionen erfolgreich
sind, Null, wenn der Hersteller der Komponente nicht vom
richtigen Typ ist.
Für das Problem des "hellen Druckes" ist die Anpassung von
Schritten und Ursachen, wie in Tabelle 6 unten gezeigt.
Nach jeder Aktion oder Frage werden die zugeordneten Ursa
chen (die an die Tabelle 4 oben angepaßt sind) aufgelistet:
Diagnostische Schritte | |
Ursache | |
A) Sicherstellen, daß sich das Medium innerhalb der Spezifikationen befindet (SA). | 1 |
B) Andere Tonerkassette verwenden, die sich innerhalb der Spezifikationen befindet (IA). | 4 |
C) Tonerkassette (SA) ausbauen, schütteln und 4b, 4c wieder einbringen. | 4b, 4c |
D) Übertragungsrolle erneut einpassen (SA). | 5b, 11a |
E) Unterschiedliches Medium verwenden (IA). | 1 |
F) Druckerwartungsset ausführen (SA). | 2, 5, 11a |
F) Drucker einem Leistungs-Ein-Ausschalten unterziehen (SA). | 11a |
G) Sicherstellen, daß sich die Umweltbedingungen innerhalb der Spezifikationen befinden (SA). | 3 |
H) Reinigen Sie das Innere des Druckers gemäß dem Benutzerhandbuch (SA). | 2, 4b, 11a |
I) Andere Übertragungsrolle, die sich innerhalb der Spezifikationen befindet, verwenden (IA). | 5, 11a |
K) Sicherstellen, daß sich Econo-Modus/Entwurfsmodus nicht mehr in der Anwendung befinden (SA). | 6a |
L) Sicherstellen, daß 300 dpi nicht in der Anwendung eingestellt ist (SA). | 6b |
M) Andere Anwendungseinstellungen bezüglich des "hellen Drucks" untersuchen und beheben (SA). | 6c |
N) Sicherstellen, daß Econo Modus nicht auf dem Druckertreiber ist (SA). | 7a |
O) Sicherstellen, daß 300 dpi nicht im Druckertreiber eingestellt ist (SA). | 7b |
P) Andere Druckertreibereinstellungen bezüglich des "hellen Drucks" untersuchen und beheben (SA). | 7c |
Q) Sicherstellen, daß sich der Econo-Modus/Entwurfsmodus nicht mehr auf dem Steuerbedienfeld des Druckers befindet (SA). | 8a |
R) Sicherstellen, daß 300 dpi nicht auf dem Steuerbedienfeld des Druckers eingestellt ist (SA). | 8b |
S) Sicherstellen, daß die Druckdichte auf dem Steuerbedienfeld nicht zu niedrig eingestellt ist (SA). | 8d |
T) Datenfluß diagnostizieren (SA). | 9 |
U) Sicherstellen, daß ein moderner Druckertreiber, der die Spezifikationen erfüllt, verwendet wird (SA). | 13 |
V) Ist das Druckerwartungsset fällig? (Q) | 2, 5, 5c |
W) Stammt die Tonerkassette von einem unterstützten Hersteller? (Q) | 4 |
X) Erscheint auf dem Steuerbedienfeld die Frage "Toner aus"? (Q) | 4, 4c |
Y) Ist die Druckerkonfigurationsseite hell gedruckt? (Q) | 1-5, 8, 11 |
In Tabelle 6 beeinflußt der diagnostische Schritt V laut
Domänenexperten die Überzeugungen der Ursachen 2, 5 und 5c.
Wenn das PM-Set fällig wird, besteht eine stärkere Anschau
ung bezüglich einiger der Ursachen, auf die durch das PM-
Set gezielt wird, d. h. (2) schmutziger Papierpfad, (5)
Übertragungsrollenprobleme im allgemeinen und (5c) abge
nutzte Übertragungsrolle im Besonderen.
Die Frage im diagnostischen Schritt Y fordert Informationen
über ein Symptom an - ob die Konfigurationsseite hell ge
druckt ist. Dies ist ein Symptom der Ursachen 1-5, 8 und
11. Diese Ursachen sind die Hardwareursachen, die noch in
Kraft sind, wenn die Konfigurationsseite gedruckt wird. Die
nicht spezifizierten Ursachen sind Softwareursachen, die
auf diese Situation keine Wirkung haben. Die Akquisition
von Wahrscheinlichkeiten für Fragen wird nachstehend weiter
beschrieben.
In einem Schritt 905 wird eine Prüfung vorgenommen, um zu
sehen, ob beliebige neue Ursachen oder Teilursachen identi
fiziert worden sind. Diese können z. B. beim Anpassen der
Ursachen und Schritte identifiziert werden. Wenn beliebige
neue Ursachen oder Teilursachen identifiziert werden, wird
zu Schritt 901 zurückgekehrt.
Beim Anpassen der Aktionen und Fragen an die Ursachen, de
nen sie zugeordnet sind, passiert es häufig, daß Ursachen
entdeckt werden, für die es keine Lösungsaktionen gibt, und
daß Aktionen entdeckt werden, die keine Ursachen lösen kön
nen, d. h. es gibt jeweils Aktionen und Ursachen, die feh
len. Wenn dies geschieht, ist es notwendig, zu Schritt 901
zurückzukehren.
In einem Schritt 906 wird eine Prüfung vorgenommen, um zu
sehen, ob neue diagnostische Schritte identifiziert worden
sind, z. B. beim Anpassen der Ursachen und Schritte. Wenn
es neue diagnostische Schritte gibt, die identifiziert wor
den sind, wird ein Sprung zurück zu Schritt 903 gemacht.
Die Ursachen und Schritte werden bei der anfänglichen Auf
listung häufig vergessen, und neue Ursachen und Schritte
werden häufig beim Anpassen der Ursachen an die Schritte
entdeckt. Daher ist es optimal, die Anpassung von Ursachen
und Schritten vor dem Herausholen der Wahrscheinlichkeiten
für Ursachen auszuführen, da dieses Herausholen teilweise
immer wieder jedesmal dann ausgeführt werden muß, wenn eine
neue Ursache entdeckt wird.
In einem Schritt 907 werden Wahrscheinlichkeiten von Ursa
chen und Teilursachen geschätzt. Wenn ein hoher Grad einer
Bestimmtheit vorhanden ist, daß alle Ursachen aufgelistet
worden sind, und Ursachen und Teilursachen in einer Hierar
chie strukturiert worden sind, sollten die Wahrscheinlich
keiten der Ursachen geschätzt werden. Dies wird normaler
weise von unten nach oben vorgenommen, so daß die Wahr
scheinlichkeiten der Teilursachen angesichts der Ursache
zuerst geschätzt werden und dann die Wahrscheinlichkeiten
der Ursachen angesichts des Problems.
Die Wahrscheinlichkeiten der Teilursachen werden zuerst ge
schätzt. Die Sätze der Teilursachen werden der Reihe nach
besucht, so daß eine separate Herausholung der Wahrschein
lichkeiten für jeden Satz von Teilursachen derselben Ursa
che ausgeführt wird. Die Wahrscheinlichkeiten der Teilursa
chen werden davon ausgehend, daß das Problem vorhanden ist
(z. B. "heller Druck") und daß die Ursache vorhanden ist
(z. B. "Tonerkassettenprobleme"), ausgelöst. Wenn alle
Wahrscheinlichkeiten der Teilursachen ausgelöst worden
sind, werden die Wahrscheinlichkeiten der Ursachen unter
der Annahme, daß das Problem vorhanden ist, ausgelöst.
Die Erfahrung hat gezeigt, daß dieses Verfahren der Wahr
scheinlichkeitsherausholung in hohem Maße effizient ist,
wenn die Wahrscheinlichkeiten hauptsächlich gegenüber der
kausalen Richtung ausgelöst werden (die Teilursachen die
Ursachen bewirken, und die Ursachen das Problem bewirken),
da es an die Domänenexperten maximale Informationen lie
fert, auf die sie ihre Wahrscheinlichkeiten stützen können,
da ihnen erlaubt wird, anzunehmen, daß das Problem und/oder
die Ursache vorhanden ist.
Die gewöhnliche Prozedur des Herausholens der Wahrschein
lichkeiten eines Satzes von Ursachen/Teilursachen verläuft
für einen Domänenexperten so, daß er die anfänglichen Wahr
scheinlichkeiten zu den meisten der Ursachen angesichts des
höheren Ursachenniveaus gibt - oder zumindest eine Rangord
nung erstellt (dies ist die höchste, dies ist die nächst
höchste etc.). Anschließend besprechen die Domänenexperten
die anfänglichen Wahrscheinlichkeiten oder Rangordnungen
und stellen diese infolge der Besprechungen ein. Wenn eine
endgültige Übereinstimmung erzielt worden ist, wird die
Herausholung geschlossen.
Die Unterschiede in der Überzeugung, die bei dem Herausho
lungsprozeß auftreten, bestehen fast immer aufgrund eines
Mangels an Wissen durch einen der Domänenexperten, und an
schließend bedarf es einer Diskussion, um zu entdecken,
welcher der Domänenexperten nicht Recht hatte. Meistens er
zielt man schnell eine Übereinstimmung, und die Wahrschein
lichkeiten werden angepaßt, um dies zu reflektieren. Gele
gentlich ist es jedoch notwendig, mit anderen Experten zu
konferieren, um diese Meinungsverschiedenheit zu klären.
Wenn die Meinungsverschiedenheit bezüglich der Wahrschein
lichkeiten sehr klein ist (z. B. 0,05), wird eine längere
Diskussion oft als nicht notwendig betrachtet und der
Durchschnitt gewählt. Wenn die Meinungsverschiedenheit je
doch sehr groß ist, ist es sehr wichtig, eine gemeinsame
Übereinkunft bezüglich der zugrundeliegenden Domänenstruk
tur zu treffen, da diese Übereinkunft bei zukünftigen Wahr
scheinlichkeitsherausholungen helfen kann.
Während des Prozesses der Herausholung wird ein Satz von
Wahrscheinlichkeiten für die in Betracht kommenden Ursachen
entwickelt. Dieser Satz von Wahrscheinlichkeiten muß nicht
notwendigerweise immer normiert werden (Summe auf 1,0). Es
gibt einen Grund, nicht flexibel zu sein und zu ermögli
chen, daß die Summe sich leicht von 1,0 unterscheidet, da
es den Prozeß erheblich verlangsamen würde, wenn eine Summe
von 1,0 die ganze Zeit über beibehalten werden müßte. Wenn
die Herausholung beendet ist, ist es einfach, die Wahr
scheinlichkeiten zu normieren.
Bei einem Projekt bevorzugten es die Domänenexperten, Pro
zentsätze anstelle von Wahrscheinlichkeiten herauszuholen,
so daß 10,0% anstelle von 0,1 etc. verwendet wurden. Dies
macht Sinn, da es einfacher ist, mit Zahlen im Bereich von
0 bis 100 als im Bereich von 0 bis 1 zu arbeiten, da dort
weniger Dezimalen vorhanden sind. Es ist ebenfalls wahr
scheinlich, daß sie beim Denken in Prozentsätzen verwendet
wurden.
Offensichtlich gibt es immer einen Betrag einer Unsicher
heit zweiter Ordnung bezüglich der herausgeholten Wahr
scheinlichkeiten. Ein Standardverfahren der Darstellung
dieser Unbestimmtheit zweiter Ordnung ist, Wahrscheinlich
keitsintervalle zu verwenden, so daß der Domänenexperte
seine/ihre Überzeugung, daß sich die Wahrscheinlichkeit in
nerhalb eines bestimmten Intervalls befindet, angibt. Wenn
sich die Domänenexperten dann bezüglich eines spezifischen
Intervalls geeinigt haben, gibt es Verfahren, die eine Ver
breitung der Wahrscheinlichkeitsintervalle in Bayes-
Netzwerken ermöglichen. Die Wiedergabe der Unbestimmtheit
zweiter Ordnung ermöglicht es dem Domänenexperten ausdrück
lich, Wahrscheinlichkeitsintervalle von unterschiedlicher
Größe für unterschiedliche Wahrscheinlichkeiten zu spezifi
zieren, und das automatisierte diagnostische System wäre
dann in der Lage, seine Schlußfolgerungen mit der geeigne
ten Unbestimmtheit anzugeben.
Für das Problem des "hellen Drucks" wurden die folgenden
Wahrscheinlichkeiten (in Prozentsätzen), wie nachstehend in
Tabelle 7 aufgeführt, ausgelöst:
Beim Schritt 908 werden Wahrscheinlichkeiten der Aktionen
und Fragen geschätzt.
Bei dem bevorzugten Ausführungsbeispiel gibt es zwei Typen
von Fragen, diejenigen, die zu den Symptomen oder Auswir
kungen der Ursachen gehören und allgemeine Fragen, die na
türlicherweise nicht als ein Symptom oder eine Auswirkung
betrachtet werden. Die Wissensakquisitionsprozesse für die
zwei Typen von Fragen sind unterschiedlich, so daß es wich
tig ist, den Typ der Frage zu bestimmen, bevor die Wahr
scheinlichkeiten für dieselbe ausgelöst werden. Der Unter
schied zwischen diesen zwei Typen von Fragen wird nachste
hend weiter ausgeführt.
Für allgemeine Fragen sind die Ursachen, die der Frage zu
geordnet sind, zuvor aufgelistet worden, d. h. die Ursa
chen, die ihre Wahrscheinlichkeiten abhängig von der Ant
wort auf die Frage verringern oder erhöhen. Für diesen Typ
von Fragen ziehen die Domänenexperten jede Antwort auf die
Frage (z. B. ja, nein etc.) in Betracht und schätzen, wie
viele der Wahrscheinlichkeiten der beeinflußten Ursachen
basierend auf den neuen Informationen ab- oder zunehmen.
Die Herausholung erfolgt sehr ähnlich derjenigen für die
Ursachen - es kann Unstimmigkeiten bei der Übereinstimmung
geben, die durch Diskussionen gelöst werden müssen.
Die Domänenexperten konzentrieren sich auf die Ursachen,
die durch die Antwort auf die Frage beeinflußt werden, da
her werden die Wahrscheinlichkeiten der Ursachen, die nicht
beeinflußt werden, nicht durch die Experten modifiziert.
Die Tatsache, daß andere Ursachen ihre Wahrscheinlichkeiten
erhöhen oder verringern, wird jedoch dazu führen, daß die
Wahrscheinlichkeiten der verbleibenden sich dementsprechend
ändern, so daß die Summe immer noch 1,0 beträgt. Es ist für
die Experten deutlich einfacher, nur die Wahrscheinlichkei
ten anzupassen, die direkt betroffen sind, und dann den
Rest dementsprechend verändern zu lassen, als daß die Ex
perten Veränderungen in allen Wahrscheinlichkeiten bewerten
müßten. Man hat auch die Erfahrung gemacht, daß die Exper
ten damit zufrieden waren, die verbleibenden Wahrschein
lichkeiten dementsprechend verändern zu lassen.
Bei dem Problem "heller Druck" wurden die Wahrscheinlich
keiten (in Prozentsätzen), wie in Tabelle 8 nachstehend
aufgeführt, angesichts der Antwort auf die Frage "Sehen Sie
den Hinweis 'Toner leer' auf dem Steuerbedienfeld?" ange
paßt:
Daher wird die Wahrscheinlichkeit der "Tonerkassettenpro
bleme", die die Ursache des Problems sind, auf 0,9 angeho
ben, wenn bekannt ist, daß das Steuerbedienfeld des Druc
kers anzeigt, daß der Toner leer ist. Da die Wahrschein
lichkeit der Teilursache "Tonerverteilung" verglichen mit
den anderen Teilursachen von "Tonerkassettenprobleme" be
reits hoch ist, wurde beschlossen, diese Wahrscheinlichkeit
nicht weiter zu erhöhen.
In ähnlicher Weise, da bekannt ist, daß das Steuerbedien
feld nicht die Anzeige "Toner leer" anzeigt, wurde be
schlossen, die Wahrscheinlichkeit der Teilursache "Toner
verteilung" von 0,85 auf 0,25 zu verringern. Es wurde je
doch beschlossen, die Gesamtwahrscheinlichkeit der "Toner
kassettenprobleme" bei 0,35 zu belassen, auch wenn bekannt
ist, daß das Steuerbedienfeld nicht "Toner leer" anzeigt.
Für allgemeine Fragen müssen die Domänenexperten ebenfalls
vorherige Wahrscheinlichkeiten für die Antworten auf die
Frage angeben. Es wird nachstehend erläutert, wie zu prüfen
ist, ob die Experten inkonsistente Informationen für allge
meine Fragen durch Analysieren der unbedingten Wahrschein
lichkeit der zugeordneten Ursachen P(C), der bedingten
Wahrscheinlichkeit P(C|Q) und der Vorherigen bezüglich der
Frage P(Q), d. h. durch Vergleichen von ΣQP(C|Q)P(Q) mit
P(C), spezifiziert haben.
Für Fragen über Symptome, sind die Ursachen, die der Frage
zugeordnet sind, im Schritt 904, der in Fig. 4 gezeigt und
nachstehend beschrieben ist, d. h. die Ursachen, die das in
Frage kommende Symptom bewirken, aufgelistet. Hier besteht
die Herausholung darin, jeder der zugeordneten Ursachen die
Wahrscheinlichkeit des Symptoms angesichts der Ursache zu
geben. Die Wahrscheinlichkeit, daß das Symptom auftritt,
wenn keine der spezifizierten Ursachen vorhanden ist, soll
te ebenfalls geschätzt werden.
Bei dem Problem "heller Druck" (Frage Y in Tabelle 5) ist
"Ist die Konfigurationsseite hell gedruckt?" eine Symptom
frage. Die Wahrscheinlichkeiten (in Prozentsätzen) wurden
wie in Tabelle 9 unten bewertet:
Die Wahrscheinlichkeit (als Prozentsatz) des Symptoms, wenn
keine der spezifizierten Ursachen vorhanden ist, beträgt 1.
Daher haben die Domänenexperten bewertet, daß z. B., wenn
die Ursache eine inkorrekte Steuerbedienfeldeinstellung ist
(Ursache 8 in Tabelle 9 oben), eine Wahrscheinlichkeit von
1,0 (100%) besteht, daß die Konfigurationsseite hell ge
druckt wird, und in ähnlicher Weise, wenn die Ursache ent
weder das Medium, der Papierpfad oder die Umweltbedingungen
etc. sind.
Wenn die Ursache ein "anderes Problem" ist, bewerteten die
Experten, daß die Konfigurationsseite mit einer Wahrschein
lichkeit von 0,5 hell gedruckt werden würde. Der Grund die
ser Wahrscheinlichkeit ist nicht 1,0, sondern, daß einige
temporäre und permanente Probleme keine Auswirkung auf das
Drucken der Konfigurationsseite haben.
Die Domänenexperten wollten die Möglichkeit nicht vollstän
dig ausschließen, daß die Konfigurationsseite hell gedruckt
werden könnte, auch wenn keine der oben spezifizierten Ur
sachen vorhanden waren, daher beließen sie es für diese Si
tuation bei einer Wahrscheinlichkeit von 0,01.
Für Aktionen ist es notwendig, die Wahrscheinlichkeit zu
bestimmen, daß die Aktion das Problem, angesichts jeder der
Ursachen, die im Schritt 904 von Fig. 4 aufgelistet sind,
löst. Man nimmt an, daß diese Ursachen die Ursachen sind,
die die Aktion potentiell lösen kann.
Die diagnostischen Algorithmen benötigen die Wahrschein
lichkeit der Aktionen, die das Problem angesichts der zuvor
erhaltenen Informationen über das Problem lösen, so daß die
Domänenexperten für jede aufgelistete Ursache Ci unter der
Annahme, daß Ci die einzige Ursache des in Frage kommenden
Problems ist, antworten müssen, was die Wahrscheinlichkeit
ist, daß das Ausführen der Aktion das Problem löst?
Die Erfahrung hat gezeigt, daß zu viele Dinge beim Ein
schätzen dieser Wahrscheinlichkeit in Betracht gezogen wer
den müssen, d. h. sowohl die tatsächliche Wahrscheinlich
keit, daß die Aktion das Problem löst, wenn sie korrekt
ausgeführt wird, als auch die Wahrscheinlichkeit, daß die
Aktion korrekt ausgeführt wird. Wenn zu viele Dinge in Be
tracht gezogen und gleichzeitig berücksichtigt werden müs
sen, sind Wahrscheinlichkeiten einer niedrigen Qualität das
Ergebnis.
Die Schätzungen werden von höherer Qualität sein, wenn die
vorstehende Herausholung in zwei WahrscheinlichkeitsHeraus
holungsfragen aufgeteilt wird. Die erste Wahrscheinlich
keitsHerausholungsfrage ist, angenommen, daß Ci die einzige
Ursache des in Frage kommenden Problems ist, was die Wahr
scheinlichkeit ist, daß ein korrektes Ausführen der Aktion
das Problem löst? Die zweite Wahrscheinlichkeitsherausho
lungsfrage ist, daß, angenommen, daß Ci die einzige Ursache
des in Frage kommenden Problems ist, was die Wahrschein
lichkeit ist, daß der Anwender die Aktion unrichtig aus
führt, ohne es zu erkennen?
Beim Beantworten der ersten WahrscheinlichkeitsHerausho
lungsfrage können die Domänenexperten annehmen, daß die Ak
tion korrekt ausgeführt wird, und daher ist es einfacher,
die Wahrscheinlichkeit, daß sie das Problem löst, zu bewer
ten. Beim Beantworten der zweiten WahrscheinlichkeitsHer
ausholungsfrage können sich die Domänenexperten darauf kon
zentrieren, die Wahrscheinlichkeit zu bewerten, daß der An
wender die Aktion unrichtig ausführt.
Es ist wichtig, die Wahrscheinlichkeit zu bewerten, daß der
Anwender die Aktion unrichtig ausführt, ohne dies zu bemer
ken, und nicht die Gesamtwahrscheinlichkeit, daß die Aktion
unrichtig ausgeführt wird. Diese Wahrscheinlichkeit wird
benötigt, um die Möglichkeit einer unrichtigen Rückmeldung
vom Anwender darzustellen. Die unrichtige Rückmeldung wird
in der Situation erhalten, wenn der Anwender nicht reali
siert, daß er die Aktion inkorrekt ausgeführt hat. Daher
ist der Fall, wenn der Anwender nicht erkennt, daß er die
Aktion unrichtig ausgeführt hat, nicht in der Wahrschein
lichkeit enthalten. In diesen Situationen wird der Anwender
keine unrichtige Rückmeldung eingeben, sondern wird wahr
scheinlich versuchen, die Aktion erneut auszuführen oder
eine Eingabe vornehmen, daß er nicht in der Lage war, die
Aktion auszuführen.
Wenn die gefundene Wahrscheinlichkeit beim Beantworten der
ersten WahrscheinlichkeitsHerausholungsfrage mit P1 be
zeichnet wird und die gefundene Wahrscheinlichkeit beim Be
antworten der zweiten WahrscheinlichkeitsHerausholungsfrage
mit P2 bezeichnet wird, wird anschließend die Gesamtwahr
scheinlichkeit der Aktion, die das Problem angesichts der
Ursache Ci löst, folgendermaßen festgestellt:
P(A = ja|Ci = ja) = P1 (1 - P2)
Die Erfahrung hat gezeigt, daß bei der bewerteten Wahr
scheinlichkeit beim Beantworten der zweiten Wahrscheinlich
keitsHerausholungsfrage eine geringe Variabilität besteht,
die auch als Ungenauigkeit der Anwenderantwort bezeichnet
wird. Daher war es ausreichend, für die Ungenauigkeit unter
Verwendung des Bereichs 0 - sehr gering, 1 - gering, 2 -
mittel, 3 - hoch, 4 - sehr hoch einen Faktor zwischen 0 und
4 einzuschätzen. Dieser Ungenauigkeitsfaktor kann dann zu
einer Wahrscheinlichkeit wie in Tabelle 10 unten konver
tiert werden:
VL: | 0 |
L: | 2% |
M: | 5% |
H: | 10% |
VH: | 20% |
Die Umwandlung der Ungenauigkeitsfaktoren in Wahrschein
lichkeiten kann durch eine Reihe von Fragen an die Domä
nenexperten bestimmt werden.
Es gibt ein paar weitere Annahmen, die beim Bewerten der
Aktionswahrscheinlichkeiten vorgenommen werden müssen.
Wenn bestimmte Voraussetzungen zum Ausführen einer Aktion
notwendig sind, wird immer davon ausgegangen, daß sie zur
Verfügung stehen, wenn die Aktion vorgeschlagen wird. Daher
ist es nicht notwendig, die Verfügbarkeit von Voraussetzun
gen beim Bewerten der Wahrscheinlichkeit, daß eine Aktion
das Problem lösen wird, zu berücksichtigen. Die Verfügbar
keit von Voraussetzungen wird gehandhabt, indem man dem An
wender ermöglicht, eine Aktion zu überspringen, indem er
berichtet, daß er nicht in der Lage ist, diese auszuführen,
oder diese nicht ausführen möchte.
Wenn eine Aktion das Ersetzen einer verdächtigen Komponente
durch eine andere umfaßt, besteht eine geringe Chance, daß
die neue Komponente fehlerhaft ist und das gleiche Problem
verursacht. Auch wenn diese Wahrscheinlichkeit oft vernach
lässigbar ist, ist es notwendig, dieselbe beim Bewerten der
Wahrscheinlichkeit, daß eine Aktion das Problem löst, in
Betracht zu ziehen. Wenn die Ersatzkomponente fehlerhaft
ist und das gleiche Problem verursacht, gibt der Anwender
in das diagnostische System ein, daß die Aktion nicht ge
holfen hat. Das System sollte dann die Ursachen, die die
Aktion lösen kann, nicht vollständig ausschließen, da die
Ersatzkomponente fehlerhaft gewesen sein könnte.
Wie oben erläutert, macht man eine Unterscheidung zwischen
Lösungsaktionen und Informationssammlungsaktionen. Auch
wenn Informationssammlungsaktionen das Problem nicht lösen
können, werden die Wahrscheinlichkeiten in fast exakt der
selben Weise gesammelt. In der Praxis, auch wenn Informati
onssammlungsaktionen nicht das Problem lösen können, führen
sie ein Experiment am System durch, um zu sehen, ob das
Problem verschwindet, wenn die Konfiguration verändert
wird. Die erste WahrscheinlichkeitsHerausholungsfrage oben
sollte dann etwas anders gestellt werden: Angenommen, daß
Ci die einzige Ursache des in Fra 59502 00070 552 001000280000000200012000285915939100040 0002010161332 00004 59383ge kommenden Problems ist,
was ist die Wahrscheinlichkeit, daß ein korrektes Ausführen
der Aktion das Problem in der neuen Konfiguration ver
schwinden läßt?
Für das Problem des "hellen Drucks" sehen die Wahrschein
lichkeiten der Aktionen aus, wie sie in der Tabelle 11 un
ten aufgeführt sind. Nach jeder Aktion sind die zugeordne
ten Ursachen und die Wahrscheinlichkeit, daß die Aktion
diese lösen wird, aufgelistet. Die Ungenauigkeitsfaktoren
werden später besprochen.
Bei einem Schritt 909 werden die Kosten der Aktionen und
Fragen geschätzt.
Bei den diagnostischen Algorithmen ist es notwendig, die
Kosten zum Ausführen der Aktionen und Fragen zu kennen, um
bestimmen zu können, welcher Schritt optimal ist, um als
nächster ausgeführt zu werden. Die Kosten können entweder
als einzelner Faktor oder als eine Kombination von mehreren
Faktoren geschätzt werden. Da die Kosten in Wirklichkeit
aus mehreren signifikanten Faktoren bestehen, scheint es
der zuverlässigste und genauste Lösungsansatz zu sein, je
den dieser Faktoren getrennt zu bewerten und dann die Fak
toren zu einem einzelnen Kostenfaktor zu kombinieren. Die
Kosten bestehen aus vielen Faktoren. Vier von ihnen, die
die bedeutsamsten zu sein scheinen, werden nachstehend be
schrieben.
Der erste Faktor ist Zeit: Die (in Minuten), die zum Aus
führen eines Schrittes notwendig ist. Die Zeit, die bei der
Arbeit aufgewendet wird, wird von der Zeit, die mit Warten
verbracht wird, unterschieden, wobei die Wartezeit geringer
als die Arbeitszeit gewichtet wird, was darauf hinweist,
daß einem Schritt, der 10 Minuten dauert, die überwiegen
dend mit Warten verbracht werden, geringere Kosten einge
räumt werden als einem Schritt, der 10 Minuten dauert, die
mit konstanter Arbeit verbracht werden. Beim Schätzen der
Zeit wird diese im Hinblick auf die Anwenderpopulation ge
mittelt. Es gibt erfahrene Anwender, die bestimmte Schritte
schneller als andere ausführen können, jedoch muß die end
gültige Zeitschätzung im Hinblick auf alle Typen von Anwen
dern gemittelt werden.
Der zweite Faktor ist das Risiko: das Risiko (sehr gering,
gering, mittel, hoch oder sehr hoch) des Kaputtmachens oder
Zerstörens einer anderen Komponente beim Ausführen des
Schritts. Das Risiko ist beim Vorschlagen von Schritten
sehr relevant, da es wünschenswert ist, die Schritte mit
dem geringsten Risiko des Kaputtmachens einer anderen Kom
ponente vor Schritten mit einem höheren Risiko vorzuschla
gen. Das Risiko muß wiederum gegenüber der Anwenderpopula
tion gemittelt werden, wenn sowohl erfahrene Anwender mit
einem geringen Risiko des Kaputtmachens einer Komponente
als auch Neuanwender mit einem höheren Risiko vorhanden
sind.
Der dritte Faktor ist Geld: der Geldbetrag (sehr gering,
gering, mittel, hoch oder sehr hoch), der notwendig ist, um
die Voraussetzungen eines Schrittes zu erwerben. Es gibt
Schritte, bei denen eine hohe Wahrscheinlichkeit besteht,
daß die Anwender nicht alle erforderlichen Voraussetzungen
aufweisen und diese erwerben müssen; und diesen Schritten
sollten höhere Kosten zugewiesen werden als ähnlichen
Schritten ohne Voraussetzungen. Der Geldbetrag, der für ei
nen Schritt erforderlich ist, muß wiederum gegenüber der
Anwenderpopulation gemittelt werden. Abhängig vom Anwender
typ verfügen einige Anwender eventuell über die notwendigen
Voraussetzungen, wohingegen andere diese erwerben müssen.
Der vierte Faktor ist Beleidigung: der Grad der Beleidi
gung, den der Anwender erfährt, wenn ihm ein Schritt vorge
schlagen wird (sehr gering, gering, mittel, hoch oder sehr
hoch). Wenn einem erfahrenen Anwender ein Schritt für An
fänger vorgeschlagen wird (z. B. 'Prüfen Sie, ob der Druc
ker eingesteckt ist.'), kann er sich eventuell beleidigt
fühlen. Daher werden für einen solchen Schritt leicht höhe
re Kosten eingeräumt, um zu ermöglichen, daß weniger belei
digende Schritte zu einem früheren Zeitpunkt der Sequenz
vorgeschlagen werden.
Es gibt mehrere andere Kostenfaktoren, die berücksichtigt
werden können, wie z. B. die Umständlichkeit beim Ausführen
eines Schritts. Die Erfahrung hat jedoch bewiesen, daß nur
für die obigen vier Faktoren ein echter Bedarf besteht. Die
Umständlichkeit eines Schritts wird teilweise durch die
Zeit und das Risiko (falls er umständlich ist, wird er
wahrscheinlich längere Zeit dauern und riskanter sein), je
doch auch durch die Fähigkeit berücksichtigt, einen Schritt
zu überspringen.
Die Kostenfaktoren müssen in einer einzigen Ziffer kombi
niert sein, um für die diagnostischen Algorithmen von Nut
zen zu sein. Um dies zu tun, müssen die Risiko-, Geld- und
Beleidigungsfaktoren in Zahlen umgewandelt und die vier
Faktoren letztendlich abgeglichen und addiert werden. Um zu
bestimmen, wie dabei vorzugehen ist, müssen viele Experi
mente mit den Domänenexperten durchgeführt werden, wobei
sie gebeten werden, Schritte, die sich bezüglich des Ko
stenfaktors unterscheiden, zu ordnen. Anhand eines ausrei
chenden Betrags solcher Experimente können die Umwandlungs
faktoren und Gewichte bestimmt werden. Ein solches Experi
ment könnte z. B. sein:
Welche von zwei Aktionen mit gleicher Wahrscheinlichkeit,
das Problem zu lösen, würden Sie zuerst vorschlagen wollen?
A1, wenn Zeit = 20, Risiko = mittel
A2, wenn = 10, Risiko = hoch
A2, wenn = 10, Risiko = hoch
Für die Drucksystemdomäne ist die Umwandlung des Risikofak
tors zu einer Zahl, die mit der Zeit vergleichbar ist,
nachstehend in Tabelle 12 aufgeführt:
sehr gering | 0 |
gering | 1 |
mittel | 2 |
hoch | 4 |
sehr hoch | 8 |
Die resultierende Zahl wird mit 9 multipliziert, d. h. ein
0-Minuten-Schritt mit sehr hohem Risiko ist gleich einem
72-(8 × 9)-Minuten-Schritt mit sehr geringem Risiko.
Die Umwandlung des Geldfaktors in eine Zahl, die mit der
Zeit vergleichbar ist, ist nachstehend in Tabelle 13 aufge
führt:
sehr gering | 0 |
gering | 1 |
mittel | 3 |
hoch | 10 |
sehr hoch | 30 |
Die resultierende Zahl in Tabelle 13 wird mit 10 multipli
ziert, d. h. ein 0-Minuten-Schritt mit einem Geldfaktor von
sehr hoch ist gleich einem 300-(30 × 10)-Minuten-Schritt
bei einem Geldfaktor von sehr gering.
Der Beleidigungsfaktor wurde nur in seltenen Gelegenheiten
beim Drucksystemprojekt verwendet, daher wurde eine volle
Umwandlung nicht definiert. Wenn ein Beleidigungsfaktor von
gering spezifiziert wurde, wurde dieser in 10 umgewandelt.
Für das Problem "heller Druck" werden die Ungenauigkeits-
und Kostenfaktoren wie in Tabelle 14 unten (in der Reihen
folge Ungenauigkeit, Zeit, Risiko, Geld und Beleidigung)
aufgeführt:
Bei einem Schritt 910 werden Aktionen und Fragen, die eine
spezielle Handhabung erfordern, identifiziert und bearbei
tet.
Es gibt mehrere Teile von zusätzlichen Informationen, die
für das diagnostische Modell spezifiziert werden müssen, um
ein diagnostisches System zu erhalten, das nach Wunsch ar
beitet. Diese werden zusammen als Aktionen und Fragen be
zeichnet, die einer speziellen Handhabung bedürfen.
Eine von diesen sind die anfänglichen Schritte. Für einige
Probleme gibt es vorgegebene Ursachen, die anfänglich aus
geschlossen werden sollten, da es für den Kunden beleidi
gend ist, zu einem späteren Zeitpunkt mit deren Untersu
chung beginnen zu müssen. Zum Beispiel ist es beim Fehler
code "Ablage 2 anheben" möglich, daß der Anwender einfach
nicht ausreichend lange gewartet hat, bis sich die Ablage
gehoben hat, da dies eine Weile dauern kann. Daher ist es
von Vorteil, zuerst zu fragen, ob der Anwender lange genug
gewartet hat, und wenn nicht, ihm zu befehlen, dies zu tun.
Es gibt keinen Grund, diese Schritte in die gewöhnliche
Auswahl der diagnostischen Schritte einzuschließen, da sie
immer zuerst vorgenommen werden sollten. Die Domänenexper
ten sollte Schritte dieses Typs identifizieren und als sol
che markieren.
Ein weiterer Teil von Informationen, die zu spezifizieren
sind, sind Workarounds. Aktionen können als Workarounds
klassifiziert werden, die bedeuten, daß sie das Problem
zwar lösen können, die Lösung dazu jedoch nicht zufrieden
stellend sein kann, z. B. das Lösen eines Problems mit un
zureichendem Speicher durch das Drucken kleinerer Aufgaben.
Wenn eine Aktion als ein Workaround klassifiziert ist, wird
der Anwender gefragt, ob er mit der Lösung zufrieden ist,
wenn das Workaround hilft.
Ein weiterer Teil von Informationen, die spezifiziert wer
den müssen, ist das Austauschen von Komponenten. Wenn bei
einer Aktion eine Komponente durch eine andere ausgetauscht
wird, ist es wichtig, dies zu registrieren, da dann das au
tomatisierte diagnostische System in der Lage sein wird,
Situationen zu handhaben, in denen die Komponente nicht
richtig eingepaßt war. Wenn das Austauschen einer Komponen
te durch eine andere funktioniert, kann dies daran liegen,
daß die Komponente zuerst nicht richtig eingepaßt war, da
her sollte das diagnostische System den Anwender auffordern
zu versuchen, die alte Komponente erneut einzubringen, um
dies zu verifizieren.
Ein anderer Teil von Informationen, die spezifiziert werden
sollen, sind irreversible Aktionen. Wenn eine Aktion das
Problem lösen kann, die Ursache jedoch nicht vollständig
identifiziert worden ist, wird der Anwender gebeten, ob er
die Diagnostik fortsetzen möchte. Wenn er der Fortsetzung
zustimmt, muß er die letzte Aktion stornieren, so daß das
Problem wieder auftaucht. Wenn die zuletzt ausgeführte Ak
tion irreversibel ist (z. B. das Rebooten des PCs, das Lei
stungs-Ein-Ausschalten des PCs), ist dies nicht möglich. In
dieser Situation sollte der Anwender nicht gefragt werden,
ob er die Diagnostik fortsetzen möchte, da dies nicht mög
lich ist. Daher sollte der Domänenexperte Aktionen regi
strieren, die irreversibel sind.
Ein weiterer Teil von Informationen, die zu spezifizieren
sind, sind eingeschlossene Aktionen. Aktionen können andere
Aktionen einschließen. Es ist z. B. typisch, daß Aktionen
das Vornehmen eines Leistungs-Ein-Ausschalten am Drucker
umfassen, so daß, wenn eine solche Aktion ausgeführt worden
ist, dem Diagnostiker später nicht vorgeschlagen werden
sollte, den Drucker erneut einem Leistungs-Ein-Ausschalten
zu unterziehen. Daher sollten die Domänenexperten regi
strieren, wenn eine Aktion andere Aktionen umfaßt.
Ein weiterer Teil von Informationen, die zu spezifizieren
sind, sind Sonderfall-Schritte. Es gibt Schritte, die nur
in Sonderfällen vorgeschlagen werden sollten, z. B. nachdem
eine spezifische Frage mit einer spezifischen Antwort be
antwortet worden ist, oder nur wenn eine spezifische Frage
nicht mit einer spezifischen Antwort beantwortet worden
ist. Zum Beispiel gibt es in der Drucksystemdomäne speziel
le herstellerspezifische Aktionen, die nicht vorgeschlagen
werden sollten, wenn der Hersteller einer Komponente veri
fiziert worden ist.
Ein anderer Teil von Informationen, die zu spezifizieren
sind, ist Beständigkeit. Beständigkeit bezieht sich auf das
Problem von alten Beobachtungen, die sich durch später aus
geführte Aktionen als ungültig erwiesen haben. Es gibt häu
fig Situationen mit einer Frage Q und einer Aktion A, wenn
Q den Status irgendeiner Eigenschaft des Systems anfordert
und wenn der Status nicht der gewünschte ist, wird Aktion A
vorgeschlagen, um dies zu beheben. Die Diagnostik kann mit
der Beobachtung, daß Q sich im unerwünschten Zustand befin
det, nicht fortgesetzt werden. Der Zustand von Q wird modi
fiziert, um sicherzustellen, daß das diagnostische System
auf gültigen Informationen operiert. Diese Situation kann
bewältigt werden, indem man Domänenexperten Situationen re
gistrieren läßt, in denen es Frage-Antwort-Paare Q und A
gibt, so daß das Ausführen von A Q in einem spezifischen
Zustand behebt. Das diagnostische System weiß dann, wie Q
in diesem Zustand automatisch zu beheben ist, wenn A ausge
führt wird, ungeachtet dessen, als was Q zuvor beobachtet
worden ist. Offensichtlich ist dies noch immer eine angenä
herte Lösung, da sie nicht in die Berechnung der geschätz
ten Reparaturkosten (ECR; ECR = expected cost of repair)
integriert ist.
Das nachstehend beschriebene Verfasserwerkzeug ermöglicht
Experten in einer Domäne (z. B. Drucksystemen, Netzwerksy
stemen etc.), ohne weiteres an Wissen über die Domäne zu
gelangen. Anhand dieses Wissens wird ein automatisiertes
diagnostisches System erzeugt, das Anfängern
/Nichtexpertenanwendern dabei hilft, Probleme in der model
lierten Domäne zu diagnostizieren.
Das Verfasserwerkzeug nutzt Grundsätze der Objektorientie
rung durch Anordnen der Informationen in Modulen entspre
chend physischen Komponenten in der Domäne. Durch erneutes
Verwenden dieser Module in mehreren diagnostischen Systemen
können Vorteile, wie z. B. geringere Zeitanforderungen, er
höhte Konsistenz und verringerte Wartungszeiten erreicht
werden.
Das Verfasserwerkzeug implementiert im wesentlichen den
Wissensakquisitionsprozeß, der vorstehend beschrieben ist.
Hier wird der Anwender des Verfasserwerkzeugs als Verfasser
bezeichnet. Die Anwender von diagnostischen Systemen, die
mit dem Verfasserwerkzeug erzeugt werden, werden Diagnosti
ker oder manchmal einfach nur Anwender bezeichnet. Die Pro
blemdomäne, die im Verfasserwerkzeug modelliert wird, wird
auch als die Vorrichtung oder das in Frage kommende System
bezeichnet. Die interne Darstellung des diagnostischen Sy
stems im Verfasserwerkzeug wird als das Modell oder die
diagnostische Systemspezifikation (DSS) bezeichnet.
Das Verfasserwerkzeug wird verwendet, um einen Satz von
diagnostischen Systemen in einer einzelnen Domäne zu erzeu
gen. Für diese Domäne kann nicht angenommen werden, daß ein
großer Betrag von Überlappung vorhanden ist, so daß viele
Module wieder verwendet werden können. Zum Beispiel ist die
Fixiererkomponente in der Druckerdomäne eine Ursache bei
vielen Fehlerbedingungen, wie z. B. Punkten, schlechte Fi
xierung etc. Für jede Fehlerbedingung in der Domäne wird
ein komplettes diagnostisches Modell verwendet. Man nimmt
an, daß der Diagnostiker die Fehlerbedingung genau identi
fizieren kann, die er gerade erfährt, und folglich kann das
zugeordnete diagnostische System ausgewählt werden.
Eine Bibliothek von Modulen wird im Verfasserwerkzeug auf
gebaut. Da diese Bibliothek anwächst und mehr Module hinzu
gefügt werden, ist es einfacher, neue diagnostische Modelle
zu erzeugen.
Die übliche Art und Weise, das Verfasserwerkzeug zu benut
zen, ist zuerst eine paar diagnostische Modelle zu erzeu
gen. Anhand dieser werden die ersten Module in der Biblio
thek für eine spätere Wiederverwendung erzeugt. Wenn mehr
und mehr diagnostische Modelle hinzugefügt werden, können
mehr und mehr Module erzeugt werden, und die vorhandenen
Module können verbessert und vergrößert werden.
Fig. 5 zeigt eine Hauptschnittstelle 50 für das Verfasser
werkzeug. Die Hauptschnittstelle 50 ist in zwei Seiten auf
geteilt. Eine Seite 51 funktioniert als ein diagnostischer
Modelleditor und wird zum Editieren von diagnostischen Mo
dellen verwendet. Eine Seite 52 umfaßt eine Liste von Bi
bliotheksmodulen und einen Bibliotheksmoduleditor. Der Bi
bliotheksmoduleditor wird zum Editieren von Bibliotheksmo
dulen verwendet. Der diagnostische Modelleditor und der Bi
bliotheksmoduleditor weisen beinahe die gleiche Funktiona
lität auf. Beide ermöglichen die Erzeugung von neuen Ursa
chen, Aktionen und Fragen, das Editieren von vorhandenen
Ursachen, Aktionen und Fragen, das Editieren von Wahr
scheinlichkeiten von all diesen und das Exportieren und Im
portieren von Elementen aus dem anderen Editor.
In einem Bereich 53 ermöglicht der diagnostische Modelledi
tor der Hauptschnittstelle 50 ferner ein Laden einer neuen
diagnostischen Spezifikation (DSS), ein Schließen der aktu
ellen DSS, ein Starten einer neuen DSS und ein Sichern der
DSS in verschiedenen Formaten, die später beschrieben wer
den. In einem Bereich 54 ermöglicht der Bibliothekmoduledi
tor der Hauptschnittstelle 50 ferner ein Sichern eines Mo
duls, ein Erzeugen eines neuen Moduls, ein Löschen eines
Moduls, ein Umbenennen eines Moduls, Übersichten über alle
Ursachen, Aktionen und Fragen zum schnellen Suchen und die
Spezifikation von Kategorien von Ursachen, die unten weiter
beschrieben sind.
Die Bausteine des Verfasserwerkzeugs sind die Bibliotheks
module, die auch Module genannt werden. Die Module entspre
chen den physischen Komponenten in der Domäne, die in Be
tracht kommt, oder Bereichen von Informationen, die eng
miteinander verwandt sind, wie z. B. der Software. Bei dem
bevorzugten Ausführungsbeispiel sind die Module so angeord
net, daß alle Ursachen im Modul gelöst werden, wenn die
physische Komponente, die dem Module entspricht, durch eine
funktionierende Komponente ausgetauscht wird. Wenn die Mo
dule in dieser Weise angeordnet sind, ist eine optimale
Wiederverwendung möglich, d. h. für Fehlerkonditionen, die
das Modul involvieren, können gewöhnlich alle Ursachen im
Modul verwendet werden. Für manche Fehlerkonditionen gibt
es aber Ursachen im Modul, die entfernt werden müssen, da
sie nicht mit dem Fehler verwandt sind.
Die Module werden von Anfang an im Verfasserwerkzeug durch
Erzeugen einer Reihe von neuen Ursachen, Aktionen und Fra
gen, die sich auf diese Ursachen beziehen, erzeugt. Alter
nativ werden Module durch Importieren von Stücken von fer
tiggestellten diagnostischen Modellen erzeugt.
Alle Module sind in der Bibliothek enthalten. Es gibt eine
Bibliothek für jede Domäne, die in Frage kommt, z. B.
Drucksysteme, Autos etc.
Wenn ein Modul verändert wird, wird die Veränderung auf al
le Fehlerkonditionen, in denen das Modul verwendet worden
ist, ausgeweitet.
Ein neues diagnostisches Modell wird erzeugt, indem zuerst
die Module kombiniert werden, die jenen physischen Kompo
nenten oder logischen Bereichen entsprechen, von denen man
annimmt, daß sie eine Wirkung auf die Fehlerkondition ha
ben. Einige Ursachen und diagnostische Schritte in diesem
Modul können ohne Beziehung sein und müssen entfernt wer
den. Wenn die Konstruktion des Modells fertiggestellt ist,
gibt das Verfasserwerkzeug dasselbe als ein Bayes-Netzwerk
(mit einigen zusätzlichen Informationen) aus. Die Bausteine
der Module, Ursachen, Aktionen und Fragen werden alle so
erzeugt, daß sie willkürlich während des Prozesses kombi
niert werden können, und es wird garantiert, daß das Ergeb
nis ein korrektes Bayes-Netzwerk sein wird. Die Konstrukti
on dieses Bayes-Netzwerks ist in der mitanhängigen Pa
tentanmeldung mit der fortlaufenden Nummer 09/353.727, die
am 14. Juli 1999 für AUTOMATED DIAGNOSIS OF PRINTER SYSTEMS
USING BAYESIAN NETWORKS eingereicht wurde, dokumentiert,
deren Gegenstand hierin durch Bezugnahme aufgenommen ist.
Im Verfasserwerkzeug können Informationen, die sich auf
diagnostische Modelle beziehen, spezifiziert werden. Spezi
ell kann folgendes spezifiziert werden:
Der Name der Fehlerkondition, die mit dem
diagnostischen Modell dargestellt wird.
Eine Erklärung dessen, was genau die Fehler
kondition ist, einschließlich Informationen
darüber, wie diese auftritt.
Die Zeit, die benötigt wird, um zu prüfen,
ob das Problem verschwunden ist. Diese Prü
fung muß nach jedem diagnostischen Schritt
ausgeführt werden, daher ist es wichtig zu
wissen, wie viel Zeit sie in Anspruch nimmt.
Eine Ursache stellt ein Ereignis oder eine Eigenschaft dar,
die, wenn sie auftritt, den Fehlerzustand mit absoluter Si
cherheit bewirkt. Beim Wissensakquisitionsprozeß werden die
Wahrscheinlichkeiten der Ursachen von den Domänenexperten
ausgelöst. Das Verfasserwerkzeug handhabt diesen Herausho
lungsprozeß, ohne die Anwesenheit eines Bayes-
Netzwerkexperten zu erfordern.
Anhand der Hauptschnittstelle 50 für das Verfasserwerkzeug
ist es möglich, eine neue Ursache zu erzeugen und eine vor
handene Ursache zu editieren. Das Erzeugen einer neuen Ur
sache oder Editieren einer alten Ursache führt zum Öffnen
einer Ursachen-Editorschnittstelle 60, die in Fig. 6 ge
zeigt ist. Ein Namenskästchen 61 ermöglicht einem Verfas
ser, den Namen der Ursache zu editieren. Ein Teilursachen
ankreuzkästchen 62 spezifiziert, ob die Ursache eine Tei
lursache einer weiteren Ursache ist. Zur vereinfachten Her
ausholung von Wahrscheinlichkeiten werden die Ursachen in
einem Baum angeordnet, wobei sich das Problem an sich an
der Wurzel befindet, woraufhin Ursachen, Teilursachen der
selben etc. folgen.
Ein Wahrscheinlichkeitsankreuzkästchen 63 ermöglicht einem
Verfasser, die Wahrscheinlichkeit der Ursache zu editieren.
Die Wahrscheinlichkeit der Ursache kann ebenfalls mit dem
Ursachenwahrscheinlichkeitseditor, der nachstehend be
schrieben ist, spezifiziert werden.
Das Auswählen einer Erklärungstaste 64 bringt eine Erklä
rungseditorschnittstelle 160, die in Fig. 16 gezeigt ist,
hervor. In einem Erklärungskästchen 161 kann eine Erklärung
der Ursache angegeben werden. Häufig ist der Name der Ursa
che nicht ausreichend, damit ein Diagnostiker die Art der
Ursache versteht, und in diesen Situationen ist eine aus
führlichere Erklärung von Vorteil. Die Erklärung wird so
geschrieben, daß sie einem Anwender des fertiggestellten
diagnostischen Systems präsentiert werden kann. In einem
Kästchen 162 kann eine Anmerkung, die weitere Informationen
über die Ursache angibt, angegeben werden. Dieses kann für
Informationen verwendet werden, die für die Verfasser der
diagnostischen Systeme relevant sind, die nicht von den An
wendern des fertiggestellten diagnostischen Systems gesehen
werden sollten.
Eine Kategorietaste 65 (in Fig. 6 gezeigt) wird ausgewählt,
wenn ein Verfasser eine oder mehrere Kategorien, in die die
Ursache fällt, spezifizieren möchte, um später die Ursache
leichter nachsehen zu können. Dieses Verfahren wird nach
stehend ausführlicher beschrieben.
Ein Verbrauchsartikel-Ankreuzkästchen 66 ermöglicht dem
Verfasser, zu markieren, daß die Ursache ein Verbrauchsar
tikel ist, d. h. eine Komponente, für deren Austausch die
Kunden verantwortlich sind, wenn diese abgenutzt ist. Dies
kommt bei der Abschlußnachricht des diagnostischen Systems
zum Tragen. Wenn bestimmt worden ist, daß die wahrschein
lichste Ursache ein abgenutzter oder defekter Verbrauchsar
tikel ist, muß der Kunde ihn selbst ersetzen. Wenn die
wahrscheinliche Ursache eine nicht aufbrauchbare Komponente
ist, muß der Kunden um weitere Unterstützung bitten.
Eine Ankreuzkästchen 67 für automatische Datenerfassung er
möglicht dem Verfasser, zu markieren, daß schlußfolgernde
Informationen über die Ursache potentiell durch direktes
Befragen der Vorrichtung, die in Frage kommt, erhalten wer
den können. Die automatische Datenerfassung ist gewöhnlich
viel effizienter, als die Informationen vom Anwender des
diagnostischen Systems zu erhalten.
Ein Beheben-durch-PC-Rebooten-Ankreuzkästchen 68 ermöglicht
dem Verfasser, zu markieren, daß diese Ursache durch Reboo
ten des Personalcomputers (PC) behoben werden kann. Diese
Informationen sind im diagnostischen System relevant, um zu
bestimmen, welche Ursachen nicht mehr gültig sind, wenn das
Rebooten des PCs beim Lösen des Problems nicht erfolgreich
ist.
Ein Beheben-durch-Leistungs-Ein-Ausschalten-des-Druckers-
Ankreuzkästchen 69 ermöglicht dem Verfasser, zu markieren,
daß diese Ursache durch Vornehmen eines Leistungs-Ein-
Ausschaltens am Drucker behoben werden kann.
Ein Abhängigkeit-von-Umgebung-Ankreuzkästchen 78 ermöglicht
einem Verfasser, Abhängigkeiten der Ursache auf der Version
oder dem Modell von Komponenten im System zu spezifizieren.
Dies soll dazu dienen, die Migration, wie nachstehend aus
führlicher erläutert, zu erleichtern.
Ein auf den Kunden zugeschnittenes Namenskästchen 79 ermög
licht dem Verfasser, den Namen der Ursache, die den Anwen
dern des diagnostischen Werkzeugs gezeigt wird, zu spezifi
zieren. Dies kann in Situationen relevant sein, in denen
der Name der Ursache für die Kunden nicht geeignet ist.
Eine Ursache-Löschen-Taste 77 ermöglicht dem Verfasser, die
Ursache aus dem diagnostischen Modell zu löschen.
Die Wahrscheinlichkeiten der Ursachen können auf zwei Arten
ausgelöst werden. Wie vorstehend beschrieben, können die
Wahrscheinlichkeiten der Ursachen alle auf einmal durch
Verwendung der Ursachen-Editorschnittstelle 60 spezifiziert
werden.
Die Wahrscheinlichkeiten von Ursachen können durch Verwen
dung einer Ursachen-Wahrscheinlichkeits-Editorschnittstelle
70, die in Fig. 7 gezeigt ist, auch effizienter spezifi
ziert werden. In einem Kästchen 71 wird dem Verfasser ein
Überblick über die Ursachen, die wie ein Baum strukturiert
sind, gegeben. Nachdem ein Verfasser eine Ursache doppelge
klickt hat, werden im Kästchen 71 alle Ursachen auf dem
gleichen Niveau und mit den gleichen Eltern wie ihre Ursa
che und ihre zugeordneten Wahrscheinlichkeiten im Kästchen
72 gezeigt. Der Verfasser kann die Wahrscheinlichkeiten
diesen Ursachen angesichts ihrer Elternursache (angesichts
des Problems, im Fall von Ursachen höchsten Ranges) zuord
nen. Die Wahrscheinlichkeiten werden so zugeordnet, daß sie
in der Summe 100% ergeben, und sie können nach Bedarf nor
miert werden. Bei dem bevorzugten Ausführungsbeispiel ar
beitet die Ursachen-Wahrscheinlichkeits-Editorschnittstelle
70 (sowie alle anderen Editorschnittstellen im Verfasser
werkzeug) mit Prozentsätzen anstelle von Wahrscheinlichkei
ten, da die Domänenexperten häufig die Arbeit mit denselben
bevorzugen.
Bei der Ursachen-Editorschnittstelle 60 kann der Verfasser
spezifizieren, daß die Ursache in eine oder mehrere Katego
rien fällt. Die Kategorien entsprechen logischen Bereichen
oder Eigenschaften in dem System, das moduliert wird, die
in der Struktur der Module nicht gespiegelt sind. Die Modu
le werden normalerweise entsprechend den physischen Kompo
nenten oder logischen Bereichen strukturiert, jedoch kann
es auch andere Möglichkeiten geben, Ursachen zu gruppieren,
und diese können mit Kategorien erfaßt werden.
Eine Kategorie-Editorschnittstelle 80, die in Fig. 8 ge
zeigt ist, wird verwendet, um neue Kategorien zu erzeugen
oder bestehende zu löschen. Beispiele von Kategorien in der
Drucksystemdomäne sind Software, Kabel, Netzwerk, Hardware,
Zubehör und Einstellungen. Die Kategorien sollten nicht er
zeugt werden, wenn ein Fehlerzustand existiert, in dem alle
Ursachen in der Kategorie relevant sind. Die Kategorien
werden ebenfalls erzeugt, um das Nachsehen von Ursachen zu
erleichtern.
Bei einem bevorzugten Ausführungsbeispiel der vorliegenden
Erfindung präsentiert ein Fenster eine Liste von allen Ur
sachen in den Bibliotheksmodulen. Dieses Fenster ermöglicht
das Einstellen von einer oder mehreren Kategorien, und die
Ursachen, die in alle spezifizierten Kategorien fallen,
werden gezeigt. Mit dieser Einrichtung gestaltet sich das
Auffinden von Ursachen viel schneller.
Eine Aktion ist ein Schritt, die der Diagnostiker ausführen
kann, bei der eine Chance besteht, das Problem entweder zu
lösen oder das Problem vorübergehend zu entfernen. Lösungs
aktionen haben das Potential, das Problem zu lösen, so daß
keine weitere Aktion erforderlich ist, und Informations
sammlungsaktionen besitzen das Potential, das Problem durch
Ausführen einer Prüfung auf dem System zu entfernen (obwohl
sie es nicht lösen). Es ist wichtig, zwischen den zwei Ty
pen von Aktionen (Aktionen, die eine beliebige der Ursachen
des Problems lösen können, und Aktionen, die Informationen
bezüglich der Ursachen liefern können) zu unterscheiden.
Lösungsaktionen und Informationssammlungsaktionen werden
unterschiedlich zum Auswählen des nächstbesten Schritts ge
handhabt. Bei dem bevorzugten Ausführungsbeispiel werden
die Informationssammlungsaktionen in der gleichen Weise wie
die Fragen behandelt.
Die Hauptschnittstelle 50 (in Fig. 5 gezeigt) für das Ver
fasserwerkzeug ermöglicht die Erzeugung von neuen Aktionen
und das Editieren von vorhandenen Aktionen durch Doppel
klicken auf die Aktionen, wie sie in Seite 51 oder Seite 52
angezeigt sind. Beide Aktionen öffnen eine Aktions-
Editorschnittstelle 90, die in Fig. 9 gezeigt ist.
Die Aktions-Editorschnittstelle 90 ermöglicht die Spezifi
kation allen Wissens, das zu der Aktion gehört, die für den
diagnostischen Prozeß relevant ist. Die Wahrscheinlichkei
ten der Aktion können auch mit der Sonderaktions-
Wahrscheinlichkeits-Editorschnittstelle, die nachstehend
beschrieben ist, eingestellt werden.
In einem Kästchen 91 ist der Name der Aktion spezifiziert.
In einem Kästchen 92 ist der Typ der Aktion spezifiziert,
d. h. ob die Aktion eine Lösung oder Informationssammlungs
aktion sind.
In einem Ankreuzkästchen 93 kann ein Verfasser spezifizie
ren, ob die Aktion der Reihe nach durchgeführt wird. Dies
ist manchmal für Aktionen relevant, die immer ausgeführt
werden sollen, bevor die wirkliche Diagnostik gestartet
wird, z. B. zum Sicherstellen einer anfänglichen Überzeu
gung über die Umgebung. Der Verfasser kann spezifizieren,
daß die Aktion als eine der ersten Aktionen durchgeführt
werden soll und ihr eine Nummer in dieser durchgeführten
Reihenfolge geben.
In einem Workaround-Ankreuzkästchen 94 kann ein Verfasser
spezifizieren, ob die Aktion ein Workaround ist. Das Worka
round präsentiert eine Lösung zum Problem, die für den Dia
gnostiker auf lange Sicht nicht zufriedenstellend sein
kann, daher wird er gefragt, ob er mit der Lösung im dia
gnostischen System für diese Aktionen zufrieden ist.
Das Auswählen einer Erklärungstaste 95 bringt eine Erklä
rungs-Editorschnittstelle 160, die in Fig. 16 gezeigt ist,
hervor. Im Erklärungskästchen 161 kann eine Erklärung der
Aktion angegeben werden. Häufig ist der Name der Aktion für
einen Diagnostiker nicht ausreichend, um die Art der Aktion
zu verstehen, und in diesen Situationen ist eine längere
Erklärung von Vorteil. Die Erklärung wird so geschrieben,
daß sie einem Anwender des fertiggestellten diagnostischen
Systems präsentiert werden kann. In einem Kästchen 162 kann
ein Hinweis, der weitere Informationen über die Aktion an
gibt, angegeben werden. Dieser kann für Informationen ver
wendet werden, die für die Verfasser des diagnostischen Sy
stems relevant sind, und die durch die Anwender des fertig
gestellten diagnostischen Systems nicht gesehen werden
sollten.
Eine Editierkostentaste 96 öffnet eine Kosten-
Editorschnittstelle 150, die in Fig. 15 gezeigt ist. Die
Kosten-Editorschnittstelle 150 wird für sowohl Aktionen als
auch Fragen verwendet. In einem Kästchen 151 der Kosten-
Editorschnittstelle 150 kann ein Verfasser einen Ungenauig
keitsfaktor spezifizieren. Der Ungenauigkeitsfaktor ist die
Wahrscheinlichkeit, daß der Diagnostiker die Aktion unrich
tig ausführt, ohne dies zu bemerken.
Unter Verwendung der Kosten-Editorschnittstelle 150 kann
ein Verfasser auch vier Kostenkomponenten spezifizieren:
Zeit, Risiko (Kaputtmachen einer anderen Komponente bei Ausführen des Schritts), Geld und Beleidigung (für Schrit te, die für einen erfahrenen Diagnostiker beleidigend sein können).
Zeit, Risiko (Kaputtmachen einer anderen Komponente bei Ausführen des Schritts), Geld und Beleidigung (für Schrit te, die für einen erfahrenen Diagnostiker beleidigend sein können).
In einem Kästchen 152 wird die Zeit, die als eine Zahl, die
in Minuten gemessen wird, spezifiziert. Ein Ankreuzkästchen
153 wird zum Spezifizieren verwendet, ob die Zeit mit War
ten oder mit aktiver Arbeit verbracht wird. Dies wird auch
bei der Berechnung der Gesamtkosten verwendet. Der Ungenau
igkeitsfaktor wird unter Verwendung eines Schiebers 157 auf
einer Skala von fünf Werten (sehr gering, gering, mittel,
hoch und sehr hoch) spezifiziert. Der Risikofaktor wird un
ter Verwendung eines Schiebers 154 auf einer Skala von fünf
Werten spezifiziert. Der Geldfaktor wird unter Verwendung
eines Schiebers 155 auf einer Skala von fünf Werten spezi
fiziert. Der Beleidigungsfaktor wird unter Verwendung eines
Schiebers 156 auf einer Skala von fünf Werten spezifiziert.
Bei der Aktions-Editorschnittstelle 90, die in Fig. 9 ge
zeigt ist, bringt das Auswählen einer Extrainformationsta
ste 97 einen Extrainformations-Editor 100 hervor, der in
Fig. 10 gezeigt ist. Ein enthaltenes Aktionsfenster 101 er
möglicht die Spezifikation aller Aktionen, die in der aktu
ellen Aktion enthalten sind, d. h. Aktionen, die ebenfalls
ausgeführt werden, wenn diese Aktion ausgeführt wird. Dies
ist für das diagnostische System höchst relevant, da das
diagnostische System weiß, daß es eine Aktion nicht vor
schlagen soll, die bereits als Teil von anderen Aktionen
ausgeführt worden ist.
Ein Fenster 102 für sich gegenseitig ausschließende Aktio
nen ermöglicht die Spezifikation von Aktionen, die sich bei
der aktuellen Aktion gegenseitig ausschließen. Zum Bei
spiel, wenn die Aktion A als sich mit der Aktion B gegen
seitig ausschließend spezifiziert wird, dann kann die Akti
on A nicht nach Aktion B vorgeschlagen werden und umge
kehrt.
In einem Bereich 103 kann der Verfasser spezifizieren, daß
die Aktion nur vorgeschlagen werden kann, nachdem eine spe
zifische Frage mit einer spezifischen Antwort beantwortet
worden ist. Dies ist zum Sicherstellen relevant, daß Vor
aussetzungen zur Verfügung stehen und/oder erfüllt sind,
bevor Aktionen vorgeschlagen werden. Diese Frage kann zu
sammen mit der Antwort spezifiziert werden. Es ist möglich,
"beliebig" als die erforderliche Antwort zu spezifizieren,
was impliziert, daß die Frage gestellt werden muß, bevor
die Aktion vorgeschlagen werden kann, jedoch ist die Ant
wort nicht von Bedeutung.
In einem Bereich 104 kann der Verfasser spezifizieren, daß
die Aktion nicht vorgeschlagen werden kann, nachdem eine
spezifische Frage mit einer spezifischen Antwort beantwor
tet worden ist. Es ist wiederum möglich, "beliebig" als
Antwort zu spezifizieren.
In einem Bereich 105 kann der Verfasser eine Frage spezifi
zieren, die in einem spezifischen Zustand (Antwort) festge
legt wird, wenn die Aktion ausgeführt worden ist. Dies kann
verwendet werden, um inkohärente Informationen im zugrunde
liegenden Bayes-Netzwerk zu verhindern. Wenn das diagnosti
sche System z. B. die Frage "Ist der Drucker eingeschal
tet?" vorschlägt, und die Antwort "nein" empfängt, dann ist
der nächste logische Schritt, die Aktion "Drucker einschal
ten" vorzuschlagen, woraufhin die Antwort auf die erste
Frage nicht mehr gültig ist. Dies kann durch Spezifizieren,
daß die Frage "Ist der Drucker eingeschaltet?" in einem Zu
stand "ja" festgelegt werden muß, nachdem die Aktion ausge
führt worden ist, gehandhabt werden.
In einem Bereich 106 kann der Verfasser spezifizieren, ob
die Aktion das Bewegen einer spezifischen Komponente um
faßt. Wenn dies der Fall ist, wird die Aktion potentiell
die Ursache dieser Komponente, die unzureichend eingepaßt
wird, lösen. Es ist wichtig, daß dies spezifiziert wird, da
das diagnostische System dann weiß, daß es den Diagnostiker
bitten muß zu versuchen, die Komponente wieder zurück zu
legen, wenn die Aktion geholfen hat, um zu sehen, ob dies
die Ursache war, warum die Komponente unzureichend einge
paßt war.
Ein Abhängigkeit-von-Umgebung-Kästchen 107 ermöglicht einem
Verfasser, Abhängigkeiten der Ursache auf der Version oder
dem Modell von Komponenten im System zu spezifizieren. Dies
zielt darauf ab, die Migration zu erleichtern, wie dies
nachstehend ausführlicher erläutert ist.
Ein Ankreuzkästchen 108 wird durch einen Verfasser verwen
det, um zu spezifizieren, ob die Aktion den Drucker einem
Leistungs-Ein-Ausschalten unterzieht. Kombiniert mit dem
Wissen über die Ursachen, die durch das Leistungs-Ein-
Ausschalten am Drucker gelöst werden, ermöglicht dies dem
diagnostischen System, diese Aktionen und Ursachen korrekt
zu behandeln.
Ein Ankreuzkästchen 109 ermöglicht einem Verfasser, zu spe
zifizieren, ob die Aktion das Rebooten des Personalcompu
ters umfaßt.
Ein Ankreuzkästchen 119 wird verwendet, um zu spezifizie
ren, ob die Aktion irreversibel ist. Wenn eine irreversible
Aktion das Problem löst, wird das diagnostische System den
Diagnostiker nicht fragen, ob er die Diagnose fortsetzen
möchte, da es unmöglich ist, das Problem durch Rückgängig
machen der Aktion erneut zu erstellen.
Ein Ankreuzkästchen 118 zur automatischen Datenerfassung
ermöglicht dem Verfasser, zu markieren, daß schlußfolgernde
Informationen über die Aktion potentiell durch direktes Be
fragen der in Frage kommenden Vorrichtung erreicht werden
können. Die automatische Datenerfassung ist normalerweise
effizienter als das Erhalten von Informationen vom Anwender
des diagnostischen Systems.
Bei der Aktions-Editorschnittstelle 90, die in Fig. 9 ge
zeigt ist, ermöglicht ein Fenster 99 für gelöste Ursachen
die Spezifikation der Ursachen, die durch die Aktion gelöst
werden können, und der Wahrscheinlichkeit, mit der sie ge
löst werden. Es ist möglich, eine neue Ursache hinzuzufü
gen, die Wahrscheinlichkeit einer bestehenden Ursache zu
editieren oder eine Ursache zu entfernen. Durch Doppelklik
ken auf eine Ursache, die im Fenster 99 für gelöste Ursa
chen angezeigt ist, wird ein Aktions-
Wahrscheinlichkeitseditor 110, der in Fig. 11 gezeigt ist,
hervorgebracht. Der Aktions-Wahrscheinlichkeitseditor 110
ermöglicht das Editieren der Wahrscheinlichkeit, daß die
Aktion die Ursache löst. Der Aktions-
Wahrscheinlichkeitseditor implementiert die Frage, die dem
Domänenexperten gestellt wird, um diese Wahrscheinlichkei
ten herauszuholen: Angenommen, daß <Ursache< die einzige
Ursache des <Problems< ist, was ist die Wahrscheinlichkeit,
daß das Problem durch das korrekte Ausführen des Schritts
<Aktion< gelöst wird?
Bei der Aktions-Editorschnittstelle 90, die in Fig. 9 ge
zeigt ist, ermöglicht das Auswählen einer Aktion-Entfernen-
Taste 98 dem Verfasser, die Aktion aus dem diagnostischen
Modell zu entfernen.
Bei dem bevorzugten Ausführungsbeispiel können die Wahr
scheinlichkeiten der Aktionen auch durch einen globalen Ak
tions-Wahrscheinlichkeitseditor editiert werden, der einen
Überblick über alle Aktionen gibt. Der Verfasser kann die
Aktion auswählen, für die er die Wahrscheinlichkeiten edi
tieren möchte, und er kann spezifische Wahrscheinlichkeiten
auswählen, die er editieren möchte oder wählen möchte, um
alle Wahrscheinlichkeiten der Ursachen, die durch die Akti
on auf einmal gelöst wurden, herauszuholen.
Eine Frage ist ein diagnostischer Schritt, der Informatio
nen über die Fehlerbedingung liefert, die zum Berechnen ei
ner Sequenz von Aktionen mit geringeren geschätzten Kosten
für die Auflösung relevant ist. Es gibt zwei Typen von Fra
gen - allgemeine Fragen und Symptomfragen. Allgemeine Fra
gen sammeln allgemeine Informationen über die Fehlerbedin
gung, die die Wahrscheinlichkeiten der Ursachen neu anord
net. Für diese Fragen werden konditionale Wahrscheinlich
keiten von Ursachen angesichts der Fragen ausgelöst. Sym
ptomfragen sammeln Informationen über Symptome von Ursa
chen, d. h. konditionale Wahrscheinlichkeiten der Frage an
gesichts der Ursachen ausgelöst werden.
Anhand der Hauptschnittstelle 50 (in Fig. 5 gezeigt) für
das Verfasserwerkzeug ist es möglich, neue Fragen von bei
den Typen zu erzeugen und vorhandene Fragen zu editieren.
Neue Fragen werden durch Auswählen einer neuen Fragetaste
aus der Hauptschnittstelle 50 erzeugt. Das Editieren einer
vorhandenen Frage wird durch Doppelklicken auf eine Frage,
die in einem Fenster in der Hauptschnittstelle 50 angezeigt
ist, erreicht. Diese beiden Aktionen öffnen den entspre
chenden Frageeditor.
Eine Schnittstelle 120 des allgemeinen Frageeditors ist in
Fig. 12 gezeigt. In einem Kästchen 121 kann ein Verfasser
den Namen der Frage spezifizieren. In einem Antwortkästchen
122 kann der Verfasser die Anzahl von Antworten und die Na
men dieser Antworten spezifizieren.
Das Auswählen einer Erklärungstaste 123 bringt eine Erklä
rungs-Editorschnittstelle 160, die in Fig. 16 gezeigt ist,
hervor. Im Erklärungskästchen 161 kann eine Erklärung der
Frage angegeben werden. Häufig ist der Name der Frage für
einen Diagnostiker nicht ausreichend, um die Art der Frage
zu verstehen, und in diesen Situationen ist eine ausführli
chere Erklärung von Vorteil. Die Erklärung ist so geschrie
ben, daß sie einem Anwender des fertiggestellten diagnosti
schen Systems präsentiert werden kann. In einem Kästchen
162 kann ein Hinweis, der weitere Informationen über die
Frage angibt, angegeben werden. Dieser kann für Informatio
nen verwendet werden, die für die Verfasser der diagnosti
schen Systeme relevant sind und die durch die Anwender des
fertiggestellten diagnostischen Systems nicht gesehen wer
den sollten.
Das Auswählen einer Kosten-editieren-Taste 124 eröffnet die
Kosteneditorschnittstelle 150, die in Fig. 15 gezeigt ist.
Die Kosteneditorschnittstelle 150 wird sowohl für Aktionen
als auch Fragen verwendet und ist vorstehend ausführlicher
beschrieben.
Das Auswählen einer Extrainformationstaste 125 bringt einen
Extrainformationseditor für Fragen hervor, der dem Extrain
formationseditor für Aktionen, der in Fig. 10 gezeigt ist,
ähnlich ist.
Der Extrainformationseditor für Fragen umfaßt einen "Nur-
nach-Frage"-Bereich, in dem der Verfasser spezifizieren
kann, daß die Frage nur gestellt werden kann, nachdem eine
spezifische Frage mit einer spezifischen Antwort beantwor
tet worden ist. Dies ist zum Sicherstellen relevant, daß
Voraussetzungen zur Verfügung stehen und/oder erfüllt sind,
bevor die Frage gestellt wird. Die Frage zusammen mit der
Antwort kann spezifiziert werden. Es ist möglich, "belie
big" als erforderliche Antwort zu spezifizieren, was impli
ziert, daß die Frage gestellt werden muß, bevor die neue
Frage gestellt werden kann, jedoch ist die Antwort nicht
von Bedeutung.
Der Extrainformationseditor für Fragen umfaßt einen "Nicht-
nach-Frage"-Bereich, in dem der Verfasser Aktionen oder
Fragen spezifizieren kann, die sich mit der aktuellen Frage
gegenseitig ausschließen. Wenn z. B. die Frage A als sich
mit der Frage B gegenseitig ausschließend spezifiziert ist,
kann die Frage A nach der Frage B nicht vorgeschlagen wer
den und umgekehrt.
Der Extrainformationseditor für Fragen umfaßt einen "Abhän
gigkeit-von-Umgebung"-Bereich, in dem der Verfasser Abhän
gigkeiten von der Frage über die Version oder das Modell
von Komponenten im System spezifizieren kann. Die zielt
darauf ab, die Migration zu erleichtern, wie nachstehend
ausführlicher erörtert wird.
Der Extrainformationseditor für Fragen umfaßt ein automati
sches Datenerfassungs-Ankreuzkästchen, das dem Verfasser
ermöglicht, zu markieren, daß schlußfolgernde Informationen
über die Frage potentiell durch direktes Befragen der in
Frage kommenden Vorrichtung erreicht werden können. Die au
tomatische Datenerfassung ist normalerweise effizienter als
ein Einholen der Informationen vom Anwender des diagnosti
schen Systems.
Der Extrainformationseditor für Fragen umfaßt ein "Enddia
gnose"-Ankreuzkästchen, das einem Verfasser ermöglicht, zu
spezifizieren, daß der diagnostische Prozeß enden sollte,
wenn die Frage in einer bestimmten Weise beantwortet ist.
Die Allgemeine-Fragen-Editorschnittstelle 120, die in Fig.
12 gezeigt ist, umfaßt auch ein Ankreuzkästchen 126, das
einem Verfasser ermöglicht, zu spezifizieren, ob die Frage
der Reihe nach durchgeführt worden ist. Dies ist manchmal
für Fragen relevant, die immer gestellt werden sollen, be
vor die wirkliche Diagnose gestartet wird, z. B. zum Si
cherstellen einer anfänglichen Überzeugung über die Umge
bung. Der Verfasser kann spezifizieren, daß die Frage als
eine der ersten Fragen durchgeführt wird und ihr die Zahl
in dieser durchgeführten Reihenfolge geben.
Eine Frage-Entfernen-Taste 127 ermöglicht dem Verfasser,
die Frage aus dem diagnostischen Modell zu entfernen.
Die Wahrscheinlichkeiten der Antworten auf die Frage können
ebenfalls spezifiziert werden. Eine Taste 128 ermöglicht
die Normierung der Wahrscheinlichkeiten.
Angesichts jeder möglichen Antwort auf die Frage können die
Ursachen, die beeinflußt werden, in einem Fenster 129 spe
zifiziert werden. Für die beeinflußten Ursachen muß die
konditionale Wahrscheinlichkeit der Ursache angesichts je
der Antwort auf die Frage spezifiziert werden. Die Wahr
scheinlichkeiten müssen korrekt balanciert werden, so daß
nicht alle Kombinationen möglich sind. Für Hintergrundin
formationen über Gleichungen, die zum Balancieren der Fra
gewahrscheinlichkeiten verwendet werden, siehe mitanhängige
Patentanmeldung mit der fortlaufenden Nummer 09/353.727,
die am 14. Juli 1999 für AUTOMATED DIAGNOSIS OF PRINTER SY
STEMS USING BAYESIAN NETWORKS eingereicht wurde. Die Ursa
chen können aus der Liste der beeinflußten Ursachen ent
fernt werden.
Wenn auf eine der Wahrscheinlichkeiten einer Ursache, die
im Fenster 129 aufgelistet ist, doppelgeklickt wird, öffnet
dies eine Veränderungs-Wahrscheinlichkeits-
Editorschnittstelle 130, die in Fig. 13 gezeigt ist. Die
Veränderungs-Wahrscheinlichkeits-Editorschnittstelle 130
zeigt den Namen der Ursache in einem Kästchen 131 an, den
Namen der Frage in einem Kästchen 132, den Zustand in einem
Kästchen 133 und die alte Wahrscheinlichkeit in einem Käst
chen 134 an. Eine neue Wahrscheinlichkeit kann in ein Käst
chen 135 eingetragen werden.
Eine Symptomfragen-Editorschnittstelle 140 ist in Fig. 14
gezeigt. In einem Kästchen 141 kann ein Verfasser den Namen
der Frage spezifizieren. In einem Kästchen 142 kann der
Verfasser die Anzahl der Antworten (Zustände) und die Namen
dieser Antworten spezifizieren.
Das Auswählen einer Erklärungstaste 143 bringt eine Erklä
rungseditorschnittstelle 160, die in Fig. 16 gezeigt ist,
hervor. Im Erklärungskästchen 161 kann eine Erklärung der
Frage angegeben werden. Häufig ist der Name der Frage für
einen Diagnostiker nicht ausreichend, um die Art der Frage
zu verstehen, und in diesen Situationen ist eine längere
Erklärung von Vorteil. Die Erklärung wird so geschrieben,
daß sie einem Anwender des fertiggestellten diagnostischen
Systems präsentiert werden kann. In einem Kästchen 162 kann
ein Hinweis angegeben werden, der weitere Informationen
über die Frage angibt. Dieser kann für Informationen ver
wendet werden, die für die Verfasser der diagnostischen Sy
steme relevant sind und die durch die Anwender des fertig
gestellten diagnostischen Systems nicht gesehen werden
sollten.
Das Auswählen einer Kosten-editieren-Taste 144 öffnet die
Kosteneditorschnittstelle 150, die in Fig. 15 gezeigt ist.
Die Kosteneditorschnittstelle 150 wird sowohl für Aktionen
als auch Fragen verwendet und nachstehend ausführlicher be
schrieben.
Das Auswählen einer Taste 144 für gegenseitige Ausschlie
ßungen ermöglicht einem Verfasser, Aktionen oder Fragen zu
spezifizieren, die sich mit der aktuellen Frage gegenseitig
ausschließen. Wenn die Frage A z. B. als sich mit der Frage
B gegenseitig ausschließend spezifiziert ist, kann die Fra
ge A nicht nach der Frage B und umgekehrt vorgeschlagen
werden.
Das Auswählen einer Extrainformationstaste 145 bringt einen
Extrainformationseditor für Fragen hervor, der dem Extrain
formationseditor für Aktionen, der in Fig. 10 gezeigt ist,
ähnlich ist.
Ein Ankreuzkästchen 146 ermöglicht einem Verfasser, zu spe
zifizieren, ob die Frage der Reihe nach durchgeführt wird.
Dies ist manchmal für Fragen relevant, die stets gestellt
werden sollten, bevor mit der wirklichen Diagnose begonnen
wird, z. B. zum Sicherstellen einer anfänglichen Überzeu
gung über die Umgebung. Der Verfasser kann spezifizieren,
daß die Frage als eine der ersten Fragen durchgeführt wird
und ihr die Zahl in dieser durchgeführten Reihenfolge zu
weisen.
Eine Frage-entfernen-Taste 147 ermöglicht dem Verfasser,
die Frage aus dem diagnostischen Modell zu entfernen.
Im Bereich 148 sind die Ursachen und Wahrscheinlichkeiten
von Zuständen (Antworten) angesichts der Ursache gezeigt.
Die Ursachen, die eine Auswirkung auf die Antwort auf die
Frage aufweisen, können der Liste von relevanten Ursachen
hinzugefügt werden oder aus der Liste entfernt werden. Für
jede der Ursachen auf dieser Liste wird die konditionale
Wahrscheinlichkeit für jede Antwort auf die Frage ange
sichts der Tatsache, daß die Ursache die einzige Ursache
des Problems ist, spezifiziert. Für Ursachen, die sich
nicht auf dieser Liste befinden, können vorgegebene kondi
tionale Wahrscheinlichkeiten für die Antworten auf die Fra
ge unter Verwendung des Kästchens 149 spezifiziert werden.
Die vorgegebene konditionale Wahrscheinlichkeit ist die
Wahrscheinlichkeit von jeder Antwort auf die Frage, wenn
die wirkliche Ursache sich nicht auf der Liste befindet. Da
nur ein Satz von vorgegebenen Wahrscheinlichkeiten spezifi
ziert werden kann, sollten diese Wahrscheinlichkeiten für
die Ursachen, die nicht aufgelistet sind, die gleichen
sein.
Die Schnittstelleneditoren, die vorstehend beschrieben
sind, werden verwendet, um Datenstrukturen zu bauen. Die
zwei Hauptdatenstrukturen sind die Bibliotheksdatenstruktur
und das aktuelle diagnostische Systemmodell.
Das aktuelle diagnostische Systemmodell weist eine Daten
struktur, die in Tabelle 15 unten aufgeführt ist, auf:
Modell
- - Name
- - Liste von Ursachen
- - Liste von Aktionen
- - Liste von Fragen
- - Problembeobachtungszeit
Die Bibliothek weist eine Datenstruktur auf, die wie in Ta
belle 16 unten aufgeführt ist:
Bibliothek
- - Liste von Modulen
- - Liste von Kategorien
Ein Modul weist dieselbe Struktur wie ein Modell auf, das
in Tabelle 17 unten aufgeführt ist:
Modul
- - Name
- - Liste von Ursachen
- - Liste von Aktionen
- - Liste von Fragen
- - Problembeobachtungszeit
Eine Ursache weist eine Datenstruktur auf, die wie in Ta
belle 18 unten aufgeführt ist:
Ursache
- - Name
- - Erklärung
- - Wahrscheinlichkeit
- - Elternursache: Null, wenn keine existiert
- - Liste von Kategorien
- - Verbrauchsartikel: 1, wenn die Ursache ein Verbrauchs artikel ist
- - Autoerfassung: 1, wenn die Daten, die der Ursache ange hören, automatisch erfaßt werden können
- - Beheben-PC-Rebooten: 1, wenn die Ursache durch Rebooten des PC behoben werden kann
- - Beheben-Leistungs-Ein-Ausschalten-Drucker: 1, wenn die Ursache durch Vornehmen eines Leistungs-Ein- Ausschaltens am Drucker behoben werden kann
- - Liste von Abhängigkeiten
- - Name der Kundenversion: Name der Ursache, die dem Kun den präsentiert wird
- - keine Kundenverwendung: 1, wenn die Ursache nicht für Kundenverwendung/Kundenzugriff gedacht ist
- - Teilename: Teilename der Ursache
Die Wahrscheinlichkeit wird mit den anderen Ursachen auf
dem gleichen Niveau wie die Ursache selbst normiert beibe
halten. Wenn keine Elternursache spezifiziert wird, wird
die Ursache auf dem oberen Niveau der Ursachenhierarchie
angeordnet. Wenn eine Elternursache spezifiziert wird, ist
die Ursache eine Teilursache dieser Ursache.
Eine Aktion weist eine Datenstruktur auf, wie in Tabelle 19
unten aufgeführt:
Aktion
- - Name
- - Erklärung
- - Typ: 0 = Lösungsaktion/1 = Informationssammlungsakti on
- - Liste von (Ursachen-, Wahrscheinlichkeits-) Paaren
- - Zeit
- - Risiko
- - Geld
- - Beleidigung
- - Ungenauigkeit
- - zuerst: 1, wenn die Aktion als eine der ersten drankom men soll
- - Zahl: wenn zuerst = 1, spezifiziert diese Zahl, wann die Aktion drankommen soll
- - Workaround: 1, wenn die Aktion ein Workaround ist
- - Liste von enthaltenen Aktionen
- - nur nach Frage: falls spezifiziert, kann die Aktion nur vorgeschlagen werden, wenn die Frage im Zustand1 beant wortet worden ist.
- - Zustand1
- - nicht nach Frage: falls spezifiziert, kann die Aktion nicht vorgeschlagen werden, wenn die Frage im Zustand2 beantwortet worden ist.
- - Zustand2
- - keine Kundenverwendung: 1, wenn die Aktion nicht für Kundenverwendung/Kundenzugriff gedacht ist
- - Liste von Aktionen, die sich mit dieser Aktion gegen seitig ausschließen
- - Frage festlegen: falls spezifiziert, wird die Frage im Zustand3 festgelegt, wenn die Aktion nicht ausgeführt worden ist
- - Zustand3
- - Komponente bewegen: 1, wenn die Aktion das Bewegen ei ner Komponente umfaßt
- - Komponente bewegt: die Komponente, die bewegt wird, wenn "Komponente bewegen" 1 beträgt
- - Zurückbewegen: 1, wenn die Komponente nicht zurückbe wegt werden soll, nachdem die Aktion ausgeführt worden ist
- - Leistungszyklen des Druckers: 1, wenn die Aktion den Drucker einem Leistungs-Ein-Ausschalten unterzieht
- - PC rebooten: 1, wenn die Aktion den PC rebootet
- - irreversibel
- - Auto-Erfassung: 1, wenn die Daten, die der Ursache an gehören, automatisch erfaßt werden können
- - Liste von Abhängigkeiten
Die Liste von Ursachen- und Wahrscheinlichkeitspaaren ist
die Liste der Ursachen, die durch die Aktion gelöst werden,
einschließlich der Wahrscheinlichkeit, daß die Aktion das
Problem unter Annahme der Ursache löst.
Eine allgemeine Frage weist eine Datenstruktur auf, die wie
in Tabelle 20 nachstehend aufgeführt ist:
Frage
- - Name
- - Erklärung
- - Anzahl der Antworten
- - Liste von Namen der Antworten
- - Typ: 0 = allgemeine Frage/1 = Symptomfrage
- - Zeit
- - Risiko
- - Geld
- - Beleidigung
- - Ungenauigkeit
- - zuerst
- - Anzahl
- - nur nach Frage
- - nicht nach Frage
- - keine Kundenverwendung: 1, wenn die Aktion nicht für Kundenverwendung/Kundenzugriff gedacht ist
- - Endfrage: 1, wenn die Diagnose enden soll, wenn die Frage mit einer spezifizierten Antwort beantwortet wird: Zustand4
- - Zustand4
- - Liste von Abhängigkeiten
- - Auto-Erfassung: 1, wenn die Daten, die der Ursache an gehören, automatisch erfaßt werden können
- - Liste von vorherigen Wahrscheinlichkeiten der Antworten
- - Liste von (Ursachen, Liste von (Antwort-, Wahrschein lichkeits-) Paaren) Paaren
Die Liste von Ursachen, Antworten und Wahrscheinlichkeiten
enthält eine Wahrscheinlichkeit für jede der Ursachen ab
hängig von jeder möglichen Antwort auf die Frage.
Eine Symptomfrage weist eine Datenstruktur auf, wie in Ta
belle 21 unten aufgeführt ist:
Frage
- - Name
- - Erklärung
- - Anzahl der Antworten
- - Liste von Namen von Antworten
- - Typ: 0 = allgemeine Frage/1 = Symptomfrage
- - Zeit
- - Risiko
- - Geld
- - Beleidigung
- - Ungenauigkeit
- - zuerst
- - Anzahl
- - nur nach Frage
- - nur nach Antwort
- - keine Kundenverwendung: 1, wenn die Aktion nicht für Kundenverwendung/Kundenzugriff gedacht ist
- - Endfrage: 1, wenn die Diagnose enden soll, wenn die Frage mit einer spezifizierten Antwort beantwortet wird: Zustand4
- - Zustand4
- - Liste von Wahrscheinlichkeiten
- - Auto-Erfassung: 1, wenn die Daten, die der Ursache an gehören, automatisch erfaßt werden können
- - Liste von (Ursachen-, Liste von (Antworts-, Wahrschein lichkeits-) Paaren) Paaren
- - Liste von Wahrscheinlichkeiten der Antworten angesichts keiner der aufgelisteten Ursachen
Die Liste von Ursachen, Antworten und Wahrscheinlichkeiten
enthält eine Wahrscheinlichkeit für jede Antwort auf die
Frage abhängig von jeder der Ursachen.
Claims (35)
1. Verfasserwerkzeug, das einen Verfasser beim Aufbauen
eines automatisierten diagnostischen Systems für ein
Produkt unterstützt, wobei das Verfasserwerkzeug fol
gende Merkmale aufweist:
eine Ursachen-Editorschnittstelle (60), die einem Ver fasser ermöglicht, in einer Ursachendatenstruktur In formationen, die sich auf Ursachen beziehen, zu pla zieren;
eine Aktions-Editorschnittstelle (90), die einem Ver fasser ermöglicht, in einer Aktionsdatenstruktur In formationen, die sich auf Aktionen beziehen, die an sprechend auf die Ursachen unternommen werden können, zu plazieren; und
eine Frage-Editorschnittstelle (120, 140), die einem Verfasser ermöglicht, in einer Fragedatenstruktur In formationen zu plazieren, die sich auf Fragen bezie hen, die einem Anwender des Produkts gestellt werden können, um beim Identifizieren von Ursachen zu helfen.
eine Ursachen-Editorschnittstelle (60), die einem Ver fasser ermöglicht, in einer Ursachendatenstruktur In formationen, die sich auf Ursachen beziehen, zu pla zieren;
eine Aktions-Editorschnittstelle (90), die einem Ver fasser ermöglicht, in einer Aktionsdatenstruktur In formationen, die sich auf Aktionen beziehen, die an sprechend auf die Ursachen unternommen werden können, zu plazieren; und
eine Frage-Editorschnittstelle (120, 140), die einem Verfasser ermöglicht, in einer Fragedatenstruktur In formationen zu plazieren, die sich auf Fragen bezie hen, die einem Anwender des Produkts gestellt werden können, um beim Identifizieren von Ursachen zu helfen.
2. Verfasserwerkzeug gemäß Anspruch 1, bei dem das Ver
fasserwerkzeug zusätzlich eine Bibliothek von Modulen
aufweist, wobei zumindest eines der Module diagnosti
sche Informationen über eine Komponente des Produkts
enthält.
3. Verfasserwerkzeug gemäß Anspruch 2, bei dem der Ver
fasser die Bibliothek von Modulen auf einer Platten
speichervorrichtung speichern kann, die Bibliothek von
Modulen vom Plattenspeichervorrichtung laden und eine
neue Bibliothek von Modulen erzeugen kann.
4. Verfasserwerkzeug gemäß Anspruch 2 oder 3, bei dem der
Verfasser Module aus der Bibliothek von Modulen beim
Aufbauen des automatisierten diagnostischen Systems
für das Produkt auswählen kann.
5. Verfasserwerkzeug gemäß einem der Ansprüche 2 bis 4,
bei dem der Verfasser neue Module erzeugen und Module
löschen kann.
6. Verfasserwerkzeug gemäß einem der Ansprüche 2 bis 5,
bei dem der Verfasser Module umbenennen und Module aus
anderen Bibliotheken von Modulen importieren kann.
7. Verfasserwerkzeug gemäß einem der Ansprüche 1 bis 6,
bei dem sich die Informationen, die sich auf eine Ur
sache beziehen, auf folgende Kategorien beziehen:
einen Namen (61) der Ursache;
Eltern (62) der Ursache;
eine Erklärung (64) der Ursache; und
eine Wahrscheinlichkeit (363), daß die Ursache vorhan den ist.
einen Namen (61) der Ursache;
Eltern (62) der Ursache;
eine Erklärung (64) der Ursache; und
eine Wahrscheinlichkeit (363), daß die Ursache vorhan den ist.
8. Verfasserwerkzeug gemäß einem der Ansprüche 1 bis 7,
bei dem sich die Informationen, die sich auf eine Ur
sache beziehen, zusätzlich auf folgende Kategorien be
ziehen:
eine Kategorie (65) der Ursache;
eine Abhängigkeit (78) von der Umgebung; und
einen Hinweis, daß ein Kunde nicht auf die Informatio nen zugreifen darf, die sich auf die Ursache beziehen.
eine Kategorie (65) der Ursache;
eine Abhängigkeit (78) von der Umgebung; und
einen Hinweis, daß ein Kunde nicht auf die Informatio nen zugreifen darf, die sich auf die Ursache beziehen.
9. Verfasserwerkzeug gemäß einem der Ansprüche 1 bis 8,
bei dem sich die Informationen, die sich auf eine Ak
tion beziehen, auf folgende Kategorien beziehen:
einen Namen (91) der Aktion;
eine Erklärung (95) der Aktion;
Ursachen (99), die durch die Aktion gelöst werden;
Wahrscheinlichkeiten, daß die Aktion spezifizierte Ur sachen löst;
einen Hinweis (92), ob die Aktion zum Informationssam meln dient oder eine potentielle Lösung ist;
Kosten (96) des Vornehmens der Aktion; und
eine Vertrauenswürdigkeit einer Antwort auf die Akti on.
einen Namen (91) der Aktion;
eine Erklärung (95) der Aktion;
Ursachen (99), die durch die Aktion gelöst werden;
Wahrscheinlichkeiten, daß die Aktion spezifizierte Ur sachen löst;
einen Hinweis (92), ob die Aktion zum Informationssam meln dient oder eine potentielle Lösung ist;
Kosten (96) des Vornehmens der Aktion; und
eine Vertrauenswürdigkeit einer Antwort auf die Akti on.
10. Verfasserwerkzeug gemäß Anspruch 9, bei dem sich die
Informationen, die sich auf eine Aktion beziehen, zu
sätzlich auf folgende Kategorien beziehen:
einen Hinweis, ob die Aktion vor anderen Aktionen vor genommen werden soll;
einen Hinweis (94), ob die Aktion eine Behelfslösung ist;
zusätzliche Aktionen, die in der Aktion enthalten sind;
ob die Aktion nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist; und
ob die Aktion nicht ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist.
einen Hinweis, ob die Aktion vor anderen Aktionen vor genommen werden soll;
einen Hinweis (94), ob die Aktion eine Behelfslösung ist;
zusätzliche Aktionen, die in der Aktion enthalten sind;
ob die Aktion nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist; und
ob die Aktion nicht ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist.
11. Verfasserwerkzeug gemäß einem der Ansprüche 1 bis 10,
bei dem sich die Informationen, die sich auf eine Fra
ge beziehen, auf folgende Kategorien beziehen:
einen Namen (121, 141) der Frage;
eine Erklärung (123, 143) der Frage;
eine Anzahl (122, 143) der Antworten;
Namen der Antworten;
Kosten (124, 144) des Findens einer Antwort auf die Frage; und
eine Vertrauenswürdigkeit der Antwort auf die Frage.
einen Namen (121, 141) der Frage;
eine Erklärung (123, 143) der Frage;
eine Anzahl (122, 143) der Antworten;
Namen der Antworten;
Kosten (124, 144) des Findens einer Antwort auf die Frage; und
eine Vertrauenswürdigkeit der Antwort auf die Frage.
12. Verfasserwerkzeug gemäß Anspruch 11, bei dem sich die
Informationen, die sich auf eine Frage beziehen, zu
sätzlich auf folgende Kategorien beziehen:
ob die Frage nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist;
ob die Frage nicht ausgeführt werden kann, nachdem ei ne spezifizierte Frage beantwortet worden ist;
einen Hinweis, ob die Frage vor anderen Fragen ge stellt werden soll; und
ob die Frage eine Symptomfrage oder eine allgemeine Frage ist.
ob die Frage nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist;
ob die Frage nicht ausgeführt werden kann, nachdem ei ne spezifizierte Frage beantwortet worden ist;
einen Hinweis, ob die Frage vor anderen Fragen ge stellt werden soll; und
ob die Frage eine Symptomfrage oder eine allgemeine Frage ist.
13. Verfasserwerkzeug gemäß Anspruch 11, bei dem sich die
Informationen, die sich auf eine Frage beziehen, spe
ziell auf eine Symptomfrage beziehen und zusätzlich
auf folgende Kategorien beziehen:
Ursachen (148) eines Symptoms;
eine Wahrscheinlichkeit (148) von Antworten auf die Frage, abhängig von Ursachen, die das Symptom verursa chen können; und
eine Wahrscheinlichkeit (148) von Antworten auf die Frage, abhängig von keinen Ursachen, die das Symptom verursachen können.
Ursachen (148) eines Symptoms;
eine Wahrscheinlichkeit (148) von Antworten auf die Frage, abhängig von Ursachen, die das Symptom verursa chen können; und
eine Wahrscheinlichkeit (148) von Antworten auf die Frage, abhängig von keinen Ursachen, die das Symptom verursachen können.
14. Verfasserwerkzeug gemäß Anspruch 11, bei dem sich die
Informationen, die sich auf eine Frage beziehen, spe
ziell auf eine allgemeine Frage und zusätzlich auf
folgende Kategorien beziehen:
vorherige Wahrscheinlichkeiten (129) der Antworten auf die Frage;
Ursachen (129), die durch Antworten auf die Frage be einflußt werden; und
eine Wahrscheinlichkeit der beeinflußten Ursachen ab hängig von jeder Antwort auf die Frage.
vorherige Wahrscheinlichkeiten (129) der Antworten auf die Frage;
Ursachen (129), die durch Antworten auf die Frage be einflußt werden; und
eine Wahrscheinlichkeit der beeinflußten Ursachen ab hängig von jeder Antwort auf die Frage.
15. Verfasserwerkzeug gemäß einem der Ansprüche 1 bis 14,
bei dem:
die Ursachen-Editorschnittstelle (60) einem Verfasser zusätzlich erlaubt, neue Ursacheneinträge zu erzeugen;
die Aktions-Editorschnittstelle (90) einem Verfasser zusätzlich erlaubt, neue Aktionseinträge zu erzeugen; und
die Frage-Editorschnittstelle (120, 140) einem Verfas ser zusätzlich erlaubt, neue Frageeinträge zu erzeu gen.
die Ursachen-Editorschnittstelle (60) einem Verfasser zusätzlich erlaubt, neue Ursacheneinträge zu erzeugen;
die Aktions-Editorschnittstelle (90) einem Verfasser zusätzlich erlaubt, neue Aktionseinträge zu erzeugen; und
die Frage-Editorschnittstelle (120, 140) einem Verfas ser zusätzlich erlaubt, neue Frageeinträge zu erzeu gen.
16. Verfasserwerkzeug gemäß einem der Ansprüche 1 bis 15,
bei dem:
die Ursachen-Editorschnittstelle (60) einem Verfasser zusätzlich erlaubt, vorhandene Ursacheneinträge zu editieren;
die Aktions-Editorschnittstelle (90) einem Verfasser zusätzlich erlaubt, vorhandene Aktionseinträge zu edi tieren; und
die Frage-Editorschnittstelle (120, 140) einem Verfas ser zusätzlich erlaubt, existierende Frageeinträge zu editieren.
die Ursachen-Editorschnittstelle (60) einem Verfasser zusätzlich erlaubt, vorhandene Ursacheneinträge zu editieren;
die Aktions-Editorschnittstelle (90) einem Verfasser zusätzlich erlaubt, vorhandene Aktionseinträge zu edi tieren; und
die Frage-Editorschnittstelle (120, 140) einem Verfas ser zusätzlich erlaubt, existierende Frageeinträge zu editieren.
17. Verfasserwerkzeug gemäß Anspruch 1 bis 16, bei dem:
die Ursachen-Editorschnittstelle (60) einem Verfasser zusätzlich erlaubt, vorhandene Ursacheneinträge zu lö schen;
die Aktions-Editorschnittstelle (90) einem Verfasser zusätzlich erlaubt, vorhandene Aktionseinträge zu lö schen; und
die Frage-Editorschnittstelle (120, 140) einem Verfas ser zusätzlich erlaubt, vorhandene Frageeinträge zu löschen.
die Ursachen-Editorschnittstelle (60) einem Verfasser zusätzlich erlaubt, vorhandene Ursacheneinträge zu lö schen;
die Aktions-Editorschnittstelle (90) einem Verfasser zusätzlich erlaubt, vorhandene Aktionseinträge zu lö schen; und
die Frage-Editorschnittstelle (120, 140) einem Verfas ser zusätzlich erlaubt, vorhandene Frageeinträge zu löschen.
18. Verfasserwerkzeug, das einen Verfasser beim Aufbauen
eines automatisierten diagnostischen Systems unter
stützt, wobei das Verfasserwerkzeug folgende Merkmale
aufweist:
eine Ursachen-Editorschnittstelle (60), die einem Ver fasser ermöglicht, in einer Ursachendatenstruktur In formationen, die sich auf Ursachen beziehen, zu pla zieren, wobei sich die Informationen für eine Ursache auf folgende Kategorien beziehen:
einen Namen (61) der Ursache;
Eltern (62) der Ursache;
eine Erklärung (64) der Ursache; und
eine Wahrscheinlichkeit (63), daß die Ursache vorhan den ist.
eine Ursachen-Editorschnittstelle (60), die einem Ver fasser ermöglicht, in einer Ursachendatenstruktur In formationen, die sich auf Ursachen beziehen, zu pla zieren, wobei sich die Informationen für eine Ursache auf folgende Kategorien beziehen:
einen Namen (61) der Ursache;
Eltern (62) der Ursache;
eine Erklärung (64) der Ursache; und
eine Wahrscheinlichkeit (63), daß die Ursache vorhan den ist.
19. Verfasserwerkzeug gemäß Anspruch 18, bei dem sich die
Informationen, die sich auf die Ursache beziehen, zu
sätzlich auf folgende Kategorien beziehen:
eine Kategorie (65) der Ursache;
eine Abhängigkeit (78) von der Umgebung; und
einen Hinweis, daß ein Kunde nicht auf die Informatio nen, die zu der Ursache gehören, zugreifen darf.
eine Kategorie (65) der Ursache;
eine Abhängigkeit (78) von der Umgebung; und
einen Hinweis, daß ein Kunde nicht auf die Informatio nen, die zu der Ursache gehören, zugreifen darf.
20. Verfasserwerkzeug, das einen Verfasser beim Aufbauen
eines automatisierten diagnostischen Systems unter
stützt, wobei das Verfasserwerkzeug folgende Merkmale
aufweist:
eine Aktions-Editorschnittstelle, die einem Verfasser ermöglicht, Informationen, die sich auf Aktionen be ziehen, die vorgenommen werden können, in einer Akti onsdatenstruktur zu plazieren, wobei sich die Informa tionen für eine Aktion auf folgende Kategorien bezie hen:
einen Namen (91) der Aktion;
eine Erklärung (45) der Aktion;
Ursachen (99), die durch die Aktion gelöst werden;
Wahrscheinlichkeiten, daß die Aktion spezifizierte Ur sachen löst;
einen Hinweis (92), ob die Aktion zum Informationssam meln dient oder eine potentielle Lösung ist;
Kosten (96) des Vornehmens der Aktion; und
eine Vertrauenswürdigkeit einer Antwort auf die Akti on.
eine Aktions-Editorschnittstelle, die einem Verfasser ermöglicht, Informationen, die sich auf Aktionen be ziehen, die vorgenommen werden können, in einer Akti onsdatenstruktur zu plazieren, wobei sich die Informa tionen für eine Aktion auf folgende Kategorien bezie hen:
einen Namen (91) der Aktion;
eine Erklärung (45) der Aktion;
Ursachen (99), die durch die Aktion gelöst werden;
Wahrscheinlichkeiten, daß die Aktion spezifizierte Ur sachen löst;
einen Hinweis (92), ob die Aktion zum Informationssam meln dient oder eine potentielle Lösung ist;
Kosten (96) des Vornehmens der Aktion; und
eine Vertrauenswürdigkeit einer Antwort auf die Akti on.
21. Verfasserwerkzeug gemäß Anspruch 20, bei dem sich die
Informationen, die sich auf die Aktion beziehen, zu
sätzlich auf folgende Kategorien beziehen:
einen Hinweis, ob die Aktion vor anderen Aktionen vor genommen werden soll;
einen Hinweis, ob die Aktion eine Behelfslösung ist;
zusätzliche Aktionen, die in der Aktion enthalten sind;
ob die Aktion nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist; und
ob die Aktion nicht ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist.
einen Hinweis, ob die Aktion vor anderen Aktionen vor genommen werden soll;
einen Hinweis, ob die Aktion eine Behelfslösung ist;
zusätzliche Aktionen, die in der Aktion enthalten sind;
ob die Aktion nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist; und
ob die Aktion nicht ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist.
22. Verfasserwerkzeug, das einen Verfasser beim Bauen ei
nes automatisierten diagnostischen Systems unter
stützt, wobei das Verfasserwerkzeug folgende Merkmale
aufweist:
eine Frage-Editorschnittstelle (120, 140), die einem Verfasser ermöglicht, in einer Fragedatenstruktur In formationen, die sich auf Fragen beziehen, die einem Anwender gestellt werden können, zu plazieren, um da bei zu helfen, Ursachen zu identifizieren, wobei sich die Informationen für eine Frage auf folgende Katego rien beziehen:
einen Namen (121, 141) der Frage;
eine Erklärung (123, 143) der Frage;
eine Anzahl (122, 242) der Antworten;
Namen der Antworten;
Kosten (124, 144) des Findens einer Antwort auf die Frage; und
eine Vertrauenswürdigkeit einer Antwort auf die Frage.
eine Frage-Editorschnittstelle (120, 140), die einem Verfasser ermöglicht, in einer Fragedatenstruktur In formationen, die sich auf Fragen beziehen, die einem Anwender gestellt werden können, zu plazieren, um da bei zu helfen, Ursachen zu identifizieren, wobei sich die Informationen für eine Frage auf folgende Katego rien beziehen:
einen Namen (121, 141) der Frage;
eine Erklärung (123, 143) der Frage;
eine Anzahl (122, 242) der Antworten;
Namen der Antworten;
Kosten (124, 144) des Findens einer Antwort auf die Frage; und
eine Vertrauenswürdigkeit einer Antwort auf die Frage.
23. Verfasserwerkzeug gemäß Anspruch 22, bei dem sich die
Informationen, die sich auf die Frage beziehen, zu
sätzlich auf folgende Kategorien beziehen:
ob die Frage nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist;
ob die Frage nicht ausgeführt werden kann, nachdem ei ne spezifizierte Frage beantwortet worden ist;
ein Hinweis, ob die Frage vor anderen Fragen gestellt werden soll; und
ob die Frage eine Symptomfrage oder eine allgemeine Frage ist.
ob die Frage nur ausgeführt werden kann, nachdem eine spezifizierte Frage beantwortet worden ist;
ob die Frage nicht ausgeführt werden kann, nachdem ei ne spezifizierte Frage beantwortet worden ist;
ein Hinweis, ob die Frage vor anderen Fragen gestellt werden soll; und
ob die Frage eine Symptomfrage oder eine allgemeine Frage ist.
24. Verfasserwerkzeug gemäß Anspruch 22 oder 23, bei dem
sich die Informationen, die sich auf die Frage bezie
hen, speziell auf eine Symptomfrage und zusätzlich auf
folgende Kategorien beziehen:
Ursachen (148) eines Symptoms;
eine Wahrscheinlichkeit (148) von Antworten auf die Frage abhängig von den Ursachen, die das Symptom ver ursachen können; und
eine Wahrscheinlichkeit (148) der Antworten auf die Frage abhängig von keinen Ursachen, die das Symptom verursachen können.
Ursachen (148) eines Symptoms;
eine Wahrscheinlichkeit (148) von Antworten auf die Frage abhängig von den Ursachen, die das Symptom ver ursachen können; und
eine Wahrscheinlichkeit (148) der Antworten auf die Frage abhängig von keinen Ursachen, die das Symptom verursachen können.
25. Verfasserwerkzeug gemäß Anspruch 22 bis 24, bei dem
sich die Informationen, die sich auf die Frage bezie
hen, speziell auf eine allgemeine Frage und zusätzlich
auf folgende Kategorien beziehen:
vorherige Wahrscheinlichkeiten (129) der Antworten auf eine Frage;
Ursachen (129), die durch Antworten auf die Frage be einflußt werden; und
eine Wahrscheinlichkeit der beeinflußten Ursachen ab hängig von jeder Antwort auf die Frage.
vorherige Wahrscheinlichkeiten (129) der Antworten auf eine Frage;
Ursachen (129), die durch Antworten auf die Frage be einflußt werden; und
eine Wahrscheinlichkeit der beeinflußten Ursachen ab hängig von jeder Antwort auf die Frage.
26. Verfasserwerkzeug, das einen Verfasser beim Aufbauen
eines automatisierten diagnostischen Systems unter
stützt, wobei das Verfasserwerkzeug folgende Merkmale
aufweist:
eine diagnostische Systemmodell-Editorschnittstelle, die dem Verfasser ermöglicht, in einer diagnostischen Systemmodellstruktur Informationen, die sich auf eine Diagnose beziehen, zu plazieren; und
eine Bibliotheksmodul-Editorschnittstelle, die dem Verfasser ermöglicht, in einer Bibliotheksdatenstruk tur Informationen, die sich auf Module beziehen, ent sprechend den Komponenten eines Produkts zu plazieren.
eine diagnostische Systemmodell-Editorschnittstelle, die dem Verfasser ermöglicht, in einer diagnostischen Systemmodellstruktur Informationen, die sich auf eine Diagnose beziehen, zu plazieren; und
eine Bibliotheksmodul-Editorschnittstelle, die dem Verfasser ermöglicht, in einer Bibliotheksdatenstruk tur Informationen, die sich auf Module beziehen, ent sprechend den Komponenten eines Produkts zu plazieren.
27. Verfasserwerkzeug gemäß Anspruch 26, bei dem die In
formationen, die sich auf Module beziehen, entspre
chend den Komponenten des Produkts folgende Merkmale
aufweisen:
einen Namen einer Komponente eines Moduls;
Ursachen der Komponentenstörung;
Aktionen, die die Störung der Komponente lösen können; und
Fragen, die Informationen über die Ursachen der Kompo nentenstörung liefern können.
einen Namen einer Komponente eines Moduls;
Ursachen der Komponentenstörung;
Aktionen, die die Störung der Komponente lösen können; und
Fragen, die Informationen über die Ursachen der Kompo nentenstörung liefern können.
28. Verfasserwerkzeug gemäß Anspruch 26 oder 27, bei dem
die Informationen, die sich auf die Diagnose beziehen,
folgende Merkmale aufweisen:
einen Namen eines Problems;
Ursachen des Problems;
Aktionen, die beim Lösen des Problems helfen können;
Fragen, die Informationen über das Problem liefern können; und
ein Zeitbetrag, der zum Beobachten, ob das Problem vorhanden ist, erforderlich ist.
einen Namen eines Problems;
Ursachen des Problems;
Aktionen, die beim Lösen des Problems helfen können;
Fragen, die Informationen über das Problem liefern können; und
ein Zeitbetrag, der zum Beobachten, ob das Problem vorhanden ist, erforderlich ist.
29. Verfasserwerkzeug gemäß einem der Ansprüche 26 bis 28,
bei dem der Verfasser ein neues diagnostisches System
modell erzeugen, diagnostische Systemmodelle vom Plat
tenspeicher laden, die diagnostischen Systemmodelle
auf dem Plattenspeicher sichern kann, so daß die dia
gnostischen Systemmodelle durch eine externe diagno
stische Systemsoftware betrieben werden können, die
diagnostischen Systemmodelle in Textformat gesichert
werden können und ein diagnostisches Systemmodell in
Textformat gedruckt werden kann.
30. Verfasserwerkzeug gemäß einem der Ansprüche 26 bis 29,
bei dem der Verfasser Ursachen, Aktionen und Fragen
aus einem aktuellen diagnostischen Systemmodell auf
ein aktuelles Bibliotheksmodul exportieren kann, und
Ursachen, Aktionen und Fragen von dem aktuellen Bi
bliotheksmodul auf das aktuelle diagnostisches System
modul exportieren kann.
31. Verfasserwerkzeug gemäß Anspruch 27, bei dem der Ver
fasser einen Überblick über alle Ursachen in der Bi
bliotheksdatenstruktur zum schnellen Nachsehen und
Einbringen erlangen kann, einen Überblick über alle
Aktionen in der Bibliotheksdatenstruktur zum schnellen
Nachsehen und Einbringen erlangen kann, und einen
Überblick über alle Fragen in der Bibliotheksdaten
struktur zum schnellen Nachsehen und Einbringen erlan
gen kann.
32. Verfasserwerkzeug gemäß Anspruch 31, bei dem der Ver
fasser neue Kategorien von Ursachen zu den Modulen
hinzufügen kann, und Ursachen, die in spezifische Ka
tegorien fallen, nachsehen kann.
33. Verfasserwerkzeug gemäß einem der Ansprüche 26 bis 32,
bei dem der Verfasser Ursachen in einer Baumstruktur
ansehen kann, Sätze von Wahrscheinlichkeiten für jedes
Niveau von Ursachen in der Baumstruktur spezifizieren
kann und die Wahrscheinlichkeiten auf jedem Niveau der
Ursachen in der Baumstruktur normieren kann.
34. Ein Verfasserwerkzeug, das einen Verfasser beim Auf
bauen eines automatisierten Auswahlsystems unter
stützt, wobei das Verfasserwerkzeug folgende Merkmale
aufweist:
eine Auswahl-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Auswahldatenstruktur Informatio nen, die sich auf Auswahlen beziehen, zu plazieren;
eine Aktions-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Aktionsdatenstruktur Informatio nen, die sich auf Aktionen beziehen, die ansprechend auf die Auswahlen vorgenommen werden können, zu pla zieren; und
eine Frage-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Fragedatenstruktur Informationen, die sich auf Fragen beziehen, die einem Anwender des Produkts gestellt werden können, um beim Identifizie ren der Auswahl zu helfen, zu plazieren.
eine Auswahl-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Auswahldatenstruktur Informatio nen, die sich auf Auswahlen beziehen, zu plazieren;
eine Aktions-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Aktionsdatenstruktur Informatio nen, die sich auf Aktionen beziehen, die ansprechend auf die Auswahlen vorgenommen werden können, zu pla zieren; und
eine Frage-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Fragedatenstruktur Informationen, die sich auf Fragen beziehen, die einem Anwender des Produkts gestellt werden können, um beim Identifizie ren der Auswahl zu helfen, zu plazieren.
35. Verfasserwerkzeug, das einen Verfasser beim Aufbauen
eines automatisierten Entscheidungsunterstützungssy
stems hilft, wobei das Verfasserwerkzeug folgende
Merkmale aufweist:
eine Situations-Editorschnittstelle, die einem Verfas ser ermöglicht, in einer Situationsdatenstruktur In formationen, die sich auf Situationen beziehen, zu plazieren;
eine Aktions-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Aktionsdatenstruktur Informatio nen, die sich auf Aktionen beziehen, die ansprechend auf die Situationen vorgenommen werden können, zu pla zieren; und
eine Frage-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Fragedatenstruktur Informationen, die sich auf Fragen beziehen, die einem Anwender des Produkts gestellt werden können, um beim Identifizie ren von Situationen zu helfen, zu plazieren.
eine Situations-Editorschnittstelle, die einem Verfas ser ermöglicht, in einer Situationsdatenstruktur In formationen, die sich auf Situationen beziehen, zu plazieren;
eine Aktions-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Aktionsdatenstruktur Informatio nen, die sich auf Aktionen beziehen, die ansprechend auf die Situationen vorgenommen werden können, zu pla zieren; und
eine Frage-Editorschnittstelle, die einem Verfasser ermöglicht, in einer Fragedatenstruktur Informationen, die sich auf Fragen beziehen, die einem Anwender des Produkts gestellt werden können, um beim Identifizie ren von Situationen zu helfen, zu plazieren.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/738,716 US7016056B2 (en) | 1999-09-02 | 2000-12-16 | Authoring tool for bayesian network diagnostic systems |
Publications (1)
Publication Number | Publication Date |
---|---|
DE10161332A1 true DE10161332A1 (de) | 2002-07-25 |
Family
ID=24969189
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10161332A Ceased DE10161332A1 (de) | 2000-12-16 | 2001-12-13 | Verfasserwerkzeug für diagnostische Systeme in Bayes-Netzwerken |
Country Status (4)
Country | Link |
---|---|
US (1) | US7016056B2 (de) |
JP (1) | JP2002202890A (de) |
DE (1) | DE10161332A1 (de) |
GB (1) | GB2375853B (de) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7212300B2 (en) * | 2000-04-06 | 2007-05-01 | Illinois Tool Works, Inc. | Printing systems accessible from remote locations |
US6687685B1 (en) * | 2000-04-07 | 2004-02-03 | Dr. Red Duke, Inc. | Automated medical decision making utilizing bayesian network knowledge domain modeling |
US20040012808A1 (en) * | 2001-06-04 | 2004-01-22 | Payne David M. | Network-based technical support and diagnostics |
DE10227542A1 (de) * | 2002-06-20 | 2004-01-15 | Merck Patent Gmbh | Verfahren und System zum Erfassen und Analysieren von Krankheitsbildern und deren Ursachen sowie zum Ermitteln passender Therapievorschläge |
US20040143561A1 (en) * | 2002-11-14 | 2004-07-22 | Jensen Finn Verner | Method for problem solving in technical systems with redundant components and computer system for performing the method |
US20050050182A1 (en) * | 2003-08-26 | 2005-03-03 | Xerox Corporation | Peripheral device diagnostic method and architecture |
US7580909B2 (en) * | 2003-08-26 | 2009-08-25 | Northrop Grumman Corporation | Visual representation tool for structured arguments |
US20050097070A1 (en) * | 2003-10-30 | 2005-05-05 | Enis James H. | Solution network decision trees |
US7599861B2 (en) | 2006-03-02 | 2009-10-06 | Convergys Customer Management Group, Inc. | System and method for closed loop decisionmaking in an automated care system |
US8379830B1 (en) | 2006-05-22 | 2013-02-19 | Convergys Customer Management Delaware Llc | System and method for automated customer service with contingent live interaction |
US7809663B1 (en) | 2006-05-22 | 2010-10-05 | Convergys Cmg Utah, Inc. | System and method for supporting the utilization of machine language |
US8341610B2 (en) * | 2007-03-15 | 2012-12-25 | International Business Machines Corporation | Method and apparatus for authoring and optimizing flowcharts |
US20090042044A1 (en) * | 2007-08-08 | 2009-02-12 | David Abecassis | Novel nanocomposite coating for the reduction of pigment particles loss and UV fade and chemical degradation for decorative & structural products made from concrete and concrete composites |
US8352309B2 (en) * | 2008-08-19 | 2013-01-08 | International Business Machines Corporation | Defining a serviceability assessment measure |
US20100057708A1 (en) * | 2008-09-03 | 2010-03-04 | William Henry Billingsley | Method and System for Computer-Based Assessment Including a Search and Select Process |
US9542139B2 (en) * | 2009-01-13 | 2017-01-10 | Canon Europa N.V. | Network printing system having a print server and a logon server |
US9251309B2 (en) * | 2011-09-21 | 2016-02-02 | GM Global Technology Operations LLC | Cost-optimized model-based extension of system life |
WO2014189500A1 (en) * | 2013-05-22 | 2014-11-27 | Hewlett-Packard Development Company, L.P. | Production simulation |
IN2013CH03925A (de) * | 2013-09-02 | 2015-09-11 | Appnomic Systems Private Ltd | |
US9805343B2 (en) * | 2016-01-05 | 2017-10-31 | Intermec Technologies Corporation | System and method for guided printer servicing |
US10970634B2 (en) * | 2016-11-10 | 2021-04-06 | General Electric Company | Methods and systems for capturing analytic model authoring knowledge |
US10545813B2 (en) * | 2017-12-11 | 2020-01-28 | Sap Se | Database diagnostic engine |
US20210133852A1 (en) * | 2019-10-30 | 2021-05-06 | Deal.Com Inc. | Advisor interface systems and methods |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4891766A (en) * | 1987-06-15 | 1990-01-02 | International Business Machines Corporation | Editor for expert system |
US4965742A (en) * | 1987-09-30 | 1990-10-23 | E. I. Du Pont De Nemours And Company | Process control system with on-line reconfigurable modules |
JP2985505B2 (ja) * | 1991-07-08 | 1999-12-06 | 株式会社日立製作所 | 品質情報収集診断システム及びその方法 |
US5539869A (en) * | 1992-09-28 | 1996-07-23 | Ford Motor Company | Method and system for processing and presenting on-line, multimedia information in a tree structure |
US5963931A (en) * | 1992-10-05 | 1999-10-05 | Expert Systems Publishing Co. | Computer-assisted decision management system |
US7385716B1 (en) * | 1999-09-02 | 2008-06-10 | Hewlett-Packard Development Company, L.P. | Authoring tool for bayesian network troubleshooters |
-
2000
- 2000-12-16 US US09/738,716 patent/US7016056B2/en not_active Expired - Lifetime
-
2001
- 2001-11-22 JP JP2001357161A patent/JP2002202890A/ja active Pending
- 2001-12-07 GB GB0129380A patent/GB2375853B/en not_active Expired - Lifetime
- 2001-12-13 DE DE10161332A patent/DE10161332A1/de not_active Ceased
Also Published As
Publication number | Publication date |
---|---|
US20020044296A1 (en) | 2002-04-18 |
JP2002202890A (ja) | 2002-07-19 |
GB0129380D0 (en) | 2002-01-30 |
GB2375853B (en) | 2005-02-16 |
GB2375853A (en) | 2002-11-27 |
US7016056B2 (en) | 2006-03-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10161332A1 (de) | Verfasserwerkzeug für diagnostische Systeme in Bayes-Netzwerken | |
DE60007587T2 (de) | Automatische diagnostik von drucker-systemen mittels bayesianischen netzwerken | |
DE10036737A1 (de) | Verfassungswerkzeug für Fehlersucheinrichtungen in Bayesschen Netzwerken | |
DE69333854T2 (de) | Automatisches Aufrufen von Rechnermitteln ohne Bedienereingriff | |
DE68929289T2 (de) | Expertensystem für fehlerdiagnose | |
Breuker et al. | Use of models in the interpretation of verbal data | |
DE10222687B4 (de) | Modellauswahl für Entscheidungsunterstützungssysteme | |
DE69523588T2 (de) | Gerät und methode zur ereigniskorrelation und problemmeldung | |
DE19717716C5 (de) | Verfahren zur automatischen Diagnose technischer Systeme | |
DE69023389T2 (de) | "Unbekannt"-Antwortverarbeitung in einem Expertendiagnosesystem. | |
Kim et al. | A survey of knowledge acquisition techniques and their relevance to managerial problem domains | |
DE102004015504A1 (de) | Verfahren und Vorrichtung zur diagnostischen Wahl eines Wartungskonzepts für ein komplexes System | |
DE69214171T2 (de) | Fehlerdiagnose durch Prozess-Simulation | |
WO2002013015A1 (de) | System zur ermittlung von fehlerursachen | |
DE4305522C2 (de) | Einrichtung zur rechnergestützten Diagnose eines aus Modulen bestehenden technischen Systems | |
DE102021126866A1 (de) | Erleichterung eines automatisierten, interaktiven, konversationellen Dialogs zur Fehlerbehebung bei einem Produktunterstützungsproblem über einen Chatbot | |
DE60219821T2 (de) | Verfahren und gerät zum wiedergewinnen von zeitreihedaten, die mit einer aktivität in beziehung stehen | |
DE102004015503A1 (de) | Verfahren und Vorrichtung zum Korrigieren diagnostischer Analysekonzepte in komplexen Systemen | |
DE102004015501A1 (de) | Verfahren und Vorrichtung für Wartbarkeit komplexer Systeme | |
DE69022783T2 (de) | Verfahren zur Unterstützung des Benutzers eines Rechnersystems und Vorrichtung zur Durchführung des besagten Verfahrens. | |
Mahling et al. | Relating human knowledge of tasks to the requirements of plan libraries | |
Allen | The development of an artificial intelligence system for inventory management using multiple experts | |
DE102011079034A1 (de) | Ansteuerung eines technischen Systems | |
binti Abdullah | The fundamentals of case-based reasoning: application to a building defect problem | |
Mockler | Using knowledge‐based systems for estimating risks inherent in a proposed KBS project |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8127 | New person/name/address of the applicant |
Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE |
|
8131 | Rejection |