[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2006024424A1 - Verbesserte reparaturverifikation für elektronische fahrzeugsysteme - Google Patents

Verbesserte reparaturverifikation für elektronische fahrzeugsysteme Download PDF

Info

Publication number
WO2006024424A1
WO2006024424A1 PCT/EP2005/009077 EP2005009077W WO2006024424A1 WO 2006024424 A1 WO2006024424 A1 WO 2006024424A1 EP 2005009077 W EP2005009077 W EP 2005009077W WO 2006024424 A1 WO2006024424 A1 WO 2006024424A1
Authority
WO
WIPO (PCT)
Prior art keywords
diagnostic
error codes
error
memory
primary
Prior art date
Application number
PCT/EP2005/009077
Other languages
English (en)
French (fr)
Inventor
Bernhard Fink
Peter Irkes
Markus Scholz
Klaus Weiss
Original Assignee
Daimlerchrysler Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Daimlerchrysler Ag filed Critical Daimlerchrysler Ag
Priority to JP2007528728A priority Critical patent/JP4742102B2/ja
Priority to EP05777338A priority patent/EP1784628A1/de
Priority to US11/792,002 priority patent/US8090495B2/en
Publication of WO2006024424A1 publication Critical patent/WO2006024424A1/de

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/005—Testing of electric installations on transport means
    • G01R31/006—Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks
    • G01R31/007—Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks using microprocessors or computers
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers

Definitions

  • the invention relates to a diagnostic system and a Diagnose ⁇ tester for the verification of motor vehicle control units, with which not only, as hitherto common, finding Feh ⁇ learning is possible, but can also be checked with the whether a repair was successful.
  • the diagnostic tester also introduces a method for improved repair verification. Diagnostic system and diagnostic tester correspond in particular to the legal requirements for diagnostic systems in the USA.
  • Diagnostic systems and diagnostic testers for motor vehicle control devices are nowadays predominantly computer-based in motor vehicle workshops.
  • the leading company in the introduction of computer-based diagnostic testers in 1994 was BMW with the BMW-DIS diagnostic system, which set the standard for today's diagnostic systems and diagnostic testers in motor vehicle workshops.
  • This system is described, for example, in the textbook on vocational training by Rauner / Schreier / Spöttel: "The future of computer-aided vehicle diagnosis", published by Bertelsmann Verlag in Bielefeld, 2002, ISBN 3-7639-3022- 1.
  • the following diagnostic testers have repeatedly on For example, a German patent application by the company Bosch, DE 199 21 845 A1, which is mentioned here by way of example because it uses these Basic structure particularly succinct and briefly summarized.
  • a diagnosis test device for motor vehicles wherein programmable control devices with self-diagnosis means are provided which programmatically control and monitor the engine control and other systems of the motor vehicle, generate error codes and store them, and which are stored via a diagnostic / diagnostic vehicle.
  • Test plug can be connected to an external diagnostic tester.
  • the invention also starts from such a basic structure for a diagnostic tester.
  • the interface or the diagnostic connector for connecting an external diagnostic tester with the motor vehicle-side control devices has been in the past and is still the subject of modernization efforts. In the US in particular, these attempts at standardization, with which the access and thus the diagnostic capability of the vehicle-mounted control devices are made possible and regulated, are still accompanied by legislative measures.
  • One standard that has emerged is the so-called Keyword Protocol 2000.
  • the standardization bases for this Keyword Protocol 2000 can be found in the international standard ISO 14 230-3, as far as the application layer is concerned, and in ISO 14 230-2 , which concerns the so-called Data Link Layer.
  • a supplementary standard to which the Keyword Protocol 2000 is based and which has become part of the aforementioned standards is the Service Vehicle Standard SAE J1979.
  • SAE J1979 Service Vehicle Standard
  • Known diagnostic systems and diagnostic testers are limited to reading out existing error codes from the control units in the motor vehicle with a diagnostic program. work and interpret and bring the result of this interpretation on a screen of the diagnostic tester for display ge. In the motor vehicle workshop then a motor vehicle mechanic works off the displayed list of deficiencies, where he can retrieve further information with the help of the diagnostic tester to the individually listed defects. Of particular interest to him are further technical basics, such as technical drawings and, of course, the repair instructions with which he can remedy the error found.
  • the solution succeeds mainly with a computer-based diagnostic tester that can exchange information with the help of a diagnostic program via a diagnostic interface and data lines with the control units installed in the motor vehicle.
  • the motor vehicle-side control devices have program routines for the self-diagnosis of the control devices and are able to store identified errors in the form of error codes in reserved memory areas.
  • the diagnostic program implemented in the diagnostic tester reads the error codes from the reserved memory areas, interprets the error codes and displays them on a display together with the interpretations.
  • a status polling is performed using the diagnostic program implemented in the diagnostic tester. With this status polling, the status information of these error codes is queried and evaluated for all error codes known in the system.
  • the fault codes to be displayed are first of all stored in one or more primary primary fault memories and, before the primary fault memory is cleared, copied into a secondary second fault memory. This allows the use of the total reset of the primary fault memory prescribed in the USA for diagnostic systems, without the diagnosis of relevant information being lost in the second fault memory.
  • the content of the secondary fault memory is the basis for the fault codes to be displayed on the display of the diagnostic tester.
  • the status polling has the main advantage that not only those errors whose fault setting conditions were once positively met in the past were displayed on the diagnostic tester, but also the potentially possible errors are displayed in the form of error codes whose Functions could not be checked because the test requirements were not available.
  • the status polling means that a fault list appears on the display of the diagnostic tester until all identified errors and also all potential errors have been tested in accordance with the test requirements and the test result is not positive Violation of a fault condition has resulted.
  • this means that the repair measure is only completed when the diagnostic tester has undergone at least one time the test prerequisites for the repair work carried out and this pass has shown that now no fault condition exists for the checked measure is present.
  • the deletion of error codes in the secondary second fault memory with the diagnostic tester is dependent on at least one further diagnostic run having been carried out for the fault code to be erased, during which the test requirements for checking the fault.
  • error codes with the status information "not tested” remain in the secondary fault memory until the repair has been tested at least once in accordance with the test prerequisites for the replacement part primary error memories activated error codes are stored in the secondary error memory B error codes with the status information "not tested” are stored.
  • the menu navigation or the screen display of the diagnostic tester, as described here, draws the workshop mechanic's attention to untested possibilities of error and helps him to remember to regularly check the repair measures carried out at least once.
  • the test prerequisites for each known error code are hereby meaningful. is fully implemented in the diagnostic program of the diagnostic tester, so that the workshop mechanic need not remember the given test conditions for every possible fault in the motor vehicle.
  • the status check is to be initiated by the motor vehicle mechanic by means of the diagnostic tester.
  • a menu item reserved for the status PoIling may be provided in the menu guidance of the diagnostic tester, upon the actuation of which a status check of the error indicated by the diagnostic tester is undertaken.
  • the status checks by the diagnostic tester can be started automatically by, for. B. after connection of the Diagnoseter ⁇ ter to the diagnostic interface of the motor vehicle in Zeit ⁇ regular intervals from the diagnostic tester a status check of the error codes initiated and carried out.
  • the diagnostic tester can run a clock and a status check, z. B. triggers automatically triggered every 10 minutes, be performed.
  • the functions for deleting the error codes in the secondary fault memory are blocked in the diagnostic tester until a status check by another diagnostic routine both the error-free function of the performed repair measure and the correct review of the repair measure based on the prescribed test requirements for each repair were carried out. For this purpose, after a complete repair, a complete reset of the primary fault memory is carried out. Subsequently, a diagnostic run is started in which, in the event of an error, the primary fault storages are again beschrienen. The entries in the secondary fault memory are updated with the result of the diagnostic run.
  • This embodiment has the advantage that the repair is not completed for the motor vehicle mechanic until all faults have been rectified and also properly checked. An arbitrary deletion of once established error codes by deletion errors or complete reset of the primary fault memory can then no longer lead to a seemingly correct service since the diagnostic tester continues to display the fault codes stored in the secondary fault memory.
  • the deletion of the error codes in the secondary error memory within the control unit is carried out if a status check has been carried out both on the error-free function of the repair measure carried out and on the correct checking of the repair measure on the basis of the test requirements prescribed for the respective error codes , For this purpose, after a repair has been carried out, a complete reset of the primary fault memory is carried out. Subsequently, when error codes are ready for testing, the status of the corresponding error codes in the secondary error memory is updated.
  • This embodiment has the advantage that for the motor vehicle mechanic, the repair is only completed when all errors have been eliminated and also properly checked. An arbitrary deletion of once detected error codes by deleting commands or complete reset of the primary fault memory, then can no longer lead to a seemingly proper service, since with the diagnostic tester continue in the secondary fault Memory stored error codes are displayed and the monitoring of the logic is completely in the control unit.
  • FIG. 1 shows a schematic representation of a Diagnosete ⁇ ters, as it is connected to the control units in a Kraft ⁇ vehicle
  • Fig. 4 shows the memory allocation of primary and secondary
  • FIG. 5 is a schematic representation for the comparison of primary and secondary fault memory after a repair and after repair verification with the diagnostic tester
  • FIG. 6 shows a flowchart for an improved repair verification with the aid of a diagnostic tester
  • FIG. 8 shows a graphical user interface, as it is displayed by the diagnostics tester to the motor vehicle mechanic
  • FIG. 9 shows the graphical user interface of the diagnoseter according to FIG. 5 as it appears to the motor vehicle mechanic after the repairs but the repairs themselves were not properly checked.
  • Figure 1 a situation is shown schematically, as it is known today in motor vehicle workshops.
  • a computer-assisted diagnostic tester 1 is connected via a standardized diagnostic interface 2 to the communication network 3 for the control units 4 in the motor vehicle.
  • Known diagnostic testers are z.
  • the control units 4 installed in the motor vehicle are in communication with each other, for example via a data bus.
  • a common data bus in motor vehicles here is the so-called CAN bus (for Control Area Network).
  • CAN bus for Control Area Network
  • the standard for the keyword protocol 2000 comprises two different application possibilities. On the one hand, the standard stipulates that the communication between the diagnostic tester and control units via a gateway S 1 z. B. the motor vehicle CAN bus to the Di ⁇ agnosesammlungstelle 2 binds, takes place or, as usual, the fault memory of the control units via the so-called. K and L lines and the standardized Diagnose ⁇ interface 2 directly into the Diagnostic tester can be read and stored.
  • FIG. 1 shows the more modern form of access via a CAN bus and thus via a gateway.
  • a gateway For the invention of concern only that there is at least one way to be able to read the fault memory of the control units with a Diagnose ⁇ tester.
  • the invention therefore covers all addressing possibilities between the diagnostic tester and the fault memory of the control units.
  • the keyword log 2000 used is merely a preferred option, with the aid of which the data contents of the error memory from the control units can be transferred very easily into the diagnostic tester.
  • the schematic representation in FIG. 2 briefly discusses the keyword protocol 2000. Complete and more detailed information is found in the already mentioned ISO standard 14 230-3. With the keyword protocol 2000, a data format and a minimum amount of codified control commands, which a control device in the motor vehicle must at least be able to work if it is to correspond to the keyword protocol 2000, have been specified specifically for the purposes of motor vehicle diagnosis.
  • the data format used by the keyword protocol is based on the ISO standard 14 230-2, the so-called. Data Link Layer to Keyword Protocol 2000.
  • the structure of such a data format includes up to four different Hea ⁇ der Bytes, the information on the data format FMT, details of Ziel ⁇ address TGT 7 information on the SRC sender address and details of the length of the header bytes contains the following data bytes.
  • the header block is always followed by a hexadecimal-modified control command, which is designated as the service identification SID.
  • the control commands specified in the keyword protocol 2000 can in this case be further subdivided and shaped in a manufacturer-specific manner. In this case, the user data block 7 would contain additional hexadecimal-modified control commands.
  • the data format according to the keyword protocol 2000 is always concluded with a byte that contains a check sum CS over all data of the respective message format.
  • the message format just described is used in its basic structure both for requests to the control units and for the answers of the control units. Of particular interest to the invention are the so-called $ 18 requests with the associated $ 58 response, which every keyword protocol must be able to include and process a 2000-capable system.
  • the codification of the requests and the response takes place here only via the hexadecimal coding 18 or 58 for determining the service identification and thus defines the payload data to be transmitted, which must at least be contained in the response.
  • the dollar sign is used here only in this patent application to emphasize that the numerical code 18 or 58 is a codified control command corresponding to the Key ⁇ word protocol 2000. If an ECU in a motor vehicle receives a $ 18 request from a diagnostic tester, it always responds with a $ 58 response. The payload of the answer is always contained in the data block 7 of the reply message.
  • the keyword protocol 2000 hereby defines not only the control commands, but also specifies them the data contents, which must contain a standardized answer to a standardized request. So z.
  • the respective status of this error code in the data block for each error code DTC1, DTC2-DTCn known in the control unit is also transmitted to an $ 18 request.
  • the status of the error code indicates whether the self-diagnosis routine of the control unit has tested the error code or not. In the simplest case, the status may consist of a single bit, with z.
  • the bit value "0" stands for a proper checking of the functions associated with the error code according to the test conditions, while the bit value "1" stands for an untested error code or for a test run of the corresponding functions in which the test requirements did not exist ,
  • any other coding can be selected, which is able to distinguish whether or not the status of an error code has been tested in accordance with the test prerequisites for the functions underlying the error code.
  • the $ 58 response thus contains in the data block 7 a table with all the error codes known in the control unit with the additional information.
  • the Keyword Protocol 2000 is in the context of the invention as a particularly widespread tete variant to see.
  • the invention itself is not limited to the keyword protocol 2000, but can be carried out with any type and form of data transmission in which, in addition to activated error codes, their status information can also be read out and selected.
  • a legal regulation is particularly relevant in this context, which states that repair and diagnosis of a motor vehicle do not allow the individual fault clearing of the fault codes determined during the diagnosis.
  • the prohibition of single error deletion applies especially to exhaust-related error codes.
  • it is only permitted here to completely delete all the fault memory of a control unit.
  • Such a general delete command is provided by the keyword protocol 2000 with the hexadecimal coded $ 14FF00 request and the diagnostic service name: "Clear Diagnostic Information.”
  • the disadvantage of this delete command is that when it is actuated, all diagnosis-relevant and thus also repair-relevant information is lost.
  • the main idea of the invention is the storage of all diagnostic information relevant for a repair verification of the motor vehicle in a second fault memory B and the separate handling of this fault memory B. Diagnostic-relevant information here are all activated and tested fault codes.
  • the diagrammatic representation of FIG. 3 illustrates in graphical form the introduction of a second fault memory B. The introduction of this secondary fault memory B makes it possible to carry out a total reset of all diagnosis-relevant information on the original primary fault memory A, without interrupting the operation Loss of the diagnostic information necessary for the repair verification.
  • the diagnostic information necessary for the repair verification is in fact buffered in the error memory B. On the second Feh ⁇ ler appointments B no total reset may be applied.
  • the motor vehicle mechanic deletes the diagnostic information in the primary fault memory A with a total reset.
  • the triggering of this deletion command is taken as a trigger signal in order to store the active fault codes from the primary fault memories in the secondary fault memory.
  • this total reset clears the error codes and status information about the error codes in all of the ECU's primary fault memories. Unaffected by this total reset remains the secondary fault memory B. This situation is illustrated by the graphical representation of FIG. In the second error memory B are still filed all previously criticized Diagnoseinf ⁇ rmationen.
  • the update of the secondary fault memory B must now be carried out in accordance with the repair progress and according to a repair verification.
  • This updating step is to be clarified with the graphic representation of FIG. 5.
  • the motor vehicle mechanic will carry out a test run with the repaired vehicle.
  • the self-diagnostic routines of the control units in the motor vehicle are activated and deliver diagnostic information regarding activated or inactive error codes as well as diagnostic information regarding the status of all known error codes as to whether the relevant error code has been tested or not.
  • This diagnosis information is written by the control units back into the primary error memory A.
  • Error codes which have been actively tested for the first time after repair can optionally be new be adopted in the secondary fault memory A.
  • the illustrated embodiment of Figure 5 that would be the DTC3 error code that has been tested positive and is now active.
  • the entirety of the contents of the primaryierepei ⁇ chern A and the secondary error memory B contains so after partial repair and after the test run the Melselsituation after partial repair and test run. If the error list of the active error codes from the primary error memory A and the list of original test codes not yet tested in the secondary error memory B are displayed to the motor vehicle mechanic with the diagnosis tester on the display, the motor vehicle mechanic has information which Repairs were successful and which are still to be done.
  • FIG. 6 shows by way of example a program schedule with which the secondary fault memory B can be compared with the primary fault memory A.
  • the flowchart consists mainly of the procedural steps 610 which are necessary in order to delete tested error codes from the secondary fault memory.
  • the secondary fault memory B is updated by clearing in error memory B all those error codes which have "tested" the status after the test run and after a polling status in the primary fault memory A.
  • a program flowchart for improved repair verification can thus be set up and implemented as a diagnosis program in a diagnostic tester.
  • FIG. 7 such a program subscription plan is shown graphically by way of example.
  • the erase command 730 is taken as a trigger signal in order to process at least the active error codes from the primary error memories and the secondary error memory. This corresponds to the method step in FIG. 7 with the reference numeral 731. After the copying process, the primary error memories are cleared 732 by means of a total reset First, all diagnostic information is lost in the primary fault memory A. For repair checking, a test run takes place in a further method step with the reference numeral 740. In this test run, which is usually a kind of test drive with the motor vehicle, the self-diagnosis routines of the control devices in the motor vehicle are activated.
  • the activated error codes from the self-diagnosis routines are again read into the primary error memory A; likewise, the status information for all known error codes can be determined by the self-diagnosis routines. Likewise, after successful test run, activated error codes and status information can again be read from the primary fault memories and determined.
  • the updating of the secondary fault memory B then takes place in a further method step 750, as has already been described in connection with the comparison of the two fault memories A and B in connection with FIG. 6.
  • the updated content of fault memory B together with the current active Ich ⁇ that have ge in the primary fault memories of the control units ge ⁇ possibly new stored on the diagnostic tester the motor vehicle mechanic brought to the display.
  • the repair is successfully completed if error codes B are not present either in the error memory B or in the primary error memories, which becomes obvious to the motor vehicle mechanic that no defect list is displayed on the display of the diagnostic tester. If there are entries in the error memory B, the corresponding deficiencies are displayed on the diagnostic tester.
  • This decision-making process is shown in the program flowchart of FIG. 7 with the reference numeral 760.
  • a derar tige decision by a yes / no query whether in the secondary error memory B or the primary error memory
  • a Fever lerkodes are stored or not.
  • the repair process starts from New.
  • the replacement of the repair process is expediently implemented with a program loop.
  • a possible touchdown point of the program loop here is the method step with the reference numeral 720 according to FIG. 7.
  • Other touchdown points can also be the method step with the reference numeral 711.
  • a method step with the reference numeral 770 can be dispensed with.
  • Figures 8 and 9 illustrate how the improved repair verification can be implemented with the diagnostic tester. Shown are typical screenshots of the display display of the diagnostic tester.
  • the motor vehicle mechanic has access to control elements on the user interface of the diagnostic tester in the form of so-called buttons, with which he can control and operate the diagnostic tester.
  • the main point of the invention is the display of all active error codes that could be found by the diagnostic tester in the control devices of the motor vehicle. In the example illustrated, these are the error codes 1000, 1001 and 1002.
  • the activated error codes which are designated as "active" in the display of FIG. 8, can be displayed, but also those error codes can be displayed who have the status "not tested".
  • FIG. 8 this is the error code 1003.
  • the screenshot according to FIG. 8 is intended to exemplarily illustrate the display, which according to FIG. Conclusion of the diagnostic tester to the diagnostic interface and after data transfer and after data se- lectation the car mechanic is displayed on the diagnostic tester.
  • menu control z. B. by a pull-down menu, the motor vehicle mechanic to the individual error codes more information with the help of the operating button 10 can retrieve.
  • z. B. by a pull-down menu
  • the motor vehicle mechanic to the individual error codes more information with the help of the operating button 10 can retrieve.
  • the corresponding error code associated fatigue ⁇ lines which are also usually integrated and stored in the diagnostic program of the diagnostic tester.
  • the vehicle mechanic can start a repair verification after complete repair.
  • FIG. 9 A possible result of a repair verification carried out in this way is illustrated by the screenshot according to FIG. 9.
  • all repairs to the error codes 1000, 1001, 1002, 1003 were carried out.
  • the repair verification then started has shown that for two of the four error codes the test requirements were not present in order to test the proper functioning of the respective functions with the aid of the self-diagnosis routines of the relevant control devices.
  • These two error codes have remained in the secondary error memory B. Therefore, this finding is displayed to the motor vehicle mechanic. It is ange ⁇ shows him which previously criticized error code could not be tested after the repair. It is particularly expedient for each error code in the database system of the diagnosis tester that the prescribed test prerequisites are also stored.
  • a special information button 12 is implemented for the retrieval of these test prerequisites, upon actuation of which a selected error code, for example, is generated.
  • a repair verification is successfully completed only when the diagnostic tester no longer displays error codes, i. E. if the primary fault memory A contains no active fault codes and all entries in the secondary fault memory B have been deleted after the test and status Polling have been carried out.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Vehicle Cleaning, Maintenance, Repair, Refitting, And Outriggers (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft einen rechnerbasierten Diagnosetester, der mit Hilfe eines Diagnoseprogramms über eine Diagnoseschnittstelle sowie über Datenleitungen mit den im Kraftfahrzeug verbauten Steuergeräten Informationen austauschen kann. Mit dem Diagnosetester wird ebenfalls ein Verfahren zur verbesserten Reparaturverifikation vorgestellt. 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, ausgelesen und dann 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 zur Reparaturverifikation relevanten Informationen im zweiten Fehlerspeicher verloren gehen.

Description

Verbesserte Reparaturverifikation für elektronische
Fahrzeugsysteme
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. Diagnosesystem und Diagno¬ setester entsprechen insbesondere den gesetzlichen Bestimmun¬ gen für DiagnoseSysteme in den USA.
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. Besonderes Augenmerk liegt hierbei auf dem ge- setzlichen Verbot einer Einzelfehlerlöschung bei abgasrele¬ vanten Steuergeräten in den USA.
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 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 aus¬ tauschen kann. Die kraftfahrzeugseitigen Steuergeräte verfü¬ gen über Programmroutinen zur Eigendiagnose der Steuergeräte und sind in der Lage identifizierte Fehler in Form von Feh¬ lercodes in reservierten Speicherbereichen abzulegen. Das im Diagnosetester implementierte Diagnoseprogramm liest die Feh¬ lercodes aus den reservierten Speicherbereichen aus, inter¬ pretiert die Fehlercodes und bringt sie auf einem Display zu¬ sammen 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 Fehlerco¬ des die Statusinformationen dieser Fehlercodes abgefragt und ausgewertet. Es werden hierbei alle Fehlercodes zur Anzeige gebracht, deren Fehlersetzbedingungen entweder positiv getes¬ tet wurden oder deren PrüfVoraussetzungen nicht vorlagen, um einen Test durchführen zu können. Die zur Anzeige zu bringen¬ den Fehlercodes werden hierbei zunächst in einem oder mehre¬ ren primären ersten Fehlerspeichern gespeichert, und vor dem Löschen der primären Fehlerspeicher in einen sekundären zwei¬ ten 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 re¬ levanten Informationen im zweiten Fehlerspeicher verloren ge¬ hen. Der Inhalt des sekundären Fehlerspeichers ist die Grund¬ lage 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 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 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 diag¬ nostizierte Fehler erst dann von der Anzeige des Diagnosetes¬ ters 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 Di¬ agnosetester unmittelbar nach der Reparatur identifiziert werden. Noch wichtiger ist, dass mit dem vorbeschriebenen Status Polling auch diejenigen potentiellen Fehlermöglichkei¬ ten aufgefunden werden, die nur deshalb für in Ordnung befun¬ den 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 befin¬ den, nur aus dem Grund, weil in dem FehlerSpeicher des zuge¬ hörigen Steuergerätes nach Löschen der primären Fehlerspei¬ cher keine Fehlercodes abgelegt sind. Mit der Erfindung hin¬ gegen verbleiben Fehlercodes mit der Statusinformation „nicht getestet" solange im sekundären Fehlerspeicher bis die Repa¬ ratur mindestens einmal entsprechend der für das Austausch¬ teil geltenden PrüfVoraussetzungen getestet wurde. Die Repa¬ ratur ist erst dann abgeschlossen wenn weder in den primären Fehlerspeichern aktivierte Fehlercodes abgelegt sind noch im sekundären Fehlerspeicher B Fehlercodes mit der Statusinfor¬ mation „nicht getestet" abgelegt sind. Die Menüführung bzw. die Bildschirmanzeige des Diagnosetesters, wie er hier be¬ schrieben 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- voller weise im Diagnoseprogramm des Diagnosetesters imple¬ mentiert, so dass der Werkstattmechaniker sich nicht für je¬ den möglichen Fehler im Kraftfahrzeug die vorgegebenen Prüf¬ voraussetzungen 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 PoIling reservierter Menüpunkt vorgesehen sein, bei dessen Betätigung eine Status¬ überprüfung des vom Diagnosetesters angezeigten Fehlers vor¬ genommen wird. Dies hat den Vorteil, dass der Kraftfahrzeug¬ mechaniker den Diagnosetester reparaturnah einsetzen kann, und immer dann, wenn er glaubt eine Reparaturmaßnahme abge¬ schlossen 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 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, 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 Repara¬ tur ein Komplett Reset der primären FehlerSpeicher durchge¬ fü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üh¬ rungsform hat den Vorteil, dass für den Kraftfahrzeugmechani¬ ker die Reparatur erst dann beendet ist, wenn alle Fehler be¬ seitigt und auch ordnungsgemäß überprüft sind. Ein willkürli¬ ches Löschen einmal festgestellter Fehlercodes durch Löschbe¬ fehle 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 Feh¬ lercodes im sekundären Fehlerspeicher innerhalb des Steuerge¬ rä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üfvor¬ aussetzungen durchgeführt wurden. Hierzu wird nach einer er¬ folgten Reparatur ein Komplett Reset der primären Fehlerspei¬ cher 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 Re¬ paratur 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 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 eine schematische Darstellung des Kopiervorgangs der Fehlercodes aus den primären Fehlerspeichern in den sekundären Fehlerspeicher,
Fig. 4 die Speicherbelegung von primären und sekundärem
Fehlerspeicher nach einem Total-Reset der primären Fehlerspeicher,
Fig. 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,
Fig. 6 ein Ablaufschema für eine verbesserte Reparaturve¬ rifikation mit Hilfe eines Diagnosetesters,
Fig. 7 ein weiteres mögliches AblaufSchema für eine ver¬ besserte Reparaturverifikation mit Hilfe eines Di¬ agnosetesters,
Fig. 8 eine graphische Benutzeroberfläche, wie sie vom Di¬ agnosetester dem Kraftfahrzeugmechaniker zur Anzei¬ ge gebracht wird,
Fig. 9 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 S1 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 verschiedene Hea¬ der Bytes, die Angaben zum Datenformat FMT, Angaben zur Ziel¬ adresse TGT7 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 hexadezimalkodifizier¬ ter Steuerbefehl, der als Service Identification SID bezeich¬ net wird. Die im Keyword-Protokoll 2000 spezifizierten Steu¬ erbefehle können hierbei herstellerspezifisch weiter unter¬ teilt und ausgeformt sein. In diesem Fall würde der Nutzda¬ tenblock 7 weitere hexadezimalkodifizierte Steuerbefehle ent¬ halten. Das Datenformat entsprechend des Keyword-Protokolls 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 Information. Es ist also mit einem $18-Request entweder durch Setzen entsprechender Para¬ meter beim Request selbst oder durch nachträgliche Selektie¬ rung des Datenblocks der zugehörigen $58-Antwort möglich, ge¬ zielt all diejenigen Fehlercodes zu identifizieren und auszu¬ lesen, deren Status anzeigt, dass die zugehörigen Funktionen nicht ordnungsgemäß entsprechend der PrüfvorausSetzungen für diese Funktionen getestet wurden. Diese Information kann ge¬ wonnen werden völlig unabhängig davon, ob eine Fehlfunktion vorlag bzw. ob ein Fehlercode verifiziert wurde und im ent¬ sprechenden Fehlerspeicher abgelegt war oder nicht. Mit ande¬ ren 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 durch¬ führen, bei der neben aktivierten Fehlercodes auch deren Sta¬ tusinformationen ausgelesen und selektiert werden können.
Nach den vorbeschriebenen Grundlagen zum Verständnis der Er¬ findung wird nun im Folgenden auf den Kern der Erfindung ein¬ gegangen. An und für sich könnte man die mit der $58-Response erhaltenen Fehlercodes inklusive deren Status in einem Feh¬ lerspeicher abspeichern und den Inhalt dieses Fehlerspeichers auf der Anzeige des Diagnosetesters zur Anzeige bringen. Der Kraftfahrzeugmechaniker erhielte dann eine Liste aller iden¬ tifizierten Fehlfunktionen und könnte die Liste in einem Re- paraturprozess Punkt für Punkt abarbeiten. Um den Überblick nicht zu verlieren, würde er sicher alle bearbeiteten Fehler¬ code nach abgeschlossener Reparatur gerne per Einzelfehlerlö¬ schung aus dem Fehlerspeicher löschen, um danach angezeigt zu bekommen ob die bearbeiteten Fehlercodes bereits vom Steuer¬ gerät wieder überprüft wurden. In den USA gibt es nun die Be¬ sonderheit, dass die Diagnose von Kraftfahrzeugen strengen gesetzlichen Regelungen unterliegt. Im Zusammenhang mit der Erfindung ist hierbei besonders eine gesetzliche Regelung re¬ levant, 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 Feh¬ lercodes. In den U.S.A. ist hier nur erlaubt, alle den Feh¬ lerspeicher eines Steuergerätes komplett zu löschen. Ein der¬ artiger allgemeiner Löschbefehl wird vom Keyword-Protokoll 2000 mit dem hexadezimalcodierten $14FF00-Request und dem Di¬ agnostic 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 ei¬ nem Diagnosetester durchführen zu können, sind deshalb zu¬ sätzliche Maßnahmen notwendig, die den Kern dieser Erfindung ausmachen. Haupterfindungsgedanke ist hierbei das Abspeichern aller für eine Reparaturverifikation des Kraftfahrzeugs rele¬ vanten Diagnoseinformationen in einem zweiten Fehlerspeicher B und die gesonderte Behandlung dieses Fehlerspeichers B. Di¬ agnoserelevante Informationen sind hierbei alle aktivierten und getesteten Fehlercodes. Die schematische Darstellung der Figur 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 diagno¬ serelevanten Informationen durchgeführt werden kann, ohne den Verlust der für die Reparaturverifikation notwendigen Diagno¬ seinformationen befürchten zu müssen. Die für die Reparatur¬ verifikation notwendigen Diagnoseinformationen sind nämlich im Fehlerspeicher B zwischengespeichert. Auf dem zweiten Feh¬ lerspeicher B darf kein Total-Reset angewandt werden.
Nach einer durchgeführten Reparatur löscht der Kraftfahrzeug¬ mechaniker mit einem Total-Reset die Diagnoseinformationen in den primären Fehlerspeichern A. Die Auslösung dieses Löschbe¬ fehls wird als Triggersignal genommen, um die aktiven Fehler¬ codes aus den primären Fehlerspeichern im sekundären Fehler¬ speicher 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 Figur 4 verdeutlicht. In dem zweiten Fehlerspeicher B sind nach wie vor alle vormals bemängelten Diagnoseinfαrmationen abgelegt.
Ausgehend von diesem Diagnosezustand muss es nun noch ent¬ sprechend dem Reparaturfortschritt und entsprechend einer Re¬ paraturverifikation zu einer Aktualisierung des sekundären Fehlerspeichers B kommen. Dieser Aktualisierungsschritt soll mit der graphischen Darstellung von Figur 5 verdeutlicht wer¬ den. Nach durchgeführter Reparatur und nach erfolgtem Total- Reset der primären Fehlerspeicher wird der Kraftfahrzeugme¬ chaniker mit dem reparierten Fahrzeug einen Testlauf durch¬ führen. Bei diesem Testlauf werden die Eigendiagnoseroutinen der Steuergeräte im Kraftfahrzeug aktiviert und liefern wie¬ der Diagnoseinformationen hinsichtlich aktivierter oder inak¬ tiver Fehlercodes sowie Diagnoseinformationen hinsichtlich des Status aller bekannten Fehlercodes, ob der betreffende Fehlercode getestet wurde oder nicht. Diese Diagnoseinforma¬ tion wird von den Steuergeräten wieder in die primären Feh¬ lerspeicher A geschrieben. Mit einem weiteren Auslesen der Diagnoseinformationen aus den primären Fehlerspeichern A kann nun mit dem Diagnosetester und mit dessen implementierten Di¬ agnoseprogramm ein Abgleich mit dem Fehlerspeicher B erfol¬ gen. 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 Fehler¬ codes, die durch die Eigendiagnoseroutinen der Steuergeräte getestet wurden. Nicht gelöscht werden, dürfen all diejenigen Fehlercodes, die beim Testlauf nicht von den Eigendiagnose¬ routinen getestet wurden. Im Ausführungsbeispiel der Figur 5 wäre das der Fehlercode DTC2, der nicht getestet wurde und deshalb im Fehlerspeicher B verbleiben muss. Gelöscht werden konnte der Fehlercode DTCl, da er von den Eigendiagnoserouti¬ nen getestet wurden. Fehlercodes, die nach erfolgter Repara¬ tur erstmals aktiv getestet wurden, können gegebenenfalls neu in den sekundären Fehlerspeicher A übernommen werden. Im dargestellten Ausführungsbeispiel der Figur 5 wäre das der Fehlercode DTC3, der positiv getestet wurde und nun aktiv ist. Die Gesamtheit der Inhalte von den primären Fehlerspei¬ chern 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 Fehler¬ speichern A und die Liste der noch nicht getesteten ursprüng¬ lichen Fehlercodes im sekundären Fehlerspeicher B mit dem Di¬ agnosetester 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 Figuren 4 und 5 be¬ schriebene Abgleich von primären Fehlerspeichern A mit dem sekundären Fehlerspeicher B lässt sich in einen Diagnosetes¬ ter programmtechnisch relativ einfach implementieren. Figur 6 zeigt hierbei exemplarisch einen Programmabiaufplan, mit dem der sekundäre Fehlerspeicher B mit den primären Fehlerspei¬ chern A abgeglichen werden kann. Der Ablaufplan besteht hauptsächlich neben Beginn und Ende aus den Verfahrensschrit¬ ten 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 Feh¬ lercodes gelöscht werden, die nach dem Testlauf und nach ei¬ nem Status Polling in den primären Fehlerspeicher A den Sta¬ tus „getestet" haben. Nach diesem Abgleich wird die in Feh¬ lerspeicher B abgelegte Fehlerliste dem Kraftfahrzeugmechani¬ ker auf dem Diagnosetester gegebenenfalls zusammen mit der Liste der aktiven Fehlercodes aus den primären Fehlerspei¬ chern zur Anzeige gebracht. Zusammenfassend lässt sich damit ein Programmablaufplan für eine verbesserte Reparaturverifikation aufstellen und als Di¬ agnoseprogramm in einem Diagnosetester implementieren. In Fi¬ gur 7 ist exemplarisch ein solcher Programmabiaufplan gra¬ phisch dargestellt. Nachdem das Kraftfahrzeug in die Werk¬ statt 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 Verfahrens¬ schritt 710 werden sämtliche Fehlercodes aus den primären Fehlerspeichern A und alle Statusinformationen zu allen be¬ kannten Fehlercodes ausgelesen. Die Statusinformationen wer¬ den ausgewertet und selektiert. Von Interesse sind alle akti¬ ven Fehlercodes und all diejenigen Fehlercodes, die von den Eigendiagnoseroutinen der Steuergeräte nicht überprüft wur¬ den. 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 Ent- scheidungsprozess wird auch mit dem Diagnosetester nachvoll¬ zogen und ist in Figur 7 symbolisch mit der Bezugsziffer 720 dargestellt. Erfolgt eine Reparatur, dargestellt mit der Be¬ zugsziffer 721, so wird nach Abschluss der Reparatur oder zu¬ mindest nach Abschluss einer Teilreparatur mit einem Befehl zum Total-Reset der Inhalt der primären Fehlerspeicher A ge¬ lö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 ko¬ pieren. Dies entspricht in Figur 7 dem Verfahrensschritt mit dem Bezugszeichen 731. Nach dem Kopiervorgang werden die pri¬ mären Fehlerspeicher per Total-Reset gelöscht 732. Dadurch gehen zunächst in den primären Fehlerspeichern A alle Diagno¬ seinformationen 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 Eigendiagno¬ seroutinen der Steuergeräte im Kraftfahrzeug aktiviert. Tre¬ ten weiterhin Fehler auf, so werden die aktivierten Fehlerco¬ des von den Eigendiagnoseroutinen wieder in die primären Feh¬ lerspeicher A eingelesen, ebenso können die Statusinformatio¬ nen zu sämtlichen bekannten Fehlercodes von den Eigendiagno¬ seroutinen ermittelt werden. Ebenso können damit nach erfolg¬ tem Testlauf wiederum aktivierte Fehlercodes und Statusinfor¬ mationen aus den primären Fehlerspeichern ausgelesen und er¬ mittelt werden.
Die Aktualisierung des sekundären Fehlerspeichers B erfolgt dann in einem weiteren Verfahrensschritt 750, wie er im Zu¬ sammenhang mit dem Abgleich der beiden Fehlerspeicher A und B schon im Zusammenhang mit Figur 6 beschrieben wurde. Nach Ab¬ gleich der primären FehlerSpeicher A mit den Inhalten des zweiten Fehlerspeichers B wird der aktualisierte Inhalt von Fehlerspeicher B zusammen mit dem aktuellen aktiven Fehlerco¬ des, die in den primären Fehlerspeichern der Steuergeräte ge¬ gebenenfalls 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ängel- liste mehr angezeigt wird. Sind im Fehlerspeicher B Einträge vorhanden, so werden die entsprechenden Mängel auf dem Diag¬ nosetester zur Anzeige gebracht. Dieser Entscheidungsprozess ist im Programmablaufplan der Figur 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 Feh¬ lercodes abgelegt sind oder nicht. Erfolgt eine Anzeige auf dem Display des Diagnosetesters, symbolisch dargestellt durch den Verfahrensschritt der Bezugsziffer 770, so setzt der Re- paraturprozess von Neu ein. Das Neueinsetzen des Reparatur¬ prozesses wird zweckmäßigerweise mit einer Programmschleife realisiert. Ein möglicher Aufsetzpunkt der Programmschleife ist hierbei der Verfahrensschritt mit dem Bezugszeichen 720 gemäß Figur 7. Andere Aufsetzpunkte können auch der Verfah¬ rensschritt mit dem Bezugszeichen 711 sein. Bei einem Auf¬ setzpunkt laut Verfahrensschritt 711 kann ein Verfahrens¬ schritt mit dem Bezugszeichen 770 entfallen.
Die Figuren 8 und 9 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 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 Steu¬ ergerä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 Fehler¬ codes, die in der Anzeige nach Figur 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 Figur 8 ist dies der Fehlercode 1003. Der Screenshot nach Figur 8 soll exemplarisch die Anzeige veranschaulichen, die nach An- Schluss des Diagnosetesters an die Diagnoseschnittstelle und nach erfolgter Datenübertragung sowie nach erfolgter Datense- lektierung dem Kraftfahrzeugmechaniker auf dem Diagnosetester zur Anzeige gebracht wird. Per Menüsteuerung, z. B. durch ein Pull-down-Menü, kann der Kraftfahrzeugmechaniker zu den ein¬ zelnen Fehlercodes weitere Informationen mit Hilfe der Be- dien-Button 10 abrufen. Von besonderem Interesse sind z. B. die zu dem jeweiligen Fehlercode zugehörigen Reparaturanlei¬ tungen, 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 Repara¬ turverifikation wird mit dem Screenshot nach Figur 9 darge¬ stellt. In dem exemplarisch gewählten Ausführungsbeispiel nach Figur 8 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. Diese beiden Fehlercodes sind im sekundären Fehler¬ speicher B verblieben. Deshalb wird dem Kraftfahrzeugmechani¬ ker dieser Befund zur Anzeige gebracht. Es wird ihm ange¬ zeigt, welcher vorher bemängelte Fehlercode nach erfolgter Reparatur nicht getestet werden konnte. Besonders zweckmäßig sind zu jedem Fehlercode in dem Datenbanksystem des Diagnose¬ testers auch die vorgeschriebenen PrüfvorausSetzungen abge¬ legt. Zweckmäßigerweise ist für die Abrufung dieser Prüfvor¬ aussetzungen ein spezieller Informations-Button 12 implemen¬ tiert, bei dessen Betätigung zu einem ausgewählten Fehlerco¬ de, z. B. Fehlercode 1000, per Menüauswahl Zusatzinformatio¬ nen 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 darge¬ stellten Ausführungsbeispiel könnte z. B. die notwendige Min¬ destdrehzahl des Bordnetzgenerators nicht erreicht worden sein, damit die nicht getesteten Stromsensoren Fehlercode 1000, 1001 überhaupt getestet werden können. Der Kraftfahr¬ zeugmechaniker erhält dann einen Hinweis, dass er die Motor¬ drehzahl des Kraftfahrzeugmotors für eine erfolgreiche Über¬ prü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, d.h. wenn die primären Fehlerspeicher A keine aktiven Fehlercodes enthalten und im sekundären Fehlerspei¬ cher B alle Einträge nach erfolgtem Test und Status Polling gelöscht wurden.

Claims

Patentansprüche
1. Rechnerbasierter Diagnosetester mit einem Diagnosepro¬ gramm und einer Diagnoseschnittstelle zur Verbindung des Diagnosetesters mit einem zu diagnostizierenden Steuerge¬ räteverbund, dadurch gekennzeichnet, dass mit dem Diagnoseprogramm aus primären Fehlerspei¬ chern (A) , insbesondere aus den Steuergeräten, Fehlerco¬ des und Statusinformationen zu Fehlercodes ausgelesen und ausgewertet werden, und dass alle Fehlercodes deren Fehlersetzbedingungen er¬ füllt sind oder zusätzlich alle Fehlercodes deren Status¬ informationen anzeigen, dass die betreffenden Fehlercodes nicht überprüft wurden, in einem sekundären Fehlerspei¬ cher (B) abgespeichert werden und mit dem Diagnosetester zur Anzeige gebracht werden.
2. Diagnosetester nach Anspruch 1, dadurch gekennzeichnet, dass die Fehlercodes im sekundären Fehlerspeicher (B) nur dann gelöscht werden, wenn eine Status Überprüfung erge¬ ben hat, dass für die zu löschenden Fehlercodes ein er¬ folgreicher Diagnoselauf stattgefunden hat.
3. Diagnosetester nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass während einer Reparatur die Statusinformationen aus¬ wählbarer Fehlercodes abgefragt werden können.
4. Diagnosetester nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Status Überprüfung zeitgesteuert ausgelöst wird.
5. Diagnosetester nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Fehlercodes in den primären Fehlerspeichern (A) durch einen allgemeinen Löschbefehl gelöscht werden.
6. Diagnosetester nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass nach einer Reparatur und nach einem anschließend durchgeführten Diagnoselauf der Inhalt des sekundären Fehlerspeichers (B) mit den Inhalten der primären Fehler¬ speicher (A) aktualisiert wird.
7. Diagnosetester nach einem der Ansprüche 1 bis S1 dadurch gekennzeichnet, dass sowohl die aktiven Fehlercodes aus den primären Feh¬ lerspeichern als auch die im sekundären Fehlerspeicher abgelegten Fehlercodes auf der Anzeige des Diagnosetes¬ ters zur Anzeige gebracht werden.
8. Diagnosesystem für die Überprüfung von Kraftfahrzeugsteu¬ ergeräten, wobei die Kraftfahrzeugsteuergeräte über Ei¬ gendiagnoseroutinen verfügen, welche bei Fehlfunktionen Fehlercodes in Kraftfahrzeugseitigen primären Fehlerspei¬ chern (A) ablegen, und diese primären Fehlerspeicher über eine Diagnoseschnittstelle mit einem externen Diagnose¬ tester verbindbar sind, wobei in dem Diagnosetester ein Diagnoseprogramm implementiert ist, dadurch gekennzeichnet, dass mit dem Diagnoseprogramm aus den primären Fehler¬ speichern Fehlercodes und Statusinformationen zu Fehler¬ codes ausgelesen und ausgewertet werden, und dass alle Fehlercodes deren Fehlersetzbedingungen er¬ füllt sind oder zusätzlich alle Fehlercodes deren Status¬ informationen anzeigen, dass die betreffenden Fehlercodes nicht überprüft wurden, in einem sekundären Fehlerspei¬ cher (B) abgelegt werden und mit dem Diagnosetester zur Anzeige gebracht werden.
9. Diagnosesystem nach Anspruch 8, dadurch gekennzeichnet, dass Fehlercodes im sekundären Fehlerspeicher (B) nur dann gelöscht werden, wenn eine Status Überprüfung erge¬ ben hat, dass für die zu löschenden Fehlercodes ein er¬ folgreicher Diagnoselauf stattgefunden hat.
10. Diagnosesystem nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass während einer Reparatur die Statusinformationen aus¬ wählbarer Fehlercodes abgefragt werden können.
11. Diagnosesystem nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass die Status Überprüfung zeitgesteuert ausgelöst wird.
12. Diagnosesystem nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Fehlercodes in den primären Fehlerspeichern (A) durch einen allgemeinen Löschbefehl gelöscht werden.
13. Diagnosesystem nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass nach einer Reparatur und nach einem anschließend durchgeführten Diagnoselauf der Inhalt des sekundären Fehlerspeichers (B) mit den Inhalten der primären Fehler¬ speicher (A) aktualisiert wird.
14. Diagnose nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass sowohl die aktiven Fehlercodes aus den primären Feh¬ lerspeichern als auch die im sekundären Fehlerspeicher abgelegten Fehlercodes auf der Anzeige des Diagnosetes¬ ters zur Anzeige gebracht werden.
15. Verfahren zur verbesserten Reparaturverifikation, bei dem mit Hilfe von Eigendiagnoseroutinen von Steuergeräten zu¬ nächst Fehlercodes ermittelt werden und in mindestens ei¬ nen primären Fehlerspeicher (A) abgelegt werden, dadurch gekennzeichnet,
- dass die ermittelten Fehlercodes auf der Anzeige des Diagnosetesters zur Anzeige gebracht werden und anhand der ermittelten Fehlercodes zumindest eine Teilreparatur durchgeführt wird,
- dass in einem weiteren Verfahrensschritt nach durchge¬ führter Reparatur, die ermittelten Fehlercodes aus den primären Fehlerspeichern (A) in einen sekundären Fehler¬ speicher (B) kopiert werden,
- dass nach diesem Kopiervorgang die primären Fehlerspei¬ cher gelöscht werden,
- dass in einem weiteren Verfahrenschritt mit Hilfe der Eigendiagnoseroutinen der Steuergeräte ein weiterer Diag¬ noselauf gestartet wird,
- dass nach dem weiteren Diagnoselauf der Inhalt des se¬ kundären Fehlerspeichers (B) mit den Inhalten der primä¬ ren Fehlerspeicher (A) abgeglichen wird, indem aus dem sekundären Fehlerspeicher (B) diejenigen Fehlercodes ge¬ löscht werden, die von den Eigendiagnoseroutinen der Steuergeräte getestet wurden.
16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die ermittelten Fehlercodes alle aktiven Fehlercodes umfassen.
17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die ermittelten Fehlercodes zusätzlich diejenigen Fehlercodes umfassen, deren Status Polling den Status „nicht getestet" ergeben hat.
18. Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass nach einem weiteren Diagnoselauf sowohl die aktiven Fehlercodes aus den primären Fehlerspeichern (A) als auch die nicht gelöschten Fehlercodes aus dem sekundären Feh¬ lerspeicher (B) auf dem Diagnosetester zur Anzeige ge¬ bracht werden.
PCT/EP2005/009077 2004-08-31 2005-08-23 Verbesserte reparaturverifikation für elektronische fahrzeugsysteme WO2006024424A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007528728A JP4742102B2 (ja) 2004-08-31 2005-08-23 自動車の制御装置のための改良されたチェック方法
EP05777338A EP1784628A1 (de) 2004-08-31 2005-08-23 Verbesserte reparaturverifikation für elektronische fahrzeugsysteme
US11/792,002 US8090495B2 (en) 2004-08-31 2005-08-23 Checking of repairs for electronic vehicle systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004042002A DE102004042002A1 (de) 2004-08-31 2004-08-31 Verbesserte Reparaturverifikation für elektronische Fahrzeugsysteme
DE102004042002.5 2004-08-31

Publications (1)

Publication Number Publication Date
WO2006024424A1 true WO2006024424A1 (de) 2006-03-09

Family

ID=35285500

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/009077 WO2006024424A1 (de) 2004-08-31 2005-08-23 Verbesserte reparaturverifikation für elektronische fahrzeugsysteme

Country Status (5)

Country Link
US (1) US8090495B2 (de)
EP (1) EP1784628A1 (de)
JP (1) JP4742102B2 (de)
DE (1) DE102004042002A1 (de)
WO (1) WO2006024424A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007240436A (ja) * 2006-03-10 2007-09-20 Denso Corp 車両診断システム
US20110125364A1 (en) * 2007-08-27 2011-05-26 Renault S.A.S. Method and system for diagnosing a malfunction of an automobile

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006029213A1 (de) * 2006-06-26 2007-12-27 Robert Bosch Gmbh Verfahren und Vorrichtung zum Erfassen und/oder Übermitteln von Service- und Diagnosedaten eines Fahrzeugs an ein Werkstatt-Managemant-System
DE102007005683B3 (de) * 2007-02-05 2008-10-02 Continental Automotive Gmbh Verfahren und Vorrichtung zum Abspeichern eines Fehlercodes
JP4363471B2 (ja) * 2007-08-03 2009-11-11 株式会社デンソー 故障コード記憶管理装置、及び記憶管理装置
JP4453764B2 (ja) * 2008-02-22 2010-04-21 トヨタ自動車株式会社 車両診断装置、車両診断システム、診断方法
FR2930823B1 (fr) * 2008-05-05 2010-10-08 Actia Muller Sa Procede et dispositif de controle de vehicule automobile
JP5272507B2 (ja) * 2008-05-12 2013-08-28 株式会社デンソー 電子制御装置
DE102008024979B4 (de) * 2008-05-23 2022-03-10 Bayerische Motoren Werke Aktiengesellschaft Bordnetz-System eines Kraftfahrzeugs und ein Verfahren zum Betrieb des Bordnetz-Systems
JP5206126B2 (ja) * 2008-06-02 2013-06-12 トヨタ自動車株式会社 車両用故障診断装置、故障診断方法
JP5176728B2 (ja) * 2008-07-04 2013-04-03 株式会社デンソー 車両用電子制御装置
FR2934389B1 (fr) * 2008-07-28 2010-12-17 Peugeot Citroen Automobiles Sa Procede de traitement d'informations et mise a disposition d'un diagnostic.
US9513789B2 (en) 2013-10-24 2016-12-06 Alldata Llc Vehicle diagnostic systems and methods
US20170024943A1 (en) 2014-03-19 2017-01-26 Cummins, Inc. System and Method for Service Assessment
US9514580B2 (en) 2014-03-19 2016-12-06 Cummins, Inc. Fault code hierarchy system
US9477843B2 (en) * 2014-06-11 2016-10-25 GM Global Technology Operations LLC Inhibiting access to sensitive vehicle diagnostic data
FR3055871B1 (fr) * 2016-09-14 2020-05-01 Continental Automotive France Procede de controle et de maintenance d'un vehicule automobile
US10943283B2 (en) 2016-11-18 2021-03-09 Cummins Inc. Service location recommendation tailoring
US10310934B2 (en) * 2017-04-27 2019-06-04 GM Global Technology Operations LLC Methods and systems for diagnosing a controller area network
CN107450515A (zh) * 2017-07-31 2017-12-08 北京新能源汽车股份有限公司 故障诊断自动测试方法及装置
US10846955B2 (en) 2018-03-16 2020-11-24 Micron Technology, Inc. Black box data recorder for autonomous driving vehicle
DE102018109193A1 (de) * 2018-04-18 2019-10-24 Ms Motorservice International Gmbh Datenverarbeitungsvorrichtung und Verfahren, Schnittstellenvorrichtung und Verfahren
US11094148B2 (en) 2018-06-18 2021-08-17 Micron Technology, Inc. Downloading system memory data in response to event detection
CN110211477A (zh) * 2018-09-01 2019-09-06 天津博诺智创机器人技术有限公司 一种工业机器人装调维修实训系统
US11782605B2 (en) 2018-11-29 2023-10-10 Micron Technology, Inc. Wear leveling for non-volatile memory using data write counters
US11373466B2 (en) 2019-01-31 2022-06-28 Micron Technology, Inc. Data recorders of autonomous vehicles
US11410475B2 (en) 2019-01-31 2022-08-09 Micron Technology, Inc. Autonomous vehicle data recorders
CN117572852B (zh) * 2024-01-16 2024-05-24 中国第一汽车股份有限公司 车辆部件故障分析方法、装置、设备、介质和产品

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4271402A (en) * 1979-08-29 1981-06-02 General Motors Corporation Motor vehicle diagnostic and monitoring device having keep alive memory
US4926352A (en) * 1987-08-07 1990-05-15 Dr. Ing. H.C.F. Porsche Aktiengesellschaft Diagnostic system for control apparatus of a motor vehicle
US5265468A (en) * 1991-03-02 1993-11-30 Wabco Standard Gmbh Error detection and display system
JPH07218391A (ja) * 1994-02-08 1995-08-18 Nippondenso Co Ltd 車両用診断装置
JPH07271589A (ja) * 1994-03-29 1995-10-20 Fuji Heavy Ind Ltd 故障診断装置
EP0819928A1 (de) * 1996-02-05 1998-01-21 Honda Giken Kogyo Kabushiki Kaisha Verfahren und vorrichtung zur diagnose von kraftfahrzeugen

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5077671A (en) * 1989-07-05 1991-12-31 The Boeing Company Test cart for aircraft control surface measurements
JP2589617B2 (ja) * 1991-12-25 1997-03-12 本田技研工業株式会社 車両用故障診断装置
JP3483691B2 (ja) * 1996-02-05 2004-01-06 本田技研工業株式会社 車両診断方法および装置
DE19921845A1 (de) 1999-05-11 2000-11-23 Bosch Gmbh Robert Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten
JP2004151021A (ja) * 2002-10-31 2004-05-27 Denso Corp 車両用故障診断装置
DE102004041740A1 (de) * 2004-08-28 2006-03-02 Daimlerchrysler Ag Verbesserte Reparaturverifikation für elektronische Fahrzeugsysteme
US7239946B2 (en) * 2004-10-25 2007-07-03 General Motors Corporation Vehicles fault diagnostic systems and methods
US7643912B2 (en) * 2004-11-01 2010-01-05 Hypertech, Inc. Programmable automotive computer method and apparatus with accelerometer input
DE102006018831A1 (de) * 2006-04-22 2007-10-25 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
US8630765B2 (en) * 2006-11-17 2014-01-14 Innova Electronics, Inc. OBD II-compliant diagnostic PC tablet and method of use
US7660662B2 (en) * 2006-12-28 2010-02-09 Detroit Diesel Corporation Fault code memory administrator with a driving cycle state machine concept
EP2026288A3 (de) * 2007-08-03 2010-11-24 Denso Corporation Elektronisches Steuersystem und -verfahren zur Fahrzeugdiagnose
US20090216401A1 (en) * 2008-02-27 2009-08-27 Underdal Olav M Feedback loop on diagnostic procedure
US20090216584A1 (en) * 2008-02-27 2009-08-27 Fountain Gregory J Repair diagnostics based on replacement parts inventory
US20090216493A1 (en) * 2008-02-27 2009-08-27 Underdal Olav M Hierarchy of diagnosis for advanced diagnostics equipment
JP4618314B2 (ja) * 2008-04-08 2011-01-26 株式会社デンソー 電子制御装置、及び車両制御システム
JP4506868B2 (ja) * 2008-04-23 2010-07-21 株式会社デンソー 電子制御装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4271402A (en) * 1979-08-29 1981-06-02 General Motors Corporation Motor vehicle diagnostic and monitoring device having keep alive memory
US4926352A (en) * 1987-08-07 1990-05-15 Dr. Ing. H.C.F. Porsche Aktiengesellschaft Diagnostic system for control apparatus of a motor vehicle
US5265468A (en) * 1991-03-02 1993-11-30 Wabco Standard Gmbh Error detection and display system
JPH07218391A (ja) * 1994-02-08 1995-08-18 Nippondenso Co Ltd 車両用診断装置
JPH07271589A (ja) * 1994-03-29 1995-10-20 Fuji Heavy Ind Ltd 故障診断装置
EP0819928A1 (de) * 1996-02-05 1998-01-21 Honda Giken Kogyo Kabushiki Kaisha Verfahren und vorrichtung zur diagnose von kraftfahrzeugen

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 1995, no. 11 26 December 1995 (1995-12-26) *
PATENT ABSTRACTS OF JAPAN vol. 1996, no. 02 29 February 1996 (1996-02-29) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007240436A (ja) * 2006-03-10 2007-09-20 Denso Corp 車両診断システム
US20110125364A1 (en) * 2007-08-27 2011-05-26 Renault S.A.S. Method and system for diagnosing a malfunction of an automobile

Also Published As

Publication number Publication date
DE102004042002A1 (de) 2006-03-02
JP2008511822A (ja) 2008-04-17
JP4742102B2 (ja) 2011-08-10
EP1784628A1 (de) 2007-05-16
US8090495B2 (en) 2012-01-03
US20080221751A1 (en) 2008-09-11

Similar Documents

Publication Publication Date Title
WO2006024424A1 (de) Verbesserte reparaturverifikation für elektronische fahrzeugsysteme
EP1782034A1 (de) Verbesserte reparaturverifikation für elektronische fahrzeugsysteme
EP0629773B1 (de) Diagnoseverfahren für Kraftfahrzeuge zum Überprüfen elektronisch gesteuerter Systeme
DE4040927C2 (de) Verfahren und Vorrichtung zur Fehlerspeicherung in einer Steuereinrichtung eines Kraftfahrzeugs
EP1751637A1 (de) Wissensbasiertes diagnosesystem für ein komplexes technisches system mit zwei getrennten wissensbasen zur verarbeitung technischer systemdaten und zur verarbeitung von kundenbeanstandungen
DE102008014922B4 (de) Speicher-Auslesesystem für eine Fahrzeugsteuervorrichtung
WO2003098557A2 (de) Verfahren zum übermitteln von fahrzeugdaten
DE112009000439T5 (de) Fahrzeuginformationsaufzeichnungsvorrichtung, Fahrzeuginformationskommunikationssystem und Fahrzeuginformationskommunikationsverfahren
WO2006105930A1 (de) Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben
WO2004074955A1 (de) Vorrichtung und verfahren zur modellbasierten on-board-diagnose
WO2001043079A1 (de) Verfahren zum erkennen von fehlern eines kraftfahrzeugs
DE102009016060A1 (de) Elektronische Steuervorrichtung und Fahrzeugsteuersystem
WO1998051538A2 (de) Verfahren zur manipulationssicheren konfigurierung eines kfz-steuergerätes sowie steuergerät
DE202006019993U1 (de) Diagnosegerät für Kraftfahrzeuge
DE102005044236B4 (de) Diagnosegerät
WO2008095518A1 (de) Anwendung einer verteilten diagnosearchitektur in autosar
DE19948663C2 (de) Diagnosesystem für Kraftfahrzeuge
WO2012031812A1 (de) Kraftfahrzeug-prüfgerät und verfahren zur identifikation von kraftfahrzeugen
EP0437551A1 (de) Verfahren und vorrichtung zum abfragen von steuergeräte-daten.
DE102017207375B3 (de) Verfahren zum Betreiben eines Kraftfahrzeugs, Speichermedium, Steuereinrichtung und Kraftfahrzeug
EP1117023B1 (de) Vorrichtung zur Diagnose von beim Betrieb eines Kraftfahrzeugs auftretenden Fehlern
DE19850990A1 (de) Steuergerät, insbesondere für Kraftfahrzeuge
DE102009053751B4 (de) Verfahren zum Diagnostizieren eines Fehlers an einem Kraftfahrzeug
DE102016009199B4 (de) Verfahren zum Betreiben einer Datenerfassungseinheit zum Erfassen von mindestens einem Steuerungsereignis einer Steuerungvorrichtung eines Kraftfahrzeugs sowie eine Datenerfassungseinheit und eine Datenverarbeitungseinheit
DE19636384C2 (de) Vorrichtung zur Fehlerdiagnose sowie Verfahren zur Fehlerdiagnose

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005777338

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007528728

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005777338

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11792002

Country of ref document: US