Method and diagnostic device for carrying out a vehicle diagnosis

Abstract

The invention relates to a method for performing vehicle diagnostics, comprising the following steps: - receiving (S14, S24) a multiplicity of fault codes from a vehicle (10), - ascertaining at least one first vehicle fault state, wherein the vehicle fault state constitutes a state of the vehicle (10) in which at least one of the fault codes was triggered in the vehicle (10), based on the respective fault code and historic vehicle data from a database, - ascertaining relevant sensor measured variables to be measured, based on the fault codes, - requesting inducement of at least the first vehicle fault state, - receiving (S16, S26) the measured sensor measured variables from the vehicle (10), - ascertaining at least one potentially defective component. The invention furthermore relates to a diagnostic device for performing the method.

Description

[0001] The present invention relates to a method and a diagnostic device for performing a vehicle diagnosis, wherein the cause of the vehicle's fault is automatically determined.

[0002] The increasing networking of control units in modern vehicles offers ever better possibilities for influencing vehicle functionalities, such as improved diagnostic capabilities in the event of a fault or the ability to remotely control functions and / or vehicle components. In a vehicle, for example a passenger car, motorcycle, or truck, fault messages from control units and sensors can be reported via an on-board diagnostics function.

[0003] Modern vehicles are complex electrical and mechanical systems that use many interconnected components to support safe and efficient vehicle operation. Such I <omponenten 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.

[0004] By analyzing the fault codes (vehicle diagnostics), it's possible to determine which vehicle components are defective and require repair. For this purpose, a vehicle diagnostic interface is typically provided, often located in the driver's footwell. An external diagnostic tool is usually connected to this interface to read the stored fault codes. The diagnostic tool then analyzes these codes to diagnose which components need to be repaired or replaced to resolve the problem. Such diagnostic tools have proven invaluable in everyday workshop practice.

[0005] However, while vehicle diagnostic tools can usually read fault codes, they cannot access all other relevant information stored in the vehicle. Furthermore, fault codes vary depending on factors such as manufacturer, vehicle type, and year of manufacture. The type and meaning of a fault code are often known to the vehicle manufacturer (OEM), but are generally not included in manufacturer specifications or instructions and are therefore unknown to the company performing vehicle diagnostics.

[0006] Even with known error codes, it's often difficult to pinpoint the actual cause of the error message. For example, if an elevated coolant temperature is reported, the possible causes can be numerous, such as a lack of coolant due to a leak in the cooling system, insufficient fluid flow due to vapor lock or a faulty coolant pump, or overheating due to previous vehicle load and climatic conditions. One way to determine the cause is to call a call center, where so-called fault trees are stored and a series of questions are asked. However, this can be labor-intensive and time-consuming.

[0007] Currently, many individual steps are necessary to perform a complete diagnosis. First, a vehicle must be selected on the diagnostic device. Then, error codes are usually read, followed by the measurement of parameters. Based on this information, the mechanic searches for the relevant vehicle information needed for the repair. However, the displayed diagnostic results are sometimes difficult to interpret and occasionally inaccurate.

[0008] Due to the increasing complexity of vehicle technology, there is a great need for fast and reliable fault root cause analysis when a fault occurs in a vehicle. In particular, it would be desirable to find a practical solution for fault root cause analysis.

[0009] Document WO 2018 / 234832 A1 describes a splitter connector used to connect a first electronic device and a second electronic device to an electronic connector. It further provides a method for determining the cause of a vehicle fault, wherein the vehicle outputs a code relating to the fault, and the method comprises the steps of: receiving a measurement of the vehicle's condition from several sensors; and determining the cause of the fault based on a combination of the code and the measured condition.

[0010] Document US 2017 / 039785 A1 describes a method for determining the root cause of a fault in a vehicle. In this method, a fault message is received on a server outside the vehicle, and the fault cause is determined on the server based on the fault message and the vehicle's load collective data and / or based on the fault message and the vehicle's state variables.

[0011] The problems mentioned above are solved, at least partially or to a substantial extent, according to the described invention by a method according to the main claim and a device according to the dependent claim. Advantageous features and further developments will become apparent from the features of the dependent claims and from the following description.

[0012] Accordingly, a procedure for performing vehicle diagnostics is provided. The procedure includes at least the following steps: Receiving a multitude of vehicle fault codes, determining at least one initial vehicle fault condition, wherein the vehicle fault condition represents a state of the vehicle in which at least one of the fault codes in the vehicle has been triggered, based on the respective fault code and historical vehicle data from a database, determining relevant sensor measurements to be taken based on the fault codes, requesting the induction of at least the first vehicle fault condition, receiving the measured sensor measurements of the vehicle, and identifying at least one potentially defective component.

