DE69935103T2

DE69935103T2 - System zur dynamischen Diagnose einer Vorrichtung

Info

Publication number: DE69935103T2
Application number: DE69935103T
Authority: DE
Inventors: Paul J. Grayslake Rother
Original assignee: Snap On Inc; Snap On Tools Corp
Current assignee: Snap On Inc
Priority date: 1998-10-27
Filing date: 1999-04-23
Publication date: 2007-08-09
Anticipated expiration: 2019-04-24
Also published as: ES2279588T3; TW460687B; EP0997638B1; US9562830B2; US20050137762A1; KR20000028587A; US8620511B2; EP0997638A3; CA2268689C; US20140081510A1; US6845307B2; DE69935103D1; US20030195681A1; AU3506499A; US6615120B1; AU754578B2; US6141608A; EP0997638A2; CA2268689A1

Description

Die Erfindung bezieht sich auf ein Verfahren gemäß dem Oberbegriff von Anspruch 1.
Ein solches Verfahren ist aus US 4,796,206 bekannt. Gemäß dem offenbarten Verfahren wählt der Benutzer die Art der erwünschten Unterstützung, wobei die Unterstützung eine Fahrzeugserviceprozedur (VSP = Vehicle Service Procedure) enthält. Als nächstes erfasst eine Fehlererfassungsprozedur (FDP = Fault Detection Procedure) Fehler durch Abfragen von Daten, die von einem Boardcomputer empfangen werden. Die erfassten Fehler werden in einer Fehleranalyseprozedur nachgeschlagen, und wenn eine entsprechende Zeile in der Analysetabelle gefunden wird, wird der entsprechende Fehler verarbeitet (FIP(s) = Fault Is Processed).
Hintergrund der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf Test- und Diagnosesysteme für Maschinen und andere arbeitende Vorrichtungen und hat eine besondere Anwendung auf selbstbewegliche Fahrzeuge, insbesondere Fahrzeuge, die durch Verbrennungsmotoren versorgt werden. Während die Erfindung in dem Kontext eines Motoranalysatorsystems beschrieben wird, sind die Prinzipien der vorliegenden Erfindung auch bei anderen Arten von Fahrzeugdiagnosesystemen anwendbar wie z.B. den Klimatisierungstest- und Servicesystemen, den Radbalancierungssystemen, den Autogasemissionsanalysesystemen und dergleichen, und sie sind auch mit Nicht-Automobil-Vorrichtungen verwendbar.
Eine Anzahl unterschiedlicher Arten von Diagnosewerkzeugen wurden bisher verwendet, um bei der Diagnose und Reparatur von Fehlerbedingungen bei Automobilen zu helfen. Solche Werkzeuge enthalten Motoranalysatoren, die entworfen sind, eine Vielfalt von Betriebszuständen eines Verbrennungsmotors zu überwachen, und Scanner zum Herunterladen von Daten von Fahrzeugbordcomputern. Zusätzlich können Diagnosewerkzeuge solche Standardlaborwerkzeuge enthalten wie z.B. Laboroszilloskope, digitale Volt/Ohm-Meter ("DVOM") und dergleichen. Im Grunde fallen diese verschiedenen Diagnosewerkzeuge in zwei Kategorien, Datenlieferer und Plattformdiagnose, auch wenn einige Motoranalysatoren wie z.B. der in dem US-Patent Nr. 5,250,935 offenbarte mit Scannern wechselwirken können und in einer Betriebsart arbeiten können, die ein Laboratoroszilloskop und/oder ein DVOM simuliert.
Datenlieferer (z.B. DVM, Scanner und Laboroszilloskope) geben dem Benutzer einfach Daten, und der Benutzer muss seine eigenen Diagnosetestverfahren und -schlüsse festlegen. Datenlieferwerkzeuge stützen sich komplett auf die Fähigkeit des Benutzers, zu entscheiden, welches Werkzeug er verwenden und was er mit den gelieferten Daten anfangen soll, einschließlich der Auswahl von Tests, die durchgeführt werden sollen, das Interpretieren der Testergebnisse und dergleichen.
Plattformprodukte, z.B. Motoranalysatoren, sind typischerweise hochgradige Systeme, die in der Lage sind, eine Vielfalt unterschiedlicher Arten von Tests durchzuführen. Sie können dem Benutzer automatische Testabfolgen bereitstellen, die das Fahrzeug in einer bestimmten Reihenfolge systematisch testen und dann auf der Grundlage der Testergebnisse Diagnoseschlüsse liefern. Plattformprodukte wie z.B. Motoranalysatoren sind im allgemeinen konzentriert auf bestimmte Arten von Problemen oder bestimmte Fahrzeugsysteme. Es kann eine beträchtliche Zeit in Anspruch nehmen, alle erforderlichen Anschlüsse zusammenzuschalten und die umfangreichen Tests durchzuführen, und der Benutzer muss entscheiden, welches Produkt er verwendet und wie die Testdaten in eine Gesamtdiagnose integriert werden sollen.
Es gibt auch Informationssysteme, die als alleinstehende Softwarepakete erhältlich sind, die Service und Reparaturinformation für eine große Vielfalt von Automobilen bereitstellen. Es ist jedoch schwierig, durch solche Produkte hindurchzufinden, um die Information zu finden, die für die Diagnose und die Reparatur erforderlich ist, und sie beruhen typischerweise nur auf der Originalausrüstungsdiagnoseinformation und können keine Information über Probleme enthalten, die draußen über die Lebensdauer des Fahrzeugs festgestellt wurden.
Zusammenfassung der Erfindung
Es ist eine allgemeine Aufgabe der Erfindung, ein verbessertes Diagnoseverfahren bereitzustellen, das die Nachteile der Systeme des Standes der Technik vermeidet, während es zusätzliche strukturelle und Betriebsvorteile bietet.
Diese Aufgabe wird erfüllt durch das Verfahren nach Anspruch 1.
Ein wichtiges Merkmal der Erfindung ist das Bereitstellen eines Diagnosesystems, das den Benutzer bei der Auswahl der durchzuführenden Tests führt und das Durchführen unnützer Tests minimiert.
In Verbindung mit dem vorigen Merkmal ist ein weiteres wichtiges Merkmal das Bereitstellen eines Diagnosesystems des dargelegten Typs, das eine fehlerbasierte Auswahl von Tests ermöglicht.
Noch ein weiteres wichtiges Merkmal ist das Bereitstellen eines Diagnosesystems des dargelegten Typs, das eine Abwandlung und Aktualisierung erleichtert, um Informationen über Probleme und Lösungen einzuschließen, die über die Lebensdauer einer zu testenden Vorrichtung in dem Feld erfahren wurden.
Noch ein weiteres wichtiges Merkmal ist das Bereitstellen eines Diagnosesystems des dargelegten Typs, das einfach in bereits existierende Diagnosehardwareplattformen integriert werden kann.
In Verbindung mit dem vorigen Merkmal ist noch ein weiteres wichtiges Merkmal das Bereitstellen eines Diagnosesystems des dargelegten Typs, das modular ist.
Noch ein weiteres wichtiges Merkmal ist das Bereitstellen eines Diagnosesystems des dargelegten Typs, das dazu entworfen ist, ausgewählte Tests in einer Reihenfolge einzuordnen, die am wahrscheinlichsten ein Problem der Vorrichtung erfolgreich diagnostiziert.
Ein weiteres wichtiges Merkmal ist das Bereitstellen eines Diagnosesystems des dargelegten Typs, das das Speichern der Ergebnisse der Benutzeranwendungen des Systems enthält zum späteren Einbringen in Systemaktualisierungen.
Kurzbeschreibung der Zeichnungen
Zum Zweck des Erleichterns eines Verstehens der Erfindung wird in den beigefügten Zeichnungen eine bevorzugte Ausführungsform veranschaulicht, aus deren Betrachtung, wenn sie in Verbindung mit der folgenden Beschreibung betrachtet wird, die Erfindung, ihr Aufbau und Betrieb und viele ihrer Vorteile einfach verstanden und geschätzt werden sollen.
1 ist ein Funktionsblockdiagramm eines Motoranalysators, der ein Diagnosesystem der vorliegenden Erfindung enthält.
2-5 sind Bildschirmanzeigen eines Motoranalysators, der das Diagnosesystem der vorliegenden Erfindung enthält.
6 ist ein Flussdiagramm eines Softwareprogramms für das Diagnosesystem der vorliegenden Erfindung.
Beschreibung der bevorzugten Ausführungsform
Mit Bezug auf 1 wird ein Funktionsblockdiagramm einer Diagnoseplattform 10 veranschaulicht, die das Diagnosesystem der vorliegenden Erfindung enthält. Die Plattform 10 wird so veranschaulicht, dass sie sich auf ein Motoranalysatorsystem bezieht, aber wie oben angegeben, könnte sie auf andere Arten von Diagnosesystemen für Fahrzeuge oder Nicht-Fahrzeuge angewendet werden. Die Plattform 10 enthält eine Motoranalysatorhardware 11, die typischerweise einen Testanschlussausleger 12 mit einer Mehrzahl von Testanschlüssen und Sensoren, die daran angepasst sind, an verschiedenen Punkten eines zugeordneten Fahrzeugmotors angeschlossen zu werden, und eine Signalverarbeitungs- und -aufbereitungshardware enthält, um den Testanschlussausleger an einen Hauptprozessor 14 anzukoppeln. Vorzugsweise ist die Diagnoseplattform 10 eine Plattform auf der Grundlage eines persönlichen Computers ("PC") mit Windows^® wie z.B. diejenige in dem von Snap-On Diagnostics vertriebenen Sun^® System 500 Motoranalysator, aber es ist klar, dass die vorliegende Erfindung auch mit anderen Arten von Motoranalysatorsystemen verwendbar wären wie z.B. mit dem in dem US-Patent Nr. 5,250,935 offenbarten.
Die Diagnoseplattform 10 enthält typischerweise eine Benutzerschnittstelle, die eine oder mehrere verschiedene Eingabe/Ausgabe-Vorrichtungen enthalten kann wie z.B. eine Tastatur 16, eine Maus 17, eine Anzeigevorrichtung bzw. einen Bildschirm 18 und einen Drucker 19. Die Diagnoseplattform 10 ist typischerweise auch mit einem Speichermedium 20 versehen, das eines oder mehrere aus einer Anzahl verschiedener Arten von Daten- und Softwarespeichervorrichtungen enthalten kann einschließlich eines RAM 21, eines ROM 22, eines CD-ROM-Laufwerks 23, eines Diskettenlaufwerks 24 und eines Festplattenlaufwerks 25. Das dynamische Diagnosesystem der vorliegenden Erfindung enthält Programmsoftware, die in dem ROM 22 angesiedelt sein kann, oder die ein alleinstehendes Softwarepaket enthalten kann, das in einem beliebigen der Medien 23-25 gespeichert ist.
Ein grundlegender Aspekt der Erfindung besteht darin, dass sie eine fehlerbasierte Fahrverhaltensdiagnose eines Fahrzeugs liefert. In einer solchen fehlerbasierten Betriebsart präsentiert das System dem Benutzer im wesentlichen ein Menü von angezeigten Problemen, z.B. durch Symbole oder Servicecodes, und der Benutzer wählt diejenigen Probleme, die für das Testfahrzeug einschlägig sind. Auf der Grundlage der gewählten Fehler präsentiert das System dem Benutzer dann eine Liste von Tests, die zum Diagnostizieren der Ursache oder Ursachen der Fehler durchgeführt werden sollen. Die Tests sind auf der Grundlage der Herstellerinformation und vorheriger Reparatur- und Diagnoseerfahrung mit dieser Art von Fahrzeug in der Reihenfolge aufgelistet, in der sie am wahrscheinlichsten beim Diagnostizieren der Fahrzeugfehler wirken.
Ein bedeutender Aspekt der Erfindung ist es, dass das Diagnosesystem auch fähig ist, in anderen Betriebsarten zu arbeiten, nämlich einem Systemtestmodus, einem Komponententestmodus und einem manuellen Modus. In allen Betriebsarten außer dem manuellen Modus zeigt das System einen oder mehrere an dem Fahrzeug durchzuführende Tests aus einer Bibliothek von Systemtests und Komponententests an, von denen repräsentative Beispiele in den Zeichnungen dargestellt sind.
Jede Verwendung des Diagnosesystems der vorliegenden Erfindung beginnt mit einer Fahrzeugidentifikationsprozedur für das zu diagnostizierende Fahrzeug. Mit Bezug auf 2 wird eine Bildschirmanzeige 30 auf dem Bildschirm 18 dargestellt, die eine digitale Computeranzeige sein kann. Auf dem oberen Teil des Anzeigeschirms 30 ist eine Reihe von Symbolen 31-35 aufgereiht, die jeweils mit "Vehicle Identification" (Fahrzeugidentifizierung), "Test/Analysis" (Test/Analyse), "Manual Testing" (Manuelles Testen), "Information" und "Shop Management" (Werkstattverwaltung) bezeichnet sind. Zum Durchführen der Fahrzeugidentifizierungsprozedur wird das Symbol 31 gewählt, was die in 2 dargestellte Bildschirmanzeige hervorruft. Das System zeigt dem Benutzer eine Anzahl von Fragen oder Feldern wie z.B. Modelljahr, Marke, Modellname, Motorgröße und dergleichen, wobei jedes Feld dem Benutzer ein Menü von eindeutigen Werten innerhalb dieses Feldes liefert, aus dem der Benutzer wählen kann. Der Benutzer führt in einer wohlbekannten Weise wie z.B. durch Verwendung der Maus 17 eine Auswahl für dieses Feld durch, und der Wert wird dem Datenbanksuchschlüssel hinzugefügt. 2 zeigt mehrere solcher Felder und die damit verbundenen Menüs. Wenn ein Menü die Länge des zugeordneten Anzeigefensters überschreitet, kann das Menü in einer bekannten Weise unter Verwendung eines Bildlaufleistensymbols durchgerollt werden. Das System ist dynamisch bezüglich der Anzahl von Fragen, die der Benutzer beantworten muss, um das Fahrzeug zu identifizieren, was es dem Benutzer ermöglicht, das Fahrzeug zu identifizieren, ohne irgendwelche überflüssigen Fragen beantworten zu müssen. Um eine Systemdiagnose durchzuführen, muss die Fahrzeugidentifizierung eine Bestimmtheit haben zumindest über das Jahr, die Marke, das Modell, die Motorgröße, den Motorcode, den Treibstofftyp, den Zündungstyp und den Luftmesstyp für das Fahrzeug. Wenn während der Laufzeit zusätzliche Fahrzeuginformation erforderlich ist, um einen ausgewählten Test durchzuführen, zeigt das System dies an und stellt dem Benutzer die geeigneten Felder und Menüs dar, um die benötigte Information einzugeben.
Sobald das Fahrzeug identifiziert ist, kann der Benutzer die Diagnose beginnen, indem er das Test/Analyse-Symbol 32 auswählt, was eine Bildschirmanzeige ähnlich der in 3 hervorbringt, die drei unterschiedliche Ordner darstellt, die entsprechend den oben beschriebenen automatischen Diagnosearten jeweils mit "Symptoms" (Symptome), "Component/System" (Komponente/System) und "Service Codes" benannt sind. Die Ordner "Symptome" und "Service Codes" beziehen sich auf die fehlerbasierten Arten. Während die folgende Diskussion im Hinblick auf den Symptomtestmodus ist, trifft sie auch allgemein auf den Servicecodetestmodus des Betriebs zu. Wenn der Symptomordner gewählt ist, zeigt er im Vordergrund die Bildschirmanzeige 39 von 3 an. Die Bildschirmanzeige 39 enthält ein Menü 40 mit Symptomen, die von dem in der Bildschirmanzeige 30 von 2 gewählten Fahrzeug gezeigt werden können, wobei der Fahrzeugtyp unten an der Bildschirmanzeige 39 angegeben ist wie bei 41. Die Liste der Symptome, die dem Benutzer dargestellt werden, ist repräsentativ für eine Industriesymptomdiagnose und unterstützt die Mehrzahl der Reklamationen des Fahrverhaltens.
Eine Standardliste von Symptomen ist möglich, weil Fahrzeuge gemeinsame Technologie benutzen. Sie haben jeweils alle Mechanik-, Zündungs-, Treibstoff- und Computerkomponenten, die im wesentlichen in derselben Weise funktionieren. Andere spezifischere Symptome können gewöhnlich einem oder mehreren der Symptome aus der Hauptsymptomliste zugeordnet werden. Ein bestimmtes Symptom, beispielsweise "Fahrzeug geht aus beim Fahren einer Rechtskurve" passt unter ein weniger spezifisches Symptom "Fahrzeug geht aus bei Leerlauf/Verlangsamung/Bremsen". Die Tests, um die Bedingung zu diagnostizieren, sind im wesentlichen dieselben. Es wird eine Standardliste von Symptomen verwendet, weil sie eine einheitliche Schnittstelle und Diagnosephilosophie für alle Fahrzeuge bereitstellt, die Eingewöhnung von Technikern und Serviceschreibern fördert und die wirkungsvollste Weise zum Entwickeln eines Systems mit "geschlossener Schleife" liefert zum Klassifizieren von Felddaten für Symptome und ihre Ursachen, wie ausführlicher unten diskutiert werden wird.
Der Benutzer/Techniker wählt eines oder mehrere der aufgelisteten Symptome, die das zu testende Fahrzeug zeigt, wie sie beispielsweise von einem Gespräch mit dem Fahrzeughalter bestimmt werden. Auf Grundlage des gewählten Symptoms oder der gewählten Symptome zeigt die Bildschirmanzeige eine Liste 42, die für das zu testende Fahrzeug spezifisch ist, mit möglichen Ursachen des ausgewählten Symptoms oder der ausgewählten Symptome und eine Entsprechungsliste von Testverfahren, die durchgeführt werden müssen, um diese Ursachen zu untersuchen. Die Testverfahren sind in der Reihenfolge der Wahrscheinlichkeit oder Likelihood aufgelistet, dass der Test beim Diagnostizieren der Ursache des gewählten Symptoms oder der gewählten Symptome erfolgreich sein wird, wobei diese Rangfolge wie bei 43 angezeigt wird.
Beim Entwickeln der Testrangfolgen während der Entwicklung der Software bewerten Fokusgruppentechniker jedes einzelne Symptom in der Symptomliste für jedes bestimmte Fahrzeug. Auf der Grundlage ihrer Erfahrung entwickeln sie eine Liste von Ursachen für jedes Symptom und legen ein Testverfahren fest, das der Benutzer für jede Ursache durchführen sollte. Dann ordnen sie jeder Ursache/jedem Test eine Nummer zu, z.B. zwischen 1 und 5, auf der Grundlage von:

