DE10161332A1

DE10161332A1 - Verfasserwerkzeug für diagnostische Systeme in Bayes-Netzwerken

Info

Publication number: DE10161332A1
Application number: DE10161332A
Authority: DE
Inventors: Claus Skaanning
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2000-12-16
Filing date: 2001-12-13
Publication date: 2002-07-25
Also published as: US20020044296A1; US7016056B2; GB2375853B; JP2002202890A; GB2375853A; GB0129380D0

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 2^N für N Variablen (10²⁴ 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, . . ., w_n ist eine konditionale Wahrscheinlichkeitstabelle P(v|w₁, . . ., w_n) 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 c₁, . . ., c_n 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 p_i die Wahrscheinlichkeit bezeichnet, daß die Komponente c_i angesichts des aktuellen Zustands der Informationen unnormal ist, dann ist n|i=1p_i = 1 gemäß der Einzelfehlerannahme. Jede Komponente c_i 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 p_i, die mit aktuellen Informationen aktualisiert sind, immer optimal ist, die Komponente, die das höchste Verhältnis p_i/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:

Tabelle 1 Schritt 1

Berechne die Wahrscheinlichkeiten der Komponen tenfehler p_i angesichts der Tatsache, daß die Vorrichtung nicht funktioniert.

Schritt 2

Beobachte die Komponente mit dem höchsten Ver hältnis p_i/C 0|i.

Schritt 3

Wenn die Komponente fehlerhaft ist, dann muß sie repariert werden.

Schritt 4

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:

Tabelle 2 Schritt 1

Schritt 2

Beobachte die Komponente mit dem höchsten Ver hältnis p_i/C 0|i.

Schritt 3

Wenn die Komponente fehlerhaft ist, dann muß sie repariert werden.

Schritt 4

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:

Tabelle 3

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:

Tabelle 4

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:

Tabelle 5

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 A_i wird für jede Ursache C_j in Betracht ge zogen, ob eine Nicht-Null-Wahrscheinlichkeit besteht, daß das Ausführen von A_i C_j 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 Q_i wird für jede Ursache C_j in Betracht ge zogen, ob eine Antwort auf Q_i direkt die Überzeugung in C_j 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:

Tabelle 6

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:

Tabelle 7

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:

Tabelle 8

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:

Tabelle 9

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 C_i unter der Annahme, daß C_i 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ß C_i 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ß C_i 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 P₁ be zeichnet wird und die gefundene Wahrscheinlichkeit beim Be antworten der zweiten WahrscheinlichkeitsHerausholungsfrage mit P₂ bezeichnet wird, wird anschließend die Gesamtwahr scheinlichkeit der Aktion, die das Problem angesichts der Ursache C_i löst, folgendermaßen festgestellt:

P(A = ja|C_i = ja) = P₁ (1 - P₂)

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:

Tabelle 10

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ß C_i 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.

Tabelle 11

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?

A₁, wenn Zeit = 20, Risiko = mittel
A₂, 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:

Tabelle 12

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:

Tabelle 13

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:

Tabelle 14

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:

Name

Der Name der Fehlerkondition, die mit dem diagnostischen Modell dargestellt wird.

Erklärung

Eine Erklärung dessen, was genau die Fehler kondition ist, einschließlich Informationen darüber, wie diese auftritt.

Problembeobachtungszeit

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

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:

Tabelle 15

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:

Tabelle 16

Bibliothek

- Liste von Modulen
- Liste von Kategorien

Ein Modul weist dieselbe Struktur wie ein Modell auf, das in Tabelle 17 unten aufgeführt ist:

Tabelle 17

Modul

Eine Ursache weist eine Datenstruktur auf, die wie in Ta belle 18 unten aufgeführt ist:

Tabelle 18

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:

Tabelle 19

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 Zustand₁ beant wortet worden ist.
- Zustand₁
- nicht nach Frage: falls spezifiziert, kann die Aktion nicht vorgeschlagen werden, wenn die Frage im Zustand₂ beantwortet worden ist.
- Zustand₂
- 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 Zustand₃ festgelegt, wenn die Aktion nicht ausgeführt worden ist
- Zustand₃
- 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:

Tabelle 20

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: Zustand₄
- Zustand₄
- 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:

Tabelle 21

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: Zustand₄
- Zustand₄
- 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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.