[0013] This method identifies the vehicle fault condition that triggered the error code. By subsequently inducing this fault condition, the precise cause of the error message can be determined by evaluating the sensor readings of the vehicle in this fault state, in relation to the error code. Overall, the proposed method simplifies and accelerates vehicle diagnostics. One of its key features is that the steps are performed automatically, primarily by a control unit such as a processor or controller. This significantly reduces the workload for automotive mechanics.

[0014] The fault code can, for example, include a diagnostic trouble code (DTC), which is generated by the vehicle's control unit using the vehicle's sensors. Such a diagnostic trouble code can be provided by a vehicle diagnostic system, a so-called on-board diagnostics (OBD), during vehicle operation if a fault condition exists.

[0015] According to this document, historical data refers to data that was determined or measured in the past and is stored in the database. This allows for a comparison of the vehicle's data with historical vehicle data, particularly data from vehicles of other manufacturers, to assess the vehicle's condition or fault state. The historical vehicle data preferably includes vehicle identification information, manufacturer, vehicle type, vehicle equipment, fault codes, mileage, vehicle age, sensor readings, and / or sensor parameters. This vehicle data is preferably compiled in at least one matrix and, in particular, assigned to a specific vehicle or vehicle group.

[0016] The database can be part of a storage medium, a server, and / or a diagnostic device. Specifically, the database is not part of the vehicle and can be referred to as an external database.

[0017] In one variant of the procedure, the request to induce the first vehicle fault condition may include at least one of the following instructions or requests: Changing, activating or adjusting at least one actuator, changing or adjusting at least one vehicle parameter, switching on or off at least one vehicle module.

[0018] Vehicle functions can also be activated, such as diesel particulate filter regeneration. The instructions or prompts are preferably followed and carried out on the vehicle by a user, such as a mechanic. Alternatively, the prompt may be sent to the vehicle itself and subsequently implemented by the vehicle. Upon receiving the prompt, at least one actuator, vehicle module, and / or vehicle control unit is modified, adjusted, switched on, or switched off accordingly, or at least one vehicle parameter is changed accordingly. Feedback from the vehicle or a user confirms that the first vehicle fault condition has been triggered. The procedure may therefore include the step of receiving confirmation that the vehicle is in the first vehicle fault condition.

[0019] The procedure may include the additional step of determining the relevance of the respective error code.

[0020] Alternatively, the relevance of a given fault code can be determined based on the average time interval between the triggering and clearing of similar historical fault codes. Clearing the fault is usually done manually by the mechanic in the workshop after the vehicle has been repaired or the fault has been rectified. The average time interval can be stored, for example, in the aforementioned database and can be based on empirical data or logged information. If a fault code remains set for an average length of time before being cleared, this may indicate that the vehicle's operation is not significantly disrupted by the fault and that no serious problem exists.Conversely, if the average time between a fault occurring and clearing is short, this may indicate that trouble-free vehicle operation is only guaranteed by a quick fault correction, is only possible to a limited extent due to the fault, or may even be impossible. Therefore, the relevance may be considered relatively high if the average time falls below a predetermined value. The relevance may be relatively low if the average time exceeds a predetermined value.

[0021] Alternatively or additionally, the fault codes can be classified by comparing them with historical fault codes from the database according to vehicle assembly groups and / or customer groups and / or correlating historical fault codes. Correlating fault codes can be fault codes that occur more frequently on average when the fault code is present. If the fault code is assigned to a specific vehicle assembly group, then the correlating fault codes can also be assigned to that assembly group. Subsequently, the relevance of each fault code can be determined based on its classification.

[0022] In a further step, the fault codes can be sorted and / or evaluated according to relevance. Relevance can be expressed as a number, e.g., either 0 (not relevant) or 1 (relevant), or a number between 0 and 1. The determination of the initial vehicle fault condition, the relevant sensor parameters to be measured, and / or the at least one potentially defective component can be based on the relevance of the fault codes.

[0023] By connecting a diagnostic tool to a diagnostic interface provided in the vehicle, the diagnostic tool can obtain information about the vehicle's current status and any existing faults. Furthermore, the diagnostic tool typically includes a user interface, such as a display, through which the user can request or enter additional information.

