Die Erfindung betrifft ein Diagnosesystem und einen Diagnose¬ tester für die Überprüfung von Kraftfahrzeugsteuergeräten, mit dem nicht nur, wie bisher üblich, das Auffinden von Feh¬ lern 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 Kraftfahrzeugsteuerge¬ räte sind heutzutage in Kraftfahrzeugwerkstätten vorwiegend rechnerbasiert. Federführend bei der Einführung rechnerba¬ sierter 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ät¬ ten 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 Al, die hier beispielhaft genannt wird, weil sie diese Grundstruktur besonders prägnant und kurz zusammenfasst. Be- schrieben wird eine Diagnosetestvorrichtung für Kraftfahrzeu¬ ge, 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 abspei¬ chern, 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 ei¬ nes externen Diagnosetesters mit den kraftfahrzeugseitigen Steuergeräten war in der Vergangenheit und ist es zum Teil noch heute Gegenstand von Normierungsbestrebungen. Insbeson¬ dere in den USA werden diese Normierungsbestrebungen, mit de¬ nen der Zugang und damit die Diagnosefähigkeit der kraftfahr- zeugseitigen 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 Inter- pretation auf einem Bildschirm des Diagnosetesters zur Anzei¬ ge zu bringen. In der Kraftfahrzeugwerkstatt arbeitet dann ein Kraftfahrzeugmechaniker die angezeigte Mängelliste ab, wobei er mit Hilfe des Diagnosetesters zu den einzeln aufge¬ führten Mängel weitere Informationen abrufen kann. Von beson¬ derem Interesse für ihn sind hierbei weitere technische Grundlagen, wie technische Zeichnungen und natürlich die Re¬ paraturanleitungen, mit denen er den festgestellten Fehler beheben kann. Hat der Kraftfahrzeugmechaniker mit seinen Re¬ paraturen die Mängelliste abgearbeitet, löscht er mit Hilfe des Diagnosetesters die abgespeicherten und ausgelesenen Feh¬ lercodes in den kraftfahrzeugseitigen Steuergeräten und im Diagnosetester selbst. Eine Abschlussüberprüfung, ob die vor¬ genommenen Reparaturen erfolgreich waren oder ob sich durch die Reparatur Folgefehler ergeben haben, wird je nach Ar¬ beitsorganisation in der Kraftfahrzeugwerkstatt mit einer ab¬ schließenden Probefahrt vorgenommen. Der Patentanmelderin be¬ kannte 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 Kraftfahrzeugmechani¬ ker bisher von einem Diagnosetester keine Unterstützung da¬ hingehend, 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 ver¬ besserte Reparaturverifikation mit Hilfe des Diagnosetesters ermöglichen. Diese Aufgabe wird gelöst mit einem Diagnosesystem und einem Diagnosetester entsprechend der unabhängigen Ansprüche. Vor¬ teilhafte Ausführungsformen der Erfindung sind in den abhän¬ gigen Ansprüchen aufgezeigt oder werden in der folgenden Be¬ schreibung verdeutlicht.

Die Lösung gelingt mit einem rechnerbasierten Diagnosetester, der mit Hilfe eines Diagnoseprogramms über eine Diagnose- schnittsteile sowie über Datenleitungen mit den im Kraftfahr¬ zeug verbauten Steuergeräten Informationen austauschen kann. Die kraftfahrzeugseitigen Steuergeräte verfügen über Pro¬ grammroutinen zur Eigendiagnose der Steuergeräte und sind in der Lage identifizierte Fehler in Form von Fehlercodes in re¬ servierten Speicherbereichen abzulegen. Das im Diagnosetester implementierte Diagnoseprogramm liest die Fehlercodes aus den reservierten Speicherbereichen aus, interpretiert die Fehler¬ codes und bringt sie auf einem Display zusammen mit den In¬ terpretationen zur Anzeige. Um zu überprüfen inwieweit vorge¬ nommene Reparaturen erfolgreich abgeschlossen wurden, wird mit Hilfe des im Diagnosetester implementierten Diagnosepro¬ gramms ein Status Polling durchgeführt. Bei diesem Status Polling werden zu allen im System bekannten Fehlercodes die Statusinformationen dieser Fehlercodes abgefragt und ausge¬ wertet . Es werden hierbei alle Fehlercodes zur Anzeige ge¬ bracht, deren FehlerSetzbedingungen entweder positiv getestet wurden oder deren PrüfVoraussetzungen nicht vorlagen, um ei¬ nen 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 Vergan¬ genheit 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 po¬ tentiellen Fehler entsprechend der PrüfVoraussetzungen getes¬ tet worden sind und das Testergebnis keine positive Verlet¬ zung einer Fehlersetzbedingung ergeben hat. Für durchgeführte Reparaturmaßnahmen bedeutet dies, dass die Reparaturmaßnahme erst dann abgeschlossen ist, wenn mit dem Diagnosetester min¬ destens ein Mal die PrüfVoraussetzungen für die durchgeführte Reparaturmaßnahme durchlaufen wurden und dieser Durchlauf er¬ geben hat, dass nun für die überprüfte Maßnahme keine Fehler¬ setzbedingung mehr vorliegt .

