-
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. Diagnosesystem und Diagnosetester entsprechen insbesondere
den gesetzlichen Bestimmungen für
Diagnosesysteme in den USA.
-
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. Beschrieben 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 ver arbeiten
und zu interpretieren und das Ergebnis dieser Interpretation 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. Besonderes Augenmerk
liegt hierbei auf dem ge setzlichen Verbot einer Einzelfehlerlöschung bei
abgasrelevanten Steuergeräten
in den USA.
-
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 hauptsächlich
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.
Die zur Anzeige zu bringenden Fehlercodes werden hierbei zunächst in
einem oder mehreren primären
ersten Fehlerspeichern gespeichert, und vor dem Löschen der
primären
Fehlerspeicher in einen sekundären
zweiten Fehlerspeicher kopiert. Dies ermöglicht die Verwendung des in
den USA für
Diagnosesysteme vorgeschriebenen Total-Reset der primären Fehlerspeicher, ohne dass
die Diagnose relevanten Informationen im zweiten Fehlerspeicher
verloren gehen. Der Inhalt des sekundären Fehlerspeichers ist die
Grundlage für
die anzuzeigenden Fehlercodes auf dem Display des Diagnosetesters.
-
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 im sekundären
zweiten Fehlerspeicher 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 Fehler codes erfüllt
waren und die Statusinformation das Ergebnis „getestet" liefert. Dies hat den Vorteil, dass
einmal diagnostizierte Fehler erst dann von der Anzeige des Diagnosetesters entfernt
werden, 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 Komplettaustausch z.B. eines Aktors oder eines Sensors
vorgenommen wird. Nach dem vorbekannten Stand der Technik würde jeder
Diagnosetester den neu eingebauten Aktor oder Sensor für in Ordnung
befinden, nur aus dem Grund, weil in dem Fehlerspeicher des zugehörigen Steuergerätes nach
Löschen
der primären
Fehlerspeicher keine Fehlercodes abgelegt sind. Mit der Erfindung
hingegen verbleiben Fehlercodes mit der Statusinformation „nicht
getestet" solange
im sekundären
Fehlerspeicher bis die Reparatur mindestens einmal entsprechend
der für
das Austauschteil geltenden Prüfvoraussetzungen
getestet wurde. Die Reparatur ist erst dann abgeschlossen wenn weder
in den primären
Fehlerspeichern aktivierte Fehlercodes abgelegt sind noch im sekundären Fehlerspeicher
B Fehlercodes mit der Statusinformation „nicht getestet" abgelegt sind. 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 sinn voller weise 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 Diagnosetesters 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
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,
durchgeführt
werden.
-
In
einer weiteren Ausführungsform
sind beim Diagnosetester die Funktionen zur Löschung der Fehlercodes im sekundären Fehlerspeicher
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. Hierzu
wird nach einer erfolgten Reparatur ein Komplett Reset der primären Fehlerspeicher
durchgeführt.
Anschließend
wird ein Diagnoselauf gestartet, bei dem im Fehlerfall die primären Fehlerspeicher wieder
beschrienen werden. Mit dem Ergebnis des Diagnoselaufs werden die
Einträge
im sekundären Fehlerspeicher
aktualisiert. 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 oder Komplett-Reset
der primären
Fehlerspeicher, kann dann nicht mehr zu einem scheinbar ordnungsgemäßen Service führen, da
mit dem Diagnosetester weiterhin die im sekundären Fehlerspeicher abgelegten
Fehlercodes zur Anzeige gebracht werden.
-
In
einer weiteren Ausführungsform
wird die Löschung
der Fehlercodes im sekundären
Fehlerspeicher innerhalb des Steuergerätes durchgeführt, wenn
eine Statusüberprüfung sowohl
die fehlerfreie Funktion der durchgeführten Reparaturmaßnahme als
auch die korrekte Überprüfung der
Reparaturmaßnahme
anhand der für
die jeweilige Fehlercodes vorgeschriebenen Prüfvoraussetzungen durchgeführt wurden.
Hierzu wird nach einer erfolgten Reparatur ein Komplett Reset der
primären
Fehlerspeicher durchgeführt.
Anschließend
wird bei der Prüfbereitschaft
von Fehlercodes, der Status der entsprechenden Fehlercodes im sekundären Fehlerspeicher
aktualisiert. Diese Ausführungsform
hat den Vorteil, daß 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 oder Komplett-Reset
der primären
Fehlerspeicher, kann dann nicht mehr zu einem scheinbar ordnungsgemäßen Service
führen,
da mit dem Diagnosetester weiterhin die im sekundären Fehler speicher
abgelegten Fehlercodes zur Anzeige gebracht werden und die Überwachung
der Logik vollständig
im Steuergerät
liegt.
-
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 eine
schematische Darstellung des Kopiervorgangs der Fehlercodes aus
den primären Fehlerspeichern
in den sekundären
Fehlerspeicher,
-
4 die
Speicherbelegung von primären und
sekundärem
Fehlerspeicher nach einem Total-Reset der primären Fehlerspeicher,
-
5 eine
schematische Darstellung für
den Abgleich von primären
und sekundärem
Fehlerspeicher nach einer Reparatur und nach erfolgter Reparaturverifikation
mit dem Diagnosetester,
-
6 ein
Ablaufschema für
eine verbesserte Reparaturverifikation mit Hilfe eines Diagnosetesters,
-
7 ein
weiteres mögliches
Ablaufschema für
eine verbesserte Reparaturverifikation mit Hilfe eines Diagnosetesters,
-
8 eine
graphische Benutzeroberfläche, wie
sie vom Diagnosetester dem Kraftfahrzeugmechaniker zur Anzeige gebracht
wird,
-
9 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 Kommunikationsschnittstellen ü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 kodifi zierten 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 Diagnosetester
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 verschiedene 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
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 verbrei tete 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 zum Verständnis der Erfindung wird nun
im Folgenden auf den Kern der Erfindung eingegangen. An und für sich könnte man
die mit der $58-Response erhaltenen Fehlercodes inklusive deren
Status in einem Fehlerspeicher abspeichern und den Inhalt dieses Fehlerspeichers
auf der Anzeige des Diagnosetesters zur Anzeige bringen. Der Kraftfahrzeugmechaniker
erhielte dann eine Liste aller identifizierten Fehlfunktionen und
könnte
die Liste in einem Reparaturprozess Punkt für Punkt abarbeiten. Um den Überblick
nicht zu verlieren, würde
er sicher alle bearbeiteten Fehlercode nach abgeschlossener Reparatur gerne
per Einzelfehlerlöschung
aus dem Fehlerspeicher löschen,
um danach angezeigt zu bekommen ob die bearbeiteten Fehlercodes
bereits vom Steuergerät
wieder überprüft wurden.
In den USA gibt es nun die Besonderheit, dass die Diagnose von Kraftfahrzeugen
strengen gesetzlichen Regelungen unterliegt. Im Zusammenhang mit
der Erfindung ist hierbei besonders eine gesetzliche Regelung relevant,
die besagt, dass bei Reparatur und Diagnose eines Kraftfahrzeugs
eine Einzelfehlerlöschung
der bei der Diagnose festgestellten Fehlercodes nicht zulässig ist.
Das Verbot der Einzelfehlerlöschung
gilt besonders für
abgasrelevante Fehlercodes. In den U.S.A. ist hier nur erlaubt,
alle den Fehlerspeicher eines Steuergerätes komplett zu löschen. Ein
derartiger allgemeiner Löschbefehl
wird vom Keyword-Protokoll 2000 mit dem hexadezimalcodierten
$14FF00-Request und dem Diagnostic Service Name: „Clear
Diagnostic Information" zur
Verfügung
gestellt. Nachteil an diesem Löschbefehl
ist, dass bei seiner Betätigung
sämtliche
diagnoserelevante und damit auch reparaturrelevante Information
verloren geht. Um auch in den USA mit dem gesetzlich vorgeschriebenen
Total-Reset der Fehlerspeicher eine verbesserte Reparaturverifikation
mit einem Diagnosetester durchführen
zu können,
sind deshalb zusätzliche Maßnahmen
notwendig, die den Kern dieser Erfindung ausmachen. Haupterfindungsgedanke
ist hierbei das Abspeichern aller für eine Reparaturverifikation
des Kraftfahrzeugs relevanten Diagnoseinformationen in einem zweiten
Fehlerspeicher B und die gesonderte Behandlung dieses Fehlerspeichers
B. Diagnoserelevante Informationen sind hierbei alle aktivierten
und getesteten Fehlercodes. Die schematische Darstellung der 3 verdeutlicht
in graphischer Form die Einführung
eines zweiten Fehlerspeichers B. Die Einführung dieses sekundären Fehlerspeichers
B ermöglicht,
dass auf dem originären
primären
Fehlerspeicher A weiterhin ein Total-Reset aller diagnoserelevanten
Informationen durchgeführt werden
kann, ohne den Verlust der für
die Reparaturverifikation notwendigen Diagnoseinformationen befürchten zu
müssen.
Die für
die Reparaturverifikation notwendigen Diagnoseinformationen sind
nämlich
im Fehlerspeicher B zwischengespeichert. Auf dem zweiten Fehlerspeicher
B darf kein Total-Reset angewandt werden.
-
Nach
einer durchgeführten
Reparatur löscht der
Kraftfahrzeugmechaniker mit einem Total-Reset die Diagnoseinformationen
in den primären
Fehlerspeichern A. Die Auslösung
dieses Löschbefehls wird
als Triggersignal genommen, um die aktiven Fehlercodes aus den primären Fehlerspeichern
im sekundären
Fehlerspeicher abzulegen. Nach diesem Kopiervorgang werden durch
diesen Total-Reset in allen primären
Fehlerspeichern der Steuergeräte
die Fehlercodes und die Statusinformationen zu den Fehlercodes gelöscht. Unberührt von
diesem Total-Reset bleibt der sekundäre Fehlerspeicher B. Diese
Situation wird mit der graphischen Darstellung der 4 verdeutlicht.
In dem zweiten Fehlerspeicher B sind nach wie vor alle vormals bemängelten
Diagnoseinformationen abgelegt.
-
Ausgehend
von diesem Diagnosezustand muss es nun noch entsprechend dem Reparaturfortschritt
und entsprechend einer Reparaturverifikation zu einer Aktualisierung
des sekundären
Fehlerspeichers B kommen. Dieser Aktualisierungsschritt soll mit
der graphischen Darstellung von 5 verdeutlicht
werden. Nach durchgeführter
Reparatur und nach erfolgtem Total-Reset der primären Fehlerspeicher wird der
Kraftfahrzeugmechaniker mit dem reparierten Fahrzeug einen Testlauf
durchführen.
Bei diesem Testlauf werden die Eigendiagnoseroutinen der Steuergeräte im Kraftfahrzeug
aktiviert und liefern wieder Diagnoseinformationen hinsichtlich
aktivierter oder inaktiver Fehlercodes sowie Diagnoseinformationen
hinsichtlich des Status aller bekannten Fehlercodes, ob der betreffende
Fehlercode getestet wurde oder nicht. Diese Diagnoseinformation
wird von den Steuergeräten
wieder in die primären
Fehlerspeicher A geschrieben. Mit einem weiteren Auslesen der Diagnoseinformationen
aus den primären Fehlerspeichern
A kann nun mit dem Diagnosetester und mit dessen implementierten
Diagnoseprogramm ein Abgleich mit dem Fehlerspeicher B erfolgen.
Bei diesem Abgleich wird geprüft,
welche Fehlercodes im zweiten Fehlerspeicher B nach erfolgter Reparatur gelöscht werden
können.
Gelöscht
werden können alle
diejenigen Fehlercodes, die durch die Eigendiagnoseroutinen der
Steuergeräte
getestet wurden. Nicht gelöscht
werden, dürfen
all diejenigen Fehlercodes, die beim Testlauf nicht von den Eigendiagnoseroutinen
getestet wurden. Im Ausführungsbeispiel der 5 wäre das der
Fehlercode DTC2, der nicht getestet wurde und deshalb im Fehlerspeicher
B verbleiben muss. Gelöscht
werden konnte der Fehlercode DTC1, da er von den Eigendiagnoseroutinen getestet
wurden. Fehlercodes, die nach erfolgter Reparatur erstmals aktiv
getestet wurden, können
gegebenenfalls neu in den sekundären
Fehlerspeicher A übernommen
werden. Im dargestellten Ausführungsbeispiel
der 5 wäre
das der Fehlercode DTC3, der positiv getestet wurde und nun aktiv
ist. Die Gesamtheit der Inhalte von den primären Fehlerspeichern A und von
dem sekundären
Fehlerspeicher B enthält
damit nach erfolgter Teil-Reparatur und nach erfolgtem Testlauf
die Mängelsituation
nach Teil-Reparatur und Testlauf. Wird die Fehlerliste der aktiven Fehlercodes
aus den primären
Fehlerspeichern A und die Liste der noch nicht getesteten ursprünglichen
Fehlercodes im sekundären
Fehlerspeicher B mit dem Diagnosetester auf dessen Anzeige dem Kraftfahrzeugmechaniker
zur Anzeige gebracht, so hat der Kraftfahrzeugmechaniker eine Information, welche
Reparaturen erfolgreich waren und welche noch zu erledigen sind.
-
Der
zuvor im Zusammenhang mit den beiden 4 und 5 beschriebene
Abgleich von primären
Fehlerspeichern A mit dem sekundären
Fehlerspeicher B lässt
sich in einen Diagnosetester programmtechnisch relativ einfach implementieren. 6 zeigt
hierbei exemplarisch einen Programmablaufplan, mit dem der sekundäre Fehlerspeicher
B mit den primären
Fehlerspeichern A abgeglichen werden kann. Der Ablaufplan besteht
hauptsächlich
neben Beginn und Ende aus den Verfahrensschritten 610, die
notwendig sind um getestete Fehlercodes aus dem sekundären Fehlerspeicher
zu löschen.
Nach erster Reparatur und nach erstem Testlauf wird der sekundäre Fehlerspeicher
B aktualisiert, indem im Fehlerspeicher B all diejenigen Fehlercodes
gelöscht werden,
die nach dem Testlauf und nach einem Status Polling in den primären Fehlerspeicher
A den Status „getestet" haben. Nach diesem
Abgleich wird die in Fehlerspeicher B abgelegte Fehlerliste dem
Kraftfahrzeugmechaniker auf dem Diagnosetester gegebenenfalls zusammen
mit der Liste der aktiven Fehlercodes aus den primären Fehlerspeichern
zur Anzeige gebracht.
-
Zusammenfassend
lässt sich
damit ein Programmablaufplan für
eine verbesserte Reparaturverifikation aufstellen und als Diagnoseprogramm
in einem Diagnosetester implementieren. In 7 ist exemplarisch
ein solcher Programmablaufplan graphisch dargestellt. Nachdem das
Kraftfahrzeug in die Werkstatt gekommen ist, wird zunächst der
Diagnosetester an die Diagnoseschnittstelle des Kraftfahrzeugs angeschlossen.
Der Prozess mit der verbesserten Reparaturverifikation wird mit
dem Diagnosetester 700 gestartet. In einem ersten Verfahrensschritt 710 werden
sämtliche
Fehlercodes aus den primären
Fehlerspeichern A und alle Statusinformationen zu allen bekannten
Fehlercodes ausgelesen. Die Statusinformationen werden ausgewertet
und selektiert. Von Interesse sind alle aktiven Fehlercodes und
all diejenigen Fehlercodes, die von den Eigendiagnoseroutinen der
Steuergeräte
nicht überprüft wurden.
Diese Fehlercodes haben den Status „nicht getestet". Zur Anzeige und
zur Weiterverarbeitung werden hierbei sämtliche aktiven Fehlercodes
sowie all diejenigen Fehlercodes mit dem Status „nicht getestet" gebracht. Anhand
der Anzeige auf dem Diagnosetester entscheidet dann der Kraftfahrzeugmechaniker,
ob eine Reparatur durchzuführen
ist oder nicht. Dieser Entscheidungsprozess wird auch mit dem Diagnosetester
nachvollzogen und ist in 7 symbolisch mit der Bezugsziffer 720 dargestellt.
Erfolgt eine Reparatur, dargestellt mit der Bezugsziffer 721,
so wird nach Abschluss der Reparatur oder zumindest nach Abschluss
einer Teilreparatur mit einem Befehl zum Total-Reset der Inhalt
der primären
Fehlerspeicher A gelöscht.
Der Löschbefehl 730 wird
hierbei als Triggersignal genommen, um zumindest die aktiven Fehlercodes
aus den primären
Fehlerspeichern und den sekundären
Fehlerspeicher zu kopieren. Dies entspricht in 7 dem
Verfahrensschritt mit dem Bezugszeichen 731. Nach dem Kopiervorgang
werden die primären
Fehlerspeicher per Total-Reset gelöscht 732. Dadurch gehen
zunächst
in den primären Fehlerspeichern
A alle Diagnoseinformationen verloren. Zur Reparaturüberprüfung erfolgt
in einem weiteren Verfahrensschritt mit dem Bezugszeichen 740 ein
Testlauf. Bei diesem Testlauf, der in der Regel eine Art Probefahrt
mit dem Kraftfahrzeug ist, werden die Eigendiagnoseroutinen der
Steuergeräte
im Kraftfahrzeug aktiviert. Treten weiterhin Fehler auf, so werden
die aktivierten Fehlercodes von den Eigendiagnoseroutinen wieder
in die primären
Fehlerspeicher A eingelesen, ebenso können die Statusinformationen
zu sämtlichen
bekannten Fehlercodes von den Eigendiagnoseroutinen ermittelt werden. Ebenso
können
damit nach erfolgtem Testlauf wiederum aktivierte Fehlercodes und
Statusinformationen aus den primären
Fehlerspeichern ausgelesen und ermittelt werden.
-
Die
Aktualisierung des sekundären
Fehlerspeichers B erfolgt dann in einem weiteren Verfahrensschritt 750,
wie er im Zusammenhang mit dem Abgleich der beiden Fehlerspeicher
A und B schon im Zusammenhang mit 6 beschrieben
wurde. Nach Abgleich der primären
Fehlerspeicher A mit den Inhalten des zweiten Fehlerspeichers B
wird der aktualisierte Inhalt von Fehlerspeicher B zusammen mit
dem aktuellen aktiven Fehlercodes, die in den primären Fehlerspeichern
der Steuergeräte
gegebenenfalls neu abgelegt wurden, auf dem Diagnosetester dem Kraftfahrzeugmechaniker
zur Anzeige gebracht. Die Reparatur ist hierbei erfolgreich beendet, wenn
weder im Fehlerspeicher B noch in den primären Fehlerspeichern Fehlercodes
vorhanden sind, was für
den Kraftfahrzeugmechaniker dadurch ersichtlich wird, dass auf der
Anzeige des Diagnosetesters keine Mängelliste mehr angezeigt wird.
Sind im Fehlerspeicher B Einträge
vorhanden, so werden die entsprechenden Mängel auf dem Diagnosetester
zur Anzeige gebracht. Dieser Entscheidungsprozess ist im Programmablaufplan
der 7 mit dem Bezugszeichen 760 dargestellt.
Programmtechnisch umgesetzt wird eine derar tige Entscheidung durch
eine Ja/Nein-Abfrage, ob im sekundären Fehlerspeicher B oder den
primären
Fehlerspeichern A Fehlercodes abgelegt sind oder nicht. Erfolgt
eine Anzeige auf dem Display des Diagnosetesters, symbolisch dargestellt
durch den Verfahrensschritt der Bezugsziffer 770, so setzt
der Reparaturprozess von Neu ein. Das Neueinsetzen des Reparaturprozesses
wird zweckmäßigerweise
mit einer Programmschleife realisiert. Ein möglicher Aufsetzpunkt der Programmschleife
ist hierbei der Verfahrensschritt mit dem Bezugszeichen 720 gemäß 7.
Andere Aufsetzpunkte können auch
der Verfahrensschritt mit dem Bezugszeichen 711 sein. Bei
einem Aufsetzpunkt laut Verfahrensschritt 711 kann ein
Verfahrensschritt mit dem Bezugszeichen 770 entfallen.
-
Die 8 und 9 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 Kraftfahrzeugmechaniker 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 Anzeige aller aktiven Fehlercodes, die von
dem Diagnosetester in den Steuergeräten des Kraftfahrzeugs aufgefunden werden
konnten. Im dargestellten Beispiel sind dies die Fehlercodes 1000, 1001 und 1002.
Zusätzlich können nicht
nur die aktivierten Fehlercodes, die in der Anzeige nach 8 als „aktiv" bezeichnet sind, zur
Anzeige gebracht, sondern es können
auch diejenigen Fehlercodes zur Anzeige gebracht werden, die den
Status „nicht
getestet" haben.
Im Ausführungsbeispiel
der 8 ist dies der Fehlercode 1003. Der Screenshot
nach 8 soll exemplarisch die Anzeige veranschaulichen,
die nach An schluss 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 kann der Kraftfahrzeugmechaniker nach
erfolgter Gesamtreparatur eine Reparaturverifikation starten.
-
Ein
mögliches
Ergebnis einer dermaßen durchgeführten Reparaturverifikation
wird mit dem Screenshot nach 9 dargestellt.
In dem exemplarisch gewählten
Ausführungsbeispiel
nach 8 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. Diese beiden Fehlercodes
sind im sekundären
Fehlerspeicher B verblieben. 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, d.h. wenn
die primären
Fehlerspeicher A keine aktiven Fehlercodes enthalten und im sekundären Fehlerspeicher
B alle Einträge
nach erfolgtem Test und Status Polling gelöscht wurden.