[0024] To identify at least one potentially defective component, historical logging data from diagnostic devices, which may be stored in a database, can also be considered. Logging typically refers to the creation of a record of a diagnostic process, usually automatically. Preferably, the historical logging data includes accessed repair information and / or accessed vehicle component information, such as that accessed during previous (historical) vehicle diagnostics. Therefore, if, after reading / receiving a specific fault code, the mechanic frequently or always accesses certain repair information and / or vehicle component information, this indicates that a specific component is defective when that particular fault code occurs.Taking historical logging data into account when identifying potentially defective components can therefore significantly accelerate automatic vehicle diagnostics.

[0025] By comparing current data with historical vehicle data, a target range can be determined for each sensor measurement. This target range preferably comprises a target value and / or a tolerance range around the target value. Measurements within the target range are therefore considered positive, while measurements outside the target range are considered negative. Typically, the target range depends on several vehicle-internal (e.g., vehicle age, mileage) or vehicle-external parameters (e.g., ambient temperature), which can also be stored in the database. Furthermore, correlating and / or related sensor measurements can be considered when determining the target range. Related sensor measurements can, for example, be assigned to the same vehicle assembly (e.g., engine, air conditioning, braking system, infotainment system, etc.).

[0026] The process may further include at least one of the following steps: Comparing the measured sensor values ​​with the respective target ranges to detect outliers in the sensor values ​​and displaying the comparison on a user interface.

[0027] The user interface can be, in particular, a display or the user interface mentioned above on the vehicle diagnostic device.

[0028] The procedure may include at least one of the following steps: Receiving at least one vehicle identification means, wherein the vehicle identification means in particular includes a vehicle identification number and / or an engine code and / or a control unit identification number and / or short designation, comparing the vehicle identification means with known vehicle identification means from the database and identifying the vehicle to be diagnosed by comparison, preferably across vehicle manufacturers and independent of the vehicle manufacturer.

[0029] The vehicle identification number specifies, for example, the vehicle manufacturer and / or vehicle type, and may also include vehicle features such as the engine variant or injection system. The vehicle identification number can include a unique vehicle number, such as a Vehicle Identification Number (VIN), which allows a vehicle to be uniquely identified. Using the vehicle identification number, information about the vehicle or comparable vehicles can be easily retrieved from the database. It has been found that the VIN is not always sufficient to definitively establish the vehicle's identity.In this case, at least one additional vehicle identification method can be used, for example, an engine code and / or a control unit identification number and / or a short vehicle designation. The short vehicle designation may be stored in a control unit of the vehicle and can provide information about the manufacturer, type, and / or equipment of the vehicle.

[0030] By combining at least two vehicle identification methods, the vehicle's identity can be determined and the vehicle (manufacturer, type and / or equipment) identified. Alternatively, the vehicle's identity can be established by recognizing a pattern in the vehicle identification method and comparing it with identical or similar patterns in the database.

[0031] The step of receiving the vehicle identification number (VIN) can, for example, involve the VIN being transmitted by the vehicle or being entered by a user. If necessary, the VIN can be transmitted or entered after a prompt.

[0032] In a further refinement, the procedure can include the following step: determining context-related repair information based on fault codes and / or sensor readings and / or potentially defective components. Context-related repair information includes, for example, wiring diagrams, labor values, or component test values ​​that the user needs to repair the vehicle or rectify the fault. This context-related repair information can be determined by comparing it with historical logging data.

[0033] According to further training, at least one potentially defective component is additionally identified based on customer service data and / or invoice data from car repair shops and / or access to repair information in the database.

[0034] Optionally, the error codes are evaluated based on the measured sensor values. This evaluation allows the identification of at least one potentially defective component. The at least one potentially defective component can then be determined based on the error codes and the measured sensor values.

[0035] Optionally, the procedure includes at least one, several or all of the following steps: Creating and / or displaying a list of potentially defective components, creating and / or displaying context-related component information, identifying and / or displaying necessary repair steps.

[0036] In a further step, the diagnostic results can be displayed on the display device, the display device preferably being part of a diagnostic device or the user interface mentioned above.

[0037] The automated procedure described above can accelerate and simplify the operation of the diagnostic tool. In particular, extensive knowledge of the diagnostic tool is no longer required. The user no longer needs to navigate through approximately 10 or more interfaces / sections with around 75 clicks. Furthermore, the proposed procedure eliminates the need for extensive automotive knowledge to interpret the combination of displayed fault codes and the read sensor values ​​(e.g., engine speed in conjunction with injection quantity and accelerator pedal position). The automatic, data-driven identification of potentially affected components (based on fault codes and sensor values ​​or parameter values) is more accurate than the previous listing of potentially affected components for each individual fault code.