In einer vorteilhaften Ausführungsform der Erfindung ist das Löschen von Fehlercodes mit dem Diagnosetester daran gebun¬ den, dass für den zu löschenden Fehlercode mindestens ein weiterer Diagnoselauf durchgeführt wurde, wobei während die¬ ses 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 Diagnose- tester kontrolliert und überprüft wurde und dabei für in Ord¬ nung befunden wurde. Falsch durchgeführte Reparaturmaßnahmen können so mit dem Diagnosetester unmittelbar nach der Repara¬ tur 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 Reparatur¬ maß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 ge¬ testete Fehlermöglichkeiten aufmerksam und hilft ihm dabei, daran zu denken, die durchgeführten Reparaturmaßnahmen min¬ destens einmal ordnungsgemäß zu überprüfen. Die Prüfvoraus- setzungen für jeden bekannten Fehlercode sind hierbei sinn- vollerweise im Diagnoseprogramm des Diagnosetesters implemen¬ tiert, so dass der Werkstattmechaniker sich nicht für jeden möglichen Fehler im Kraftfahrzeug die vorgegebenen PrüfVor¬ aussetzungen merken zu braucht.

In einer vorteilhaften Ausführungsform der Erfindung ist die Statusüberprüfung mittels des Diagnosetesters vom Kraftfahr¬ zeugmechaniker 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 vorge¬ nommen wird. Dies hat den Vorteil, dass der Kraftfahrzeugme¬ chaniker den Diagnosetester reparaturnah einsetzen kann, und immer dann, wenn er glaubt eine Reparaturmaßnahme abgeschlos¬ sen zu haben, diese Reparaturmaßnahme sofort mit dem Diagno¬ setester überprüfen kann.

In einer anderen Ausführungsform der Erfindung kann die Sta¬ tusüberprüfung vom Diagnosetester automatisch immer dann ein- geleitet werden, wenn ein vom Diagnosetester angezeigter Man¬ gel 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 ge¬ startet werden, indem z. B. nach Anschluss des Diagnosetes¬ ters an die Diagnoseschnittstelle des Kraftfahrzeugs in zeit¬ lich 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 ausge¬ löst und durchgeführt werden.

In einer weiteren Ausführungsform sind beim Diagnosetester die Funktionen zur Löschung der Fehlercodes, die während ei¬ ner Diagnoseroutine in die Fehlerspeicher der Steuergeräte im Kraftfahrzeug geschrieben wurden, so lange blockiert, bis ei¬ ne Statusüberprüfung durch eine weitere Diagnoseroutine so¬ wohl die fehlerfreie Funktion der durchgeführten Reparatur¬ maß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ührungs- form hat den Vorteil, dass für den Kraftfahrzeugmechaniker die Reparatur erst dann beendet ist, wenn alle Fehler besei¬ tigt und auch ordnungsgemäß überprüft sind. Ein willkürliches Löschen einmal festgestellter Fehlercodes durch Löschbefehle, wie Einzelfehlerlöschung oder Komplett-Reset aller Fehler¬ speicher, kann dann nicht mehr zu einem scheinbar ordnungsge¬ mäßen Service führen.

Ohne Beschränkung der Allgemeinheit wird im Folgenden die Er¬ findung anhand von graphischen Darstellungen näher erläutert. Es zeigen :

