EP4147210A1 - Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose - Google Patents

Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose

Info

Publication number
EP4147210A1
EP4147210A1 EP21722886.5A EP21722886A EP4147210A1 EP 4147210 A1 EP4147210 A1 EP 4147210A1 EP 21722886 A EP21722886 A EP 21722886A EP 4147210 A1 EP4147210 A1 EP 4147210A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
diagnostic device
sensor
error codes
error
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP21722886.5A
Other languages
English (en)
French (fr)
Inventor
Martin Gütlein
Uwe Riegger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hella Gutmann Solutions GmbH
Original Assignee
Hella Gutmann Solutions GmbH
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 Hella Gutmann Solutions GmbH filed Critical Hella Gutmann Solutions GmbH
Publication of EP4147210A1 publication Critical patent/EP4147210A1/de
Pending legal-status Critical Current

Links

Classifications

    • 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/0808—Diagnosing performance data
    • 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
    • G07C2205/00—Indexing scheme relating to group G07C5/00
    • G07C2205/02—Indexing scheme relating to group G07C5/00 using a vehicle scan tool

Definitions

  • the present invention relates to a method and a diagnostic device for carrying out a vehicle diagnosis, the cause of the fault in the vehicle being determined automatically.
  • a vehicle diagnosis interface is usually provided in the vehicle, which is often arranged in the driver's footwell.
  • an external vehicle diagnostic device is connected to the vehicle diagnostic interface in order to read out the stored fault codes.
  • the fault codes are then analyzed by the vehicle diagnostic device to diagnose which components need to be repaired or replaced in order to correct the problem.
  • vehicle diagnostic devices have proven themselves in everyday workshop life.
  • the vehicle diagnostic device can generally read out the error codes, but cannot access all of the other relevant information stored in the vehicle.
  • the error codes also differ according to manufacturer, vehicle type and vehicle year. The type and meaning of the error code are often known to the vehicle manufacturer (OEM), but are usually not the subject of manufacturer information / instructions and are therefore not known to the company involved in vehicle diagnostics.
  • the method comprises at least the following steps:
  • the vehicle fault condition representing a condition of the vehicle in which at least one of the fault codes was triggered in the vehicle, based on the respective fault code and historical vehicle data from a database
  • the method is used to determine the vehicle fault condition in which the fault code was triggered. Because the vehicle fault condition is subsequently brought about, the exact cause of the fault message can be determined via an evaluation of the sensor measurements of the vehicle in the vehicle fault condition, depending on the fault code. Overall, the proposed method simplifies and speeds up vehicle diagnosis.
  • the method is characterized, among other things, by the fact that the steps are carried out automatically, in particular by a control unit such as a processor or controller. This can significantly reduce the workload for a motor vehicle mechanic.
  • the error code can include, for example, a diagnostic error code, a so-called Diagnostic Trouble Code (DTC), which is generated by a control device of the vehicle with the aid of sensors of the vehicle.
  • DTC Diagnostic Trouble Code
  • Such a diagnostic error code can, for example, be provided by a vehicle diagnostic system, a so-called on-board diagnosis (OBD), during operation of the vehicle if an error condition is present.
  • OBD on-board diagnosis
  • historical data refer to data that were determined or measured in the past and are stored in the database.
  • Vehicle data of the vehicle can therefore be compared with the historical vehicle data, in particular also from vehicles from other vehicle manufacturers, in order to be able to make a statement about the vehicle condition or the vehicle fault condition.
  • the historical vehicle data preferably include vehicle identification means, vehicle manufacturer, vehicle type, vehicle equipment, error codes, mileage, vehicle age, sensor measured values and / or sensor measured variables.
  • the vehicle data mentioned are preferably combined in at least one matrix and, in particular, assigned to a specific vehicle or a specific vehicle group.
  • the database can be part of a storage medium, a server and / or a diagnostic device. In particular, the database is not part of the vehicle and can be referred to as an external database.
  • the request to bring about the first vehicle fault condition can contain at least one of the following instructions or requests:
  • Vehicle functions can also be activated, e.g. regeneration of the diesel particulate filter.
  • the instructions or requests are preferably followed by a user, such as a car mechanic, and carried out on the vehicle.
  • the request may be sent to the vehicle itself and then implemented by the vehicle.
  • the at least one actuator, vehicle module and / or vehicle control unit are changed, set, switched on or off accordingly, or the at least one vehicle parameter is changed accordingly.
  • Feedback from the vehicle or a user can be used to identify that the first vehicle fault condition was caused.
  • the method can thus include the step of receiving a confirmation that the vehicle is in the first vehicle fault state.
  • the method can include the additional step: determining a relevance of the respective error code.
  • the relevance of the respective error code can be determined based on an average time span between triggering and deleting the same historical error codes.
  • the fault is usually deleted manually in the workshop by the mechanic after the vehicle has been repaired or the fault has been rectified.
  • the average time span can, for example, be stored in the database mentioned and can, for example, be based on experience evaluation values or logged data. If an error code remains set on average for a long time before the error is deleted, this can be an indication that the vehicle operation is not significantly disrupted by the error and that there is no serious error.
  • the time span between triggering the error and clearing the error is short on average, this can be an indication that trouble-free vehicle operation can only be guaranteed by quickly eliminating the error, only possible to a limited extent due to the error that occurs or even being canceled under certain circumstances is closed. It can thus be provided that the relevance is comparatively high if the average time span falls below a predetermined value. The relevance can be comparatively low if the average time span exceeds a predetermined value.
  • the error codes can be classified by comparison with historical error codes from the database according to vehicle assemblies and / or customer groups and / or correlating historical error codes. Correlating error codes can be error codes that occur more frequently when the error code occurs. If the fault code is assigned to a specific vehicle assembly, then the correlating fault codes can also be assigned to this vehicle assembly. The relevance of the respective error code can then be determined using the classification of the error code.
  • the error codes can be sorted and / or evaluated according to relevance.
  • the relevance can be expressed by a number, e.g. either 0 (not relevant) or 1 (relevant) or a number between 0 and 1.
  • the determination of the first vehicle error state, the relevant sensor parameters to be measured and / or the at least one potentially defective component can be done based on the relevance of the error codes.
  • the diagnostic device can receive information about the current state of the vehicle and the errors present. Furthermore, there is usually a user interface such as a display with a user interface in the diagnostic device, via which additional information information can be queried or entered by the user.
  • a user interface such as a display with a user interface in the diagnostic device, via which additional information information can be queried or entered by the user.
  • historical logging data from diagnostic devices can also be taken into account, which can in particular be stored in the database.
  • Logging is usually the creation of a log of a diagnostic process, which is usually created automatically.
  • the historical logging data preferably include called up repair information and / or called up vehicle component information that was called up during earlier (historical) vehicle diagnoses, for example. If, after reading / receiving a certain error code, certain repair information and / or vehicle component information is often or always called up by the mechanic, this is an indication that a certain component is defective when this certain error code occurs. Taking the historical logging data into account when determining the potentially defective component can thus considerably accelerate the automatic vehicle diagnosis.
  • a target range can be determined for each sensor measured variable.
  • the target range here preferably comprises a target measured value and / or a tolerance range around the target measured value. Measured values that lie within the target range are accordingly assessed as positive, while measured values that lie outside the target range are assessed as negative.
  • the target range depends on several parameters internal to the vehicle (e.g. vehicle age, mileage) or external parameters (e.g. outside temperature), which can also be stored in the database. Correlating sensor measured variables and / or related sensor measured variables can also be taken into account for the determination of the setpoint range.
  • Related sensor measurement variables can, for example, be assigned to the same vehicle assembly (e.g. engine, air conditioning, brake system, infotainment system, etc.).
  • the method can further have at least one of the following steps:
  • the user interface can in particular be a display or the above-mentioned user interface on the vehicle diagnostic device.
  • the process can include at least one of the following steps:
  • the vehicle identification means includes in particular a vehicle identification number and / or an engine code and / or a control unit identification number and / or short name,
  • the vehicle identification means indicates, for example, the vehicle manufacturer and / or a vehicle type of the vehicle and, if necessary, equipment features of the vehicle such as the engine variant or injection system.
  • the vehicle identification means can include, for example, a vehicle-specific number, for example a vehicle identification number (hereinafter: FIN, Vehicle Identification Number, VIN) with which a vehicle can be uniquely identified.
  • FIN Vehicle Identification Number
  • VIN Vehicle Identification Number
  • information on the vehicle or on comparable vehicles can be determined from the database in a simple manner. It turned out that the VIN is not always sufficient to clearly determine the identity of the vehicle.
  • at least one further vehicle identification means can be used, for example an engine code and / or a control unit identification number and / or a short description of the vehicle.
  • the short description of the vehicle can be stored in a control unit of the vehicle and can provide information about the manufacturer, type and / or equipment of the vehicle.
  • the identity of the vehicle can be inferred and the vehicle (manufacturer, type and / or equipment) recognized.
  • the identity of the vehicle can be determined by recognizing a pattern in the vehicle identification means and comparing it with the same or similar patterns in the database.
  • the step of receiving the vehicle identification means can include, for example, that the vehicle identification means is transmitted by the vehicle or is entered by a user. If necessary, the vehicle identification means can be transmitted or entered after a request.
  • the method can include the following step: determining context-related repair information on the basis of the error codes and / or the sensor measured variables and / or the potentially defective components.
  • Context-related repair information is, for example, circuit diagrams, work values or component test values that the user needs to repair the vehicle or to rectify the fault.
  • the context-related repair information can be determined by comparing it with the historical logging data.
  • the at least one potentially defective component is additionally determined on the basis of customer service data and / or invoice data from motor vehicle workshops and / or access to repair information in the database.
  • the error codes can be evaluated based on the measured sensor parameters.
  • the at least one potentially defective component can be determined.
  • the at least one potentially defective component can then be determined using the error codes and the measured sensor measurement variables.
  • the method comprises at least one, several or all of the following steps:
  • the diagnostic results can be displayed on the display device, the display device preferably being part of a diagnostic device or of the above-mentioned user interface.
  • the automatic method described above can speed up and simplify the operation of the diagnostic device.
  • extensive knowledge of the diagnostic device is no longer required.
  • the user no longer has to navigate through approx. 10 or more interfaces / categories with approx. 75 "clicks".
  • extensive vehicle knowledge is also no longer necessary to combine the displayed error codes and the read out sensor readings.
  • the automatic, data-driven identification of potentially affected components is more accurate than the previous listing of possibly affected components per individual error code.
  • the above-mentioned method can in particular be carried out by a vehicle diagnostic device, a server and / or a system comprising a vehicle diagnostic device and a server.
  • the vehicle diagnostic device, the server or the system can preferably be connected to the vehicle via a vehicle diagnostic interface, e.g. directly or indirectly.
  • the invention provides a diagnostic device which is designed to carry out the above method.
  • the diagnostic device is designed to carry out at least the following steps:
  • the vehicle fault condition representing a condition of the vehicle in which at least one of the fault codes was triggered in the vehicle, based on the respective fault code and historical vehicle data from a database
  • the diagnostic device is not part of the vehicle and can, for example, be arranged outside the vehicle or in a vehicle interior, preferably temporarily for the duration of the diagnosis.
  • the diagnostic device can comprise a vehicle diagnostic device and / or a mobile device and / or a server or be a vehicle diagnostic device or a server.
  • the diagnostic device can be a system or part of a system which comprises a vehicle diagnostic device and a server.
  • the diagnostic device can set up a communication link with the vehicle, in particular the vehicle-based control units.
  • the device for receiving and / or sending data can have a communication device.
  • the diagnostic device typically comprises a control unit, e.g. for processing data and / or controlling further units.
  • the database can be part of the diagnostic device. Alternatively, the database can also be provided outside the diagnostic device, e.g. part of an external server.
  • FIG. 1 shows a schematic representation of a vehicle diagnostic device connected to a vehicle
  • FIG. 2 shows a schematic representation of a system for performing a vehicle diagnosis
  • FIG. 3 shows a schematic illustration of a communication sequence between a vehicle and a vehicle diagnostic device
  • FIG. 4 shows a schematic representation of a further communication sequence between a vehicle and a system.
  • the invention provides a method for performing a diagnosis of a vehicle 10.
  • the method is preferably carried out by means of a vehicle diagnostic device 20 indicated in FIGS. 1 and 3 or a system 40 indicated in FIGS. 2 and 4, the system in the exemplary embodiment of FIGS. 2 and 4 comprises a vehicle diagnostic device 20 and a server 30.
  • FIG. 1 shows a vehicle 10 which has a multiplicity of control units 11, 12, for example at least 10 or more.
  • the control units 11, 12 can be connected to one another, for example via a CAN bus system.
  • at least one control unit 11 is connected to a vehicle diagnosis interface 13.
  • 1 shows a vehicle diagnosis device 20, which typically includes a control and processing unit, a communication unit, a memory and an input and output unit for communication with a user such as a motor vehicle mechanic.
  • the vehicle diagnostic device 20 can usually be connected to the vehicle diagnostic interface 13 of the vehicle via signal lines (i.e. wired). tool 10 can be connected.
  • the vehicle diagnostic device 20 typically has a plug that is compatible with the vehicle diagnostic interface 13. When connecting the plug to the vehicle diagnostic interface 13, both are electrically connected to one another.
  • a wireless communication link between the vehicle diagnostic device 20 and the vehicle 10 and the control devices 11, 12 is possible.
  • the control units 11, 12 are usually each connected to a multiplicity of sensors which record measured values during the operation of the vehicle.
  • Conceivable sensor measurements include, for example, a coolant temperature, an engine temperature, a vehicle speed, an engine speed, an engine torque, an ambient temperature, an ambient air pressure, a boost pressure of an exhaust gas turbocharger of the drive engine, an engaged gear of a transmission of the vehicle 10, etc. If a sensor If the measured value falls below or exceeds a certain target value range, the corresponding control device 11, 12 generates an error code.
  • the error code is assigned to an error state and contains, for example, a code number to identify malfunctions that can occur during the operation of a vehicle.
  • the trouble code is also known as a diagnostic trouble code or Diagnostic Trouble Code (DTCj.
  • the aim of the vehicle diagnosis is to be able to determine which component in the vehicle 10 is defective and how this component can be repaired.
  • the vehicle diagnostic device 20 evaluates the error codes, which during operation of the vehicle 10 via an evaluation of the sensor measured values by the at least one Vehicle control unit 11, 12 are generated and stored in a vehicle-mounted memory.
  • the vehicle control devices 11, 12 are designed to read out the error codes stored in the vehicle 10 and to transmit them to the diagnostic device 20 (or the server 30).
  • the vehicle diagnostic device 20 can therefore communicate directly with the respective vehicle control device 11, 12 in order to retrieve the required error codes from the vehicle Control unit 11, 12 to obtain.
  • the fault codes can then be analyzed by the vehicle diagnostic device 20 in order to diagnose whether and which vehicle components need to be repaired or replaced in order to rectify the problem.
  • a statement can be made about which vehicle components are defective and require repair.
  • Fig. 3 shows schematically a preferred communication flow between tween the vehicle 10 and the vehicle diagnostic device 20.
  • the sending and receiving steps are each summarized in an arrow with a reference number.
  • An identification of the vehicle is usually required so that the vehicle diagnostic device 20 can assign the error codes to a specific vehicle 10, in particular the manufacturer, type and equipment of the vehicle 10. Therefore, the vehicle diagnostic device 20 sends (Sil) a request for identifying the vehicle 10 to the vehicle. The vehicle 10 then sends (S12) at least one vehicle identification means of the vehicle 10, which can be stored in a vehicle memory, 1 to the vehicle diagnostic device 12. In alternative embodiments, the manufacturer, type and / or equipment of the vehicle 10 or the vehicle identification means are carried out manually a technician or vehicle mechanic entered the vehicle diagnostic device 12.
  • the vehicle diagnostic device 20 can then, for example, request the error codes from the vehicle 10 (S13).
  • the vehicle 10 then sends the requested error codes to the vehicle diagnostic device 20, and the vehicle diagnostic device 20 receives (S14) the vehicle error codes. After receipt, the Error codes are analyzed or evaluated by the vehicle diagnostic device 12.
  • vehicle diagnostic device 20 can additionally request currently measured sensor measured values or sensor measured values stored in the vehicle from vehicle 10. This is done, for example, via a corresponding request (S15).
  • the vehicle control device 11, 12 calls up the requested sensor measured values, e.g. from a memory in the vehicle, or addresses corresponding vehicle sensors to issue or record the sensor measured values.
  • the measured sensor values are then sent from the vehicle control device 11, 12 to the vehicle diagnostic device 20 for further evaluation or processing (S16). Based on the error codes and the sensor measured values, the vehicle diagnostic device 20 can determine which component in the vehicle is defective and requires repair.
  • steps Sil and S13, S12 and S14 can each be combined.
  • the vehicle diagnostic device 20 can also send commands to the vehicle control device 11, 12.
  • a command to the vehicle control unit includes a setting of the sensor or a change in the setting of the sensor, where the setting includes, for example, a sensitivity of the sensor, a frequency of the measurements and / or a time sequence of the measurements.
  • the status of the vehicle control device 11, 12 can be changed or set by the vehicle diagnostic device 20 via a corresponding message. It would be conceivable in this context, for example. Inspection interval, control of actuators or the like. The course of the vehicle diagnosis is described below.
  • the vehicle diagnosis can alternatively also be carried out with the system 40 shown in FIG. 2.
  • the system 40 comprises the vehicle diagnostic device 20 described above and a server 30.
  • the vehicle diagnostic device 20 is preferably connected to the vehicle 10 via the vehicle interface 13.
  • the vehicle diagnostic device 20 is also wirelessly or wired to an external server 30. This enables communication between the server 30 and the diagnostic device 20. The communication between the vehicle 10, the diagnostic device 20 and the server 30 is discussed below.
  • a communication link is established between the diagnostic device 20 and the vehicle 10 (S10). Thereafter (or before or at the same time) a communication connection is established between the diagnostic device 20 and the server 30 (S20). The diagnostic device 20 is now able to mediate communication between the server 30 and the vehicle 10. In this way, the diagnostic device 20 can convey data or messages between the vehicle 10 and the server 30.
  • An identification of the vehicle 10 is usually required so that the server 30 can assign the error codes to a specific manufacturer and vehicle type.
  • the server 30 therefore sends (S21) a request for identifying the vehicle 10 to the diagnostic device 20, which forwards the request to the vehicle 10 (Sil).
  • the vehicle 10 then sends (S12) at least one identification means of the vehicle 10, which can be stored in a vehicle-side memory, via the diagnostic device 20 to the server 30 (S22).
  • the server 30 can then request error codes from the vehicle 10, for example.
  • the diagnostic device 20 forwards, for example, the request from the server 30 to the vehicle control device 10 (S23, S13).
  • the vehicle 10 then sends (S14) the requested error codes to the diagnostic device 20, which sends the error codes to the server 30 (S24).
  • the error codes can be analyzed or evaluated by the server 30.
  • the server 30 can also request measured sensor values from the vehicle 10. This is done, for example, via a request that is forwarded from the diagnostic device 20 to the vehicle 10 (S25, S15).
  • the vehicle 10 calls up the requested sensor measured values from the vehicle-side memory or addresses corresponding vehicle sensors to issue or to acquire the sensor measured values.
  • the sensor readings are then sent from the vehicle 10 to the diagnostic device 20 (S16) and from the diagnostic nos réelle 20 is sent to the server 30 for further evaluation or processing (S26). Based on the error codes, the identification means and the sensor measured values, the server 30 can determine which component in the vehicle 10 is defective and requires repair.
  • steps S21 and S23, Sil and S13, S12 and S14, and S22 and S24 can each be combined.
  • the server 30 can also send commands to the vehicle 10 via the diagnostic device 20.
  • a command to the vehicle includes a setting of the sensor or a change in the setting of the sensor, the setting including, for example, a sensitivity of the sensor, a frequency of the measurements and / or a time sequence of the measurements.
  • the status of the vehicle 10 can be changed or set by the server 30 via a corresponding message.
  • e.g. inspection intervals, actuation of actuators or the like would be conceivable.
  • the vehicle 10 can also receive new software components or updates that the server 30 sends to the vehicle 10 via the diagnostic device 20.
  • a mobile device such as a mobile phone, laptop, computer, tablet PC or the like can alternatively be provided, which on the one hand with the vehicle 10, in particular via the vehicle interface 13, and on the other hand with the server 30 is connected, and which the communication between the vehicle 10 and the server 30 mediated.
  • the mobile device therefore preferably forwards messages such as commands and / or inquiries or data such as measured values and / or DTCs from vehicle 10 to server 30 and vice versa.
  • the actual vehicle diagnosis which can be carried out in particular by the vehicle diagnosis device 20, the server 30 or the system 40, will be discussed in greater detail below.
  • VIN vehicle identification number
  • engine code / or a control unit identification number and / or a short description.
  • the vehicle identification means is compared with known vehicle means from the database in order to identify the vehicle 10. In some cases, the VIN is insufficient to unequivocally identify the vehicle 10. In these cases, on the basis of manually selected vehicles with an existing VIN in the database, patterns are extracted that can also be used for unknown VINs. By including the engine code and the abbreviation, vehicles from all manufacturers can be identified for which the VIN alone is not sufficient.
  • the procedure also has the following steps:
  • the vehicle error state representing a state of the vehicle 10 in which at least one of the error codes in the vehicle 10 was triggered, based on the respective error code and historical vehicle data from a database outside the vehicle 10,
  • Request to bring about at least the first vehicle fault condition preferably by displaying a request on a display of the diagnostic device 20, and receiving S16, S26 of the measured sensor parameters of the vehicle 10.
  • the historical vehicle data in the database is preferably used, the database being stored in a storage medium that is, for example, part of the diagnostic device 20, the server 30 or another server.
  • the historical vehicle data include at least the vehicle manufacturer, vehicle type, vehicle equipment, error codes, mileage, vehicle age, sensor measured values and / or sensor measured values.
  • a check is made as to how the vehicle condition was before the error code (e.g. based on the speed or engine speed) or whether an actuator test / control element test was carried out on components (e.g. blower or air conditioning activated).
  • historical data can be used, for example, to check which sensor measured variables (sensor parameters) are increasingly selected by the user if a corresponding error code is present. By bringing about the first vehicle fault condition, relevant measured values can therefore be recorded, which can then be used for the diagnosis.
  • the vehicle state can be brought about, for example, by changing or setting at least one actuator, changing or setting at least one vehicle parameter, switching on or off at least one vehicle module and / or switching on or off at least one vehicle control device.
  • a corresponding confirmation can be sent to the vehicle diagnostic device 20 or the server 30. If necessary, depending on the error code, several vehicle error states can be brought about successively, in each of which the relevant sensor parameters to be measured are measured.
  • the relevance of the respective error code can be determined.
  • the error codes are then sorted and weighted according to relevance. For example, only the most relevant error codes are taken into account for the diagnosis. Less relevant error codes can be ignored. If, for example, an average period of time between triggering and deleting the error code exceeds a predetermined time period, the error can be classified as irrelevant. On the other hand, the error code can be classified as relevant if the average time span between triggering and deleting the error code falls below a predetermined duration.
  • the error codes can be classified by comparison with historical error codes from the database according to vehicle assemblies and / or customer groups and / or correlating historical error codes. Correlating error codes are error codes that occur more frequently when the error code occurs. If the error code is assigned to a specific vehicle assembly, then the correcting error codes can also be assigned to this vehicle assembly. The relevance of the respective error code can then be determined using the classification of the error code.
  • the procedure also includes the following step:
  • Determining at least one potentially defective component in the vehicle 10 in particular on the basis of the error codes, the measured sensor values and the mileage of the vehicle.
  • calls to technical information such as repair information or vehicle component information are stored by the mechanic on the diagnostic device 20 in a log, which is also referred to as logging.
  • the logging data are preferably also in the data deposited in a bank. The logging data can be taken into account when determining the potentially defective component.
  • the selection of relevant information on the diagnostic device 20 that is necessary for the repair is usually based on his motor vehicle expert knowledge.
  • the mechanic often has up to 18 different categories with additional sub-categories in the diagnostic device: e.g. circuit diagrams, labor values or component test values. According to conventional solutions, the mechanic had to make a suitable selection in each category.
  • the corresponding categories are stored in the database (e.g. on the server 30 and / or the diagnostic device 20).
  • relevant components or component formations are extracted, for example from a memory of the diagnostic device 20 or the database.
  • the at least one potentially defective component is additionally determined on the basis of customer service data and / or invoice data from motor vehicle workshops and / or access to repair information in the database.
  • the method can include the following step: Determination of context-related repair information on the basis of the error codes and / or the sensor measured variables and / or the potentially defective components.
  • Context-related repair information is e.g. wiring diagrams, labor values or component test values that the user needs to repair the vehicle or to rectify the fault.
  • the context-related repair information can be determined using the historical logging data.
  • the relevance of the error codes can be determined, for example on the basis of the same historical error codes. For example, if the error codes remain set for a longer period of time, this is an indicator that the error code is less relevant. Historical error codes from customer groups can also be used to classify the relevance that relate to the re- Focus on repairing less critical problems (e.g. "Glaser"). If error codes are read out of their focus there (e.g. error codes that were generated based on engine sensor readings), then this is also an indicator that the error code is less relevant Customer concerns are another problem.
  • Prediction models can be developed on the basis of the historical vehicle data (relevant error codes, sensor readings and mileage readings) in conjunction with the extracted components.
  • Anomalies in the sensor readings can also be determined.
  • a self-learning system (diagnostic device 20, server 30 or system 40) should identify correlating sensor measurement values and related sensor sensor measurement values and form a main cluster (majority of all healthy measurement points) on which outlier models can be trained. Error codes can also be included to identify the main cluster. This means that no error codes or a number of error codes that do not exceed a predetermined limit are preferably set for the measured values in the main cluster.
  • These models can be applied to current sensor measurements and calculate a probability of whether the measurement should be classified as an outlier / anomaly. Measured values that lie within a target range are accordingly assessed as positive, while measured values that lie outside the target range are assessed as negative.
  • Correlating and / or related sensor measured variables can be taken into account to determine the target range.
  • the measured sensor parameters can be compared with the respective target ranges in order to identify outliers in the sensor parameters.
  • the degree of deviation of the measured value from the target range can be specified, for example by showing it on the display on the diagnostic device 20.
  • the method optionally has at least one of the following steps: Creating and displaying a list of potentially defective components, creating and displaying context-related component information on the defective components and / or determining and displaying necessary repair steps.

Abstract

Die Erfindung betrifft ein Verfahren zum Durchführen einer Fahrzeugdiagnose, umfassend die Schritte: - Empfangen (S14, S24) einer Vielzahl von Fehlercodes eines Fahrzeuges (10), - Ermitteln zumindest eines ersten Fahrzeugfehlerzustandes, wobei der Fahrzeugfehlerzustand einen Zustand des Fahrzeuges (10) darstellt, in dem zumindest einer der Fehlercodes im Fahrzeug (10) ausgelöst wurde, basierend auf dem jeweiligen Fehlercode und historischen Fahrzeugdaten aus einer Datenbank, - Ermitteln von zu messenden relevanten Sensormessgrößen basierend auf den Fehlercodes, - Auffordern zum Herbeiführen zumindest des ersten Fahrzeugfehlerzustandes, - Empfangen (S16, S26) der gemessenen Sensormessgrößen des Fahrzeuges (10), - Ermitteln von mindestens einem potentiell defekten Bauteil. Weiter betrifft die Erfindung eine Diagnosevorrichtung zum Durchführen des Verfahrens.

Description

Verfahren und Diagnosevorrichtung zum Durchführen einer Fahrzeugdiagnose
Die vorliegende Erfindung bezieht sich auf ein Verfahren sowie eine Diagnose vorrichtung zum Durchführen einer Fahrzeugdiagnose, wobei die Fehlerursa- che des Fahrzeugs automatisch bestimmt wird.
Die zunehmende Vernetzung von Steuergeräten in heutigen Kraftfahrzeugen bietet immer bessere Einwirkungsmöglichkeiten auf Funktionalitäten im Fahr zeug, z.B. bessere Diagnosemöglichkeiten im Fehlerfall oder Möglichkeiten zur Fernbedienung von Funktionen und/oder Komponenten des Fahrzeugs. Bei einem Fahrzeug, beispielsweise einem Personenkraftwagen, Zweirädern oder einem Lastkraftwagen, können Fehlermeldungen von Steuergeräten und Sen soren über eine sogenannte On-Board-Diagnosefunktion gemeldet werden. Moderne Fahrzeuge sind komplexe elektrische und mechanische Systeme, die viele miteinander kommunizierende Komponenten verwenden, um einen si cheren und effizienten Fahrzeugbetrieb zu unterstützen. Derartige Kompo- nenten können anfällig für Störungen, Ausfälle und Fehler sein, welche den Betrieb eines Fahrzeugs beeinträchtigen können. Wenn derartige Störungen oder Fehler auftreten, kann die beeinträchtigte Komponente einen entspre chenden Fehlercode auslösen, zum Beispiel einen Diagnostic Trouble Code (DTCj. Der Fehlercode wird in der Regel in einem fahrzeugseitigen Speicher gespeichert. Hiernach kann etwa ein Warnsignal ausgegeben werden, durch das der Fahrer veranlasst wird, eine Werkstatt aufzusuchen.
Mittels einer Auswertung der Fehlercodes (Fahrzeugdiagnose) kann eine Aus sage darüber getroffen werden, welche Fahrzeugkomponenten defekt sind und eine Reparatur benötigen. Hierzu ist üblicherweise eine Fahrzeugdiagno seschnittstelle im Fahrzeug vorgesehen, welche oftmals im Fußraum beim Fahrer angeordnet ist. Typischerweise wird ein externes Fahrzeugdiagnosege rät an die Fahrzeugdiagnoseschnittstelle angeschlossen, um die gespeicherten Fehlercodes auszulesen. Hiernach werden die Fehlercodes durch das Fahr zeugdiagnosegerät analysiert, um zu diagnostizieren, welche Komponenten repariert oder ersetzt werden müssen, um das Problem zu beheben. Im Werk stattalltag haben sich solche Fahrzeugdiagnosegeräte bewährt.
Allerdings kann das Fahrzeugdiagnosegerät in der Regel zwar die Fehlercodes auslesen, jedoch nicht auf alle im Fahrzeug gespeicherten weiteren relevanten Informationen zurückgreifen. Des Weiteren unterscheiden sich die Fehler codes u.a. nach Hersteller, Fahrzeugtyp und Fahrzeugbaujahr. Art und Be deutung des Fehlercodes sind oftmals zwar dem Hersteller des Fahrzeuges (OEM) bekannt, sind aber in der Regel nicht Gegenstand von Herstelleranga ben / -hinweisen und damit dem mit der Fahrzeugdiagnose befassten Unter nehmen nicht bekannt.
Auch bei bekannten Fehlercodes ist es oft umständlich, auf die eigentliche Ursache der Fehlermeldung zu schließen. Wenn beispielsweise als Fehler eine erhöhte Kühlmitteltemperatur gemeldet wird, können die Fehlerursachen vielfältig sein, etwa ein Mangel an Kühlflüssigkeit aufgrund einer Undichtigkeit im Kühlsystem, ein mangelnder Flüssigkeitsdurchsatz aufgrund von Dampfbla sen oder einer defekten Kühlmittelpumpe, oder eine Überhitzung aufgrund einer vorherigen Fahrzeugbelastung und klimatischen Bedingungen. Eine Möglichkeit zur Ermittlung der Fehlerursache ist beispielsweise ein Anruf bei einem Callcenter, wo sogenannte Fehlerbäume hinterlegt sind, die über Fra gen abgearbeitet werden. Dies kann jedoch personal- und zeitintensiv sein.
Aktuell sind viele einzelne Arbeitsschritte notwendig, um eine komplette Di agnose durchführen zu können. Zuerst muss ein Fahrzeug auf dem Diagnose gerät ausgewählt werden. Dann erfolgen meist das Auslesen von Fehlercodes und anschließend das Messen von Parametern. Auf Basis dieser Information sucht der Mechaniker die entsprechenden Fahrzeuginformationen, die er für die Reparatur benötigt. Allerdings sind die dargestellten Diagnoseergebnisse mitunter schwierig zu interpretieren und teilweise ungenau.
Aufgrund der steigenden Komplexität der Fahrzeugtechnik besteht daher ein großer Bedarf an einer schnellen und zuverlässigen Fehlerursachenbestim mung, wenn ein Fehler an einem Fahrzeug auftritt. Insbesondere wäre es wünschenswert, eine praxistaugliche Lösung für die Fehlerursachenbestim mung zu finden.
Die genannten Probleme werden nach der beschriebenen Erfindung zumin dest teilweise oder zu einem wesentlichen Teil durch ein Verfahren entspre chend dem Hauptanspruch sowie eine Vorrichtung gemäß dem Nebenan spruch gelöst. Vorteilhafte Merkmale und Weiterbildungen ergeben sich durch die Merkmale der abhängigen Ansprüche sowie aus der nachfolgenden Beschreibung.
Dementsprechend wird ein Verfahren zur Durchführung einer Fahrzeugdiag nose bereitgestellt. Das Verfahren umfasst zumindest die Schritte:
Empfangen einer Vielzahl von Fehlercodes eines Fahrzeuges,
Ermitteln zumindest eines ersten Fahrzeugfehlerzustandes, wobei der Fahrzeugfehlerzustand einen Zustand des Fahrzeuges darstellt, in dem zumindest einer der Fehlercodes im Fahrzeug ausgelöst wurde, basie rend auf dem jeweiligen Fehlercode und historischen Fahrzeugdaten aus einer Datenbank,
Ermitteln von zu messenden relevanten Sensormessgrößen basierend auf den Fehlercodes,
- Auffordern zum Herbeiführen zumindest des ersten Fahrzeugfehlerzu- Standes,
Empfangen der gemessenen Sensormessgrößen des Fahrzeuges,
Ermitteln von mindestens einem potentiell defekten Bauteil.
Mit dem Verfahren wird also der Fahrzeugfehlerzustand ermittelt, in dem der Fehlercode ausgelöst wurde. Dadurch, dass der Fahrzeugfehlerzustand an schließend herbeigeführt wird, kann über eine Auswertung der Sensormess größen des sich im Fahrzeugfehlerzustand befindlichen Fahrzeuges in Abhän gigkeit des Fehlercodes die genaue Ursache der Fehlermeldung ermittelt wer den. Insgesamt können durch das vorgeschlagene Verfahren eine Vereinfa chung und Beschleunigung der Fahrzeugdiagnose erzielt werden. Das Verfah ren zeichnet sich unter anderem dadurch aus, dass die Schritte automatisch, insbesondere durch eine Steuereinheit wie einen Prozessor oder Controller durchgeführt werden. Hierdurch kann der Aufwand für einen Kfz-Mechaniker erheblich reduziert werden.
Der Fehlercode kann beispielsweise einen Diagnosefehlercode, einen soge nannten Diagnostic Trouble Code (DTC), umfassen, welcher von einem Steu ergerät des Fahrzeugs mit Hilfe von Sensoren des Fahrzeugs erzeugt wird. Ein derartiger Diagnosefehlercode kann beispielsweise von einem Fahrzeugdiag nosesystem, einer sogenannten On-Board-Diagnose (OBD), während des Be triebs des Fahrzeugs bereitgestellt werden, falls ein Fehlerzustand vorliegt.
Gemäß der vorliegenden Schrift beziehen sich historische Daten auf Daten, die in der Vergangenheit ermittelt oder gemessen wurden und in der Daten bank gespeichert sind. Es können also Fahrzeugdaten des Fahrzeuges mit den historischen Fahrzeugdaten, insbesondere auch von Fahrzeugen anderer Fahrzeughersteller, verglichen werden, um eine Aussage über den Fahrzeug zustand oder den Fahrzeugfehlerzustand treffen zu können. Die historischen Fahrzeugdaten umfassen vorzugsweise Fahrzeugidentifikationsmittel, Fahr zeughersteller, Fahrzeugtyp, Fahrzeugausstattung, Fehlercodes, Kilometer stand, Fahrzeugalter, Sensormesswerte und/oder Sensormessgrößen. Die ge nannten Fahrzeugdaten sind vorzugsweise in mindestens einer Matrix zu sammengefasst und insbesondere einem bestimmten Fahrzeug oder einer bestimmten Fahrzeuggruppe zugeordnet. Die Datenbank kann Bestandteil eines Speichermediums, eines Servers und/oder eines Diagnosegeräts sein. Die Datenbank ist insbesondere nicht Bestandteil des Fahrzeuges und kann als externe Datenbank bezeichnet wer den.
In einer Variante des Verfahrens kann die Aufforderung zum Herbeiführen des ersten Fahrzeugfehlerzustandes mindestens eine der nachstehenden Anwei sungen oder Aufforderungen enthalten:
Ändern, Aktivieren oder Einstellen mindestens eines Stellglieds,
Ändern oder Einstellen mindestens eines Fahrzeugparameters,
An- oder Abschalten mindestens eines Fahrzeugmoduls.
Es können auch Fahrzeugfunktionen aktiviert werden, z.B. die Regenerierung vom Dieselpartikelfilter. Die Anweisungen oder Aufforderungen werden vor zugsweise durch einen Benutzer, wie einen Kfz-Mechaniker, befolgt und am Fahrzeug durchgeführt. Unter Umständen wird die Aufforderung an das Fahr zeug selbst geschickt und anschließend durch das Fahrzeug umgesetzt. Nach Empfang der Aufforderung werden das mindestens eine Stellglied, Fahrzeug modul und/oder Fahrzeugsteuergerät entsprechend geändert, eingestellt, an- oder abgeschaltet, bzw. der mindestens eine Fahrzeugparameter wird ent sprechend geändert. Über eine Rückmeldung vom Fahrzeug oder einem Be nutzer kann erkannt werden, dass der erste Fahrzeugfehlerzustand herbeige führt wurde. Das Verfahren kann somit den Schritt enthalten: Empfangen ei ner Bestätigung, dass sich das Fahrzeug im ersten Fahrzeugfehlerzustand be findet.
Das Verfahren kann den zusätzlichen Schritt umfassen: Ermitteln einer Rele vanz des jeweiligen Fehlercodes.
Wahlweise kann die Relevanz des jeweiligen Fehlercodes anhand einer durch schnittlichen Zeitspanne zwischen Auslösen und Löschen von gleichen histori schen Fehlercodes bestimmt werden. Das Löschen des Fehlers erfolgt in der Regel in der Werkstatt manuell durch den Mechaniker nach der Reparatur des Fahrzeuges oder Behebung des Fehlers. Die durchschnittliche Zeitspanne kann z.B. in der genannten Datenbank hinterlegt sein und kann z.B. auf Erfah- rungswerten oder protokollierten Daten basiert sein. Falls ein Fehlercode im Schnitt lange gesetzt bleibt, bevor der Fehler gelöscht wird, kann dies ein Hinweis dafür sein, dass der Fahrzeugbetrieb durch den Fehler nicht erheblich gestört wird und kein gravierender Fehler vorliegt. Falls umgekehrt die Zeit spanne zwischen Auslösen des Fehlers und Löschen des Fehlers im Schnitt kurz ist, kann dies ein Hinweis sein, dass der störungsfreie Fahrzeugbetrieb nur durch schnelle Behebung des Fehlers gewährleistet ist, durch den auftre tenden Fehler nur eingeschränkt möglich oder unter Umständen sogar ausge schlossen ist. Es kann somit vorgesehen sein, dass die Relevanz vergleichs weise hoch ist, wenn die durchschnittliche Zeitspanne einen vorbestimmten Wert unterschreitet. Die Relevanz kann vergleichsweise gering sein, wenn die durchschnittliche Zeitspanne einen vorbestimmten Wert überschreitet.
Alternativ oder zusätzlich können die Fehlercodes durch Vergleich mit histori schen Fehlercodes aus der Datenbank nach Fahrzeugbaugruppen und/oder Kundengruppen und/oder korrelierenden historischen Fehlercodes klassifi ziert werden. Korrelierende Fehlercodes können hierbei Fehlercodes sein, die bei Auftreten des Fehlercodes im Schnitt vermehrt auftreten. Wenn der Fehlercode einer bestimmten Fahrzeugbaugruppe zugeordnet ist, dann kön nen die korrelierenden Fehlercodes ebenfalls dieser Fahrzeugbaugruppe zu geordnet werden. Anschließend kann die Relevanz des jeweiligen Fehlercodes anhand der Klassifikation des Fehlercodes ermittelt werden.
In einem weiteren Schritt können die Fehlercodes nach Relevanz sortiert und/oder ausgewertet werden. Die Relevanz kann hierbei durch eine Zahl ausgedrückt werden, z.B. entweder 0 (nicht-relevant) oder 1 (relevant) oder eine Zahl zwischen 0 und 1. Die Ermittlung des ersten Fahrzeugfehlerzustan des, der zu messenden relevanten Sensormessgrößen und/oder des mindes tens einen potenziell defekten Bauteils kann basierend auf der Relevanz der Fehlercodes erfolgen.
Durch das Verbinden eines Diagnosegeräts mit einer im Fahrzeug vorgesehe nen Diagnoseschnittstelle kann das Diagnosegerät Informationen über den aktuellen Zustand des Fahrzeuges und die vorliegenden Fehler bekommen. Weiter ist in der Regel eine Benutzerschnittstelle wie eine Anzeige mit einer Benutzeroberfläche im Diagnosegerät vorhanden, über die zusätzliche Infor- mationen vom Benutzer abgefragt oder eingegeben werden können.
Für das Ermitteln des mindestens einen potentiell defekten Bauteils können zusätzlich historische Logging-Daten von Diagnosegeräten berücksichtigt wer den, die insbesondere in der Datenbank hinterlegt sein können. Als Logging bezeichnet man üblicherweise die Erstellung eines Protokolls eines Diagno seprozesses, wobei die Erstellung in der Regel automatisch erfolgt. Vorzugs weise umfassen die historischen Logging-Daten aufgerufene Reparaturinfor mationen und/oder aufgerufene Fahrzeugbauteilinformationen, die z.B. wäh rend früherer (historischer) Fahrzeugdiagnosen aufgerufen wurden. Falls also nach Auslesen/Empfangen eines bestimmten Fehlercodes oft oder immer bestimmte Reparaturinformationen und/oder Fahrzeugbauteilinformationen durch den Mechaniker aufgerufen werden, ist dies ein Indiz dafür, dass bei Auftreten dieses bestimmten Fehlercodes ein bestimmtes Bauteil defekt ist. Die Berücksichtigung der historischen Logging-Daten bei der Ermittlung des potentiell defekten Bauteils kann die automatische Fahrzeugdiagnose somit erheblich beschleunigen.
Durch Vergleich mit historischen Fahrzeugdaten kann für jede Sensormess größe ein Sollbereich ermittelt werden. Der Sollbereich umfasst hierbei vor zugsweise einen Sollmesswert und/oder einen Toleranzbereich um den Soll messwert. Messwerte, die innerhalb des Sollbereichs liegen, werden demnach als positiv bewertet, während Messwerte, die außerhalb des Sollbereichs lie gen, als negativ bewertet werden. In der Regel hängt der Sollbereich von mehreren fahrzeuginternen (z.B. Fahrzeugalter, Kilometerleistung) oder fahr zeugexternen Parametern (z.B. Außentemperatur) ab, die ebenfalls in der Datenbank gespeichert sein können. Weiter können für die Bestimmung des Sollbereichs korrelierende Sensormessgrößen und/oder zusammenhängende Sensormessgrößen berücksichtigt werden. Zusammenhängende Sensormess größen können zum Beispiel der gleichen Fahrzeugbaugruppe (etwa Motor, Klimaanlage, Bremssystem, Infotainmentsystem usw.) zugeordnet sein.
Das Verfahren kann weiter zumindest einen der folgenden Schritte aufweisen:
Vergleichen der gemessenen Sensormessgrößen mit den jeweiligen Sollbereichen zum Erkennen von Ausreißern in den Sensormess größen und Darstellen des Vergleichs an einer Benutzerschnittstelle.
Die Benutzerschnittstelle kann insbesondere eine Anzeige oder die oben ge nannte Benutzerschnittstelle am Fahrzeugdiagnosegerät sein.
Das Verfahren kann mindestens einen der folgenden Schritte enthalten:
Empfangen mindestens eines Fahrzeugidentifikationsmittels, wo bei das Fahrzeugidentifikationsmittel insbesondere eine Fahrzeu gidentifizierungsnummer und/oder einen Motorcode und/oder ei ne Steuergerätidentifizierungsnummer und/oder Kurzbezeichnung umfasst,
Vergleichen des Fahrzeugidentifikationsmittels mit bekannten Fahrzeugidentifikationsmitteln aus der Datenbank und Erkennen des zu diagnostizierenden Fahrzeuges durch den Ver gleich, vorzugsweise fahrzeugherstellerübergreifend und vom Fahrzeughersteller unabhängig.
Das Fahrzeugidentifikationsmittel gibt beispielsweise den Fahrzeughersteller und/oder einen Fahrzeugtyp des Fahrzeugs und darüber hinaus gegebenen falls Ausstattungsmerkmale des Fahrzeugs wie die Motorvariante oder Ein spritzsystem an. Das Fahrzeugidentifikationsmittel kann beispielsweise eine fahrzeugindividuelle Nummer umfassen, etwa eine Fahrzeugidentifizierungs nummer (nachstehend: FIN, englisch: Vehicle Identification Number, VIN), mit welcher ein Fahrzeug eindeutig identifizierbar sein kann. Mit Hilfe des Fahr zeugidentifikationsmittels können Informationen zu dem Fahrzeug oder zu vergleichbaren Fahrzeugen aus der Datenbank auf einfache Art und Weise ermittelt werden. Es hat sich herausgestellt, dass die FIN nicht immer aus reicht, um die Identität des Fahrzeuges eindeutig festzustellen. In diesem Fall kann mindestens ein weiteres Fahrzeugidentifikationsmittel verwendet wer den, beispielsweise ein Motorcode und/oder eine Steuergerätidentifizie rungsnummer und/oder eine Kurzbezeichnung des Fahrzeuges. Die Kurzbe zeichnung des Fahrzeuges kann in einem Steuergerät des Fahrzeuges hinter legt sein und kann eine Auskunft über Hersteller, Typ und/oder Ausstattung des Fahrzeuges geben.
Durch Kombination von mindestens zwei Fahrzeugidentifikationsmitteln kann auf die Identität des Fahrzeuges geschlossen werden und das Fahrzeug (Her steller, Typ und/oder Ausstattung) erkannt werden. Alternativ kann die Identi tät des Fahrzeuges über eine Erkennung eines Musters im Fahrzeugidentifika tionsmittel und Abgleich mit gleichen oder ähnlichen Mustern der Datenbank festgestellt werden.
Der Schritt des Empfange ns des Fahrzeugidentifikationsmittels kann z.B. bein halten, dass das Fahrzeugidentifikationsmittel durch das Fahrzeug übermittelt wird oder durch einen Benutzer eingegeben wird. Gegebenenfalls kann das Fahrzeugidentifikationsmittel nach einer Aufforderung übermittelt oder ein gegeben werden.
In einer weiteren Ausgestaltung kann das Verfahren den folgenden Schritt umfassen: Ermitteln von kontextbezogenen Reparaturinformationen auf Basis der Fehlercodes und/oder den Sensormessgrößen und/oder den potentiell defekten Bauteilen. Kontextbezogene Reparaturinformationen sind etwa Schaltpläne, Arbeitswerte oder Bauteilprüfwerte, die der Benutzer für die Re paratur des Fahrzeuges bzw. die Behebung des Fehlers benötigt. Die kontext bezogenen Reparaturinformationen können durch Abgleich mit den histori schen Logging-Daten ermittelt werden.
Gemäß einer Weiterbildung wird das mindestens eine potentiell defekte Bau teil zusätzlich auf Basis von Kundendienstdaten und/oder Rechnungsdaten auf Kfz-Werkstätten und/oder Zugriffen auf Reparaturinformationen in der Da tenbank ermittelt.
Optional werden die Fehlercodes anhand der gemessenen Sensormessgrößen ausgewertet. Mithilfe dieser Auswertung kann das mindestens eine potentiell defekte Bauteil ermittelt werden. Das mindestens eine potentiell defekte Bau teil kann dann anhand der Fehlercodes und der gemessenen Sensormessgrö ßen bestimmt werden.
Optional umfasst das Verfahren mindestens einen, mehrere oder sämtliche der nachfolgenden Schritte:
Erstellen und/oder Darstellen einer Liste mit potentiell defekten Bau- teilen,
Erstellen und/oder Darstellen von kontextbezogenen Bauteilinformati onen,
Ermitteln und/oder Darstellen von notwendigen Reparaturschritten.
In einem weiteren Schritt können die Diagnoseergebnisse auf der Anzeigevor richtung angezeigt werden, wobei die Anzeigevorrichtung vorzugsweise Be standteil eines Diagnosegeräts bzw. der oben genannten Benutzerschnittstelle ist.
Das vorstehend beschriebene automatische Verfahren kann die Bedienung des Diagnosegeräts beschleunigen und vereinfachen. Insbesondere wird kein umfangreiches Wissen über das Diagnosegerät mehr vorausgesetzt. Der Nut zer muss sich nicht weiter mit ca. 75 „Klicks" durch ca. 10 oder mehr Oberflä chen/Rubriken navigieren. Mit dem vorgeschlagenen Verfahren ist außerdem kein umfangreiches Kfz-Wissen mehr notwendig, um die Kombination der angezeigten Fehlercodes und die ausgelesenen Sensormesswerte zu interpre tieren (z.B. Motordrehzahl in Verbindung mit Einspritzmenge und Fahrpedal stellung). Die automatische, datengetriebene Identifikation von potentiell betroffenen Bauteilen (anhand von Fehlercodes und Sensormesswerten bzw. Parameterwerten) ist genauer als die bisherige Auflistung von möglicherweise betroffenen Bauteilen pro einzelnen Fehlercode.
Das oben genannte Verfahren kann insbesondere durch ein Fahrzeugdiagno segerät, einen Server und/oder ein System umfassend ein Fahrzeugdiagnose gerät und einen Server durchgeführt werden. Das Fahrzeugdiagnosegerät, der Server oder das System können zum Kommunizieren mit dem Fahrzeug vor zugsweise über eine Fahrzeugdiagnoseschnittstelle mit dem Fahrzeug ver bunden werden, z.B. direkt oder indirekt verbunden.
Des Weiteren wird mit der Erfindung eine Diagnosevorrichtung bereitgestellt, die darauf ausgerichtet ist, das vorstehende Verfahren durchzuführen. Die Diagnosevorrichtung ist ausgestaltet, zumindest folgende Schritte durchzu führen:
Empfangen einer Vielzahl von Fehlercodes eines Fahrzeuges, Ermitteln zumindest eines ersten Fahrzeugfehlerzustandes, wobei der Fahrzeugfehlerzustand einen Zustand des Fahrzeuges darstellt, in dem zumindest einer der Fehlercodes im Fahrzeug ausgelöst wurde, basierend auf dem jeweiligen Fehlercode und historischen Fahrzeugdaten aus einer Datenbank,
Ermitteln von zu messenden relevanten Sensormessgrößen basie rend auf den Fehlercodes,
Auffordern zum Herbeiführen zumindest des ersten Fahrzeug fehlerzustandes,
Empfangen der gemessenen Sensormessgrößen des Fahrzeuges, Ermitteln von mindestens einem potentiell defekten Bauteil.
Die Diagnosevorrichtung ist nicht Bestandteil des Fahrzeuges und kann z.B. außerhalb des Fahrzeuges oder in einem Fahrzeuginnenraum, vorzugsweise vorübergehend während der Dauer der Diagnose, angeordnet sein. Die Diag nosevorrichtung kann ein Fahrzeugdiagnosegerät und/oder ein mobiles Gerät und/oder einen Server umfassen oder ein Fahrzeugdiagnosegerät oder ein Server sein. Die Diagnosevorrichtung kann ein System oder Teil eines Systems sein, welches ein Fahrzeugdiagnosegerät und einen Server umfasst.
Die Diagnosevorrichtung kann eine Kommunikationsverbindung mit dem Fahrzeug, insbesondere den fahrzeugseitigen Steuergeräten aufbauen. Hierzu kann die Vorrichtung zum Empfangen und/oder Senden von Daten eine Kommunikationseinrichtung aufweisen. Weiter umfasst die Diagnosevorrich tung typischerweise eine Steuereinheit, z.B. zum Verarbeiten von Daten und/oder Steuern von weiteren Einheiten. Die Datenbank kann Bestandteil der Diagnosevorrichtung sein. Alternativ kann die Datenbank auch außerhalb der Diagnosevorrichtung vorgesehen sein, z.B. Bestandteil eines externen Ser vers.
Es sei an dieser Stelle betont, dass Merkmale, die nur in Bezug auf das Verfah ren genannt wurden, auch für die genannte Diagnosevorrichtung beansprucht werden können und umgekehrt. Es versteht sich, dass die oben beschriebe nen Ausführungsformen miteinander kombiniert werden können, sofern sich die Kombinationen nicht gegenseitig ausschließen. Im Folgenden werden Ausführungsformen der Erfindung anhand beigefügter Zeichnungen näher erläutert. Hierbei sind die Figuren schematisiert und teil weise vereinfacht. Gezeigt werden:
Fig. 1 eine schematische Darstellung eines mit einem Fahrzeug verbundenen Fahrzeugdiagnosegeräts;
Fig. 2 eine schematische Darstellung eines Systems zum Durchführen einer Fahrzeugdiagnose;
Fig. 3 eine schematische Darstellung eines Kommunikationsablaufs zwischen einem Fahrzeug und einem Fahrzeugdiagnosegerät und
Fig. 4 eine schematische Darstellung eines weiteren Kommunikationsablaufs zwischen einem Fahrzeug und einem System.
In den Figuren sind wiederkehrende Merkmale mit denselben Bezugszeichen versehen.
Mit der Erfindung wird ein Verfahren zum Durchführen einer Diagnose eines Fahrzeuges 10 bereitgestellt. Das Verfahren wird vorzugsweise mittels eines in Figuren 1 und 3 angedeuteten Fahrzeugdiagnosegeräts 20 oder eines in Figu ren 2 und 4 angedeuteten Systems 40 durchgeführt, wobei das System im Ausführungsbeispiel der Fign. 2 und 4 ein Fahrzeugdiagnosegerät 20 und ei nen Server 30 umfasst.
Die Fig. 1 zeigt ein Fahrzeug 10, das eine Vielzahl von Steuergeräten 11, 12 aufweist, z.B. mindestens 10 oder mehr. Wie in der Fig. 1 angedeutet, können die Steuergeräte 11, 12 miteinander z.B. über ein CAN-Bussystem verbunden sein. Außerdem ist mindestens ein Steuergerät 11 mit einer Fahrzeugdiagno seschnittstelle 13 verbunden. Weiter zeigt die Fig. 1 ein Fahrzeugdiagnosege rät 20, das typischerweise eine Steuer- und Verarbeitungseinheit, eine Kom munikationseinheit, einen Speicher sowie eine Eingabe- und Ausgabeeinheit für eine Kommunikation mit einem Benutzer wie einem Kfz-Mechaniker um fasst. Üblicherweise kann das Fahrzeugdiagnosegerät 20 mittels Signalleitun gen (also drahtgebunden) an die Fahrzeugdiagnoseschnittstelle 13 des Fahr- zeuges 10 angeschlossen werden. Das Fahrzeugdiagnosegerät 20 weist typi scherweise einen Stecker auf, der mit der Fahrzeugdiagnoseschnittstelle 13 kompatibel ist. Beim Verbinden des Steckers mit der Fahrzeugdiagnose schnittstelle 13 werden beide elektrisch miteinander verbunden. In manchen Fällen ist alternativ oder zusätzlich eine drahtlose Kommunikationsverbindung des Fahrzeugdiagnosegeräts 20 mit dem Fahrzeug 10 und den Steuergeräten 11, 12 möglich.
Die Steuergeräte 11, 12 sind üblicherweise jeweils mit einer Vielzahl von Sen soren verbunden, die während des Betriebs des Fahrzeuges 10 Messwerte erfassen. Denkbare Sensormessgrößen umfassen beispielsweise eine Kühlmit teltemperatur, eine Motortemperatur, eine Fahrzeuggeschwindigkeit, eine Motordrehzahl, ein Motordrehmoment, eine Umgebungstemperatur, einen Umgebungsluftdruck, einen Ladedruck eines Abgasturboladers des An triebsmotors, einen eingelegten Gang eines Getriebes des Fahrzeugs 10 usw.. Falls ein durch einen Sensor gemessener Messwert einen bestimmten Soll wertbereich unter- oder überschreitet, erzeugt das entsprechende Steuerge rät 11, 12 einen Fehlercode. Der Fehlercode ist einem Fehlerzustand zugeord net und beinhaltet beispielsweise eine Kennziffer zur Identifikation von Fehl funktionen, die während des Betriebs eines Fahrzeugs auftreten können. Der Fehlercode wird auch als Diagnosefehlercode oder Diagnostic Trouble Code (DTCj bezeichnet.
Ziel der Fahrzeugdiagnose ist es, feststellen zu können, welches Bauteil im Fahrzeug 10 defekt ist und wie dieses Bauteil repariert werden kann. Um fest stellen zu können, welches Bauteil des Fahrzeuges defekt ist, wertet das Fahr zeugdiagnosegerät 20 (oder der Server 30, s. unten) die Fehlercodes aus, wel che im laufenden Betrieb des Fahrzeuges 10 über eine Auswertung der Sen sormesswerte durch das mindestens eine Fahrzeugsteuergerät 11, 12 erzeugt werden und in einem fahrzeugseitigen Speicher gespeichert werden.
Nach einer entsprechenden Aufforderung sind die Fa h rze ugste ue rge räte 11, 12 dazu ausgestaltet, die im Fahrzeug 10 gespeicherten Fehlercodes auszule sen und an das Diagnosegerät 20 (bzw. den Server 30) zu übermitteln. Das Fahrzeugdiagnosegerät 20 kann also direkt mit dem jeweiligen Fahrzeugsteu ergerät 11, 12 kommunizieren, um die benötigten Fehlercodes vom Fahrzeug- Steuergerät 11, 12 zu erlangen. Hiernach können die Fehlercodes durch das Fahrzeugdiagnosegerät 20 analysiert werden, um zu diagnostizieren, ob und welche Fahrzeugkomponenten repariert oder ersetzt werden müssen, um das Problem zu beheben. Somit kann mittels einer Auswertung der Fehlercodes (Fahrzeugdiagnose) eine Aussage darüber getroffen werden, welche Fahr zeugkomponenten defekt sind und eine Reparatur benötigen.
Statt auf einzelne Komponenten 11, 12, 13 des Fahrzeuges 10 oder des Diag nosegeräts 20 wird nachstehend der Einfachheit halber auf das Fahrzeug 10 sowie das Fahrzeugdiagnosegerät 20 Bezug genommen.
Die Fig. 3 zeigt schematisch einen bevorzugten Kommunikationsablauf zwi schen dem Fahrzeug 10 und dem Fahrzeugdiagnosegerät 20. Hierbei sind die Sende- und Empfangsschritte jeweils in einem Pfeil mit einem Bezugszeichen zusammengefasst.
Nach dem Verbinden des Steckers des Diagnosegeräts 20 mit der Fahrzeugdi agnoseschnittstelle 13 wird eine Kommunikationsverbindung zwischen dem Fahrzeugdiagnosegerät 20 und dem Fahrzeug 10 aufgebaut (S10).
Üblicherweise wird eine Identifikation des Fahrzeugs benötigt, damit das Fahrzeugdiagnosegerät 20 die Fehlercodes einem bestimmten Fahrzeug 10, insbesondere Hersteller, Typ und Ausstattung des Fahrzeuges 10, zuordnen kann. Daher schickt (Sil) das Fahrzeugdiagnosegerät 20 eine Anfrage zum Identifizieren des Fahrzeuges 10 an das Fahrzeug. Daraufhin sendet (S12) das Fahrzeug 10 mindestens ein Fahrzeugidentifikationsmittel des Fahrzeuges 10, das in einem fahrzeugseitigen Speicher gespeichert sein kann, 1 zum Fahr zeugdiagnosegerät 12. In alternativen Ausführungsformen werden Hersteller, Typ und/oder Ausstattung des Fahrzeuges 10 oder das Fahrzeugidentifikati onsmittel manuell durch einen Techniker oder Fahrzeugmechaniker am Fahr zeugdiagnosegerät 12 eingegeben.
Hiernach kann das Fahrzeugdiagnosegerät 20 z.B. die Fehlercodes vom Fahr zeug 10 anfordern (S13). Daraufhin sendet das Fahrzeug 10 die angeforderten Fehlercodes zum Fahrzeugdiagnosegerät 20 und das Fahrzeugdiagnosegerät 20 empfängt (S14) die Fahrzeugfehlercodes. Nach Empfang können die Fehlercodes durch das Fahrzeugdiagnosegerät 12 analysiert bzw. ausgewertet werden.
Für eine genauere Diagnose kann das Fahrzeugdiagnosegerät 20 zusätzlich aktuell gemessene Sensormesswerte oder im Fahrzeug gespeicherte Sensor messwerte vom Fahrzeug 10 anfordern. Dies geschieht z.B. über eine entspre chende Anforderung (S15). Das Fahrzeugsteuergerät 11, 12 ruft die angefor derten Sensormesswerte z.B. aus einem fahrzeugseitigen Speicher ab oder spricht entsprechende Fahrzeugsensoren zur Herausgabe oder zum Erfassen der Sensormesswerte an. Die Sensormesswerte werden dann vom Fahrzeug steuergerät 11, 12 zum Fahrzeugdiagnosegerät 20 zur weiteren Auswertung oder Bearbeitung geschickt (S16). Basierend auf den Fehlercodes und den Sensormesswerten kann das Fahrzeugdiagnosegerät 20 feststellen, welches Bauteil im Fahrzeug defekt ist und eine Reparatur benötigt.
An dieser Stelle sei angemerkt, dass bestimmte Sende- und Empfangsschritte zusammengefasst werden können. So können z.B. die Schritte Sil und S13, S12 und S14 jeweils zusammengefasst werden.
Weiter kann das Fahrzeugdiagnosegerät 20 Befehle an das Fahrzeugsteuerge rät 11, 12 schicken. Z.B. umfasst ein Befehl an das Fahrzeugsteuergerät eine Einstellung des Sensors oder eine Änderung der Einstellung des Sensors, wo bei die Einstellung z.B. eine Empfindlichkeit des Sensors, eine Häufigkeit der Messungen und/oder einen zeitlichen Ablauf der Messungen einschließt.
Zusätzlich oder alternativ kann der Status des Fahrzeugsteuergeräts 11, 12 durch das Fahrzeugdiagnosegerät 20 über eine entsprechende Nachricht ge ändert oder gesetzt werden. Denkbar wäre in diesem Zusammenhang etwa. Inspektionsintervall, Ansteuerung von Stellgliedern oder dergleichen. Der Ab lauf der Fahrzeugdiagnose wird weiter unten beschrieben.
Die Fahrzeugdiagnose kann alternativ auch mit dem in Fig. 2 gezeigten System 40 durchgeführt werden. Das System 40 umfasst das zuvor beschriebene Fahrzeugdiagnosegerät 20 und einen Server 30. Das Fahrzeugdiagnosegerät 20 ist, wie oben erläutert, vorzugsweise über die Fahrzeugschnittstelle 13 mit dem Fahrzeug 10 verbunden. Das Fahrzeugdiagnosegerät 20 ist außerdem drahtlos oder drahtgebunden mit einem externen Server 30 verbunden. Hier durch ist eine Kommunikation zwischen dem Server 30 und dem Diagnosege rät 20 möglich. Nachfolgend wird auf die Kommunikation zwischen dem Fahr zeug 10, dem Diagnosegerät 20 und dem Server 30 eingegangen.
Zunächst wird eine Kommunikationsverbindung zwischen dem Diagnosegerät 20 und dem Fahrzeug 10 aufgebaut (S10). Danach (oder davor oder gleichzei tig) wird eine Kommunikationsverbindung zwischen dem Diagnosegerät 20 und dem Server 30 aufgebaut (S20). Jetzt ist das Diagnosegerät 20 in der Lage, eine Kommunikation zwischen dem Server 30 und dem Fahrzeug 10 zu vermit teln. So kann das Diagnosegerät 20 Daten oder Nachrichten zwischen dem Fahrzeug 10 und dem Server 30 vermitteln.
Üblicherweise wird eine Identifikation des Fahrzeugs 10 benötigt, damit der Server 30 die Fehlercodes einem bestimmten Hersteller und Fahrzeugtyp zu ordnen kann. Daher schickt (S21) der Server 30 eine Anfrage zum Identifizie ren des Fahrzeuges 10 an das Diagnosegerät 20, welcher die Anfrage an das Fahrzeug 10 weiterleitet (Sil). Daraufhin sendet (S12) das Fahrzeug 10 min destens ein Identifikationsmittel des Fahrzeuges 10, welches in einem fahr zeugseitigen Speicher gespeichert sein kann, über das Diagnosegerät 20 zum Server 30 (S22).
Hiernach kann der Server 30 z.B. Fehlercodes vom Fahrzeug 10 anfordern. Das Diagnosegerät 20 leitet z.B. die Anforderung vom Server 30 weiter zum Fahr zeugsteuergerät 10 (S23, S13). Hieraufhin sendet (S14) das Fahrzeug 10 die angeforderten Fehlercodes zum Diagnosegerät 20, das die Fehlercodes an den Server 30 schickt (S24). Nach Empfang können die Fehlercodes durch den Ser ver 30 analysiert bzw. ausgewertet werden.
Für eine genauere Diagnose kann der Server 30 zusätzlich Sensormesswerte vom Fahrzeug 10 anfordern. Dies geschieht z.B. über eine Anforderung, die vom Diagnosegerät 20 an das Fahrzeug 10 weitergeleitet wird (S25, S15). Das Fahrzeug 10 ruft die angeforderten Sensormesswerte aus dem fahrzeugseiti gen Speicher ab oder spricht entsprechende Fahrzeugsensoren zur Herausga be oder zum Erfassen der Sensormesswerte an. Die Sensormesswerte werden dann vom Fahrzeug 10 zum Diagnosegerät 20 geschickt (S16) und vom Diag- nosegerät 20 zum Server 30 zur weiteren Auswertung oder Bearbeitung ge schickt (S26). Basierend auf den Fehlercodes, dem Identifikationsmittel und den Sensormesswerten kann der Server 30 feststellen, welches Bauteil im Fahrzeug 10 defekt ist und eine Reparatur benötigt.
An dieser Stelle sei angemerkt, dass bestimmte Sende- und Empfangsschritte zusammengefasst werden können. So können z.B. die Schritte S21 und S23, Sil und S13, S12 und S14, und S22 und S24 jeweils zusammengefasst werden.
Weiter kann der Server 30 über das Diagnosegerät 20 Befehle an das Fahrzeug 10 schicken. Z.B. umfasst ein Befehl an das Fahrzeug eine Einstellung des Sen sors oder eine Änderung der Einstellung des Sensors, wobei die Einstellung z.B. eine Empfindlichkeit des Sensors, eine Häufigkeit der Messungen und/oder einen zeitlichen Ablauf der Messungen einschließt.
Zusätzlich oder alternativ kann der Status des Fahrzeugs 10 durch den Server 30 über eine entsprechende Nachricht geändert oder gesetzt werden. Denk bar wäre in diesem Zusammenhang z.B. Inspektionsintervall, Ansteuerung von Stellgliedern oder dergleichen.
Das Fahrzeug 10 kann auch neue Softwarekomponenten oder Updates be kommen, die der Server 30 über das Diagnosegerät 20 zum Fahrzeug 10 schickt.
Es versteht sich, dass die in den Figuren 1 und 2 bzw. 3 und 4 dargestellten und oben beschriebenen Merkmale bzw. Schritte miteinander kombiniert werden können, sofern sich die Kombinationen nicht gegenseitig ausschlie ßen. Merkmale bzw. Schritte, die nur in Bezug auf das Diagnosegerät 20 ge nannt wurden, können auch für den Server 30 und das System 40 beansprucht werden und umgekehrt.
Im System 40 kann statt des gezeigten Fahrzeugdiagnosegeräts 20 alternativ ein mobiles Gerät wie ein mobiles Telefon, Laptop, Computer, Tablet-PC oder dergleichen, vorgesehen sein, das einerseits mit dem Fahrzeug 10, insbeson dere über die Fahrzeugschnittstelle 13, und andererseits mit dem Server 30 verbunden ist, und welches die Kommunikation zwischen dem Fahrzeug 10 und dem Server 30 vermittelt. Das mobile Gerät leitet also vorzugsweise Nachrichten wie Befehle und/oder Anfragen oder Daten wie Messwerte und/oder DTCs vom Fahrzeug 10 zum Server 30 weiter und umgekehrt.
Nachstehend wird näher auf die eigentliche Fahrzeugdiagnose eingegangen, die insbesondere durch das Fahrzeugdiagnosegerät 20, den Server 30 oder das System 40 durchgeführt werden kann.
Zunächst erfolgt typischerweise eine automatisierte Fahrzeugerkennung. Für die Fahrzeugerkennung wird mindestens das bereits oben erwähnte Fahrzeugidentifikationsmittel verwendet, das insbesondere eine Fahrzeu gidentifizierungsnummer (FIN) und/oder einen Motorcode und/oder eine Steuergerätidentifizierungsnummer und/oder eine Kurzbezeichnung umfas sen kann. Das Fahrzeugidentifikationsmittel wird mit bekannten Fahrzeugmit teln aus der Datenbank verglichen, um das Fahrzeug 10 zu identifizieren. In manchen Fällen reicht die FIN nicht aus, um das Fahrzeug 10 zweifelsfrei zu identifizieren. In diesen Fällen werden auf Basis von manuell ausgewählten Fahrzeugen mit vorhandener FIN in der Datenbank Muster extrahiert, die auch für unbekannte FINs verwendet werden können. Durch die Einbeziehung des Motorcodes und der Kurzbezeichnung können herstellerübergreifend Fahrzeuge identifiziert werden, bei denen die FIN alleine nicht ausreicht.
Danach erfolgt folgender Schritt:
Empfangen S14, S24 einer Vielzahl von Fehlercodes des Fahrzeuges 10.
Das Verfahren weist weiter folgende Schritte auf:
Ermitteln zumindest eines ersten Fahrzeugfehlerzustandes, wobei der Fahrzeugfehlerzustand einen Zustand des Fahrzeuges 10 dar stellt, in dem zumindest einer der Fehlercodes im Fahrzeug 10 aus gelöst wurde, basierend auf dem jeweiligen Fehlercode und histo rischen Fahrzeugdaten aus einer Datenbank außerhalb des Fahr zeuges 10,
Ermitteln von zu messenden relevanten Sensormessgrößen basie- rend auf den Fehlercodes,
Auffordern zum Herbeiführen zumindest des ersten Fahrzeug fehlerzustandes, vorzugsweise durch Anzeigen einer Anforderung auf einer Anzeige des Diagnosegeräts 20, und Empfangen S16, S26 der gemessenen Sensormessgrößen des Fahr zeuges 10.
Somit wird ein Fahrzeugzustand ermittelt, den der Mechaniker und/oder das Fahrzeug 10 herbeiführen soll, um qualitativ gute Sensormesswerte messen zu können (z.B. Drehzahlerhöhung im Leerlauf, Probefahrt, Klimaanlage akti vieren). Hierzu wird vorzugsweise auf die historischen Fahrzeugdaten der Da tenbank zurückgegriffen, wobei die Datenbank in einem Speichermedium hin terlegt ist, das beispielsweise Bestandteil des Diagnosegeräts 20, des Servers 30 oder eines weiteren Servers ist. Die historischen Fahrzeugdaten umfassen zumindest Fahrzeughersteller, Fahrzeugtyp, Fahrzeugausstattung, Fehler codes, Kilometerstand, Fahrzeugalter, Sensormesswerte und/oder Sen sormessgrößen.
Typischerweise wird auf Basis der historischen Daten geprüft, wie der Fahr zeugzustand bei dem Fehlercode bisher war (z.B. anhand der Geschwindigkeit oder Motordrehzahl) oder ob ein Aktortest/Stellgliedtest von Bauteilen durchgeführt wurde (z.B. Gebläse oder Klimaanlage aktiviert). Weiter kann zum Beispiel auf Basis historischer Daten geprüft werden, welche Sen sormessgrößen (Sensorparameter) vermehrt durch Nutzer ausgewählt wer den, wenn ein entsprechender Fehlercode vorhanden ist. Durch das Herbei führen des ersten Fahrzeugfehlerzustandes können daher relevante Messwer te erfasst werden, die anschließend für die Diagnose verwendet werden kön nen.
Der Fahrzeugzustand kann z.B. durch Ändern oder Einstellen mindestens eines Stellglieds, Ändern oder Einstellen mindestens eines Fahrzeugparameters, An oder Abschalten mindestens eines Fahrzeugmoduls und/oder An- oder Ab schalten mindestens eines Fahrzeugsteuergeräts herbeigeführt werden. Nachdem das Fahrzeug in den Fahrzeugfehlerzustand versetzt wurde, kann eine entsprechende Bestätigung an das Fahrzeugdiagnosegerät 20 oder den Server 30 geschickt werden. Bei Bedarf können je nach Fehlercode sukzessiv mehrere Fahrzeugfehlerzu stände herbeigeführt werden, in denen jeweils relevante zu messende Sen sormessgrößen gemessen werden.
Um die Genauigkeit zu erhöhen, kann eine Relevanz des jeweiligen Fehler codes ermittelt werden. Die Fehlercodes werden dann nach Relevanz sortiert und gewichtet. Beispielsweise werden lediglich die relevantesten Fehlercodes für die Diagnose berücksichtigt. Weniger relevante Fehlercodes können unbe rücksichtigt bleiben. Falls zum Beispiel eine durchschnittliche Zeitspanne zwi schen Auslösen und Löschen des Fehlercodes eine vorbestimmte zeitliche Dauer überschreitet, kann der Fehler als nicht-relevant eingestuft werden. Andererseits kann der Fehlercode als relevant eingestuft werden, wenn die durchschnittliche Zeitspanne zwischen Auslösen und Löschen des Fehlercodes eine vorbestimmte zeitliche Dauer unterschreitet.
Alternativ oder zusätzlich können die Fehlercodes durch Vergleich mit histori schen Fehlercodes aus der Datenbank nach Fahrzeugbaugruppen und/oder Kundengruppen und/oder korrelierenden historischen Fehlercodes klassifi ziert werden. Korrelierende Fehlercodes sind hierbei Fehlercodes, die bei Auf treten des Fehlercodes im Schnitt vermehrt auftreten. Wenn der Fehlercode einer bestimmten Fahrzeugbaugruppe zugeordnet ist, dann können die korre lierenden Fehlercodes ebenfalls dieser Fahrzeugbaugruppe zugeordnet wer den. Anschließend kann die Relevanz des jeweiligen Fehlercodes anhand der Klassifikation des Fehlercodes ermittelt werden.
Außerdem umfasst das Verfahren den folgenden Schritt:
Ermitteln von mindestens einem potentiell defekten Bauteil im Fahrzeug 10, insbesondere anhand der Fehlercodes, den gemesse nen Sensormesswerten und des Kilometerstandes des Fahrzeuges.
Vorzugsweise werden Aufrufe an technischen Informationen,, wie Reparatur informationen oder Fahrzeugbauteilinformationen durch den Mechaniker auf dem Diagnosegerät 20 in einem Protokoll gespeichert, was auch als Logging bezeichnet wird. Die Logging-Daten sind vorzugsweise ebenfalls in der Daten- bank hinterlegt. Die Logging-Daten können bei der Ermittlung des potenziell defekten Bauteils berücksichtigt werden.
Wenn ein Mechaniker beispielsweise einen Fehlercode oder Messwerte aus liest, erfolgt dann meistens auf Basis seines Kfz-Expertenwissens die Auswahl an relevanten Informationen am Diagnosegerät 20, die zur Reparatur not wendig sind. Oftmals stehen dem Mechaniker im Diagnosegerät 20 bis zu 18 verschiedene Rubriken mit weiteren Subrubriken zur Verfügung: z.B. Schalt pläne, Arbeitswerte oder Bauteilprüfwerte. Nach konventionellen Lösungen musste der Mechaniker in jeder Rubrik eine passende Auswahl treffen. Nach der Auswahl der Rubriken und der Anzeige des Contents werden die entspre chenden Rubriken (Pfad zum Content) in der Datenbank (z.B. auf dem Server 30 und/oder dem Diagnosegerät 20) gespeichert. Anhand der Rubriken und des Contents werden relevante Bauteile bzw. Bauteilformationen extrahiert, beispielsweise aus einem Speicher des Diagnosegeräts 20 oder der Daten bank.
Gemäß einer Weiterbildung wird das mindestens eine potentiell defekte Bau teil zusätzlich auf Basis von Kundendienstdaten und/oder Rechnungsdaten auf KfZ-Werkstätten und/oder Zugriffen auf Reparaturinformationen in der Da tenbank ermittelt.
In einer weiteren Variante kann das Verfahren den folgenden Schritt umfas sen: Ermitteln von kontextbezogenen Reparaturinformationen auf Basis der Fehlercodes und/oder den Sensormessgrößen und/oder den potentiell defek ten Bauteilen. Kontextbezogene Reparaturinformationen sind z.B. Schaltplä ne, Arbeitswerte oder Bauteilprüfwerte, die der Benutzer für die Reparatur des Fahrzeuges bzw. die Behebung des Fehlers benötigt. Die kontextbezoge nen Reparaturinformationen können mittels der historischen Logging-Daten ermittelt werden.
Zusätzlich kann die Relevanz der Fehlercodes ermittelt werden, z.B. auf Basis von gleichen historischen Fehlercodes. Wenn z.B. die Fehlercodes über einen längeren Zeitraum gesetzt bleiben, ist dies ein Indikator, dass der Fehlercode weniger relevant ist. Es können auch historische Fehlercodes von Kunden gruppen für die Einstufung der Relevanz genutzt werden, die sich auf die Re- paratur weniger kritischer Probleme fokussieren (z.B. „Glaser"). Wenn dort Fehlercodes außerhalb ihres Fokus ausgelesen werden (z.B. Fehlercodes, die basierend auf Motorsensormesswerten erzeugt wurden), dann ist dies eben falls ein Indikator dafür, dass der Fehlercode weniger relevant ist. Gegenstand des Kundenanliegens ist nämlich ein anderes Problem.
Auf Basis der historischen Fahrzeugdaten (relevanter Fehlercodes, Sensor messwerte und Kilometer-Stände) in Verbindung mit den extrahierten Bautei len können Vorhersage-Modelle entwickelt werden.
Weiter können Anomalien in den Sensormesswerten ermittelt werden. Ein selbstlernendes System (Diagnosegerät 20, Server 30 oder System 40) soll korrelierende Sensormesswerte und zusammenhängende Sensorsensormess größen identifizieren und daraus ein Hauptcluster (Mehrheit aller gesunden Messpunkte) bilden, auf dem Ausreißer-Modelle (Outlier-Modelle) trainiert werden können. Zur Identifizierung des Hauptclusters können zusätzlich Fehlercodes miteinbezogen werden. D.h. bei den Messwerten im Hauptclus ter sind vorzugsweise keine Fehlercodes oder eine Anzahl an Fehlercodes ge setzt, die eine vorbestimmte Grenze nicht überschreitet. Diese Modelle kön nen auf aktuelle Sensormessungen angewendet werden und eine Wahr scheinlichkeit berechnen, ob die Messung als Outlier/Anomalie einzustufen ist. Messwerte, die innerhalb eines Sollbereichs liegen, werden demnach als positiv bewertet, während Messwerte, die außerhalb des Sollbereichs liegen, als negativ bewertet werden. Für die Bestimmung des Sollbereichs können korrelierende und/oder zusammenhängende Sensormessgrößen berücksich tigt werden. Die gemessenen Sensormessgrößen können mit den jeweiligen Sollbereichen verglichen werden zum Erkennen von Ausreißern in den Sen sormessgrößen. Beispielsweise kann der Grad der Abweichung des Mess werts von dem Soll-Bereich angegeben werden, etwa durch Darstellung auf der Anzeige am Diagnosegerät 20. Diese Modelle ermöglichen eine Visualisie rung / Anzeige des aktuellen Messwertes mit einem Soll-Messwert inklusive dessen Toleranzbereichs (Soll-Bereich). Hierdurch wird die Nachvollziehbar keit der Ergebnisse ermöglicht und der Mechaniker kann besser einschätzen, wie die Ergebnisse zustande gekommen sind.
Optional weist das Verfahren mindestens einen der folgenden Schritte auf: Erstellen und Darstellen einer Liste mit potentiell defekten Bauteilen, Erstellen und Darstellen von kontextbezogenen Bauteilinformationen der defekten Bauteile und/oder - Ermitteln und Darstellen von notwendigen Reparaturschritten.
Es versteht sich, dass die in den Figuren dargestellten und oben beschriebe nen Ausführungsformen miteinander kombiniert werden können, sofern sich die Kombinationen nicht gegenseitig ausschließen. Merkmale, die nur in Be- zug auf das Fahrzeugdiagnosegerät 20 und/oder den Server 30 genannt wur den, können auch für das System 40 oder das Verfahren beansprucht werden und umgekehrt.
Bezugszeichenliste:
10 Fahrzeug
11 Fahrzeugsteuergerät
12 Fahrzeugsteuergerät
13 Diagnoseschnittstelle
20 Fahrzeugdiagnosegerät
30 Server
40 System

Claims

Patentansprüche
1. Verfahren zum Durchführen einer Fahrzeugdiagnose, umfassend die Schritte:
Empfangen (S14, S24) einer Vielzahl von Fehlercodes eines Fahr zeuges (10),
Ermitteln zumindest eines ersten Fahrzeugfehlerzustandes, wobei der Fahrzeugfehlerzustand einen Zustand des Fahrzeuges (10) dar stellt, in dem zumindest einer der Fehlercodes im Fahrzeug (10) ausgelöst wurde, basierend auf dem jeweiligen Fehlercode und his torischen Fahrzeugdaten aus einer Datenbank,
Ermitteln von zu messenden relevanten Sensormessgrößen basie rend auf den Fehlercodes,
Auffordern zum Herbeiführen zumindest des ersten Fahrzeug fehlerzustandes,
Empfangen (S16, S26) der gemessenen Sensormessgrößen des Fahrzeuges (10),
Ermitteln von mindestens einem potentiell defekten Bauteil.
2. Verfahren nach Anspruch 1, wobei die Aufforderung zum Herbeiführen des ersten Fahrzeugfehlerzustandes mindestens eine der nachstehen den Anweisungen enthält:
Ändern, Aktivieren oder Einstellen mindestens eines Stellglieds, Aktivieren einer Fahrzeugfunktion,
Ändern oder Einstellen mindestens eines Fahrzeugparameters, An- oder Abschalten mindestens eines Fahrzeugmoduls.
3. Verfahren nach einem der vorstehenden Ansprüche, mit dem zusätzli chen Schritt:
Ermitteln einer Relevanz des jeweiligen Fehlercodes, wobei die Relevanz des jeweiligen Fehlercodes anhand einer durchschnittlichen Zeitspanne zwischen Auslösen und Löschen von gleichen historischen Fehlercodes bestimmt wird und/oder wobei die Fehlercodes durch Vergleich mit historischen Fehler codes aus der Datenbank nach Fahrzeugbaugruppen und/oder Kun dengruppen und/oder korrelierenden historischen Fehlercodes klassi fiziert werden, und die Relevanz des jeweiligen Fehlercodes anhand der Klassifikation des Fehlercodes ermittelt wird.
4. Verfahren nach Anspruch 3, wobei die Relevanz vergleichsweise hoch ist, wenn die durchschnittliche Zeitspanne vergleichsweise klein ist, und wobei die Relevanz vergleichsweise gering ist, wenn die durch schnittliche Zeitspanne vergleichsweise groß ist.
5. Verfahren nach einem der vorstehenden Ansprüche, wobei für das Ermitteln des mindestens einen potentiell defekten Bauteils zusätzlich historische Logging-Daten von Diagnosegeräten berücksichtigt werden.
6. Verfahren nach Anspruch 5, wobei die historischen Logging-Daten auf gerufene Reparaturinformationen und/oder aufgerufene Fahrzeugbau teilinformationen umfassen.
7. Verfahren nach einem der vorstehenden Ansprüche, wobei durch Ver gleich mit historischen Fahrzeugdaten für jede Sensormessgröße ein Sollbereich ermittelt wird, wobei der Sollbereich vorzugsweise einen Sollmesswert und einen Toleranzbereich um den Sollmesswert um fasst.
8. Verfahren nach Anspruch 7, wobei für die Bestimmung des Sollbe reichs korrelierende Sensormessgrößen und/oder zusammenhängende Sensormessgrößen berücksichtigt werden.
9. Verfahren nach Anspruch 6 oder 7, mit den zusätzlichen Schritten:
Vergleichen der gemessenen Sensormessgrößen mit den jeweiligen Sollbereichen zum Erkennen von Ausreißern in den Sensormess größen und
Darstellen des Vergleichs an einer Be n utze rsch nittste Ile.
10. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch mindestens einen der folgenden Schritte:
Empfangen (S12, S22) mindestens eines Fahrzeugidentifikations mittels, wobei das Fahrzeugidentifikationsmittel insbesondere eine Fahrzeugidentifizierungsnummer und/oder einen Motorcode und/oder eine Steuergerätidentifizierungsnummer und/oder eine Kurzbezeichnung umfasst,
Vergleichen des Fahrzeugidentifikationsmittels mit bekannten Fahrzeugidentifikationsmitteln aus der Datenbank und fahrzeugherstellerunabhängiges Erkennen des zu diagnostizieren den Fahrzeuges (10) durch den Vergleich.
11. Verfahren nach einem der vorstehenden Ansprüche, wobei die histori schen Fahrzeugdaten Fahrzeugidentifikationsmittel, Fahrzeugherstel ler, Fahrzeugtyp, Fahrzeugausstattung, Fehlercodes, Kilometerstand, Fahrzeugalter, Sensormesswerte und/oder Sensormessgrößen umfas sen.
12. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch den zusätzlichen Schritt: Ermitteln von kontextbezogenen Repa raturinformationen auf Basis der Fehlercodes und/oder den Sen sormessgrößen und/oder den potentiell defekten Bauteilen.
13. Verfahren nach einem der vorstehenden Ansprüche, wobei das min destens eine potentiell defekte Bauteil zusätzlich auf Basis von Kun dendienstdaten und/oder Rechnungsdaten auf KfZ-Werkstätten und/oder Zugriffen auf Reparaturinformationen in der Datenbank er mittelt wird.
14. Verfahren nach einem der vorstehenden Ansprüche, wobei die Fehler codes anhand der gemessenen Sensormessgrößen ausgewertet wer den, wobei das mindestens eine potentiell defekte Bauteil anhand der Fehlercodes und der gemessenen Sensormessgrößen bestimmt wird.
15. Diagnosevorrichtung ausgestaltet zum Durchführen des Verfahrens gemäß einem der vorstehenden Ansprüche, wobei die Diagnosevor richtung insbesondere ein Fahrzeugdiagnosegerät (20) und/oder einen Server (30) umfasst.
EP21722886.5A 2020-05-07 2021-05-04 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose Pending EP4147210A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP20173583.4A EP3907707A1 (de) 2020-05-07 2020-05-07 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
PCT/EP2021/061617 WO2021224202A1 (de) 2020-05-07 2021-05-04 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose

Publications (1)

Publication Number Publication Date
EP4147210A1 true EP4147210A1 (de) 2023-03-15

Family

ID=70617041

Family Applications (2)

Application Number Title Priority Date Filing Date
EP20173583.4A Withdrawn EP3907707A1 (de) 2020-05-07 2020-05-07 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
EP21722886.5A Pending EP4147210A1 (de) 2020-05-07 2021-05-04 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP20173583.4A Withdrawn EP3907707A1 (de) 2020-05-07 2020-05-07 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose

Country Status (5)

Country Link
US (1) US20230252829A1 (de)
EP (2) EP3907707A1 (de)
AU (1) AU2021269012A1 (de)
CA (1) CA3181930A1 (de)
WO (1) WO2021224202A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021213965A1 (de) 2021-12-08 2023-06-15 Zf Friedrichshafen Ag Verfahren zur Fehlerdiagnose für ein Kraftfahrzeug
DE102021132801A1 (de) 2021-12-13 2023-06-15 Audi Aktiengesellschaft Verfahren und Prozessorschaltung zum Verifizieren einer Kilometerstandsangabe einer Kilometerstandsanzeigeeinheit eines Kraftfahrzeugs sowie zugehöriges System und zugehörige Servervorrichtung
CN115933619A (zh) * 2023-01-05 2023-04-07 中国第一汽车股份有限公司 一种远程诊断方法、系统、电子设备及存储介质
CN117434927B (zh) * 2023-12-20 2024-04-02 中汽研（天津）汽车工程研究院有限公司 一种检测电子控制器故障状态的云端诊断系统及装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100324376A1 (en) * 2006-06-30 2010-12-23 Spx Corporation Diagnostics Data Collection and Analysis Method and Apparatus
JP4720770B2 (ja) * 2007-04-02 2011-07-13 トヨタ自動車株式会社 車両用情報記録システム
US8924071B2 (en) * 2013-04-26 2014-12-30 Ford Global Technologies, Llc Online vehicle maintenance
DE102015214739B4 (de) * 2015-08-03 2022-12-29 Volkswagen Aktiengesellschaft Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug und Server zum Durchführen der Bestimmung der Fehlerursache
GB201710048D0 (en) * 2017-06-23 2017-08-09 Remote Asset Man Ltd Electrical connector

Also Published As

Publication number Publication date
AU2021269012A1 (en) 2023-01-19
CA3181930A1 (en) 2021-11-11
WO2021224202A1 (de) 2021-11-11
EP3907707A1 (de) 2021-11-10
US20230252829A1 (en) 2023-08-10

Similar Documents

Publication Publication Date Title
DE102015214739B4 (de) Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug und Server zum Durchführen der Bestimmung der Fehlerursache
WO2021224202A1 (de) Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
DE102014105674A1 (de) Online-fahrzeugwartung
DE4441101B4 (de) Verfahren und Vorrichtung zur Bestimmung von Diagnoseschwellwerten für einen bestimmten Kraftfahrzeugtyp im Feld
EP2676115B1 (de) System und verfahren zum identifizieren, diagnostizieren, warten und reparieren eines fahrzeugs
DE10235525B4 (de) Verfahren und System zur Überwachung des Zustands eines Fahrzeugs
EP2718908B1 (de) Mobile kommunikationsschnittstelle, system mit mobiler kommunikationsschnittstelle und verfahren zum identifizieren, diagnostizieren, warten und reparieren eines fahrzeugs
WO2001043079A1 (de) Verfahren zum erkennen von fehlern eines kraftfahrzeugs
DE112009000439T5 (de) Fahrzeuginformationsaufzeichnungsvorrichtung, Fahrzeuginformationskommunikationssystem und Fahrzeuginformationskommunikationsverfahren
EP2146262A1 (de) Verfahren zum Bestimmen fehlerhafter Komponenten in einem System
DE102019108446A1 (de) Verfahren und Vorrichtung zum Isolieren eines fahrzeugseitigen Fehlers
WO2012110262A1 (de) Mobile kommunikationsschnittstelle, system mit mobiler kommunikationsschnittstelle und verfahren zum identifizieren, diagnostizieren, warten und reparieren eines fahrzeugs
DE102018003801B4 (de) Verfahren und Steueranordnung zur Vorhersage einer Fehlfunktion einer Radlagereinheit einer Achse in einem Fahrzeug
WO2006056355A2 (de) Diagnose- und servicesystem für ein kraftfahrzeug
DE102012011538A1 (de) Verfahren und System zur Telediagnose von Fahrzeugen
DE102014114202A1 (de) Verfahren zum Prognostizieren einer Panne und/oder eines Reparatur- und/oder Wartungsbedarfs
WO2007022849A2 (de) Verfahren zur identifikation komplexer diagnosesituationen im kundendienst
DE19722188A1 (de) Vorrichtung zur Funktionsüberprüfung eines elektronisch gesteuerten Regelsystems in einem Kraftfahrzeug nach einem Fertigungsvorgang
EP2166514B1 (de) Kraftfahrzeugdiagnosesystem
DE102015214987B4 (de) Bestimmung eines defekten Bauteils eines Fahrzeugs
DE102021202177A1 (de) Verfahren zum bestimmen des betriebszustands von fahrzeugkomponenten
DE10024211B4 (de) Diagnoseverfahren für den Zustand eines Kraftfahrzeuges
DE102005014308A1 (de) Verfahren und Anordnung zur Nutzerführung bei der Diagnose komplexer Systeme sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium
WO2014005771A1 (de) Fahrzeugdiagnosevorrichtung zum ermitteln eines bedarfs für eine überprüfung von mindestens einer komponente eines kraftfahrzeuges und fahrzeugdiagnoseverfahren zum ermitteln eines bedarfs für eine überprüfung von mindestens einer komponente eines kraftfahrzeuges
DE102018212801A1 (de) Diagnose komplexer Systeme

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20221107

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)