[0038] The above-mentioned procedure can be carried out, in particular, 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 be connected to the vehicle for communication, preferably via a vehicle diagnostic interface, e.g., directly or indirectly.

[0039] Furthermore, the invention provides a diagnostic device designed to perform the aforementioned method. The diagnostic device is configured to perform at least the following steps: Receiving a multitude of vehicle fault codes, determining at least one initial vehicle fault condition, wherein the vehicle fault condition represents a state of the vehicle in which at least one of the fault codes in the vehicle has been triggered, based on the respective fault code and historical vehicle data from a database, determining relevant sensor measurements to be taken based on the fault codes, requesting the induction of at least the first vehicle fault condition, receiving the measured sensor measurements of the vehicle, and identifying at least one potentially defective component.

[0040] The diagnostic device is not part of the vehicle and can be located, for example, outside the vehicle or inside the vehicle, preferably temporarily for the duration of the diagnosis. The diagnostic device can comprise a vehicle diagnostic tool and / or a mobile device and / or a server, or it can be either a vehicle diagnostic tool or a server. The diagnostic device can be a system or part of a system that includes a vehicle diagnostic tool and a server.

[0041] The diagnostic device can establish a communication link with the vehicle, in particular with the vehicle's control units. For this purpose, the device may include a communication unit for receiving and / or sending data. Furthermore, the diagnostic device typically comprises a control unit, e.g., for processing data and / or controlling other units. The database may be part of the diagnostic device. Alternatively, the database may be located outside the diagnostic device, e.g., as part of an external server.

[0042] It should be emphasized here that features mentioned only in relation to the method can also be claimed for the diagnostic device mentioned, and vice versa. It is understood that the embodiments described above can be combined with one another, provided that the combinations are not mutually exclusive.

[0043] The following section explains embodiments of the invention in more detail with reference to the accompanying drawings. The figures are schematic and partially simplified. They show: Fig. 1 a schematic representation of a vehicle diagnostic device connected to a vehicle; Fig. 2 a schematic representation of a system for performing vehicle diagnostics; Fig. 3 a schematic representation of a communication sequence between a vehicle and a vehicle diagnostic device; and Fig. 4 a schematic representation of another communication sequence between a vehicle and a system.

[0044] Recurring features in the figures are labelled with the same reference symbols.

[0045] The invention provides a method for performing a diagnosis of a vehicle 10. The method is preferably carried out by means of a Figure 1 and 3 indicated vehicle diagnostic device 20 or one in Figures 2 and 4 system 40 indicated, wherein the system in the exemplary embodiment of the Fig. 2 and 4 It includes a vehicle diagnostic device (20 units) and a server (30 units).

[0046] The Fig. 1 Figure 10 shows a vehicle 10 that has a large number of control units 11, 12, e.g., at least 10 or more. As shown in the Fig. 1 As indicated, control units 11 and 12 can be connected to each other, for example, via a CAN bus system. Furthermore, at least one control unit 11 is connected to a vehicle diagnostic interface 13. The following further details are shown. Fig. 1A vehicle diagnostic device 20 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 car mechanic. The vehicle diagnostic device 20 can usually be connected to the vehicle diagnostic interface 13 of the vehicle 10 via signal lines (i.e., wired). The vehicle diagnostic device 20 typically has a connector that is compatible with the vehicle diagnostic interface 13. When the connector is plugged into the vehicle diagnostic interface 13, the two are electrically connected. In some cases, a wireless communication connection between the vehicle diagnostic device 20 and the vehicle 10 and the control units 11, 12 is possible, either alternatively or additionally.

[0047] The control units 11 and 12 are typically each connected to a variety of sensors that acquire 10 measured values ​​during vehicle operation. Possible sensor measurements include, for example, coolant temperature, engine temperature, vehicle speed, engine speed, engine torque, ambient temperature, ambient air pressure, boost pressure of the exhaust gas turbocharger of the drive engine, the selected gear of the vehicle's transmission, etc. If a measured value from a sensor falls below or exceeds a certain target value range, the corresponding control unit 11 or 12 generates a fault code. The fault code is associated with a fault condition and includes, for example, a code number to identify malfunctions that can occur during vehicle operation. The fault code is also referred to as a diagnostic trouble code (DTC).