Fig. 1 eine schematische Darstellung eines Diagnosetes¬ ters, wie er an die Steuergeräte in einem Kraft¬ fahrzeug angeschlossen ist, Fig. 2 eine schematische Darstellung von Datenformaten, wie sie im Keyword-Protokoll 2000 vereinbart sind, Fig. 3 ein AblaufSchema für eine verbesserte Reparaturve¬ rifikation mit Hilfe eines Diagnosetesters, Fig. 4 ein weiteres mögliches Ablaufschema für eine ver¬ besserte Reparaturverifikation mit Hilfe eines Di¬ agnosetesters, Fig. 5 eine graphische Benutzeroberfläche, wie sie vom Di¬ agnosetester dem Kraftfahrzeugmechaniker zur Anzei¬ ge gebracht wird, Fig. 6 die graphische Benutzeroberfläche des Diagnosetes¬ ters nach Figur 5, wie sie sich dem Kraftfahrzeug¬ mechaniker zeigt, nachdem zwar die Reparaturen durchgeführt wurden, die Reparaturen selbst aber nicht ordnungsgemäß überprüft wurden.

In Figur 1 ist eine Situation schematisch dargestellt, wie sie heute in Kraftfahrzeugwerkstätten bekannt ist. Für die Diagnose eines Kraftfahrzeuges wird ein rechnergestützter Di¬ agnosetester 1 über eine genormte Diagnoseschnittstelle 2 an das Kommunikationsnetzwerk 3 für die Steuergeräte 4 im Kraft¬ fahrzeug 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 Steuerge¬ räte-Software in speziell reservierte Speicherbereiche, sog. Fehlerspeicher, geschrieben. In der schematischen Darstellung der Figur 1 sind diese reservierten, nicht flüchtigen Spei¬ cherbereiche als FS (für Fehler-Speicher) bezeichnet. Für die Kommunikation und für den Datenaustausch zwischen einem Diag¬ nosetester 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 Nor¬ mierung sich in der ISO-Norm 14 230-3 wiederfindet. Soweit für das Verständnis der Erfindung erforderlich, wird weiter unten im Zusammenhang mit Figur 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 Rechen¬ system des Diagnosetester zu übertragen. Die Norm zu dem Key¬ word-Protokoll 2000 umfasst hierbei zwei verschiedene Appli¬ kationsmö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 Di¬ agnoseschnittstelle 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 Diagnose¬ schnittstelle 2 direkt in den Diagnosetester ausgelesen und abgelegt werden können. In der schematischen Darstellung der Figur 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 Feh¬ lerspeicher 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 trans¬ feriert werden können.

Mit der schematischen Darstellung in Figur 2 wird kurz auf das Keyword-Protokoll 2000 eingegangen. Vollständige und de¬ tailliertere 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 Steuerbe¬ fehlen, die ein Steuergerät im Kraftfahrzeug mindestens ver¬ arbeiten können muss, wenn es dem Keyword-Protokoll 2000 ent¬ sprechen soll, festgelegt. Das vom Keyword-Protokoll verwen¬ dete 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 ent¬ hält. Nach dem Header-Block folgt immer ein hexadezimalkodi¬ fizierter Steuerbefehl, der als Service Identification SID bezeichnet wird. Die im Keyword-Protokoll 2000 spezifizierten Steuerbefehle können hierbei herstellerspezifisch weiter un¬ terteilt und ausgeformt sein. In diesem Fall würde der Nutz¬ datenblock 7 weitere hexadezimalkodifizierte Steuerbefehle enthalten. Das Datenformat entsprechend des Keyword-Proto¬ kolls 2000 wird immer mit einem Byte abgeschlossen, dass eine Checksumme CS über alle Daten des jeweiligen Botschaftsfor¬ mats 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 Key¬ word-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 Antwortbot- schaft enthalten. Das Keyword-Protokoll 2000 definiert hier¬ bei nicht nur die Steuerbefehle, sondern spezifiziert auch die Dateninhalte, die eine normierte Antwort auf eine nor¬ mierte Anfrage enthalten muss. So ist z. B. festgelegt, dass auf einen $18-Request die zugehörige §58-Response im Daten¬ block zu jedem im Steuergerät bekannten Fehlercode DTCl, DTC2 - DTCn auch der jeweilige Status dieses Fehlercodes mitüber¬ tragen wird. Der Status des Fehlercodes gibt hierbei an, ob die Eigendiagnoseroutine des Steuergeräts den Fehlercode ge¬ testet 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 zuge¬ ordneten 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 ge¬ wä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 Daten¬ block 7 eine Tabelle mit allen im Steuergerät bekannten Feh¬ lercodes 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 Selek¬ tierung des Datenblocks der zugehörigen $58-Antwort möglich, gezielt all diejenigen Fehlercodes zu identifizieren und aus¬ zulesen, deren Status anzeigt, dass die zugehörigen Funktio¬ nen nicht ordnungsgemäß entsprechend der PrüfVoraussetzungen für diese Funktionen getestet wurden. Diese Information kann gewonnen werden, völlig unabhängig davon, ob eine Fehlfunkti¬ on 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 Fehlerco¬ des über ihren Status abzufragen. Das Keyword-Protokoll 2000 ist im Zusammenhang mit der Erfindung als eine besonders ver¬ breitete 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 durch¬ führen, bei der neben aktivierten Fehlercodes auch deren Sta¬ tusinformationen ausgelesen und selektiert werden können.