(a) welche Tests erforderlich sind, um die Ursache der Symptome zu bestimmen;
(b) der Reihenfolge, in der die Tests durchgeführt werden sollten auf der Grundlage der Wahrscheinlichkeit der Ursache; und
(c) in dem Fall, in dem mehr als eine Ursache gleiche Wahrscheinlichkeit hat, das Einordnen der Testempfehlungen nach der zum Durchführen des Testverfahrens benötigten Zeit, wobei die kürzeren Zeiten höher eingeordnet sind.

Es gibt drei Hauptkriterien zum Bestimmen der Wahrscheinlichkeit der Ursache für jeden Test, die in der Reihenfolge der Wichtigkeit sind:

1. Praktische Erfahrung beim Diagnostizieren der Beziehung zwischen Symptom und Ursache/Test;
2. Betriebstheoriewissen, wie das System arbeitet und welche Systeme oder Komponenten die wahrscheinlichste Ursache für jedes Symptom sind, und
3. Leichtigkeit des Testens und/oder die zum Durchführen des Tests benötigte Zeit.

Beim Abschätzen der Rangfolge ist die praktische Erfahrung das Erste, was zu berücksichtigen ist. Der Techniker verwendet Folgendes als Richtschnur beim Abschätzen der Rangfolge:

Rang Auftreten