[0048] The aim of vehicle diagnostics is to determine which component in vehicle 10 is defective and how this component can be repaired. To determine which component of the vehicle is defective, the vehicle diagnostic device 20 (or the server 30, see below) evaluates the fault codes that are generated during the operation of vehicle 10 by evaluating the sensor readings of at least one vehicle control unit 11, 12 and stored in a vehicle memory.

[0049] Upon a corresponding request, the vehicle control units 11 and 12 are configured to read the fault codes stored in the vehicle 10 and 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 units 11 and 12 to obtain the necessary fault codes. The vehicle diagnostic device 20 can then analyze these fault codes to diagnose whether and which vehicle components need to be repaired or replaced to resolve the problem. Thus, by evaluating the fault codes (vehicle diagnostics), a statement can be made about which vehicle components are defective and require repair.

[0050] Instead of referring to individual components 11, 12, 13 of the vehicle 10 or the diagnostic device 20, for the sake of simplicity, reference is made below to the vehicle 10 and the vehicle diagnostic device 20.

[0051] The Fig. 3 The diagram schematically shows 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.

[0052] After connecting the plug of the diagnostic device 20 to the vehicle diagnostic interface 13, a communication connection is established between the vehicle diagnostic device 20 and the vehicle 10 (S10).

[0053] Typically, vehicle identification is required so that the vehicle diagnostic tool 20 can assign the fault codes to a specific vehicle 10, in particular the make, type, and equipment of the vehicle 10. Therefore, (S11) the vehicle diagnostic tool 20 sends a request to the vehicle 10 to identify the vehicle. Subsequently, (S12) the vehicle 10 sends at least one vehicle identification identifier, which may be stored in a vehicle-side memory, 1 to the vehicle diagnostic tool 12. In alternative embodiments, the make, type, and / or equipment of the vehicle 10 or the vehicle identification identifier is manually entered into the vehicle diagnostic tool 12 by a technician or vehicle mechanic.

[0054] The vehicle diagnostic tool 20 can then request the fault codes from vehicle 10 (S13). Vehicle 10 then sends the requested fault codes to the vehicle diagnostic tool 20, and the vehicle diagnostic tool 20 receives (S14) the vehicle fault codes. After receipt, the fault codes can be analyzed and evaluated by the vehicle diagnostic tool 12.

[0055] For a more precise diagnosis, the vehicle diagnostic tool 20 can additionally request currently measured sensor values ​​or sensor 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 retrieves the requested sensor values, for example, from a vehicle-side memory or communicates with the corresponding vehicle sensors to output or acquire the sensor values. The sensor values ​​are then sent from the vehicle control unit 11, 12 to the vehicle diagnostic tool 20 for further evaluation or processing (S16). Based on the fault codes and the sensor values, the vehicle diagnostic tool 20 can determine which component in the vehicle is defective and requires repair.

[0056] It should be noted that certain transmission and reception steps can be combined. For example, steps S11 and S13, and S12 and S14, can each be combined.

[0057] Furthermore, the vehicle diagnostic tool can send 20 commands to the vehicle control unit 11, 12. For example, a command to the vehicle control unit includes a sensor setting or a change to the sensor setting, where the setting includes, for example, the sensor sensitivity, the frequency of measurements and / or the timing of the measurements.

[0058] Additionally or alternatively, the status of the vehicle control unit 11, 12 can be changed or set by the vehicle diagnostic device 20 via a corresponding message. This could include, for example, the inspection interval, the control of actuators, or similar functions. The vehicle diagnostic procedure is described below.

[0059] Vehicle diagnostics can alternatively also be performed using the in Fig. 2The procedure is carried out using the system 40 shown. System 40 comprises the previously described vehicle diagnostic device 20 and a server 30. As explained above, 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 via a wired connection 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 described below.

[0060] First, a communication connection is established between the diagnostic device 20 and the vehicle 10 (S10). Then (or before or simultaneously), a communication connection is established between the diagnostic device 20 and the server 30 (S20). Now the diagnostic device 20 is able to mediate communication between the server 30 and the vehicle 10. In this way, the diagnostic device 20 can transmit data or messages between the vehicle 10 and the server 30.

[0061] Typically, vehicle identification (VIN) is required so that server 30 can assign the fault codes to a specific manufacturer and vehicle type. Therefore, server 30 sends a request (S21) to diagnostic device 20 to identify VIN, which then forwards the request to VIN (S11). VIN 10 then sends at least one VIN, which may be stored in the vehicle's memory, via diagnostic device 20 to server 30 (S22).