Nach den vorbeschriebenen Grundlagen wird nun im Zusammenhang mit den Figuren 3 bis 6 auf den Kern der Erfindung eingegan¬ gen. Figur 3 zeigt ein AblaufSchema für eine mögliche verbes¬ serte Reparaturverifikation. Nach dem Anschluss des Diagnose¬ testers 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- gerate verifizierten und aktivierten Fehlercodes. Im Unter¬ schied 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 Diagno¬ setester weiterverarbeitet. Nach entsprechender Selektion werden auf einem geeigneten Display des Diagnosetesters alle aktiven Fehlercodes, ggf. mit weiteren Erläuterungen, zur An¬ zeige gebracht. Die Liste der aktiven Fehlercodes wird hier¬ bei gemäß der Erfindung um diejenigen Fehlercodes ergänzt, deren Statusabfrage ergeben hat, dass sie von den Eigendiag¬ noseroutinen 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 po¬ tentielle Fehlerkandidaten darstellen. Selektion und Anzeige der Fehlercodes können von dem Diagnoseprogramm in einem Ver¬ arbeitungsschritt zusammengefasst sein, was in Figur 3 symbo¬ lisch mit dem Programmschritt 320 dargestellt ist. Anhand der angezeigten Fehlerliste entscheidet der Kraftfahrzeugmechani¬ ker, ob er eine Reparatur durchführen will oder nicht. Das Ergebnis dieser Entscheidung kann in der Menüführung des Di¬ agnosetesters mit einem Entscheidungsschritt 330 abgefragt werden. In einer alternativen Ausführungsform kann jedoch auf diesen Entscheidungsschritt in der Menüführung des Diagnose¬ testers verzichtet werden. In jedem Fall muss jedoch nach ei¬ ner durchgeführten Reparatur 340 ein identifizierter Fehler¬ code in dem jeweiligen Fehlerspeicher des betreffenden Steu¬ ergeräts gelöscht werden. Bei bisher bekannten Diagnosetes¬ tern war es zu jeder Zeit und ohne weitere Überprüfung mög¬ lich, sämtliche Fehlercodes, die sich in Fehlerspeichern von Steuergeräten im Kraftfahrzeug befanden, zu löschen. Die Er¬ findung besteht nun darin, dass nach einem Löschen eines Feh¬ lercodes 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 Ei¬ gendiagnoseroutinen 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 Diagno¬ setester weder aktive Fehlercodes noch Fehlercodes mit dem Status „nicht getestet" angezeigt werden. Mit dieser Pro¬ grammschleife wird sichergestellt, dass die erfolgten Repara¬ turmaß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 Kraftfahrzeugmechani¬ ker 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 Figur 4 dargestellt. Auch hier werden mit einem Diagnosetester nach dessen Anschluss an die Diagnoseschnittstelle des Kraftfahrzeugs die Eigendiagnose¬ routinen der im Kraftfahrzeug befindlichen Steuergeräte ge¬ startet oder es werden zumindest die in den Fehlerspeichern der Steuergeräte abgelegten Fehlercodes ausgelesen. Zusätz¬ lich zu den verifizierten und aktiven Fehlercodes werden die Statusinformationen zu den Fehlercodes ausgelesen und weiter¬ verarbeitet. 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 Figur 3. Auch bei dem Ausführungsbeispiel der Figur 4 kann die Entscheidung des Kraftfahrzeugmechanikers, ob er ei¬ ne 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 ent¬ sprechend dem Ablaufplan nach Figur 4 nach jedem durchgeführ¬ ten Reparaturschritt eine Einzelfehlerüberprüfung 450 star¬ ten. Eine Einzelfehlerüberprüfung kann insbesondere dann sinnvoll sein, wenn der Diagnosetester vier verschiedene Feh¬ lercodes anzeigt. Der Kraftfahrzeugmechaniker kann dann zu¬ nä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 ausge¬ wählten Fehlercode eine Reparaturverifikation durchgeführt wird. Die Reparaturverifikation erfolgt durch Starten der Ei¬ gendiagnoseroutine des betreffenden Steuergeräts und durch eine Statusüberprüfung des aktuell reparierten Fehlercodes. Kann die Eigendiagnoseroutine des Steuergeräts den beanstan¬ deten 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 Reparatur¬ liste 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 Figur 4 mit dem Programmschritt 460 verdeutlicht.

