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

Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose Download PDF

Info

Publication number
EP3907707A1
EP3907707A1 EP20173583.4A EP20173583A EP3907707A1 EP 3907707 A1 EP3907707 A1 EP 3907707A1 EP 20173583 A EP20173583 A EP 20173583A EP 3907707 A1 EP3907707 A1 EP 3907707A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
error
error codes
diagnostic device
sensor
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.)
Withdrawn
Application number
EP20173583.4A
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
Priority to EP20173583.4A priority Critical patent/EP3907707A1/de
Priority to AU2021269012A priority patent/AU2021269012A1/en
Priority to US17/998,101 priority patent/US20230252829A1/en
Priority to PCT/EP2021/061617 priority patent/WO2021224202A1/de
Priority to EP21722886.5A priority patent/EP4147210A1/de
Priority to CA3181930A priority patent/CA3181930A1/en
Publication of EP3907707A1 publication Critical patent/EP3907707A1/de
Withdrawn legal-status Critical Current

Links

Images

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.
  • control units in today's motor vehicles offer ever better options for influencing functionalities in the vehicle, e.g. better diagnostic options in the event of a fault or options for remote control of functions and / or components of the vehicle.
  • a vehicle for example a passenger car, two-wheeled vehicle or a truck
  • error messages from control units and sensors can be reported via what is known as an on-board diagnostic function.
  • Modern vehicles are complex electrical and mechanical systems that use many communicating components to support safe and efficient vehicle operation. Such components can be susceptible to malfunctions, failures and errors that can affect the operation of a vehicle. If such malfunctions or errors occur, the affected component can trigger a corresponding error code, for example a Diagnostic Trouble Code (DTC).
  • the fault code is usually stored in a memory on the vehicle. A warning signal can then be output, which prompts the driver to visit a workshop.
  • a vehicle diagnostic interface is usually provided in the vehicle, which is often arranged in the driver's footwell.
  • An external vehicle diagnostic device is typically 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.
  • Such 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 differ according to manufacturer, vehicle type and vehicle year. The type and meaning of the error code are often known to the manufacturer of the vehicle (OEM), but are generally not the subject of manufacturer information / instructions and are therefore not known to the company involved in vehicle diagnostics.
  • 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 by evaluating the sensor measured variables of the vehicle in the vehicle fault condition as a function of the fault code. Overall, the proposed method can simplify and accelerate the vehicle diagnosis.
  • the method is characterized, among other things, in 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 unit 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.
  • the database is not part of the vehicle and can be referred to as an external database.
  • 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 device 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 brought about.
  • the method can thus include the step of: receiving confirmation that the vehicle is in the first vehicle fault condition.
  • 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 on the basis of an average time span between triggering and deletion of 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 empirical 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 through quick elimination of the error, because of the error that occurs is only possible to a limited extent or even excluded under certain circumstances. 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 fault condition, the relevant sensor parameters to be measured and / or the at least one potentially defective one Component can be made 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 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 by comparing it with historical vehicle data.
  • the target range here preferably includes 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 measured variables can, for example, be assigned to the same vehicle assembly (for example engine, air conditioning system, brake system, infotainment system, etc.).
  • the user interface can in particular be a display or the above-mentioned user interface on the vehicle diagnostic device.
  • the vehicle identification means indicates, for example, the vehicle manufacturer and / or a vehicle type of the vehicle and, furthermore, possibly 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 name 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 on the basis of the error codes and the measured sensor parameters.
  • the diagnostic results can be displayed on the display device, the display device preferably being part of a diagnostic device or 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 knowledge of vehicles is no longer necessary in order to interpret the combination of the displayed error codes and the read out sensor measurement values (e.g. engine speed in connection with injection quantity and accelerator pedal position).
  • 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. connected directly or indirectly.
  • 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 further 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.
  • the invention provides a method for performing a diagnosis of a vehicle 10.
  • the method is preferably carried out using an in Figures 1 and 3 indicated vehicle diagnostic device 20 or one in Figures 2 and 4th indicated system 40, the system in the embodiment of Figs. 2 and 4th a vehicle diagnostic device 20 and a server 30.
  • the Fig. 1 shows a vehicle 10 which has a multiplicity of control units 11, 12, for example at least 10 or more. Like in the Fig. 1 indicated, the control units 11, 12 can be connected to one another, for example via a CAN bus system. In addition, at least one control device 11 is connected to a vehicle diagnostic interface 13.
  • a vehicle diagnostic device 20 which typically comprises 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 by means of signal lines (that is, wired) 10 can be connected.
  • the vehicle diagnostic device 20 typically has a plug that is compatible with the vehicle diagnostic interface 13. When the connector is connected to the vehicle diagnostic interface 13, the two 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 devices 11, 12 are usually each connected to a multiplicity of sensors which record measured values during the operation of the vehicle 10.
  • Conceivable sensor measured variables 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 measured value is measured by a sensor If it falls below or exceeds a certain setpoint range, the corresponding control unit 11, 12 generates an error code.
  • the error code is assigned to an error condition and contains, for example, a code number for identifying 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 (DTC).
  • DTC Diagnostic Trouble Code
  • 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 ongoing operation of the vehicle 10 via an evaluation of the sensor measured values by the at least one vehicle control device 11, 12 are generated and stored in a vehicle-mounted memory.
  • the vehicle control devices 11, 12 are designed to read out the fault 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 obtain the required error codes from the vehicle control device 11 to attain 12.
  • 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.
  • the Fig. 3 shows schematically a preferred communication sequence between the vehicle 10 and the vehicle diagnostic device 20.
  • the sending and receiving steps are each summarized in an arrow with a reference symbol.
  • 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 (S11) 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 manually performed by a technician or vehicle mechanic entered on vehicle diagnostic device 12.
  • the vehicle diagnostic device 20 can then request, for example, 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.
  • the error codes be analyzed or evaluated by the vehicle diagnostic device 12.
  • the vehicle diagnostic device 20 can additionally request currently measured sensor measured values or sensor measured values stored in the vehicle from the vehicle 10. This is done, for example, via a corresponding request (S15).
  • the vehicle control unit 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 S11 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, 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 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 vehicle diagnosis process is described below.
  • the vehicle diagnosis can alternatively also be carried out with the in Fig. 2 system 40 shown.
  • 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 (S11).
  • the vehicle 10 then sends (S12) at least one means of identification of the vehicle 10, which can be stored in a memory in the vehicle, 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 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 10 to the diagnostic device 20 (S16) and from the diagnostic device 20 sent to 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, S11 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, control 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 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.
  • a vehicle state is thus determined which the mechanic and / or the vehicle 10 should bring about in order to be able to measure high-quality sensor measured values (e.g. increase in engine speed when idling, test drive, activate air conditioning).
  • 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 variables.
  • a check is made to determine how the vehicle status was previously with the error code (e.g. based on the speed or engine speed) or whether an actuator test / final control element test was carried out on components (e.g. blower or air conditioning activated). Furthermore, it can be checked on the basis of historical data, for example, which sensor measured variables (sensor parameters) are increasingly selected by the user if a corresponding error code is available. 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.
  • 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 time span 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 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.
  • calls to technical information such as repair information or vehicle component information by the mechanic are stored on the diagnostic device 20 in a log, which is also referred to as logging.
  • the logging data are preferably also stored in the database. The logging data can be used in determining the potential defective component are taken into account.
  • 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 available in the diagnostic device 20 with additional sub-categories: 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: 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 e.g. 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 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 for the classification of relevance, which focus on the repair of less critical problems (eg "Glaser"). If there If error codes are read out of their focus (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. The subject of the customer concern is a different 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 measured values and related sensor sensor measured values and form a main cluster (majority of all healthy measuring points) on which outlier models can be trained. Error codes can also be included to identify the main cluster. This means that the measured values in the main cluster preferably have no error codes or a number of error codes that do not exceed a predetermined limit.
  • 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.

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

  • Die vorliegende Erfindung bezieht sich auf ein Verfahren sowie eine Diagnosevorrichtung zum Durchführen einer Fahrzeugdiagnose, wobei die Fehlerursache des Fahrzeugs automatisch bestimmt wird.
  • Die zunehmende Vernetzung von Steuergeräten in heutigen Kraftfahrzeugen bietet immer bessere Einwirkungsmöglichkeiten auf Funktionalitäten im Fahrzeug, 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 Sensoren über eine sogenannte On-Board-Diagnosefunktion gemeldet werden.
  • Moderne Fahrzeuge sind komplexe elektrische und mechanische Systeme, die viele miteinander kommunizierende Komponenten verwenden, um einen sicheren und effizienten Fahrzeugbetrieb zu unterstützen. Derartige Komponenten 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 entsprechenden Fehlercode auslösen, zum Beispiel einen Diagnostic Trouble Code (DTC). 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 Aussage darüber getroffen werden, welche Fahrzeugkomponenten defekt sind und eine Reparatur benötigen. Hierzu ist üblicherweise eine Fahrzeugdiagnoseschnittstelle im Fahrzeug vorgesehen, welche oftmals im Fußraum beim Fahrer angeordnet ist. Typischerweise wird ein externes Fahrzeugdiagnosegerät an die Fahrzeugdiagnoseschnittstelle angeschlossen, um die gespeicherten Fehlercodes auszulesen. Hiernach werden die Fehlercodes durch das Fahrzeugdiagnosegerät analysiert, um zu diagnostizieren, welche Komponenten repariert oder ersetzt werden müssen, um das Problem zu beheben. Im Werkstattalltag 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 Fehlercodes u.a. nach Hersteller, Fahrzeugtyp und Fahrzeugbaujahr. Art und Bedeutung des Fehlercodes sind oftmals zwar dem Hersteller des Fahrzeuges (OEM) bekannt, sind aber in der Regel nicht Gegenstand von Herstellerangaben / -hinweisen und damit dem mit der Fahrzeugdiagnose befassten Unternehmen 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 Dampfblasen 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 Fragen abgearbeitet werden. Dies kann jedoch personal- und zeitintensiv sein.
  • Aktuell sind viele einzelne Arbeitsschritte notwendig, um eine komplette Diagnose durchführen zu können. Zuerst muss ein Fahrzeug auf dem Diagnosegerä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 Fehlerursachenbestimmung, wenn ein Fehler an einem Fahrzeug auftritt. Insbesondere wäre es wünschenswert, eine praxistaugliche Lösung für die Fehlerursachenbestimmung zu finden.
  • Die genannten Probleme werden nach der beschriebenen Erfindung zumindest teilweise oder zu einem wesentlichen Teil durch ein Verfahren entsprechend dem Hauptanspruch sowie eine Vorrichtung gemäß dem Nebenanspruch 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 Fahrzeugdiagnose 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, 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 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 anschließend herbeigeführt wird, kann über eine Auswertung der Sensormessgrößen des sich im Fahrzeugfehlerzustand befindlichen Fahrzeuges in Abhängigkeit des Fehlercodes die genaue Ursache der Fehlermeldung ermittelt werden. Insgesamt können durch das vorgeschlagene Verfahren eine Vereinfachung und Beschleunigung der Fahrzeugdiagnose erzielt werden. Das Verfahren 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 sogenannten Diagnostic Trouble Code (DTC), umfassen, welcher von einem Steuergerät des Fahrzeugs mit Hilfe von Sensoren des Fahrzeugs erzeugt wird. Ein derartiger Diagnosefehlercode kann beispielsweise von einem Fahrzeugdiagnosesystem, einer sogenannten On-Board-Diagnose (OBD), während des Betriebs 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 Datenbank 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 Fahrzeugzustand oder den Fahrzeugfehlerzustand treffen zu können. Die historischen Fahrzeugdaten umfassen vorzugsweise Fahrzeugidentifikationsmittel, Fahrzeughersteller, Fahrzeugtyp, Fahrzeugausstattung, Fehlercodes, Kilometerstand, Fahrzeugalter, Sensormesswerte und/oder Sensormessgrößen. Die genannten Fahrzeugdaten sind vorzugsweise in mindestens einer Matrix zusammengefasst 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 werden.
  • In einer Variante des Verfahrens kann die Aufforderung zum Herbeiführen des ersten Fahrzeugfehlerzustandes mindestens eine der nachstehenden Anweisungen 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 vorzugsweise durch einen Benutzer, wie einen Kfz-Mechaniker, befolgt und am Fahrzeug durchgeführt. Unter Umständen wird die Aufforderung an das Fahrzeug selbst geschickt und anschließend durch das Fahrzeug umgesetzt. Nach Empfang der Aufforderung werden das mindestens eine Stellglied, Fahrzeugmodul und/oder Fahrzeugsteuergerät entsprechend geändert, eingestellt, an- oder abgeschaltet, bzw. der mindestens eine Fahrzeugparameter wird entsprechend geändert. Über eine Rückmeldung vom Fahrzeug oder einem Benutzer kann erkannt werden, dass der erste Fahrzeugfehlerzustand herbeigeführt wurde. Das Verfahren kann somit den Schritt enthalten: Empfangen einer Bestätigung, dass sich das Fahrzeug im ersten Fahrzeugfehlerzustand befindet.
  • Das Verfahren kann den zusätzlichen Schritt umfassen: Ermitteln einer Relevanz des jeweiligen Fehlercodes.
  • Wahlweise kann die Relevanz des jeweiligen Fehlercodes anhand einer durchschnittlichen Zeitspanne zwischen Auslösen und Löschen von gleichen historischen 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 Erfahrungswerten 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 Zeitspanne 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 auftretenden Fehler nur eingeschränkt möglich oder unter Umständen sogar ausgeschlossen ist. Es kann somit vorgesehen sein, dass die Relevanz vergleichsweise 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 historischen Fehlercodes aus der Datenbank nach Fahrzeugbaugruppen und/oder Kundengruppen und/oder korrelierenden historischen Fehlercodes klassifiziert 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önnen die korrelierenden Fehlercodes ebenfalls dieser Fahrzeugbaugruppe zugeordnet 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 Fahrzeugfehlerzustandes, der zu messenden relevanten Sensormessgrößen und/oder des mindestens einen potenziell defekten Bauteils kann basierend auf der Relevanz der Fehlercodes erfolgen.
  • Durch das Verbinden eines Diagnosegeräts mit einer im Fahrzeug vorgesehenen 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 Informationen 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 werden, die insbesondere in der Datenbank hinterlegt sein können. Als Logging bezeichnet man üblicherweise die Erstellung eines Protokolls eines Diagnoseprozesses, wobei die Erstellung in der Regel automatisch erfolgt. Vorzugsweise umfassen die historischen Logging-Daten aufgerufene Reparaturinformationen und/oder aufgerufene Fahrzeugbauteilinformationen, die z.B. während 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 Sensormessgröße ein Sollbereich ermittelt werden. Der Sollbereich umfasst hierbei vorzugsweise einen Sollmesswert und/oder einen Toleranzbereich um den Sollmesswert. Messwerte, die innerhalb des Sollbereichs liegen, werden demnach als positiv bewertet, während Messwerte, die außerhalb des Sollbereichs liegen, als negativ bewertet werden. In der Regel hängt der Sollbereich von mehreren fahrzeuginternen (z.B. Fahrzeugalter, Kilometerleistung) oder fahrzeugexternen 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 Sensormessgrößen können zum Beispiel dergleichen 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 Sensormessgrößen und
    • Darstellen des Vergleichs an einer Benutzerschnittstelle.
  • Die Benutzerschnittstelle kann insbesondere eine Anzeige oder die oben genannte Benutzerschnittstelle am Fahrzeugdiagnosegerät sein.
  • Das Verfahren kann mindestens einen der folgenden Schritte enthalten:
    • Empfangen mindestens eines Fahrzeugidentifikationsmittels, wobei das Fahrzeugidentifikationsmittel insbesondere eine Fahrzeugidentifizierungsnummer und/oder einen Motorcode und/oder eine Steuergerätidentifizierungsnummer und/oder Kurzbezeichnung umfasst,
    • Vergleichen des Fahrzeugidentifikationsmittels mit bekannten Fahrzeugidentifikationsmitteln aus der Datenbank und
    • Erkennen des zu diagnostizierenden Fahrzeuges durch den Vergleich, vorzugsweise fahrzeugherstellerübergreifend und vom Fahrzeughersteller unabhängig.
  • Das Fahrzeugidentifikationsmittel gibt beispielsweise den Fahrzeughersteller und/oder einen Fahrzeugtyp des Fahrzeugs und darüber hinaus gegebenenfalls Ausstattungsmerkmale des Fahrzeugs wie die Motorvariante oder Einspritzsystem an. Das Fahrzeugidentifikationsmittel kann beispielsweise eine fahrzeugindividuelle Nummer umfassen, etwa eine Fahrzeugidentifizierungsnummer (nachstehend: FIN, englisch: Vehicle Identification Number, VIN), mit welcher ein Fahrzeug eindeutig identifizierbar sein kann. Mit Hilfe des Fahrzeugidentifikationsmittels 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 ausreicht, um die Identität des Fahrzeuges eindeutig festzustellen. In diesem Fall kann mindestens ein weiteres Fahrzeugidentifikationsmittel verwendet werden, beispielsweise ein Motorcode und/oder eine Steuergerätidentifizierungsnummer und/oder eine Kurzbezeichnung des Fahrzeuges. Die Kurzbezeichnung des Fahrzeuges kann in einem Steuergerät des Fahrzeuges hinterlegt 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 (Hersteller, Typ und/oder Ausstattung) erkannt werden. Alternativ kann die Identität des Fahrzeuges über eine Erkennung eines Musters im Fahrzeugidentifikationsmittel und Abgleich mit gleichen oder ähnlichen Mustern der Datenbank festgestellt werden.
  • Der Schritt des Empfangens des Fahrzeugidentifikationsmittels kann z.B. beinhalten, dass das Fahrzeugidentifikationsmittel durch das Fahrzeug übermittelt wird oder durch einen Benutzer eingegeben wird. Gegebenenfalls kann das Fahrzeugidentifikationsmittel nach einer Aufforderung übermittelt oder eingegeben 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 Reparatur des Fahrzeuges bzw. die Behebung des Fehlers benötigt. Die kontextbezogenen Reparaturinformationen können durch Abgleich mit den historischen Logging-Daten ermittelt werden.
  • Gemäß einer Weiterbildung wird das mindestens eine potentiell defekte Bauteil zusätzlich auf Basis von Kundendienstdaten und/oder Rechnungsdaten auf Kfz-Werkstätten und/oder Zugriffen auf Reparaturinformationen in der Datenbank 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 Bauteil 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 Bauteilen,
    • Erstellen und/oder Darstellen von kontextbezogenen Bauteilinformationen,
    • Ermitteln und/oder Darstellen von notwendigen Reparaturschritten.
  • In einem weiteren Schritt können die Diagnoseergebnisse auf der Anzeigevorrichtung angezeigt werden, wobei die Anzeigevorrichtung vorzugsweise Bestandteil 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 Nutzer 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 interpretieren (z.B. Motordrehzahl in Verbindung mit Einspritzmenge und Fahrpedalstellung). 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 Fahrzeugdiagnosegerät, einen Server und/oder ein System umfassend ein Fahrzeugdiagnosegerät und einen Server durchgeführt werden. Das Fahrzeugdiagnosegerät, der Server oder das System können zum Kommunizieren mit dem Fahrzeug vorzugsweise über eine Fahrzeugdiagnoseschnittstelle mit dem Fahrzeug verbunden 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 durchzufü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 basierend auf den Fehlercodes,
    • Auffordern zum Herbeiführen zumindest des ersten Fahrzeugfehlerzustandes,
    • 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 Diagnosevorrichtung 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 Diagnosevorrichtung 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 Servers.
  • Es sei an dieser Stelle betont, dass Merkmale, die nur in Bezug auf das Verfahren genannt wurden, auch für die genannte Diagnosevorrichtung beansprucht werden können und umgekehrt. Es versteht sich, dass die oben beschriebenen 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 teilweise 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 Figuren 2 und 4 angedeuteten Systems 40 durchgeführt, wobei das System im Ausführungsbeispiel der Fign. 2 und 4 ein Fahrzeugdiagnosegerät 20 und einen 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 Fahrzeugdiagnoseschnittstelle 13 verbunden. Weiter zeigt die Fig. 1 ein Fahrzeugdiagnosegerät 20, das typischerweise eine Steuer- und Verarbeitungseinheit, eine Kommunikationseinheit, einen Speicher sowie eine Eingabe- und Ausgabeeinheit für eine Kommunikation mit einem Benutzer wie einem Kfz-Mechaniker umfasst. Üblicherweise kann das Fahrzeugdiagnosegerät 20 mittels Signalleitungen (also drahtgebunden) an die Fahrzeugdiagnoseschnittstelle 13 des Fahrzeuges 10 angeschlossen werden. Das Fahrzeugdiagnosegerät 20 weist typischerweise einen Stecker auf, der mit der Fahrzeugdiagnoseschnittstelle 13 kompatibel ist. Beim Verbinden des Steckers mit der Fahrzeugdiagnoseschnittstelle 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 Sensoren verbunden, die während des Betriebs des Fahrzeuges 10 Messwerte erfassen. Denkbare Sensormessgrößen umfassen beispielsweise eine Kühlmitteltemperatur, eine Motortemperatur, eine Fahrzeuggeschwindigkeit, eine Motordrehzahl, ein Motordrehmoment, eine Umgebungstemperatur, einen Umgebungsluftdruck, einen Ladedruck eines Abgasturboladers des Antriebsmotors, einen eingelegten Gang eines Getriebes des Fahrzeugs 10 usw.. Falls ein durch einen Sensor gemessener Messwert einen bestimmten Sollwertbereich unter- oder überschreitet, erzeugt das entsprechende Steuergerät 11, 12 einen Fehlercode. Der Fehlercode ist einem Fehlerzustand zugeordnet und beinhaltet beispielsweise eine Kennziffer zur Identifikation von Fehlfunktionen, die während des Betriebs eines Fahrzeugs auftreten können. Der Fehlercode wird auch als Diagnosefehlercode oder Diagnostic Trouble Code (DTC) 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 feststellen zu können, welches Bauteil des Fahrzeuges defekt ist, wertet das Fahrzeugdiagnosegerät 20 (oder der Server 30, s. unten) die Fehlercodes aus, welche im laufenden Betrieb des Fahrzeuges 10 über eine Auswertung der Sensormesswerte durch das mindestens eine Fahrzeugsteuergerät 11, 12 erzeugt werden und in einem fahrzeugseitigen Speicher gespeichert werden.
  • Nach einer entsprechenden Aufforderung sind die Fahrzeugsteuergeräte 11, 12 dazu ausgestaltet, die im Fahrzeug 10 gespeicherten Fehlercodes auszulesen und an das Diagnosegerät 20 (bzw. den Server 30) zu übermitteln. Das Fahrzeugdiagnosegerät 20 kann also direkt mit dem jeweiligen Fahrzeugsteuergerät 11, 12 kommunizieren, um die benötigten Fehlercodes vom Fahrzeugsteuergerä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 Fahrzeugkomponenten defekt sind und eine Reparatur benötigen.
  • Statt auf einzelne Komponenten 11, 12, 13 des Fahrzeuges 10 oder des Diagnosegerä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 zwischen 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 Fahrzeugdiagnoseschnittstelle 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 (S11) 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 Fahrzeugdiagnosegerät 12. In alternativen Ausführungsformen werden Hersteller, Typ und/oder Ausstattung des Fahrzeuges 10 oder das Fahrzeugidentifikationsmittel manuell durch einen Techniker oder Fahrzeugmechaniker am Fahrzeugdiagnosegerät 12 eingegeben.
  • Hiernach kann das Fahrzeugdiagnosegerät 20 z.B. die Fehlercodes vom Fahrzeug 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 Sensormesswerte vom Fahrzeug 10 anfordern. Dies geschieht z.B. über eine entsprechende Anforderung (S15). Das Fahrzeugsteuergerät 11, 12 ruft die angeforderten 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 Fahrzeugsteuergerä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 S11 und S13, S12 und S14 jeweils zusammengefasst werden.
  • Weiter kann das Fahrzeugdiagnosegerät 20 Befehle an das Fahrzeugsteuergerät 11, 12 schicken. Z.B. umfasst ein Befehl an das Fahrzeugsteuergerät eine Einstellung des Sensors 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 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 Ablauf 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. Hierdurch ist eine Kommunikation zwischen dem Server 30 und dem Diagnosegerät 20 möglich. Nachfolgend wird auf die Kommunikation zwischen dem Fahrzeug 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 gleichzeitig) 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 vermitteln. 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 zuordnen kann. Daher schickt (S21) der Server 30 eine Anfrage zum Identifizieren des Fahrzeuges 10 an das Diagnosegerät 20, welcher die Anfrage an das Fahrzeug 10 weiterleitet (S11). Daraufhin sendet (S12) das Fahrzeug 10 mindestens ein Identifikationsmittel des Fahrzeuges 10, welches in einem fahrzeugseitigen 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 Fahrzeugsteuergerä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 Server 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 fahrzeugseitigen Speicher ab oder spricht entsprechende Fahrzeugsensoren zur Herausgabe oder zum Erfassen der Sensormesswerte an. Die Sensormesswerte werden dann vom Fahrzeug 10 zum Diagnosegerät 20 geschickt (S16) und vom Diagnosegerät 20 zum Server 30 zur weiteren Auswertung oder Bearbeitung geschickt (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, S11 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 Sensors 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. Denkbar wäre in diesem Zusammenhang z.B. Inspektionsintervall, Ansteuerung von Stellgliedern oder dergleichen.
  • Das Fahrzeug 10 kann auch neue Softwarekomponenten oder Updates bekommen, 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 genannt 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, insbesondere ü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 Fahrzeugidentifizierungsnummer (FIN) und/oder einen Motorcode und/oder eine Steuergerätidentifizierungsnummer und/oder eine Kurzbezeichnung umfassen kann. Das Fahrzeugidentifikationsmittel wird mit bekannten Fahrzeugmitteln 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 darstellt, in dem zumindest einer der Fehlercodes im Fahrzeug 10 ausgelöst wurde, basierend auf dem jeweiligen Fehlercode und historischen Fahrzeugdaten aus einer Datenbank außerhalb des Fahrzeuges 10,
    • Ermitteln von zu messenden relevanten Sensormessgrößen basierend auf den Fehlercodes,
    • Auffordern zum Herbeiführen zumindest des ersten Fahrzeugfehlerzustandes, vorzugsweise durch Anzeigen einer Anforderung auf einer Anzeige des Diagnosegeräts 20, und
    • Empfangen S16, S26 der gemessenen Sensormessgrößen des Fahrzeuges 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 aktivieren). Hierzu wird vorzugsweise auf die historischen Fahrzeugdaten der Datenbank zurückgegriffen, wobei die Datenbank in einem Speichermedium hinterlegt ist, das beispielsweise Bestandteil des Diagnosegeräts 20, des Servers 30 oder eines weiteren Servers ist. Die historischen Fahrzeugdaten umfassen zumindest Fahrzeughersteller, Fahrzeugtyp, Fahrzeugausstattung, Fehlercodes, Kilometerstand, Fahrzeugalter, Sensormesswerte und/oder Sensormessgrößen.
  • Typischerweise wird auf Basis der historischen Daten geprüft, wie der Fahrzeugzustand 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 Sensormessgrößen (Sensorparameter) vermehrt durch Nutzer ausgewählt werden, wenn ein entsprechender Fehlercode vorhanden ist. Durch das Herbeiführen des ersten Fahrzeugfehlerzustandes können daher relevante Messwerte erfasst werden, die anschließend für die Diagnose verwendet werden können.
  • 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 Abschalten 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 Fahrzeugfehlerzustände herbeigeführt werden, in denen jeweils relevante zu messende Sensormessgrößen gemessen werden.
  • Um die Genauigkeit zu erhöhen, kann eine Relevanz des jeweiligen Fehlercodes 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 unberücksichtigt bleiben. Falls zum Beispiel eine durchschnittliche Zeitspanne zwischen 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 historischen Fehlercodes aus der Datenbank nach Fahrzeugbaugruppen und/oder Kundengruppen und/oder korrelierenden historischen Fehlercodes klassifiziert werden. Korrelierende Fehlercodes sind hierbei Fehlercodes, die bei Auftreten des Fehlercodes im Schnitt vermehrt auftreten. Wenn der Fehlercode einer bestimmten Fahrzeugbaugruppe zugeordnet ist, dann können die korrelierenden Fehlercodes ebenfalls dieser Fahrzeugbaugruppe zugeordnet werden. 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 gemessenen Sensormesswerten und des Kilometerstandes des Fahrzeuges.
  • Vorzugsweise werden Aufrufe an technischen Informationen,, wie Reparaturinformationen 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 Datenbank hinterlegt. Die Logging-Daten können bei der Ermittlung des potenziell defekten Bauteils berücksichtigt werden.
  • Wenn ein Mechaniker beispielsweise einen Fehlercode oder Messwerte ausliest, erfolgt dann meistens auf Basis seines Kfz-Expertenwissens die Auswahl an relevanten Informationen am Diagnosegerät 20, die zur Reparatur notwendig sind. Oftmals stehen dem Mechaniker im Diagnosegerät 20 bis zu 18 verschiedene Rubriken mit weiteren Subrubriken zur Verfügung: z.B. Schaltplä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 entsprechenden 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 Datenbank.
  • Gemäß einer Weiterbildung wird das mindestens eine potentiell defekte Bauteil zusätzlich auf Basis von Kundendienstdaten und/oder Rechnungsdaten auf KfZ-Werkstätten und/oder Zugriffen auf Reparaturinformationen in der Datenbank ermittelt.
  • In einer weiteren Variante 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 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 kontextbezogenen 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 Kundengruppen für die Einstufung der Relevanz genutzt werden, die sich auf die Reparatur 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 ebenfalls 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, Sensormesswerte und Kilometer-Stände) in Verbindung mit den extrahierten Bauteilen 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 Sensorsensormessgröß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 Hauptcluster sind vorzugsweise keine Fehlercodes oder eine Anzahl an Fehlercodes gesetzt, die eine vorbestimmte Grenze nicht überschreitet. Diese Modelle können auf aktuelle Sensormessungen angewendet werden und eine Wahrscheinlichkeit 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ücksichtigt werden. Die gemessenen Sensormessgrößen können mit den jeweiligen Sollbereichen verglichen werden zum Erkennen von Ausreißern in den Sensormessgrößen. Beispielsweise kann der Grad der Abweichung des Messwerts von dem Soll-Bereich angegeben werden, etwa durch Darstellung auf der Anzeige am Diagnosegerät 20. Diese Modelle ermöglichen eine Visualisierung / Anzeige des aktuellen Messwertes mit einem Soll-Messwert inklusive dessen Toleranzbereichs (Soll-Bereich). Hierdurch wird die Nachvollziehbarkeit 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 beschriebenen Ausführungsformen miteinander kombiniert werden können, sofern sich die Kombinationen nicht gegenseitig ausschließen. Merkmale, die nur in Bezug auf das Fahrzeugdiagnosegerät 20 und/oder den Server 30 genannt wurden, 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 (15)

  1. 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.
  2. Verfahren nach Anspruch 1, wobei die Aufforderung zum Herbeiführen des ersten Fahrzeugfehlerzustandes mindestens eine der nachstehenden 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ätzlichen 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 Fehlercodes aus der Datenbank nach Fahrzeugbaugruppen und/oder Kundengruppen und/oder korrelierenden historischen Fehlercodes klassifiziert 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 durchschnittliche 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 aufgerufene Reparaturinformationen und/oder aufgerufene Fahrzeugbauteilinformationen umfassen.
  7. Verfahren nach einem der vorstehenden Ansprüche, wobei durch Vergleich mit historischen Fahrzeugdaten für jede Sensormessgröße ein Sollbereich ermittelt wird, wobei der Sollbereich vorzugsweise einen Sollmesswert und einen Toleranzbereich um den Sollmesswert umfasst.
  8. Verfahren nach Anspruch 7, wobei für die Bestimmung des Sollbereichs 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 Sensormessgrößen und
    - Darstellen des Vergleichs an einer Benutzerschnittstelle.
  10. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch mindestens einen der folgenden Schritte:
    - Empfangen (S12, S22) mindestens eines Fahrzeugidentifikationsmittels, 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 diagnostizierenden Fahrzeuges (10) durch den Vergleich.
  11. Verfahren nach einem der vorstehenden Ansprüche, wobei die historischen Fahrzeugdaten Fahrzeugidentifikationsmittel, Fahrzeughersteller, Fahrzeugtyp, Fahrzeugausstattung, Fehlercodes, Kilometerstand, Fahrzeugalter, Sensormesswerte und/oder Sensormessgrößen umfassen.
  12. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch den zusätzlichen Schritt: Ermitteln von kontextbezogenen Reparaturinformationen auf Basis der Fehlercodes und/oder den Sensormessgrößen und/oder den potentiell defekten Bauteilen.
  13. Verfahren nach einem der vorstehenden Ansprüche, wobei das mindestens eine potentiell defekte Bauteil zusätzlich auf Basis von Kundendienstdaten und/oder Rechnungsdaten auf KfZ-Werkstätten und/oder Zugriffen auf Reparaturinformationen in der Datenbank ermittelt wird.
  14. Verfahren nach einem der vorstehenden Ansprüche, wobei die Fehlercodes anhand der gemessenen Sensormessgrößen ausgewertet werden, 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 Diagnosevorrichtung insbesondere ein Fahrzeugdiagnosegerät (20) und/oder einen Server (30) umfasst.