[0062] Server 30 can then request fault codes from vehicle 10. Diagnostic tool 20 forwards the request from server 30 to vehicle control unit 10 (S23, S13). Vehicle 10 then sends (S14) the requested fault codes to diagnostic tool 20, which sends the fault codes to server 30 (S24). Upon receipt, server 30 can analyze and evaluate the fault codes.

[0063] For a more precise diagnosis, server 30 can additionally request sensor readings from vehicle 10. This occurs, for example, via a request forwarded from diagnostic device 20 to vehicle 10 (S25, S15). Vehicle 10 retrieves the requested sensor readings from its onboard memory or communicates with the corresponding vehicle sensors to output or acquire the sensor readings. The sensor readings are then sent from vehicle 10 to diagnostic device 20 (S16) and from diagnostic device 20 to server 30 for further evaluation or processing (S26). Based on the fault codes, the identification method, and the sensor readings, server 30 can determine which component in vehicle 10 is defective and requires repair.

[0064] It should be noted that certain transmit and receive steps can be combined. For example, steps S21 and S23, S11 and S13, S12 and S14, and S22 and S24 can each be combined.

[0065] Furthermore, the server 30 can send commands to the vehicle 10 via the diagnostic device 20. For example, a command to the vehicle includes a sensor setting or a change to the sensor setting, where the setting includes, for example, the sensor's sensitivity, the frequency of measurements, and / or the timing of the measurements.

[0066] Additionally or alternatively, the status of vehicle 10 can be changed or set by server 30 via a corresponding message. Examples of possible changes in this context would include inspection intervals, control of actuators, or similar functions.

[0067] Vehicle 10 can also receive new software components or updates that server 30 sends to vehicle 10 via diagnostic device 20.

[0068] It goes without saying that the ones in the Figures 1 and 2 The features and steps shown in sections 3 and 4 and described above can be combined, provided the combinations are not mutually exclusive. Features and steps mentioned only in relation to diagnostic device 20 can also be applied to server 30 and system 40, and vice versa.

[0069] In system 40, instead of the vehicle diagnostic device 20 shown, a mobile device such as a mobile phone, laptop, computer, tablet PC, or the like can be used. This device is connected to the vehicle 10, in particular via the vehicle interface 13, and to the server 30, and mediates the communication between the vehicle 10 and the server 30. The mobile device therefore preferably forwards messages such as commands and / or requests or data such as measured values ​​and / or DTCs from the vehicle 10 to the server 30 and vice versa.

[0070] The following section discusses in more detail the actual vehicle diagnostics, which can be carried out in particular by the vehicle diagnostic device 20, the server 30 or the system 40.

[0071] Typically, automated vehicle recognition is performed first. This recognition process uses at least the vehicle identification method mentioned above, which may include a vehicle identification number (VIN), an engine code, an electronic control unit (ECU) identification number, and / or a short description. This vehicle identification method is compared with known vehicle identifiers in the database to identify vehicle 10. In some cases, the VIN alone is insufficient to unambiguously identify vehicle 10. In these cases, patterns are extracted from manually selected vehicles with existing VINs in the database; these patterns can also be used for unknown VINs. By including the engine code and the short description, vehicles from different manufacturers can be identified when the VIN alone is insufficient.

[0072] The following step then follows: Received S14, S24 a variety of vehicle error codes 10.

[0073] The procedure further comprises the following steps: Determining at least one initial vehicle fault condition, wherein the vehicle fault condition represents a state of vehicle 10 in which at least one of the fault codes in vehicle 10 has been triggered, based on the respective fault code and historical vehicle data from a database outside of vehicle 10; determining relevant sensor measurements to be measured based on the fault codes. Requesting the induction of at least the first vehicle fault condition, preferably by displaying a request on a display of the diagnostic device 20, and receiving S16, S26 of the measured sensor values ​​of the vehicle 10.

[0074] This determines a vehicle condition that the mechanic and / or the vehicle 10 should induce in order to obtain high-quality sensor readings (e.g., increased idle speed, test drive, activation of the air conditioning). For this purpose, historical vehicle data from the database is preferably accessed. The database is stored on a storage medium that is, for example, part of the diagnostic device 20, the server 30, or another server. The historical vehicle data includes at least the vehicle manufacturer, vehicle type, vehicle equipment, fault codes, mileage, vehicle age, sensor readings, and / or sensor parameters.