Alternativ zur Einzelfehlerlöschung kann der Kraftfahrzeugme¬ chaniker natürlich auch zunächst alle angezeigten Reparaturen durchführen und dann mit dem Diagnosetester eine Reparaturve¬ rifikation für alle vormals beanstandeten Fehlercodes durch¬ führen lassen. Dies würde dem AblaufSchema der Figur 3 ent¬ sprechen. Die Wahl, welches Vorgehen der Kraftfahrzeugmecha¬ niker wählt ist diesem selbst überlassen. Mit dem erfindungs¬ gemäßen Diagnosetester können beide AblaufSchemata zur Repa¬ raturverifikation durchgeführt werden.

Die Figuren 5 und 6 veranschaulichen, wie die verbesserte Re¬ paraturverifikation mit dem Diagnosetester umgesetzt werden kann. Dargestellt sind typische Screenshots von dem Anzeige¬ display des Diagnosetesters. Neben Informationen zu dem un¬ tersuchten Fahrzeug 8 zum angezeigten Dateninhalt 9 stehen dem Diagnosemechaniker auf der Benutzeroberfläche des Diagno¬ setesters in Form von sog. Buttons 10 Bedienelemente zur Ver¬ fü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 Diagnosetes¬ ter in den Steuergeräten des Kraftfahrzeugs zusätzlich zu den aktivierten Fehlercodes aufgefunden werden konnten. Im darge¬ stellten 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 Diagnose¬ testers 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 Figur 5 als aktuell bezeichnet sind, zur Anzeige ge- bracht, sondern es werden auch diejenigen Fehlercodes zur An¬ zeige gebracht, die den Status „nicht getestet" haben. Im Ausführungsbeispiel der Figur 5 ist dies der Fehlercode 1003. Der Screenshot nach Figur 5 soll exemplarisch die Anzeige veranschaulichen, die nach Anschluss des Diagnosetesters an die Diagnoseschnittstelle und nach erfolgter Datenübertragung sowie nach erfolgter Datenselektierung dem Kraftfahrzeugme¬ chaniker 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 be¬ sonderem Interesse sind z. B. die zu dem jeweiligen Fehlerco¬ de zugehörigen Reparaturanleitungen, die in der Regel eben¬ falls in dem Diagnoseprogramm des Diagnosetesters integriert und abgelegt sind. Mit Hilfe von Bedien-Buttons 10, z.B. F3 kann der Kraftfahrzeugmechaniker die vorbeschriebenen Einzel- fehlerü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 Repara¬ turverifikation wird mit dem Screenshot nach Figur 6 darge¬ stellt. In dem exemplarisch gewählten Ausführungsbeispiel nach Figur 5 wurden alle Reparaturen zu den Fehlercodes 1000, 1001, 1002, 1003 durchgeführt. Die dann gestartete Reparatur¬ verifikation hat jedoch ergeben, dass für zwei der vier Feh¬ lercodes 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 Be¬ fund 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äßi¬ gerweise 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üfVor¬ aussetzungen auch Angaben darüber enthalten, welche PrüfVor¬ aussetzungen nicht erfüllt waren. In dem dargestellten Aus¬ führungsbeispiel könnte z. B. die notwendige Mindestdrehzahl des Bordnetzgenerators nicht erreicht worden sein, damit die nicht getesteten Stromsensoren Fehlercode 1000, 1001 über¬ haupt getestet werden können. Der Kraftfahrzeugmechaniker er¬ hält dann einen Hinweis, dass er die Motordrehzahl des Kraft¬ fahrzeugmotors für eine erfolgreiche Überprüfung mindestens auf z. B. 2000 Umdrehungen pro Minute steigern muss.

Eine Reparaturverifikation ist erst erfolgreich abgeschlos¬ sen, wenn der Diagnosetester keine Fehlercodes mehr zur An¬ zeige bringt.