Method and device for identifying a fault cause of a fault event in a vehicle based on a vehicle
By using an LSTM-based recurrent classification model in vehicles to identify fault causes, the problem of difficulty in identifying fault causes in existing technologies is solved, thereby improving the accuracy and efficiency of fault diagnosis.
Patent Information
- Application Number
- CN202480048670.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-07-25
- Filing Date
- 2024-07-17
- Publication Date
- 2026-02-24
AI Technical Summary
When a vehicle malfunctions, the cause of the malfunction is difficult to identify clearly. Existing technologies often rely on intuitive operation or diagnostic software, which means that the order of inspection and the identification of the cause of the malfunction may not be the optimal approach.
A data-based recurrent classification model, particularly an LSTM network, is employed. By collecting and encoding time series data of vehicle events, the model is trained to identify the causes of failures and uses timestamps and event stamps to correlate and predict vehicle events.
It enables efficient identification of vehicle malfunction causes, improves the accuracy and efficiency of fault diagnosis, and reduces unnecessary inspection steps and resource waste.
Smart Images
Figure CN121569255A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to identifying the cause of a malfunction in a vehicle, particularly based on the chronological sequence of past vehicle events, after the malfunction has occurred. The invention further relates to a method for diagnosing a vehicle based on the chronological sequence of vehicle events and diagnostic events involving successive and / or simultaneous inspection interventions. Background Technology
[0002] When a malfunction occurs in a vehicle, the cause is often not clearly identified. Therefore, a series of checks are typically performed in the workshop, and the results are evaluated. The results are derived from a series of diagnostic steps in the workshop. Workshop staff intuitively, or diagnostic software, prescribes the order of checks within the scope of guided fault finding. Due to this intuitive approach in the workshop, the order and selection of checks, as well as the definition of the cause of the malfunction, are not always the optimal methods for finding the root cause. Summary of the Invention
[0003] According to the present invention, a computer-implemented method for finding future malfunction events in a vehicle as described in claim 1, and a corresponding apparatus as described in the parallel claims are provided.
[0004] Other design options are described in the dependent claims.
[0005] According to the first aspect, a method for identifying the cause of a fault in a vehicle is provided, comprising the following steps: - Collect vehicle events in a time-series manner during the vehicle's service life; -Especially after a failure occurs, a time series of input vectors is created, in which vehicle events collected and descriptions of the failures are encoded; - Provides a data-based cyclic classification model, which is trained to assign a time series of an input vector to an output vector having a description of the probability of the cause of the failure occurring; - Evaluate the data-based cyclic classification model based on the sequence created from the input vector in order to determine the most likely cause of the failure. - Use signals to indicate the most likely cause of the malfunction.
[0006] During the operation of a motor vehicle, data on vehicle events that occur are continuously collected. Vehicle events include operational events, repair events, malfunction events, and diagnostic events at specific points in time.
[0007] Vehicle events collected during the vehicle's lifespan can thus be transmitted to a central unit and / or stored in the vehicle's memory, each equipped with a timestamp. Additional events are added, stored for the corresponding vehicle at the vehicle manufacturer or other organization, such as an insurance company.
[0008] Events that characterize driver-specific and / or vehicle-specific operations are considered operational events. These include events such as driving at high speeds above a speed threshold and for a duration exceeding a predetermined driving time, impacts caused by driving on uneven ground or by collisions with environmental objects at accelerations above a pre-given threshold, environmental conditions such as very low or very high ambient temperatures (defined by not exceeding or exceeding limits, respectively) for a predetermined minimum duration, rainfall, the timing and scale of software updates, driver input and changes to preset settings, alarm device triggering, and limited field of view of external cameras.
[0009] Fault events can be identified through automatic monitoring functions in the control equipment. These faults are stored in a fault memory and, when necessary, transmitted to a central unit, which records the time sequence of the faults that occurred. Additionally, fault events can also be identified and recorded through driver observation.
[0010] A repair event corresponds to a specific repair, replacement, or other event involving a vehicle component, such as an event that occurs during a workshop visit for repair or periodic maintenance.
[0011] Furthermore, during workshop visits, diagnostic procedures can be performed, resulting in outcomes that can be provided as diagnostic events or results. Diagnostic results may include, for example, measurements of battery voltage, readouts from fault memory, etc. Repair measures are typically stored electronically and are therefore available as vehicle-specific events.
[0012] All vehicle events are equipped with timestamps and / or mileage readings, indicating when the events occurred and, consequently, their sequence. Therefore, for each vehicle, there exists a history of vehicle events arranged chronologically by timestamps.
[0013] In complex systems like vehicles, events within the vehicle influence subsequent operation and behavior, potentially affecting, accelerating, or delaying the development of faults, and, if necessary, even promoting their occurrence. However, because very different vehicle events and their sequences have varying effects on the overall vehicle system, these very different events and their sequences have so far been difficult to correlate. Nevertheless, vehicle events may influence each other, and this relationship may not be immediately apparent. However, it is quite possible that past vehicle events may trigger the development of future fault events. It is also conceivable that developing faults are always foreshadowed in the preparatory phase (im Vorfeld) through similar sequences of vehicle events.
[0014] Therefore, it is proposed to use a data-based cyclic classification model to evaluate all vehicle events that occur in order to determine the cause of the failure.
[0015] Therefore, descriptions of defective components, faults such as generator defects, fault types, defective functions, or "screen not displaying" and vehicle events can be encoded according to a mapping table. Here, all vehicle events within a pre-defined time window are aggregated and encoded into an input vector. The time windows are sequential and cover the vehicle's or component's service life to date.
[0016] By employing a data-based cyclic classification model, vehicle events within successive time windows can be evaluated. This classifier enables the identification of the underlying causes of any malfunctions.
[0017] Data-based classification models can be configured as recurrent neural networks, such as LSTM (Long Short-Term Memory), GRU, or transformers. The timestamps of vehicle events allow the vehicle events to be pre-given as inputs based on timelines within successive time windows during the evaluation of the recurrent model, making time referencing between vehicle events possible using the data-based model.
[0018] A preferred data-based model can be an LSTM (Long Short-Term Memory) network, where a state vector is recursively evaluated along with the input vector at the corresponding time step. The input vector represents an encoding of vehicle events that have occurred up to or within a past time window. When multiple vehicle events occur simultaneously, they can be associated in an element-specific manner using vector addition, averaging, or maximum selection to generate each element of the input vector. Such associations can thus be performed element-wise, such that vehicle events assigned to the same element within a time window are correlated or aggregated. Vehicle events assigned to different elements can be integrated into the input vector using simple vector addition.
[0019] In particular, the internal state vector of the data-based classification model can be mapped to an output vector by means of at least one fully connected layer, the elements of which describe the probability of a possible fault cause (among multiple possible fault causes) of the fault that occurred, wherein the most probable fault cause is determined by means of a Softmax function applied to the output vector, which is the fault cause whose assigned element in the output vector has the highest value.
[0020] It can be stipulated that the most probable cause of a failure is signaled by outputting a description of the cause of the failure to the user. In particular, based on the cause of the failure, it can be explained to the user whether the component or function described as the source of the failure is the same as the component or function that caused the failure, or whether the cause of the failure is in a different component or function.
[0021] According to another aspect, an apparatus can be provided, which is configured to perform the above-described method. Attached Figure Description
[0022] The embodiments will now be explained in more detail with reference to the accompanying drawings. Wherein: Figure 1 A schematic diagram of a central unit and a motor vehicle system for collecting vehicle events is shown. Figure 2 A schematic diagram illustrating the timing of vehicle events evaluated using a recurrent neural network; and Figure 3 A flowchart is shown to illustrate a method for identifying the causes of malfunctions occurring in a vehicle using predictive diagnostics based on vehicle events. Detailed Implementation
[0023] Figure 1 The vehicle 1 is shown, which has multiple components and one or more control devices 2, which are designed to identify and control vehicle functions and to identify vehicle events.
[0024] Vehicle events may include operational events, which describe special operating modes or conditions that load the vehicle in a manner exceeding normal levels, such as driving at high speeds above a speed threshold and for more than a specific driving duration, impacts caused by driving on uneven ground or by collisions with environmental objects, and driving conditions such as rainfall of a predetermined intensity for a predetermined minimum duration. Other vehicle events may describe, for example, the timing of software updates or inputs made by the driver to preset parameters.
[0025] In addition, vehicle events may include malfunction events, such as those determined by an automatic monitoring function in one of the control devices.
[0026] In addition, vehicle incidents may also include diagnostic results performed during vehicle workshop visits for repairs or maintenance. Diagnostic results may include, for example, measurements of voltage, readouts from fault memory, etc.
[0027] The identified vehicle events can be transmitted to central unit 3 along with a corresponding timestamp indicating the time when the corresponding vehicle event occurred. Central unit 3 records the temporal sequence of the vehicle events. Alternatively, the occurring fault events can also be collected in the vehicle's internal fault memory in an appropriate manner.
[0028] Vehicle events are stored with appropriate timestamps, which mark the occurrence of events starting from the beginning of the vehicle's service life. The timestamps may indicate the current date and time, the elapsed time since the start of the service life, or the vehicle's mileage in kilometers, or something similar.
[0029] A classification model 31 can be implemented in the central unit 3. This classification model is constructed using data-based recurrent models, such as LSTM, GRU, and Transformer models. Classification model 31 enables the evaluation of the temporal sequence of vehicle events and provides an output vector, the elements of which are assigned to possible causes of failure. The corresponding element values indicate the probability for the relevant cause of failure, thereby enabling the identification of possible causes of failure.
[0030] The classification model 31 is trained accordingly as a recurrent model, and can have, for example, in Figure 2 The structure shown. Combined Figure 3 This describes a method for evaluating a data-based classification model 31.
[0031] In step S1, vehicle events are collected and stored as described above.
[0032] In step S2, vehicle events F1…Fn can be stored using timestamps.
[0033] Alternatively, the timing of vehicle events F1…Fn can be aggregated into successive time windows Z1…Zm, the duration of which can be, for example, between 1 second and 1 hour. The time windows are used to aggregate the vehicle events F1…Fn occurring within them, and to map the vehicle events to an input vector E or an input matrix, respectively. Mapping is performed using an allocation table, which assigns different vehicle events to corresponding elements of the code or input vector.
[0034] The mapping can be performed such that the occurrence or non-occurrence of a vehicle event is marked with an element value of 0 or 1, and the measured value is assigned as an element value to the element of the input vector accordingly. If multiple vehicle events within a time window involve the same element in the input vector E, the corresponding values can be aggregated into a sum, average, or maximum value, depending on the type of the element. Furthermore, the input vector can also describe the fault and / or type of the fault, such as a description of a defective component like a generator or display unit, or a description of a fault type such as a malfunction or a missing or jammed speed display.
[0035] Now in step S3, the data-based cyclic classification model 31 evaluates the temporal sequence of successive input vectors E, wherein the internal state of the classification model 31 is updated at each evaluation.
[0036] At the end of the sequence of input vectors E1…Em, the internal state Z can be used in step S4 to perform classification. Thus, for example, the internal state can be mapped onto multiple labels, each label describing a possible cause of the fault, using at least one fully connected layer 32. The probability of the classification result can be determined from these labels using a softmax function 33. The probability is described for each possible classified cause of the fault.
[0037] Furthermore, the number of diagnostic events during a vehicle's stay in the workshop can vary significantly, as some vehicles may be repaired very quickly with very few inspections, while others require substantial expenditure.
[0038] Regarding classification models constructed as LSTMs, a technique known as Truncated Backpropagation Through Time can be applied. Backpropagation Through Time is a version of the backpropagation method used to train modern recurrent neural networks, such as LSTMs. Truncated Backpropagation Through Time is a modified version of this scheme, which is more efficient in sequence prediction problems with very long sequences. Here, the long sequence of diagnostic events is divided into successive subsequences and processed separately.
[0039] Accordingly, the classification model 31 can be trained using a training dataset of vehicles that exhibit faults with specific known causes after a certain operating duration. By recording the sequence of vehicle events in these vehicles, these vehicle events can be assigned to corresponding fault causes, such that a sequence of input vectors is derived for a corresponding time window, which can be assigned to fault causes. Thus, the training dataset is determined or defined by the temporal sequence (Zeitreihe) of the input vectors and the fault causes (as labels).
[0040] When providing a training dataset in this form, it is assumed that previous vehicle events lead to corresponding malfunction events with specific probabilities. Therefore, this training dataset can be used to train a classification model.
[0041] In the subsequent step S5, a cause of failure can be output for the described fault. For example, this may result in a replacement component of the vehicle whose function has been affected according to the fault description.
Claims
1. A computer-implemented method for identifying the cause of a malfunction occurring in a vehicle, comprising the following steps: - Collect vehicle events in a time sequence during the vehicle's service life (S1); - Especially after a failure occurs, a time series of (S2) input vectors (E) are created, in which vehicle events collected and descriptions of the failures that occurred are encoded; - Provides a data-based cyclic classification model, which is trained to assign a time series of an input vector (E) to an output vector having a description of the probability of the cause of the failure occurring; - Evaluate the data-based cyclic classification model (S3, S4) based on the sequence created from the input vector (E) in order to determine the most likely cause of the failure. - Use a signal (S5) to notify the most likely cause of the fault that occurred.
2. The method according to claim 1, wherein the vehicle events include operation events, repair events, fault events, and diagnostic events.
3. The method according to claim 1 or 2, wherein the input vector (E) further includes basic vehicle data, particularly information about the manufacturing date, components, special equipment, and / or the manufacturing plant.
4. The method of claim 2, wherein the operational events describe events characterizing individual driver operations, particularly over-the-air updates, alarm device triggering, acquired temperature and / or acquired voltage, wherein fault events describe identified faults through automatic monitoring functions in the control equipment, wherein repair events correspond to specific repairs or replacements of vehicle components, and wherein diagnostic events correspond to the results of workshop inspections.
5. The method according to any one of claims 1 to 4, wherein vehicle events collected during the service life are stored in a central unit outside the vehicle and / or in the vehicle's memory in a manner provided with timestamps, mileage descriptions, or incremental event counters according to the sequence of occurrence.
6. The method according to any one of claims 1 to 5, wherein a sequence of input vectors (E) is created by assigning vehicle events in successive time windows to the input vectors (E), wherein the vehicle events are respectively encoded onto at least one element of the input vectors (E), wherein the element values determined by multiple vehicle events within the relevant time window are correlated with each other.
7. The method according to any one of claims 1 to 6, wherein a data-based classification model is set up using a recurrent neural network, particularly in the form of an LSTM (Long Short-Term Memory network), a GRU, or a transformer (31).
8. The method according to claim 7, wherein the internal state vector of the data-based classification model (31) is mapped to an output vector by means of at least one fully connected layer (32), the elements of the output vector describing the probability of the possible causes of the fault, wherein the most likely cause of the fault is determined by means of a Softmax function (33) applied to the output vector.
9. The method according to any one of claims 1 to 8, wherein the most probable cause of failure is notified by signaling a description of the cause of failure, wherein in particular, the description of the cause of failure describes whether the component or function to which the failure is located is the source of the failure.
10. An apparatus (3) configured to perform the method according to any one of claims 1 to 9.
11. A computer program comprising instructions that, when executed in the apparatus of claim 9, cause the apparatus to perform the steps described herein.
12. A machine-readable storage medium having a computer program as claimed in claim 11 stored thereon.