5 immer zu sehen

4 sehr verbreitet

3 ziemlich verbreitet

2 ab und zu

1 selten
Wenn ein Test/eine Ursache an der Grenze zwischen zwei Rängen liegt, verwendet der Techniker die Leichtigkeit des Testens als bestimmenden Faktor. Beispiel: ein bestimmtes Symptom hat eine Treibstofflieferungstest/ursachenrangfolge zwischen 3 und 4. Wenn der Test leicht durchzuführen ist, wird er als 4 eingeordnet. Wenn er schwer durchzuführen ist, wird er als 3 eingeordnet. Die Leichtigkeit des Testens wird nur als Abgleichfaktor für das Abschätzen des Rangs verwendet.
Wenn der Techniker keine praktische Erfahrung bezüglich einer Beziehung zwischen Symptom und Ursache/Test hat, wird das Sys tem dann unter dem Gesichtspunkt einer Betriebstheorie untersucht. Mit dem Wissen des Technikers, wie das System arbeitet, und durch Vergleichen von Ursachen/Tests an ähnlichen Systemen untersucht der Techniker, ob es andere wahrscheinliche Ursachen/Tests für jedes Symptom gibt. Wenn ja, werden sie wie folgt eingeordnet:

Rang Wahrscheinlichkeit

3 sehr wahrscheinlich

