-
Die
Erfindung betrifft ein Diagnosesystem und einen Diagnosetester für die Überprüfung von Kraftfahrzeugsteuergeräten, mit
dem nicht nur, wie bisher üblich,
das Auffinden von Fehlern möglich
ist, sondern mit dem ebenfalls überprüft werden
kann, ob eine vorgenommene Reparatur erfolgreich war. Mit dem Diagnosetester
wird ebenfalls ein Verfahren zur verbesserten Reparaturverifikation
vorgestellt.
-
Diagnosesysteme
und Diagnosetester für Kraftfahrzeugsteuergeräte sind
heutzutage in Kraftfahrzeugwerkstätten vorwiegend rechnerbasiert.
Federführend
bei der Einführung
rechnerbasierter Diagnosetester war im Jahre 1994 die Firma BMW
mit dem Diagnosesystem BMW-DIS, das den Standard für die heutigen
Diagnosesysteme und Diagnosetester in Kraftfahrzeugwerkstätten setzte.
Dieses System ist beispielsweise beschrieben in dem Lehrbuch zur
Berufsbildung von Rauner/Schreier/Spöttel: „Die Zukunft computergestützter Kfz-Diagnose", erschienen beim
Bertelsmann Verlag in Bielefeld, 2002, ISBN 3-7639-3022-1. Nachfolgende Diagnosetester haben
immer wieder auf die Grundstruktur dieses Diagnosesystems zurückgegriffen.
So z. B. auch eine deutsche Patentanmeldung der Firma Bosch,
DE 199 21 845 A1 ,
die hier beispielhaft genannt wird, weil sie diese Grundstruktur
besonders prägnant
und kurz zusammenfasst. Be schrieben wird eine Diagnosetestvorrichtung
für Kraftfahrzeuge,
wobei im Kraftfahrzeug programmierbare Steuergeräte mit Eigendiagnosemittel
vorgesehen sind, welche programmgesteuert die Motorsteuerung und
andere Systeme des Kraftfahrzeugs steuern, überwachen, Fehlercodes generieren
und diese abspeichern, und welche über einen kraftfahrzeugseitigen
Diagnose-/Prüfstecker mit
einem externen Diagnosetester verbindbar sind. Die Erfindung geht
ebenfalls von einer derartigen Grundstruktur für einen Diagnosetester aus.
-
Die
Schnittstelle bzw. der Diagnosestecker zur Verbindung eines externen
Diagnosetesters mit den kraftfahrzeugseitigen Steuergeräten war
in der Vergangenheit und ist es zum Teil noch heute Gegenstand von
Normierungsbestrebungen. Insbesondere in den USA werden diese Normierungsbestrebungen,
mit denen der Zugang und damit die Diagnosefähigkeit der kraftfahrzeugseitigen
Steuergeräte
ermöglicht
und geregelt wird, noch durch gesetzgebende Maßnahmen begleitet. Ein Standard,
der sich herausgebildet hat, ist das sog. Keyword-Protokoll 2000.
Die Normierungsgrundlagen für
dieses Keyword-Protokoll 2000 finden sich in dem internationalen
Standard ISO 14 230-3, was den Application Layer angeht, und in
ISO 14 230-2, was den sog. Data Link Layer angeht. Eine ergänzende Norm,
auf die das Keyword-Protokoll 2000 aufsetzt, und die zum Bestandteil
der vorgenannten Normen geworden ist, ist der Service Vehicle Standard
SAE J1979. Für
die hier beschriebene Erfindung von Bedeutung sind insbesondere
die Möglichkeiten
zum Auslesen der Datenspeicher in den Steuergeräten, die das Keyword-Protokoll 2000 für einen
Diagnosetester bietet.
-
Bekannte
Diagnosesysteme und Diagnosetester beschränken sich darauf, vorhandene
Fehlercodes aus den Steuergeräten
im Kraftfahrzeug auszulesen, mit einem Diagnoseprogramm zu verarbeiten
und zu interpretieren und das Ergebnis dieser Inter pretation auf
einem Bildschirm des Diagnosetesters zur Anzeige zu bringen. In
der Kraftfahrzeugwerkstatt arbeitet dann ein Kraftfahrzeugmechaniker die
angezeigte Mängelliste
ab, wobei er mit Hilfe des Diagnosetesters zu den einzeln aufgeführten Mängel weitere
Informationen abrufen kann. Von besonderem Interesse für ihn sind
hierbei weitere technische Grundlagen, wie technische Zeichnungen
und natürlich
die Reparaturanleitungen, mit denen er den festgestellten Fehler
beheben kann. Hat der Kraftfahrzeugmechaniker mit seinen Reparaturen
die Mängelliste
abgearbeitet, löscht
er mit Hilfe des Diagnosetesters die abgespeicherten und ausgelesenen
Fehlercodes in den kraftfahrzeugseitigen Steuergeräten und
im Diagnosetester selbst. Eine Abschlussüberprüfung, ob die vorgenommenen
Reparaturen erfolgreich waren oder ob sich durch die Reparatur Folgefehler
ergeben haben, wird je nach Arbeitsorganisation in der Kraftfahrzeugwerkstatt
mit einer abschließenden
Probefahrt vorgenommen. Der Patentanmelderin bekannte Diagnosesysteme
und Diagnosetester unterstützen
die Qualitätsüberprüfung der
vorgenommenen Reparaturen nicht. Sie sind hierzu auch nicht geeignet,
da die Mängelliste
und die Fehlercodes in den Steuergeräten vom Kraftfahrzeugmechaniker
per Löschbefehl
gelöscht
werden. Damit gehen naturgemäß die Informationen über eine
einmal vorgelegene und festgestellte Fehlfunktion verloren. Daher
hatte der Kraftfahrzeugmechaniker bisher von einem Diagnosetester
keine Unterstützung
dahingehend, ob seine Reparatur erfolgreich war oder nicht.
-
Ausgehend
von dem vorher beschriebenen Stand der Technik ist es daher das
Bestreben der Erfindung, ein Diagnosesystem und einen Diagnosetester
anzugeben, welche und welcher eine verbesserte Reparaturverifikation
mit Hilfe des Diagnosetesters ermöglichen.
-
Diese
Aufgabe wird gelöst
mit einem Diagnosesystem und einem Diagnosetester entsprechend der
unabhängigen
Ansprüche.
Vorteilhafte Ausführungsformen
der Erfindung sind in den abhängigen Ansprüchen aufgezeigt
oder werden in der folgenden Beschreibung verdeutlicht.
-
Die
Lösung
gelingt mit einem rechnerbasierten Diagnosetester, der mit Hilfe
eines Diagnoseprogramms über
eine Diagnoseschnittstelle sowie über Datenleitungen mit den
im Kraftfahrzeug verbauten Steuergeräten Informationen austauschen
kann. Die kraftfahrzeugseitigen Steuergeräte verfügen über Programmroutinen zur Eigendiagnose
der Steuergeräte
und sind in der Lage identifizierte Fehler in Form von Fehlercodes
in reservierten Speicherbereichen abzulegen. Das im Diagnosetester
implementierte Diagnoseprogramm liest die Fehlercodes aus den reservierten
Speicherbereichen aus, interpretiert die Fehlercodes und bringt
sie auf einem Display zusammen mit den Interpretationen zur Anzeige.
Um zu überprüfen inwieweit
vorgenommene Reparaturen erfolgreich abgeschlossen wurden, wird
mit Hilfe des im Diagnosetester implementierten Diagnoseprogramms
ein Status Polling durchgeführt.
Bei diesem Status Polling werden zu allen im System bekannten Fehlercodes
die Statusinformationen dieser Fehlercodes abgefragt und ausgewertet.
Es werden hierbei alle Fehlercodes zur Anzeige gebracht, deren Fehlersetzbedingungen
entweder positiv getestet wurden oder deren Prüfvoraussetzungen nicht vorlagen,
um einen Test durchführen
zu können.
-
Das
Status Polling hat hauptsächlich
den Vorteil, dass auf dem Diagnosetester nicht nur diejenigen Fehler
zur Anzeige gebracht werden, deren Fehlersetzbedingungen in der
Vergangenheit einmal positiv erfüllt
waren, sondern es werden auch die potentiell möglichen Fehler in Form von
Fehlercodes zur Anzeige gebracht, deren Funktionen nicht überprüft werden konnten,
weil hierzu die Prüfvoraussetzungen
nicht vorgelegen haben. Für
die Unterstützung
des Werkzeugmechanikers in der Kraftfahrzeugwerkstatt bedeutet das
Status Polling, dass auf der Anzeige des Diagnosetesters, so lange
eine Mängelliste
erscheint, bis alle identifizierten Fehler und auch alle potentiellen
Fehler entsprechend der Prüfvoraussetzungen
getestet worden sind und das Testergebnis keine positive Verletzung
einer Fehlersetzbedingung ergeben hat. Für durchgeführte Reparaturmaßnahmen
bedeutet dies, dass die Reparaturmaßnahme erst dann abgeschlossen
ist, wenn mit dem Diagnosetester mindestens ein Mal die Prüfvoraussetzungen
für die
durchgeführte
Reparaturmaßnahme
durchlaufen wurden und dieser Durchlauf ergeben hat, dass nun für die überprüfte Maßnahme keine
Fehlersetzbedingung mehr vorliegt.
-
In
einer vorteilhaften Ausführungsform
der Erfindung ist das Löschen
von Fehlercodes mit dem Diagnosetester daran gebunden, dass für den zu
löschenden
Fehlercode mindestens ein weiterer Diagnoselauf durchgeführt wurde,
wobei während
dieses Diagnoselaufs die Prüfvoraussetzungen
zur Überprüfung des
betreffenden Fehlercodes erfüllt
waren und das Testergebnis ergeben hat, dass nun kein Fehler mehr
vorliegt. Dies hat den Vorteil, dass einmal diagnostizierte Fehler
erst dann vom Werkstattmechaniker gelöscht werden können, wenn
eine evtl. durchgeführte
Reparatur mindestens einmal mit dem Diagnosetester kontrolliert
und überprüft wurde
und dabei für
in Ordnung befunden wurde. Falsch durchgeführte Reparaturmaßnahmen
können
so mit dem Diagnosetester unmittelbar nach der Reparatur identifiziert
werden. Noch wichtiger ist, dass mit dem vorbeschriebenen Status
Polling auch diejenigen potentiellen Fehlermöglichkeiten aufgefunden werden,
die nur deshalb für
in Ordnung befunden wurden, weil die Prüfvoraussetzungen für eine sinnvolle Überprüfung nicht
vorgelegen haben. Dies ist besonders dann von Bedeutung, wenn eine
Reparatur durch Kom plettaustausch eines Steuergeräts vorgenommen
wird. Nach dem vorbekannten Stand der Technik würde jeder Diagnosetester das
neu eingebaute Steuergerät für in Ordnung
befinden, nur aus dem Grund, weil in seinem Fehlerspeicher keine
Fehlercodes abgelegt sind. Mit der Erfindung hingegen gilt die Reparaturmaßnahme erst
dann abgeschlossen, wenn das Steuergerät mit dem Diagnosetester mindestens
einmal entsprechend der für
das Steuergerät
geltenden Prüfvoraussetzungen
getestet wurde und dabei kein Fehler festgestellt werden konnte.
Die Menüführung bzw.
die Bildschirmanzeige des Diagnosetesters, wie er hier beschrieben
wird, macht den Werkstattmechaniker auf nicht getestete Fehlermöglichkeiten
aufmerksam und hilft ihm dabei, daran zu denken, die durchgeführten Reparaturmaßnahmen
mindestens einmal ordnungsgemäß zu überprüfen. Die
Prüfvoraussetzungen
für jeden
bekannten Fehlercode sind hierbei sinnvollerweise im Diagnoseprogramm
des Diagnosetesters implementiert, so dass der Werkstattmechaniker
sich nicht für
jeden möglichen
Fehler im Kraftfahrzeug die vorgegebenen Prüfvoraussetzungen merken zu
braucht.
-
In
einer vorteilhaften Ausführungsform
der Erfindung ist die Statusüberprüfung mittels
des Diagnosetesters vom Kraftfahrzeugmechaniker einzuleiten. Hierzu
kann bei der Menüführung des
Diagnosetesters ein für
das Status Polling reservierter Menüpunkt vorgesehen sein, bei
dessen Betätigung
eine Statusüberprüfung des
vom Diagnosetester angezeigten Fehlers vorgenommen wird. Dies hat
den Vorteil, dass der Kraftfahrzeugmechaniker den Diagnosetester
reparaturnah einsetzen kann, und immer dann, wenn er glaubt eine
Reparaturmaßnahme
abgeschlossen zu haben, diese Reparaturmaßnahme sofort mit dem Diagnosetester überprüfen kann.
-
In
einer anderen Ausführungsform
der Erfindung kann die Statusüberprüfung vom
Diagnosetester automatisch immer dann ein geleitet werden, wenn ein
vom Diagnosetester angezeigter Mangel gelöscht werden soll. In diesem
Fall ist das Starten des Status Polling an das Aufrufen der Löschfunktion für die Rücksetzung
der Fehlercodes in den Steuergeräten
gekoppelt.
-
In
weniger bevorzugten Ausführungsformen der
Erfindung können
die Statusüberprüfungen vom Diagnosetester
selbsttätig
gestartet werden, indem z. B. nach Anschluss des Diagnosetesters
an die Diagnoseschnittstelle des Kraftfahrzeugs in zeitlich regelmäßigen Abständen vom
Diagnosetester eine Statusüberprüfung der
Fehlercodes initiiert und durchgeführt wird. Hierzu kann im Diagnosetester
eine Uhr mitlaufen und eine Statusüberprüfung, z. B. alle 10 Minuten
selbsttätig
ausgelöst
und durchgeführt
werden.
-
In
einer weiteren Ausführungsform
sind beim Diagnosetester die Funktionen zur Löschung der Fehlercodes, die
während
einer Diagnoseroutine in die Fehlerspeicher der Steuergeräte im Kraftfahrzeug
geschrieben wurden, so lange blockiert, bis eine Statusüberprüfung durch
eine weitere Diagnoseroutine sowohl die fehlerfreie Funktion der
durchgeführten
Reparaturmaßnahme
als auch die korrekte Überprüfung der
Reparaturmaßnahme
anhand der für
die jeweilige Reparatur vorgeschriebenen Prüfvoraussetzungen durchgeführt wurden.
Diese Ausführungsform
hat den Vorteil, dass für
den Kraftfahrzeugmechaniker die Reparatur erst dann beendet ist, wenn
alle Fehler beseitigt und auch ordnungsgemäß überprüft sind. Ein willkürliches
Löschen
einmal festgestellter Fehlercodes durch Löschbefehle, wie Einzelfehlerlöschung oder
Komplett-Reset aller Fehlerspeicher, kann dann nicht mehr zu einem
scheinbar ordnungsgemäßen Service
führen.
-
Ohne
Beschränkung
der Allgemeinheit wird im Folgenden die Erfindung anhand von graphischen Darstellungen
näher erläutert.
-
Es
zeigen:
-
1 eine
schematische Darstellung eines Diagnosetesters, wie er an die Steuergeräte in einem Kraftfahrzeug
angeschlossen ist,
-
2 eine
schematische Darstellung von Datenformaten, wie sie im Keyword-Protokoll
2000 vereinbart sind,
-
3 ein
Ablaufschema für
eine verbesserte Reparaturverifikation mit Hilfe eines Diagnosetesters,
-
4 ein
weiteres mögliches
Ablaufschema für
eine verbesserte Reparaturverifikation mit Hilfe eines Diagnosetesters,
-
5 eine
graphische Benutzeroberfläche, wie
sie vom Diagnosetester dem Kraftfahrzeugmechaniker zur Anzeige gebracht
wird,
-
6 die
graphische Benutzeroberfläche des
Diagnosetesters nach 5, wie sie sich dem Kraftfahrzeugmechaniker
zeigt, nachdem zwar die Reparaturen durchgeführt wurden, die Reparaturen selbst
aber nicht ordnungsgemäß überprüft wurden.
-
In 1 ist
eine Situation schematisch dargestellt, wie sie heute in Kraftfahrzeugwerkstätten bekannt
ist. Für
die Diagnose eines Kraftfahrzeuges wird ein rechnergestützter Diagnosetester 1 über eine
genormte Diagnoseschnittstelle 2 an das Kommunikationsnetzwerk 3 für die Steuergeräte 4 im Kraftfahrzeug
angeschlossen. Bekannte Diagnosetester sind z. B. das System DAS
von DaimlerChrysler oder das System BMW-DIS, das in der Beschreibungseinleitung
bereits erwähnt
wurde. Die im Kraftfahrzeug verbauten Steuergeräte 4 sind beispielsweise über einen
Datenbus miteinander in Kommunikationsverbindung. Ein verbreiteter
Datenbus in Kraftfahrzeugen ist hierbei der sog. CAN-Bus (für Control
Area Network). Jedes der verbauten Steuergeräte im Kraftfahrzeug verfügt neben
den Kommunikati onsschnittstellen über die Fähigkeit zur Eigendiagnose.
Im Rahmen der Eigendiagnose der Steuergeräte werden mit Hilfe der Diagnoseroutine
in den Steuergeräten
festgestellte Fehler in kodifizierter Form als sog. Fehlercodes
von der Steuergeräte-Software
in speziell reservierte Speicherbereiche, sog. Fehlerspeicher, geschrieben.
In der schematischen Darstellung der 1 sind diese
reservierten, nicht flüchtigen
Speicherbereiche als FS (für
Fehler-Speicher) bezeichnet. Für
die Kommunikation und für
den Datenaustausch zwischen einem Diagnosetester und den im Kraftfahrzeug
verbauten Steuergeräten
hat sich ein Standard etabliert, der unter dem Namen Keyword-Protokoll 2000 bekannt
ist und dessen Spezifizierung und Normierung sich in der ISO-Norm
14 230-3 wiederfindet. Soweit für
das Verständnis
der Erfindung erforderlich, wird weiter unten im Zusammenhang mit 2 noch
auf dieses Keyword-Protokoll
2000 näher
eingegangen. Mit den im Keyword-Protokoll
2000 verabredeten Steuerbefehlen und Datenformaten ist es möglich, über die
Diagnoseschnittstelle die kodifizierten Inhalte der Fehlerspeicher
der einzelnen Steuergeräte
mit Hilfe des Diagnosetesters auszulesen und in das Rechensystem des
Diagnosetester zu übertragen.
Die Norm zu dem Keyword-Protokoll 2000 umfasst hierbei zwei verschiedene
Applikationsmöglichkeiten.
Zum einen sieht die Norm vor, dass die Kommunikation zwischen Diagnosetester
und Steuergeräte über ein Gateway 5,
das z. B. den Kraftfahrzeug-CAN-Bus an die Diagnoseschnittstelle 2 anbindet,
erfolgt oder aber, dass wie früher üblich, die
Fehlerspeicher der Steuergeräte über die
sog. K- und L-Leitungen und über
die normierte Diagnoseschnittstelle 2 direkt in den Diagnosetester
ausgelesen und abgelegt werden können.
In der schematischen Darstellung der 1 ist die
modernere Form des Zugriffs über
einen CAN-Bus und
damit über
ein Gateway dargestellt. Für
die Erfindung von Belang ist lediglich, dass es mindestens eine
Möglichkeit
gibt, die Fehlerspeicher der Steuergeräte mit einem Diagnose tester
auslesen zu können.
Die Erfindung erfasst daher alle Adressierungsmöglichkeiten zwischen Diagnosetester
und Fehlerspeicher der Steuergeräte.
Auch das verwendete Keyword-Protokoll
2000 ist lediglich eine bevorzugte Möglichkeit, mit dessen Hilfe
die Dateninhalte der Fehlerspeicher aus den Steuergeräten besonders
einfach in den Diagnosetester transferiert werden können.
-
Mit
der schematischen Darstellung in 2 wird kurz
auf das Keyword-Protokoll 2000 eingegangen. Vollständige und
detailliertere Informationen findet der Fachmann in der bereits
erwähnten ISO-Norm
14 230-3. Mit dem Keyword-Protokoll 2000 wurden speziell für die Zwecke
der Kraftfahrzeugdiagnose ein Datenformat und ein Mindestumfang
an kodifizierten Steuerbefehlen, die ein Steuergerät im Kraftfahrzeug
mindestens verarbeiten können
muss, wenn es dem Keyword-Protokoll 2000 entsprechen soll, festgelegt.
Das vom Keyword-Protokoll verwendete Datenformat beruht auf der ISO-Norm
14 230-2, dem sog. Data Link Layer zum Keyword-Protokoll 2000. Der
Aufbau eines solchen Datenformats beinhaltet bis zu vier verschiedenen Header
Bytes, die Angaben zum Datenformat FMT, Angaben zur Zieladresse
TGT, Angaben zur Senderadresse SRC und Angaben zur Länge des
nach den Header Bytes folgenden Datenbytes enthält. Nach dem Header-Block folgt
immer ein hexadezimalkodifizierter Steuerbefehl, der als Service
Identification SID bezeichnet wird. Die im Keyword-Protokoll 2000 spezifizierten
Steuerbefehle können
hierbei herstellerspezifisch weiter unterteilt und ausgeformt sein.
In diesem Fall würde
der Nutzdatenblock 7 weitere hexadezimalkodifizierte Steuerbefehle
enthalten. Das Datenformat entsprechend des Keyword-Protokolls 2000
wird immer mit einem Byte abgeschlossen, dass eine Checksumme CS über alle
Daten des jeweiligen Botschaftsformats enthält. Das eben beschriebene Botschaftsformat
wird in seiner Grundstruktur sowohl für Anfragen an die Steuergeräte als auch
für die
Antworten der Steuergeräte
benutzt. Für die
Erfindung von besonderem Interesse sind hierbei die sog. $18-Requests mit den
zugehörigen
$58-Response, die jedes Keyword-Protokoll
2000-fähige System
beinhalten muss und verarbeiten können muss. Die Kodifizierung
der Requests und der Response erfolgt hierbei lediglich über die
Hexadezimalcodierung 18 bzw. 58 zur Bestimmung der Service Identification
und legt damit die zu übertragenden
Nutzdaten, die in der Response mindestens enthalten sein müssen, fest.
Das Dollarzeichen wird hier in dieser Patentanmeldung lediglich
dazu benutzt, um herauszustellen, dass es sich bei dem Zahlencode
18 bzw. 58 um einen kodifizierten Steuerbefehl entsprechend des
Keyword-Protokolls 2000 handelt. Erhält ein Steuergerät in einem
Kraftfahrzeug von einem Diagnosetester einen $18-Request, so antwortet
es immer mit einer $58-Response. Die Nutzdaten der Antwort sind
hierbei stets im Datenblock 7 der Antwortbotschaft enthalten.
Das Keyword-Protokoll 2000 definiert hierbei nicht nur die Steuerbefehle, sondern
spezifiziert auch die Dateninhalte, die eine normierte Antwort auf
eine normierte Anfrage enthalten muss. So ist z. B. festgelegt,
dass auf einen $18-Request die zugehörige §58-Response im Datenblock zu
jedem im Steuergerät
bekannten Fehlercode DTC1, DTC2 – DTCn auch der jeweilige Status dieses
Fehlercodes mitübertragen
wird. Der Status des Fehlercodes gibt hierbei an, ob die Eigendiagnoseroutine
des Steuergeräts
den Fehlercode getestet hat oder nicht. Im einfachsten Fall kann
der Status aus einem einzelnen Bit bestehen, wobei z. B. der Bitwert „0" für eine ordnungsgemäße Überprüfung der
dem Fehlercode zugeordneten Funktionen entsprechend der Prüfvoraussetzungen
steht, während der
Bitwert „1" für einen
nicht getesteten Fehlercode oder für einen Testdurchlauf der entsprechenden Funktionen,
bei dem die Prüfvoraussetzungen
nicht vorlagen, steht. Selbstverständlich kann auch jede andere
Codierung gewählt
werden, die in der Lage ist, zu unterscheiden, ob der Status eines
Fehlercodes entsprechend der Prüfvoraussetzungen
für die dem
Fehlercode zugrundeliegenden Funktionen getestet wurde oder nicht.
Die $58-Response enthält also
in dem Datenblock 7 eine Tabelle mit allen im Steuergerät bekannten
Fehlercodes mit der zusätzlichen
Status Information. Es ist also mit einem $18-Request entweder durch
Setzen entsprechender Parameter beim Request selbst oder durch nachträgliche Selektierung
des Datenblocks der zugehörigen $58-Antwort
möglich,
gezielt all diejenigen Fehlercodes zu identifizieren und auszulesen,
deren Status anzeigt, dass die zugehörigen Funktionen nicht ordnungsgemäß entsprechend
der Prüfvoraussetzungen
für diese
Funktionen getestet wurden. Diese Information kann gewonnen werden,
völlig
unabhängig davon,
ob eine Fehlfunktion vorlag bzw. ob ein Fehlercode verifiziert wurde
und im entsprechenden Fehlerspeicher abgelegt war oder nicht. Mit
anderen Worten ist es möglich
auch nicht aktivierte Fehlercodes über ihren Status abzufragen.
Das Keyword-Protokoll 2000 ist im Zusammenhang mit der Erfindung
als eine besonders verbreitete Ausführungsvariante zu sehen. Die
Erfindung selbst ist nicht auf das Keyword-Protokoll 2000 beschränkt, sondern lässt sich
mit jeder Art und Form der Datenübertragung
durchführen,
bei der neben aktivierten Fehlercodes auch deren Statusinformationen
ausgelesen und selektiert werden können.
-
Nach
den vorbeschriebenen Grundlagen wird nun im Zusammenhang mit den 3 bis 6 auf
den Kern der Erfindung eingegangen. 3 zeigt ein
Ablaufschema für
eine mögliche
verbesserte Reparaturverifikation. Nach dem Anschluss des Diagnosetesters
an die Diagnoseschnittstelle des Kraftfahrzeugs kann mit dem im
Diagnosetester implementierten Diagnoseprogramm eine Diagnosesitzung
gestartet werden. Hierfür
wird in einem ersten Schritt 310 der Dateninhalt der Fehlerspeicher
der Steuergeräte
im Kraftfahrzeug ausgelesen. Ausgelesen werden hierbei sämtliche
durch die Eigendiagnoseroutinen der Steuer geräte verifizierten und aktivierten Fehlercodes.
Im Unterschied zum vorbekannten Stand der Technik werden jedoch
gemäß der Erfindung
nicht nur die aktiven Fehlercodes ausgelesen, sondern es werden
mit einer geeigneten Abfrage zu allen im System bekannten Fehlercodes
auch die Statusinformationen ausgelesen. Die dermaßen ausgelesenen
Daten werden im Diagnosetester weiterverarbeitet. Nach entsprechender
Selektion werden auf einem geeigneten Display des Diagnosetesters alle
aktiven Fehlercodes, ggf. mit weiteren Erläuterungen, zur Anzeige gebracht.
Die Liste der aktiven Fehlercodes wird hierbei gemäß der Erfindung
um diejenigen Fehlercodes ergänzt,
deren Statusabfrage ergeben hat, dass sie von den Eigendiagnoseroutinen
der Steuergeräte
nicht getestet wurden. Dadurch werden auch Fehlercodes zur Anzeige
gebracht, die zwar nicht aktiv sind, die jedoch aufgrund der fehlenden Überprüfung potentielle
Fehlerkandidaten darstellen. Selektion und Anzeige der Fehlercodes
können
von dem Diagnoseprogramm in einem Verarbeitungsschritt zusammengefasst
sein, was in 3 symbolisch mit dem Programmschritt 320 dargestellt
ist. Anhand der angezeigten Fehlerliste entscheidet der Kraftfahrzeugmechaniker,
ob er eine Reparatur durchführen
will oder nicht. Das Ergebnis dieser Entscheidung kann in der Menüführung des Diagnosetesters
mit einem Entscheidungsschritt 330 abgefragt werden. In
einer alternativen Ausführungsform
kann jedoch auf diesen Entscheidungsschritt in der Menüführung des
Diagnosetesters verzichtet werden. In jedem Fall muss jedoch nach
einer durchgeführten
Reparatur 340 ein identifizierter Fehlercode in dem jeweiligen
Fehlerspeicher des betreffenden Steuergeräts gelöscht werden. Bei bisher bekannten
Diagnosetestern war es zu jeder Zeit und ohne weitere Überprüfung möglich, sämtliche
Fehlercodes, die sich in Fehlerspeichern von Steuergeräten im Kraftfahrzeug
befanden, zu löschen.
Die Erfindung besteht nun darin, dass nach einem Löschen eines
Fehlercodes bzw. nach einem Löschversuch
eines Fehlercodes mit dem Diagnosetester und mit den Eigendiagnoseroutinen
der Steuergeräte
eine Reparaturüberprüfung durchgeführt wird.
Diese Reparaturüberprüfung wird
durchgeführt,
indem die Eigendiagnoseroutinen der Steuergeräte nach einem Löschversuch
eines Fehlercodes noch einmal gestartet werden. Es werden wieder
die Verarbeitungsschritte 310 und 320 durchlaufen.
Die Reparatur ist dann erfolgreich beendet, wenn auf dem Diagnosetester
weder aktive Fehlercodes noch Fehlercodes mit dem Status „nicht
getestet" angezeigt
werden. Mit dieser Programmschleife wird sichergestellt, dass die
erfolgten Reparaturmaßnahmen
mindestens einmal getestet wurden. Konnte ein erfolgreicher Test
nicht durchgeführt
werden, weil z. B. die Prüfvoraussetzungen
für einen
Diagnoselauf nicht vorlagen, so wird diese fehlgeschlagene Überprüfung mit
der Abfrage der Fehlercodes auf den Status „nicht getestet" festgestellt und
auf der Anzeige des Diagnosetesters dem Kraftfahrzeugmechaniker
zur Anzeige gebracht. In diesem Falle wäre die Reparatur nicht verifiziert worden
und der Kraftfahrzeugmechaniker wird darauf hingewiesen, dass die
Prüfvoraussetzungen
für eine Überprüfung nicht
vorlagen.
-
Ein
weiteres Ausführungsbeispiel
gemäß der Erfindung
ist mit dem Programmablaufplan der 4 dargestellt.
Auch hier werden mit einem Diagnosetester nach dessen Anschluss
an die Diagnoseschnittstelle des Kraftfahrzeugs die Eigendiagnoseroutinen
der im Kraftfahrzeug befindlichen Steuergeräte gestartet oder es werden
zumindest die in den Fehlerspeichern der Steuergeräte abgelegten
Fehlercodes ausgelesen. Zusätzlich
zu den verifizierten und aktiven Fehlercodes werden die Statusinformationen
zu den Fehlercodes ausgelesen und weiterverarbeitet. Auf dem Display
des Diagnosetesters werden schließlich alle aktiven Fehlercodes
sowie alle Fehlercodes mit dem Status „nicht getestet" zur Anzeige gebracht.
Die Verarbeitungsschritte 410 bzw. 420 entsprechen
hierbei genau den Verarbeitungsschritten 310 bzw. 320 nach
dem Ablaufplan aus 3. Auch bei dem Ausführungsbeispiel
der 4 kann die Entscheidung des Kraftfahrzeugmechanikers,
ob er eine Reparatur durchführen
will oder nicht, per Menüabfrage 430 dokumentiert
werden oder auch nicht. Entschließt sich der Kraftfahrzeugmechaniker
zu einer Reparatur, so kann er gemäß dem Ausführungsbeispiel für die Reparaturverifikation
entsprechend dem Ablaufplan nach 4 nach jedem
durchgeführten
Reparaturschritt eine Einzelfehlerüberprüfung 450 starten.
Eine Einzelfehlerüberprüfung kann
insbesondere dann sinnvoll sein, wenn der Diagnosetester vier verschiedene
Fehlercodes anzeigt. Der Kraftfahrzeugmechaniker kann dann zunächst einen
Fehlercode per Pull-down-Menü auswählen, sich
auf dem Diagnosetester die zugehörigen
Reparaturanleitungen holen und anzeigen lassen, dann die Reparatur 440 durchführen und nach
abgeschlossener Reparatur eben diese Einzelfehlerüberprüfung 450 starten.
Ein Starten der Einzelfehlerüberprüfung bewirkt
dann, dass mit dem Diagnosetester zu dem ausgewählten Fehlercode eine Reparaturverifikation
durchgeführt
wird. Die Reparaturverifikation erfolgt durch Starten der Eigendiagnoseroutine
des betreffenden Steuergeräts
und durch eine Statusüberprüfung des
aktuell reparierten Fehlercodes. Kann die Eigendiagnoseroutine des
Steuergeräts
den beanstandeten Fehlercode ordnungsgemäß prüfen und ergibt diese Prüfung, dass
nun der Fehlercode nicht mehr aktiv ist, so wird der betreffende
Fehlercode per Einzelfehlerlöschung
aus der Fehlerliste des Diagnosetesters entfernt. Dies hat für den Kraftfahrzeugmechaniker
den Vorteil, dass er die Reparaturliste Punkt für Punkt abarbeiten kann und
immer dann, wenn er meint, den ausgewählten Mangelpunkt beseitigt
zu haben, dies sofort mittels einer Einzelfehlerüberprüfung mit Hilfe des Diagnosetesters überprüfen kann.
Die Teilreparatur gilt dabei als erfolgreich, wenn der betreffende
Einzelfehler aus der Fehlerliste des Diagnosetesters nicht mehr
angezeigt wird.
-
Dieser
Sachverhalt ist im Ablaufschema der 4 mit dem
Programmschritt 460 verdeutlicht.
-
Alternativ
zur Einzelfehlerlöschung
kann der Kraftfahrzeugmechaniker natürlich auch zunächst alle
angezeigten Reparaturen durchführen
und dann mit dem Diagnosetester eine Reparaturverifikation für alle vormals
beanstandeten Fehlercodes durchführen
lassen. Dies würde
dem Ablaufschema der 3 entsprechen. Die Wahl, welches
Vorgehen der Kraftfahrzeugmechaniker wählt ist diesem selbst überlassen.
Mit dem erfindungsgemäßen Diagnosetester
können
beide Ablaufschemata zur Reparaturverifikation durchgeführt werden.
-
Die 5 und 6 veranschaulichen,
wie die verbesserte Reparaturverifikation mit dem Diagnosetester
umgesetzt werden kann. Dargestellt sind typische Screenshots von
dem Anzeigedisplay des Diagnosetesters. Neben Informationen zu dem
untersuchten Fahrzeug 8 zum angezeigten Dateninhalt 9 stehen
dem Diagnosemechaniker auf der Benutzeroberfläche des Diagnosetesters in
Form von sog. Buttons 10 Bedienelemente zur Verfügung, mit
denen er den Diagnosetester steuern und bedienen kann. Hauptpunkt
der Erfindung ist die zusätzliche
Anzeige aller nicht getesteten Fehlercodes, die von dem Diagnosetester
in den Steuergeräten
des Kraftfahrzeugs zusätzlich
zu den aktivierten Fehlercodes aufgefunden werden konnten. Im dargestellten
Beispiel sind dies die Fehlercodes 1000, 1001 und 1002. Gemäß der Erfindung
wird zu jedem Fehlercode auch seine Statusinformation abgefragt
und auf der Anzeige des Diagnosetesters zur Anzeige gebracht. Die
Anzeige kann z. B. in Form einer Spalte 11 mit dem Namen „Status" erfolgen, in der
dann zu jedem Fehlercode die entsprechenden Statusinformationen
getestet oder nicht getestet abgelegt sind. Es werden jedoch nicht
nur die aktivierten Fehlercodes, die in der Anzeige nach 5 als
aktuell bezeichnet sind, zur Anzeige ge bracht, sondern es werden
auch diejenigen Fehlercodes zur Anzeige gebracht, die den Status „nicht
getestet" haben.
Im Ausführungsbeispiel
der 5 ist dies der Fehlercode 1003. Der Screenshot nach 5 soll
exemplarisch die Anzeige veranschaulichen, die nach Anschluss des
Diagnosetesters an die Diagnoseschnittstelle und nach erfolgter Datenübertragung
sowie nach erfolgter Datenselektierung dem Kraftfahrzeugmechaniker
auf dem Diagnosetester zur Anzeige gebracht wird. Per Menüsteuerung,
z. B. durch ein Pull-down-Menü,
kann der Kraftfahrzeugmechaniker zu den einzelnen Fehlercodes weitere
Informationen mit Hilfe der Bedien-Button 10 abrufen. Von
besonderem Interesse sind z. B. die zu dem jeweiligen Fehlercode
zugehörigen
Reparaturanleitungen, die in der Regel ebenfalls in dem Diagnoseprogramm
des Diagnosetesters integriert und abgelegt sind. Mit Hilfe von
Bedien-Buttons 10, z.B. F3 kann der Kraftfahrzeugmechaniker die
vorbeschriebenen Einzelfehlerüberprüfungen zu einem
speziellen Fehlercode initiieren oder nach erfolgter Gesamtreparatur,
z.B. mit Bedienbutton F7 eine Reparaturverifikation starten.
-
Ein
mögliches
Ergebnis einer dermaßen durchgeführten Reparaturverifikation
wird mit dem Screenshot nach 6 dargestellt.
In dem exemplarisch gewählten
Ausführungsbeispiel
nach 5 wurden alle Reparaturen zu den Fehlercodes 1000, 1001,
1002, 1003 durchgeführt.
Die dann gestartete Reparaturverifikation hat jedoch ergeben, dass
für zwei
der vier Fehlercodes die Prüfvoraussetzungen nicht
vorlagen, um mit Hilfe der Eigendiagnoseroutinen der betreffenden
Steuergeräte
das ordnungsgemäße Funktionieren
der betreffenden Funktionen zu testen. Deshalb wird dem Kraftfahrzeugmechaniker dieser
Befund zur Anzeige gebracht. Es wird ihm angezeigt, welcher vorher
bemängelte
Fehlercode nach erfolgter Reparatur nicht getestet werden konnte.
Besonders zweckmäßig sind
zu jedem Fehlercode in dem Datenbanksystem des Diagnosetesters auch die
vorgeschriebenen Prüfvoraussetzungen
abgelegt. Zweckmäßigerweise
ist für
die Abrufung dieser Prüfvoraussetzungen
ein spezieller Informations-Button 12 implementiert, bei
dessen Betätigung zu
einem ausgewählten
Fehlercode, z. B. Fehlercode 1000, per Menüauswahl Zusatzinformationen
abgerufen werden können.
Diese Zusatzinformationen können
neben den Prüfvoraussetzungen
auch Angaben darüber
enthalten, welche Prüfvoraussetzungen nicht
erfüllt
waren. In dem dargestellten Ausführungsbeispiel
könnte
z. B. die notwendige Mindestdrehzahl des Bordnetzgenerators nicht
erreicht worden sein, damit die nicht getesteten Stromsensoren Fehlercode
1000, 1001 überhaupt
getestet werden können.
Der Kraftfahrzeugmechaniker erhält
dann einen Hinweis, dass er die Motordrehzahl des Kraftfahrzeugmotors
für eine
erfolgreiche Überprüfung mindestens
auf z. B. 2000 Umdrehungen pro Minute steigern muss.
-
Eine
Reparaturverifikation ist erst erfolgreich abgeschlossen, wenn der
Diagnosetester keine Fehlercodes mehr zur Anzeige bringt.