[0075] Typically, historical data is used to check the vehicle's previous state when the fault code appeared (e.g., based on speed or engine RPM) or whether an actuator test was performed on components (e.g., whether the blower or air conditioning was activated). Furthermore, historical data can be used to determine which sensor parameters are most frequently selected by users when a corresponding fault code is present. By inducing the initial vehicle fault state, relevant measurements can be collected and subsequently used for diagnosis.

[0076] The vehicle state can be brought about, for example, by changing or adjusting at least one actuator, changing or adjusting at least one vehicle parameter, switching at least one vehicle module on or off, and / or switching at least one vehicle control unit on or off. Once the vehicle has been put into the vehicle fault state, a corresponding confirmation can be sent to the vehicle diagnostic device 20 or the server 30.

[0077] If necessary, depending on the error code, several vehicle fault states can be successively induced, in each of which relevant sensor parameters are measured.

[0078] To increase accuracy, the relevance of each fault code can be determined. The fault codes are then sorted and weighted according to their relevance. For example, only the most relevant fault codes are considered for diagnosis. Less relevant fault codes can be disregarded. If, for instance, the average time between the fault code being triggered and cleared exceeds a predetermined duration, the fault can be classified as non-relevant. Conversely, the fault code can be classified as relevant if the average time between its triggering and clearing falls below a predetermined duration.

[0079] Alternatively or additionally, the fault codes can be classified by comparing them with historical fault codes from the database according to vehicle assembly groups and / or customer groups and / or correlating historical fault codes. Correlating fault codes are those that occur more frequently on average when the fault code itself is present. If the fault code is assigned to a specific vehicle assembly group, then the correlating fault codes can also be assigned to that assembly group. The relevance of each fault code can then be determined based on its classification.

[0080] Furthermore, the procedure includes the following step: Identifying at least one potentially defective component in the vehicle 10, in particular based on the fault codes, the measured sensor readings and the vehicle's mileage.

[0081] Preferably, requests for technical information, such as repair information or vehicle component information, are stored by the mechanic in a log on the diagnostic device 20. This is also referred to as logging. The logging data is preferably also stored in the database. The logging data can be taken into account when identifying the potentially defective component.

[0082] When a mechanic reads out a fault code or measured values, they typically select the relevant information needed for the repair on diagnostic tool 20, based on their automotive expertise. Often, the mechanic has access to up to 18 different categories with further subcategories on diagnostic tool 20: for example, wiring diagrams, labor values, or component test values. With conventional solutions, the mechanic had to make a suitable selection in each category. After selecting the categories and displaying the content, the corresponding categories (path to the content) are stored in the database (e.g., on server 30 and / or diagnostic tool 20). Based on the categories and their content, relevant components or component information are extracted, for example, from the memory of diagnostic tool 20 or the database.

[0083] According to further training, at least one potentially defective component is additionally identified based on customer service data and / or invoice data from car repair shops and / or access to repair information in the database.

[0084] In another variation, the procedure can include the following step: determining context-related repair information based on fault codes and / or sensor readings and / or potentially defective components. Context-related repair information includes, for example, wiring diagrams, labor values, or component test values ​​that the user needs to repair the vehicle or rectify the fault. This context-related repair information can be determined using historical logging data.

[0085] Additionally, the relevance of the fault codes can be determined, for example, based on similar historical fault codes. If, for instance, fault codes remain set over a longer period, this indicates that the fault code is less relevant. Historical fault codes from customer groups that focus on repairing less critical problems (e.g., "glaziers") can also be used to classify relevance. If fault codes outside their focus are read out (e.g., fault codes generated based on engine sensor readings), this also indicates that the fault code is less relevant, as the customer's issue concerns a different problem.

[0086] Based on historical vehicle data (relevant error codes, sensor readings and mileage) in conjunction with the extracted components, predictive models can be developed.

[0087] Furthermore, anomalies in the sensor readings can be detected. A self-learning system (diagnostic device 20, server 30, or system 40) is designed to identify correlating sensor readings and related sensor parameters and form a main cluster (the majority of all healthy measurement points) on which outlier models can be trained. Error codes can also be included to identify the main cluster. This means that the measurements in the main cluster preferably contain no error codes or a number of error codes that does not exceed a predetermined limit. These models can be applied to current sensor measurements and calculate the probability of classifying the measurement as an outlier / anomaly. Measurements within a target range are thus considered positive, while measurements outside the target range are considered negative.Correlating and / or related sensor measurements can be considered to determine the target range. The measured sensor values ​​can be compared with the respective target ranges to identify outliers in the sensor measurements. For example, the degree of deviation of the measured value from the target range can be indicated, such as by displaying it on the diagnostic device 20. These models enable a visualization / display of the current measured value along with a target measured value, including its tolerance range. This allows for the traceability of the results and enables the mechanic to better assess how the results were obtained.