2 wahrscheinlich

1 möglich
Wenn ein Test/eine Ursache an der Grenze zwischen zwei Rängen liegt, wird die Leichtigkeit des Testens wie oben dargelegt zum Zuordnen eines Rangs verwendet.
Wenn der Benutzer wie in 3 mehr als ein Symptom wählt und gefunden wird, dass eine bestimmte Ursache für mehr als eines der ausgewählten Symptome möglich ist, steigt die Wahrscheinlichkeit, dass diese Ursache das Grundproblem ist, an und die Empfehlung für den zugeordneten Test steigt in der empfohlenen Testreihenfolge weiter nach oben.
Nachdem die Symptome gewählt wurden und die zugeordneten empfohlenen Testverfahren angezeigt wurden, kann der Benutzer eines der angezeigten Testverfahren auswählen, und das System wird dann dieses Verfahren aufrufen oder starten. Während die Bildschirmanzeige 39 eine empfohlene Reihenfolge zum Durchführen der aufgelisteten Tests auflistet, ist der Benutzer frei, die Tests in einer beliebigen gewünschten Reihenfolge durchzuführen.
Die Bildschirmanzeige 39 enthält entlang einem unteren Teil des Bildschirms eine Reihe von Symbolen 44-48, die jeweils Systemmodulen entsprechen, die zum Durchführen der gewählten Testverfahren nützlich sind. Die in 3 gezeigten Modulsym bole dienen lediglich zur Veranschaulichung und sind jeweils mit "Quick Tip" (Schnellhinweis), "Analyser" (Analysator), "Scan Tool" (Abtastwerkzeug), "Shop Key" (Werkstattschlüssel) und "Lab Scope/DVOM" (Laboroszilloskop/DVOM) gekennzeichnet.
Schnellhinweise sind Informationsartikel, die zu dem Symptom des untersuchten Fahrzeugs gehören. Dieses Modul liefert dem Techniker Informationen, die es ermöglichen, das Fahrzeug mit einem Minimum von Anschlüssen und Tests zu diagnostizieren. Diese Hinweise werden von der Technikerfokusgruppe auf der Grundlage ihrer Erfahrung beim Diagnostizieren der gewählten Symptome erzeugt. Diese Vorausinformation könnte Stunden des Diagnostizierens sparen. Wenn die Schnellhinweise dem Benutzer dargestellt werden, sind sie vorzugsweise in der Reihenfolge ihrer Wichtigkeit z.B. auf einer Skala von 1-5 eingeordnet, wobei 5 der Wichtigste ist. Die Rangfolge unterscheidet zwischen Information, die man "wissen muss" und die "gut zu wissen ist".
Das Shopkey-Modul ist ein Testlink, das den Benutzer direkt zu einer Bibliothek von Artikeln schickt, die dem Benutzer einschlägige OEM-Komponententestverfahren liefern.
Das Analysatormodul ist ein Link zu den Motoranalysatorfunktionen der Plattform 10, während das Laboroszilloskop/DVOM-Modul ein Link zu den Laboroszilloskopen- und DVOM-Funktionen der Plattform 10 ist. Das Abtastmodul ist eine Verbindung zu den Funktionen eines Scanners wie z.B. des von Snap-On Diagnostics unter der Bezeichnung MT2500 vertriebenen, der daran angepasst ist, mit dem Bordcomputer des zu testenden Fahrzeugs verbunden zu werden.
Sobald der Benutzer den durchzuführenden Test auswählt, fragt das System die Testbibliotheksdatenbank ab, um zu bestimmen, welches Modul oder welche Module den durchzuführenden bestimmten Test unterstützen, und gibt dann die entsprechenden Symbo le frei und hebt sie hervor. Wenn ein Testverfahren durch mehrere Module unterstützt wird, zeigt das System an, welches Modul als das wirkungsvollste eingeschätzt wird, indem das hervorgehobene Symbol blinkt. Wenn der Benutzer ein hervorgehobenes Symbol auswählt, ruft das System den geeigneten Test auf oder sendet den Benutzer zu dem entsprechenden Artikel in Shop-Key, wenn das das gewählte Symbol ist.
Das Starten eines bestimmten Testverfahrens enthält typischerweise das Initialisieren einer Folge von Bildschirmanzeigen, die den Benutzer beim Durchführen des Testverfahrens leiten. Wenn beispielsweise das Abtastwerkzeug implementiert wird, wird der Benutzer in der Weise des Anschließens und Verwendens des zugeordneten Scanners zum Herunterladen von Information von dem Fahrzeugbordcomputer und/oder des Steuerns des Betriebs bestimmter Computerfunktionen geleitet, alles in bekannter Weise. Wenn andererseits das Analysatormodul ausgewählt ist, enthalten die Anweisungen zum Durchführen des ausgewählten Testverfahrens typischerweise das Anschließen der Testanschlüsse an das zugeordnete Fahrzeug, gewünschte Motorbetriebsbedingungen und dergleichen, alles in einer bekannten Weise.
Die Anfangsdiagnosedaten für dieses System sind primär von den Fokusgruppen entlehnt, die OEM-Techniker enthalten, weil ihre Zugehörigkeit zu einem bestimmten OEM sie mit einem konzentrierten Umgang mit diesen Fahrzeugen und einem gesteigerten Zugriff auf OEM-Informationen ausstattet. Ihre Erfahrung ist jedoch gewöhnlich auf Fahrzeuge eingeschränkt, die weniger als drei Jahre alt sind. Weiter neigen ihre Daten dazu, die Probleme wiederzugeben, die in dem geographischen Bereich existieren, in dem die OEM-Techniker leben. In Florida gesammelte Daten könnten die Probleme, die in einem Winter in Minnesota auftreten, nicht genau wiedergeben. Die Diagnose des vorliegenden Systems muss sich über die Lebensdauer des Fahrzeugs verändern, um genauer die Probleme wiederzugeben, die auftre ten, wenn das Fahrzeug zurückgelegte Kilometer sammelt, und um eine breitere geographische Anwendung zu erzielen.
Dementsprechend kann während der Symptomdiagnose ein (nicht gezeigtes) Symbol "Diagnose bestätigen" auf dem Bildschirm verfügbar gemacht werden. Wenn der Benutzer ein gewähltes Testverfahren durchgeführt hat und die Grundursache für das gewählte Symptom oder die gewählten Symptome herausgefunden hat, wählt der Benutzer das Diagnosebestätigungssymbol. Das System zeigt dann die Symptome, die zur Beginn der Diagnose gewählt wurden, und die Liste empfohlener Tests an. Der Benutzer kann den Test wählen, der das Problem gefunden hat, und die Daten werden in einer Datenbank gespeichert. In dieser Datenbank speichert das System das derzeitige Fahrzeug, die gewählten Symptome, den Testnamen und gibt dem Test einen Zählwert von 1 für jedes der gewählten Symptome. Wenn ein anderer Test als die empfohlenen Tests das Problem gefunden hat, wird dem Benutzer ein Textfenster dargestellt, um eine kurze Beschreibung des zum Isolieren der Ursache der Symptome verwendeten Tests einzugeben. Auch diese Daten werden gespeichert. Die gespeicherten Daten werden während eines Softwareupdatevorgangs über Modem empfangen. Datenverifikations- und Analyseroutinen durchsuchen die aktualisierten Daten. Es wird die Anzahl von Malen geprüft, die jede Ursache/Test jedes Symptoms für jedes spezifische Fahrzeug diagnostiziert hat. Dann wird dieses Verhältnis mit den Empfehlungen verglichen, die in der Datenbank gespeichert sind, und die Rangreihenfolge wird wie erforderlich verändert. Jede der von einem Benutzer eingegebenen Reparaturen wird ebenfalls geprüft, um festzustellen, ob ein neuer Test für das System entwickelt werden sollte oder ob die Information als Schnellhinweis hinzugefügt werden sollte.
6 ist ein Flussdiagramm, das das Softwareprogramm für die vorliegende Erfindung unter Verwendung fehlerbasierter Betriebsarten wie z.B. der Symptomtestbetriebsart oder der Servicecodetestbetriebsart veranschaulicht. Zunächst gibt der Be nutzer bei 50 unter Verwendung eines Bildschirms wie desjenigen von 2 Fahrzeugidentifizierungsdaten ein, und dann wählt er das Test/Analyse-Symbol, was einen Bildschirm hervorbringt (s. 3), der es dem Benutzer ermöglicht, die Betriebsart Symptomtesten, Komponenten- oder Systemtesten oder Servicecodetesten zu wählen. Wenn entweder die Betriebsart Symptomtesten oder die Betriebsart Servicecodetesten gewählt werden, greift das Programm bei 51 auf die geeignete Datenbank zu und zeigt dem Benutzer wie in dem Bildschirm von 3 die Fehler (Symptome oder Servicecodes) an. Der Benutzer wählt bei 52 einen oder mehrere Fehler, und das System greift dann bei 53 auf die Datenbank mit den gewählten Fehlern zu und baut eine Liste anwendbarer Ursachen und zugeordneter Testverfahren auf. In dieser Hinsicht fragt das Programm bei 54, wie viele Fehler gewählt wurden, und wenn einer gewählt wurde, sortiert es die Liste 55 nach den Rang und stellt sie dem Benutzer dar wie in dem Bildschirm von 3, wobei Tests, die vorher durchgeführt wurden, bei 56 hervorgehoben werden. Wenn bei 54 mehr als ein Fehler gewählt wurde, wendet das Programm bei 57 einen Einordnungsalgorithmus für jede Ursache/Test an und sortiert die Liste wieder, wobei er sie dem Benutzer in der Form eines Bildschirms wie desjenigen von 3 anzeigt. Der Benutzer wählt dann bei 58 den durchzuführenden Test, und das System erzeugt den Test bei 59, wobei es den Benutzer erforderlichenfalls zu dessen Durchführung auffordert. Dann gibt der Benutzer unter Verwendung eines geeigneten (nicht gezeigten) Symbols an, ob der Test die Ursache des Fehlers identifiziert hat oder nicht, wodurch er die Programmabfrage bei 60 beantwortet. Falls nein, hebt das Programm den Test bei 61 hervor, und der Benutzer wählt dann einen anderen Test. Wenn der Test den Fehler identifiziert hat, speichert das Programm bei 62 diese Information für spätere Wiedergewinnung. Das System fragt dann bei 63, ob das Testen fortgeführt werden soll. Falls ja, wird der letzte durchgeführte Test wieder bei 61 hervorgehoben, und falls nein verlässt das System den Fehlertestbetrieb bei 64.
In der Diagnosebetriebsart des Servicecodetestens ist der Betrieb im wesentlichen wie oben beschrieben, außer dass der Techniker die Fahrzeugservicecodes als Diagnosestartpunkt verwendet, und die Servicecodes sind spezifisch für einzelne Fahrzeuge. Wenn der Benutzer durch Auswählen des Ordners 38 auf dem Bildschirm von 3 diese Betriebsart wählt, ermöglicht das System 2 verschiedene Startverfahren. Bei dem ersten Verfahren fragt das System den Benutzer falls erforderlich durch eine Servicecodezugangsprozedur und verwendet das Abtastwerkzeugmodul, um die bestehenden Servicecodes aus dem Fahrzeug auszulesen. Das System stellt dem Benutzer dann ein Menü von lediglich den Servicecodes dar, die derzeit in dem Computerspeicher des Fahrzeugs gespeichert sind. Der Benutzer wählt dann den Code aus, den er diagnostizieren will. Bei dem zweiten Verfahren hat der Techniker im voraus die Servicecodes des Fahrzeugs abgerufen. Das System stellt dem Benutzer dann eine Bildschirmanzeige dar, die ein Menü aller auf dem getesteten Fahrzeug möglichen Servicecodes anzeigt. Der Benutzer wählt den Code, den er diagnostizieren will.
Auf der Grundlage des gewählten Servicecodes oder der gewählten Servicecodes zeigt der Anzeigeschirm wie oben in 3 angegeben eine Liste möglicher Ursachen des gewählten Servicecodes und eine Entsprechungsliste von Testverfahren, die zum Untersuchen dieser Ursachen durchgeführt werden soll. Die Testverfahren sind in der Reihenfolge der Wahrscheinlichkeit oder Likelihood aufgelistet, dass der Test beim Diagnostizieren der Ursache des gewählten Servicecodes erfolgreich sein wird. Auswählen und Aufrufen eines angezeigten Testverfahrens wird auf dieselbe Weise durchgeführt, wie sie oben in Verbindung mit dem Symptomtestbetrieb von 3 beschrieben wurde.
Der Systemtestbetrieb, der durch Wählen des Komponente/System-Ordnersymbols 37 auf dem Bildschirm 39 von 3 aufgenommen werden kann, verifiziert den Betrieb eines Fahrzeuguntersys tems und verwendet primär Motoranalysatorsystemtests. In diesem Testbetrieb führt das System den Techniker nicht bei der Festlegung, welche Tests durchgeführt werden sollten. Der Techniker verwendet seine eigene Erfahrung, um zu bestimmen, welche Tests erforderlich sind, sowie die Reihenfolge, in der sie durchgeführt werden sollen. Viele dieser Tests sind prozedural. Jeder Test enthält eine Abfrage- und Datensammelfähigkeit. Beim Ende des Tests wertet eine Diagnosemaschine die Daten aus und stellt die Diagnoseschlüsse dar.
Das System präsentiert dem Benutzer anfänglich bei der Bildschirmanzeige 65 wie in 4 dargestellt ein Menü 66 anwendbarer Systemtests. Der Techniker wählt den gewünschten Test aus dem Menü, und das System hebt das anwendbare der Modulsymbole 44-48 hervor. Der Benutzer wählt ein hervorgehobenes Modul, und ein zugeordneter Text wird aufgerufen. Wenn der Benutzer zu dem Systemtestbildschirm von 4 zurückkehrt, wird jeder Test, der vorher vollendet wurde, in einer unterschiedlichen Farbe dargestellt. Das bietet einen Mechanismus, um zu verfolgen, welche Tests in dieser Diagnosesitzung durchgeführt wurden. Das System fragt den Benutzer auch während des Durchführens jedes Tests und sammelt auch die Testdaten, und beim Ende des Tests wertet es die Daten aus und präsentiert dem Benutzer die Diagnoseschlüsse. Wenn ein Test beendet ist, zeigt das System diese Tatsache an, so dass er nicht unabsichtlich wiederholt wird.
Wenn der Komponententestbetrieb gewählt ist, erscheint die Bildschirmanzeige 67 von 5. Der Komponententest überprüft den Betrieb einer einzelnen Komponente des Fahrzeugs. Bei diesem Testbetrieb führt das System dem Techniker nicht beim Bestimmen, welche Tests durchgeführt werden sollen. Der Techniker verwendet seine eigene Erfahrung, um festzulegen, welche Tests erforderlich sind, sowie die Reihenfolge, in der sie durchgeführt werden sollten.
Die Komponententestdatabank enthält Zeiger auf Tests in der Testbibliothek, die auf bestimmte zu testende Fahrzeuge zutreffen. Die Liste von Fahrzeugkomponententests, die dem Benutzer zur Verfügung stehen, ist dynamisch, da jedes Fahrzeug potentiell einen einzigartigen Satz von Komponenten hat. Die Komponententestbibliothek kann Hunderte von Komponententests enthalten. Die Bildschirmanzeige 67 von 5 listet die verfügbaren Komponententests für das zu diagnostizierende Fahrzeug. Der Benutzer wählt den geeigneten Komponententest. Das System hebt unter Verwendung der Symbole 44-48 die anwendbaren Module hervor, die das Testen der ausgewählten Komponente unterstützen. Der Benutzer wählt ein hervorgehobenes Modul, um einen geeigneten Test zu starten, im wesentlichen auf dieselbe Weise wie es oben in Verbindung mit der systembasierten Diagnosebetriebsart beschrieben war.
Aus dem Vorigen ist ersichtlich, dass ein verbessertes dynamisches Diagnosesystem bereitgestellt wurde, das eine Anzahl verschiedener Diagnoseverfahren enthält einschließlich problembasierter Diagnose und das leicht aktualisiert wird, um Serviceerfahrung mit dem Fahrzeug während seines Verwendungslebens zu berücksichtigen.
Während bestimmte Ausführungsformen der vorliegenden Erfindung gezeigt und beschrieben wurden, ist es dem Fachmann klar, dass Änderungen und Abweichungen durchgeführt werden können, ohne von der Erfindung in ihren breiteren Aspekten abzuweichen. Der in der vorigen Beschreibung und den beigefügten Zeichnungen dargelegte Gegenstand wird lediglich zur Veranschaulichung gegeben und nicht zur Einschränkung.