EP20173583.4A 2020-05-07 2020-05-07 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose Withdrawn EP3907707A1 (de)

Priority Applications (6)

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
AU2021269012A AU2021269012A1 (en) 2020-05-07 2021-05-04 Method and diagnostic device for performing vehicle diagnostics
US17/998,101 US20230252829A1 (en) 2020-05-07 2021-05-04 Method and diagnostic device for performing vehicle diagnostics
PCT/EP2021/061617 WO2021224202A1 (de) 2020-05-07 2021-05-04 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
EP21722886.5A EP4147210A1 (de) 2020-05-07 2021-05-04 Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
CA3181930A CA3181930A1 (en) 2020-05-07 2021-05-04 Method and diagnostic device for performing vehicle diagnostics

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
EP3907707A1 true EP3907707A1 (de) 2021-11-10

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 After (1)

Application Number Title Priority Date Filing Date
EP21722886.5A Pending EP4147210A1 (de) 2020-05-07 2021-05-04 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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117434927A (zh) * 2023-12-20 2024-01-23 中汽研（天津）汽车工程研究院有限公司 一种检测电子控制器故障状态的云端诊断系统及装置

Families Citing this family (2)

* 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

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2133243A1 (de) * 2007-04-02 2009-12-16 Toyota Jidosha Kabushiki Kaisha Informationsaufzeichnungssystem für ein fahrzeug
US20100324376A1 (en) * 2006-06-30 2010-12-23 Spx Corporation Diagnostics Data Collection and Analysis Method and Apparatus
US20140324275A1 (en) * 2013-04-26 2014-10-30 Ford Global Technologies, Llc Online vehicle maintenance
US20170039785A1 (en) * 2015-08-03 2017-02-09 Volkswagen Ag Method for determining the cause of failure in a vehicle
WO2018234832A1 (en) * 2017-06-23 2018-12-27 Remote Asset Management Limited ELECTRIC DIVIDER CONNECTOR HAVING INVIOLABILITY CHARACTERISTIC