[0088] Optionally, the procedure includes at least one of the following steps: Creating and displaying a list of potentially defective components, creating and displaying context-related component information for the defective components, and / or identifying and displaying necessary repair steps.

[0089] It is understood that the embodiments shown in the figures and described above can be combined with one another, provided that the combinations are not mutually exclusive. Features mentioned only in relation to the vehicle diagnostic device 20 and / or the server 30 can also be claimed for the system 40 or the method, and vice versa. Reference symbol list:

[0090] 10 Vehicle 11 Vehicle control unit 12 Vehicle control unit 13 Diagnostic interface 20 Vehicle diagnostic device 30 Server 40 System

Claims

1. A method for performing vehicle diagnostics, comprising the steps of: - receiving (S14, S24) a plurality of fault codes from a vehicle (10), - determining at least one first vehicle fault state, the vehicle fault state constituting a state of the vehicle (10) in which at least one of the fault codes has been triggered in the vehicle (10), on the basis of the relevant fault code and historical vehicle data from a database, - determining relevant sensor measurement variables to be measured on the basis of the fault codes, - requesting that at least the first vehicle fault state be induced, - receiving (516, S26) the measured sensor measurement variables from the vehicle (10), - determining at least one potentially defective component.

2. The method according to claim 1, wherein the request for the first vehicle fault state to be induced contains at least one of the following instructions: - changing, activating, or setting at least one final control element, - activating a vehicle function, - changing or setting at least one vehicle parameter, - switching at least one vehicle module on or off.

3. The method according to any of the preceding claims, comprising the additional step of: - determining a relevance of the fault code in question, the relevance of the fault code in question being determined on the basis of an average time interval between triggering and deleting identical historical fault codes and / or wherein the fault codes are classified by vehicle assembly and / or customer group and / or correlating historical fault codes by comparison with historical fault codes from the database, and the relevance of the fault code in question is determined on the basis of the classification of the fault code.

4. The method according to claim 3, wherein the relevance is comparatively high when the average time interval is comparatively short, and wherein the relevance is comparatively low when the average time interval is comparatively long.

5. The method according to any one of the preceding claims, wherein historical logging data from diagnostic tools are additionally taken into consideration for determining the at least one potentially defective component.

6. The method according to claim 5, wherein the historical logging data include retrieved repair information and / or retrieved vehicle component information.

7. The method according to any one of the preceding claims, wherein a target range is determined by comparison with historical vehicle data for each sensor measurement variable, wherein the target range preferably includes a target measurement value and a tolerance range around the target measurement value.

8. The method according to claim 7, wherein correlating sensor measurement variables and / or coherent sensor measurement variables are taken into consideration for determining the target range.

9. The method according to claim 6 or 7, comprising the additional steps of: - comparing the measured sensor measurement variables with the respective target ranges for identifying outliers in the sensor measurement variables and - displaying the comparison on a user interface.

10. The method according to any of the preceding claims, characterised by at least one of the following steps: - receiving (S12, S22) at least one vehicle identification means, the vehicle identification means in particular including a vehicle identification number and / or an engine code and / or a controller identification number and / or a code designation, - comparing the vehicle identification means with known vehicle identification means from the database, and - identifying the vehicle (10) to be diagnosed in a vehiclemanufacturer-independent manner on the basis of the comparison.

11. The method according to any one of the preceding claims, wherein the historical vehicle data include the vehicle identification means, vehicle manufacturer, vehicle type, vehicle equipment, fault codes, mileage, vehicle age, sensor measurement values, and / or sensor measurement variables.

12. The method according to any of the preceding claims, characterised by the additional step of: determining context-based repair information on the basis of the fault codes and / or the sensor measurement variables and / or the potentially defective components.

13. The method according to any one of the preceding claims, wherein the at least one potentially defective component is additionally determined on the basis of service data and / or billing data at garages and / or on the basis of accessing repair information in the database.

14. The method according to any one of the preceding claims, wherein the fault codes are evaluated on the basis of the measured sensor measurement variables, wherein the at least one potentially defective component is determined on the basis of the fault codes and the measured sensor measurement variables.

15. A diagnostic device designed for carrying out the method according to any of the preceding claims, wherein the diagnostic device in particular comprises a vehicle diagnostic tool (20) and / or a server (30).

Images