Claims

Verfahren für einen Benutzer zum Diagnostizieren einer Vorrichtung, bei dem die Vorrichtungsidentifizierungsinformation von dem Benutzer in ein Testsystem eingegeben wird (50), das eine entfernte Datenbank (62) enthält, als Reaktion darauf, dass ein Test durchgeführt wird, um eine Ursache eines Fehlers zu diagnostizieren, der von der Vorrichtung erfahren wird, geprüft wird, ob der Test eine Ursache des Fehlers diagnostiziert hat oder nicht (60), falls der Test die Ursache des Fehlers diagnostiziert hat, die Vorrichtungsidentifizierungsinformation, der gewählte Fehler oder die gewählten Fehler und der Testname gespeichert werden (62) und diese gespeicherten Daten zum Aktualisieren der entfernten Datenbank (62) gespeichert werden, dadurch gekennzeichnet, dass nach dem Eingeben der Vorrichtungsidentifizierungsinformation dem Benutzer ein Menü von Fehlern angezeigt wird (51), der Benutzer einen oder mehrere Fehler auswählt (52), als Antwort auf die Auswahl eines Fehlers oder mehrerer Fehler durch den Benutzer zumindest ein Test aus der entfernten Datenbank gewählt wird, wodurch der Test an der Vorrichtung durchgeführt werden kann zum Diagnostizieren der Ursache des Fehlers oder der Fehler (53, 54, 55, 57), und die Tests in der Reihenfolge aufgelistet sind, in der sie am wahrscheinlichsten wirkungsvoll zum Diagnostizieren der Fehler sind (56), wobei diese Reihenfolge basiert auf: (a) welche Tests erforderlich sind, um die Ursache der Symptome zu bestimmen, (b) der Reihenfolge, in der die Tests durchgeführt werden sollten, basierend auf der Wahrscheinlichkeit der Ursache, und (c) falls mehr als eine Ursache die gleiche Wahrscheinlichkeit hat, das Einordnen der Testempfehlungen nach der Zeit, die zum Durchführen des Testverfahrens erforderlich ist, wobei die kürzere Zeit höher eingeordnet ist.
Verfahren nach Anspruch 1, bei dem die Vorrichtung ein Fahrzeug enthält.
Verfahren nach einem der vorigen Ansprüche, bei dem das dem Benutzer Anzeigen zumindest eines Tests zur Auswahl durch den Benutzer das Anzeigen einer Angabe zumindest eines Systems der Vorrichtung enthält, an der ein Test durchgeführt werden kann, um eine Ursache eines Fehlers zu diagnostizieren, der von der Vorrichtung erfahren werden kann.
Verfahren nach einem der Ansprüche 1, 2, 3, bei dem das dem Benutzer Anzeigen zumindest eines Tests zur Auswahl durch den Benutzer das Anzeigen einer Angabe zumindest einer Komponente der Vorrichtung enthält, an der ein Test durchgeführt werden kann, um eine Ursache eines Fehlers zu diagnostizieren, der von der Vorrichtung erfahren werden kann.
Verfahren nach einem der Ansprüche 1, 2, 3, bei dem das dem Benutzer Anzeigen zumindest eines Tests das Zugreifen auf eine Wissensdatenbank enthält, die eine Bibliothek enthält, die eine Mehrzahl von Tests enthält (53).
Verfahren nach einem der Ansprüche 1, 2, 3, bei dem das dem Benutzer Anzeigen zumindest eines Tests das Anzeigen enthält, welche Tests vorher durchgeführt wurden.
Verfahren nach Anspruch 1, bei dem das Empfangen der Vorrichtungsidentifizierungsinformation das Auffordern des Benutzers enthält, einen Vorrichtungsidentifizierungsvorgang durchzuführen.
Verfahren nach Anspruch 1, das weiter das Auffordern des Benutzers enthält, den Test durchzuführen.
Verfahren nach Anspruch 1, das weiter das Speichern von Testdaten in einem Speichermechanismus enthält.
Verfahren nach Anspruch 1, bei dem die entfernte Systembibliothek die Vorrichtungsdiagnosedaten aktualisiert.
Verfahren nach Anspruch 1, das weiter das Auswerten der Testdaten und das dem Benutzer Anzeigen zumindest einer Diagnoseschlussfolgerung enthält.