Patent Citations (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
EP2133243A1 (de) * 2007-04-02 2009-12-16 Toyota Jidosha Kabushiki Kaisha Informationsaufzeichnungssystem für ein fahrzeug
US20140324275A1 (en) * 2013-04-26 2014-10-30 Ford Global Technologies, Llc Online vehicle maintenance
US20170039785A1 (en) * 2015-08-03 2017-02-09 Volkswagen Ag Method for determining the cause of failure in a vehicle
WO2018234832A1 (en) * 2017-06-23 2018-12-27 Remote Asset Management Limited ELECTRIC DIVIDER CONNECTOR HAVING INVIOLABILITY CHARACTERISTIC

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117434927A (zh) * 2023-12-20 2024-01-23 中汽研（天津）汽车工程研究院有限公司 一种检测电子控制器故障状态的云端诊断系统及装置
CN117434927B (zh) * 2023-12-20 2024-04-02 中汽研（天津）汽车工程研究院有限公司 一种检测电子控制器故障状态的云端诊断系统及装置

Also Published As

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

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
DE102014105674A1 (de) Online-fahrzeugwartung
DE102020103768A1 (de) Überwachung und Diagnose von Fahrzeugsystemproblemen mit Maschinenlern-Klassifikatoren
EP3907707A1 (de) Verfahren und diagnosevorrichtung zum durchführen einer fahrzeugdiagnose
WO2001043079A1 (de) Verfahren zum erkennen von fehlern eines kraftfahrzeugs
DE112012001923T5 (de) Zur Zusammenarbeit fähiges Multi-Agentensystem zur Fehlerdiagnose an einem Fahrzeug sowie zugehöriges Verfahren
WO2012110263A1 (de) System und verfahren zum identifizieren, diagnostizieren, warten und reparieren eines fahrzeugs
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
DE102011108678A1 (de) Ereignisgesteuertes Datamining-Verfahren zum Verbessern von Fehlercodeeinstellungen und zum Isolieren von Fehlern
WO2006056355A2 (de) Diagnose- und servicesystem für ein kraftfahrzeug
EP3001380A1 (de) Diagnoseverfahren und erhebungsverfahren für fahrzeuge
DE102018109195A1 (de) Diagnosesystem und Verfahren zum Verarbeiten von Daten eines Kraftfahrzeugs
DE102007048610A1 (de) Verfahren zum Erfassen von Informationen
DE102005040142A1 (de) Verfahren zur Identifikation komplexer Diagnosesituationen im Kundendienst
DE102021125867A1 (de) Automatisierte detektion von fahrzeugdatenmanipulation und mechanischen ausfällen
EP3014372B1 (de) Werkstatt-diagnosesystem
EP3147832A1 (de) Datenverarbeitungsanlage und verfahren für diese zur zustandsüberwachung einer mehrzahl an fahrzeugen
DE102015214987B4 (de) Bestimmung eines defekten Bauteils eines Fahrzeugs
DE102021202177A1 (de) Verfahren zum bestimmen des betriebszustands von fahrzeugkomponenten
DE102020128497A1 (de) Computerimplementiertes Verfahren und System zur dialogunterstützten Ferndiagnose eines Defekts an einem technischen Bauteil und/oder System eines Fahrzeugs und Trainingsverfahren
WO2020114724A1 (de) Verfahren zum überprüfen wenigstens eines fahrzeugs sowie elektronische recheneinrichtung
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
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: THE APPLICATION HAS BEEN PUBLISHED

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

B565 Issuance of search results under rule 164(2) epc

Effective date: 20201001

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20220511