Fault early warning method, device, equipment and storage medium

Abstract

The application discloses a fault early warning method and device, equipment and storage medium, the method first obtains vehicle fault data before and after the target fault occurs; based on the mapping relationship between the model version number and the data processing rule pre-stored in the cloud, the current version number of the vehicle fault early warning model deployed in the cloud is determined, the target data processing rule corresponding to the current version number, the target data processing rule is the data processing rule adopted by the model in the corresponding version training process; then the vehicle fault data is processed according to the target data processing rule and input into the model, the fault early warning result containing early warning, fault and normal is obtained, and whether the early warning is triggered is judged accordingly. Through the unified data processing rule of model offline training and online inference, the problem that the actual operation accuracy of the cloud model is low and the early warning is easy to fluctuate is solved, the operation accuracy and early warning stability of the model are significantly improved, and the accuracy and stability of the vehicle fault early warning are ensured.

Description

Technical Field

[0001] This invention relates to the field of fault diagnosis technology, and in particular to a fault early warning method, device, equipment and storage medium. Background Technology

[0002] In vehicle fault warning technology, cloud-based vehicle fault warning models are typically deployed to enable online monitoring and early warning of vehicle faults. After acquiring vehicle fault data, the cloud processes the data and inputs it into the model to obtain the warning result. However, currently, cloud-deployed vehicle fault warning models suffer from lower actual operating accuracy than their offline training accuracy, which can easily lead to fluctuations in warnings and affect the accuracy and stability of fault warnings.

[0003] Therefore, improving the operational accuracy of cloud-deployed vehicle fault warning models and reducing warning fluctuations are urgent technical problems that need to be solved. Summary of the Invention

[0004] This invention provides a fault early warning method, device, equipment, and storage medium to solve the technical problems of low operating accuracy and fluctuating early warning in cloud-deployed vehicle fault early warning models in the prior art.

[0005] Firstly, a fault early warning method is provided, applied in the cloud, wherein a vehicle fault early warning model is deployed in the cloud, and the method includes: Acquire vehicle fault data, which is vehicle operation data before and after the occurrence of the target fault; Obtain the current version number of the vehicle fault warning model, and based on the mapping relationship between the model version number and data processing rules pre-stored in the cloud, determine the data processing rule corresponding to the current version number as the target data processing rule; wherein, the target data processing rule is the data processing rule adopted by the vehicle fault warning model during the training process of the corresponding version. The vehicle fault data is processed based on the target data processing rules, and the processed data is input into the vehicle fault early warning model to obtain the fault early warning result output by the model. The fault early warning result includes early warning, fault, and normal. Based on the fault warning results, determine whether to trigger a vehicle fault warning.

[0006] In some embodiments, the target data processing rules include data standardization rules, data leakage prevention and control rules, key data screening rules, and key data preprocessing rules; The processing of the vehicle fault data based on the target data processing rules includes: The vehicle fault data is converted into standard fault data with a unified format and time sequence alignment according to the data standardization rules to obtain a standard data set; According to the data leakage prevention and control rules, data containing explicit information after a failure occurs are removed from the standard data set to obtain a candidate data set; According to the key data filtering rules, key data related to the target fault are filtered from the candidate data set to obtain the key data set; According to the key data preprocessing rules, the data in the key data set is filled in for missing data and normalized. Based on a preset time window, the data in the key data set is divided into multiple time-series samples, which are used as input data to the vehicle fault warning model.

[0007] In some embodiments, the vehicle fault data includes a vehicle identification number and a timestamp corresponding to each data entry, and the data standardization rules include: The vehicle fault data is uniformly parsed and converted to ensure that the data format, field definition and data type are consistent. Based on the vehicle identification code and the timestamp, the vehicle fault data is time-synchronized, and the vehicle fault data is uniformly sorted and integrated into standard fault data according to the time sequence.

[0008] In some embodiments, the data leakage prevention and control rules include: Based on the semantic category of each field in the standard data set, data containing conclusive fields are removed; the conclusive fields are fields whose semantic category belongs to the fault determination result category, including at least one of the following: fault code field, diagnostic conclusion field, after-sales diagnostic conclusion field, and repair work order field. Based on the temporal change characteristics of each field in the standard data set, data containing posterior fields are removed; the posterior fields are fields that only change significantly after a fault occurs and are strongly bound to the time of the fault occurrence, including at least one of alarm trigger flag, alarm latch flag, protection degradation result status, fault posterior statistics, and reset status.

[0009] In some embodiments, the key data filtering rules include: Based on a pre-constructed multi-strategy comprehensive evaluation method, the data in the candidate data set are evaluated, and key data is selected from the candidate data set according to the evaluation results. The multi-strategy comprehensive evaluation method includes at least one of the following: correlation test evaluation method, statistical significance test evaluation method, and feature importance evaluation method.

[0010] In some embodiments, before deploying the vehicle fault warning model of the current version number in the cloud, the method further includes: Acquire historical fault data for multiple vehicles; The historical fault data is processed according to the target data processing rules. The pre-constructed initial vehicle fault warning model is trained based on the processed historical fault data to obtain the current version of the vehicle fault warning model. The current version of the vehicle fault warning model is deployed in the cloud, and the mapping relationship between the current version of the model and the target data processing rules is stored in the cloud.

[0011] In some embodiments, processing the historical fault data according to the target data processing rules includes: The historical fault data is converted into standard historical fault data with a unified format and time sequence alignment according to the data standardization rules to obtain a standard historical data set; According to the data leakage prevention and control rules, data containing explicit information after the failure occurred is removed from the standard historical data set to obtain a candidate historical data set; A three-class fault label is constructed for the data in the candidate historical data set, and the three-class fault label includes three types of fault labels: normal, warning and fault. The data in the candidate historical data set after the labels are constructed are divided into a training set, a validation set, and a test set; According to the key data filtering rules, key historical data related to the target fault are filtered from the training set to obtain a key historical data set; According to the key data preprocessing rules, the data in the key historical data set is filled in for missing data and normalized. Based on a preset time window, the data in the key historical data set is divided into multiple historical time series samples, wherein the multiple time series samples are used as training data for the vehicle fault warning model.

[0012] In some embodiments, determining whether to trigger a vehicle fault warning based on the fault warning result includes: When the fault warning result is a warning and the warning duration reaches the duration threshold, a vehicle fault warning is triggered.

[0013] In some embodiments, after triggering a vehicle malfunction warning, the method further includes: An abnormal vehicle detection log is generated and sent to the R&D end. The abnormal vehicle detection log includes at least the vehicle identification code, key data segments within a preset time period before and after the warning time, the current version number of the vehicle fault warning model, and the target data processing rule corresponding to the current version number. Receive maintenance suggestions from the R&D team based on the vehicle inspection logs; Based on the maintenance recommendations, the urgency level of the maintenance is determined, and a maintenance work order corresponding to the urgency level is generated; Based on the level of the repair work order, the work order is sent to the corresponding target terminal, so that the target terminal executes the handling plan corresponding to the level of the repair work order. The target terminal includes at least one of the vehicle terminal, the vehicle owner terminal, and the after-sales service terminal. Receive the processing results fed back from the target terminal.

[0014] Secondly, a fault warning device is provided, applied in the cloud, wherein a vehicle fault warning model is deployed in the cloud, and the device includes: The acquisition module is used to acquire vehicle fault data and the current version number of the vehicle fault early warning model. The vehicle fault data is the vehicle operation data before and after the target fault occurs. The determination module is used to determine the data processing rule corresponding to the current version number as the target data processing rule based on the mapping relationship between the model version number and the data processing rule pre-stored in the cloud; wherein, the target data processing rule is the data processing rule adopted by the vehicle fault warning model during the training process of the corresponding version; The processing module is used to process the vehicle fault data based on the target data processing rules, and input the processed data into the vehicle fault early warning model to obtain the fault early warning result output by the model. The fault early warning result includes early warning, fault, and normal. The early warning module is used to determine whether to trigger a vehicle fault warning based on the fault warning result.

[0015] Thirdly, an electronic device is provided, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the fault warning method as described in the first aspect.

[0016] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing the computer to perform the fault warning method as described in the first aspect.

[0017] The technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: This invention provides a fault early warning method, apparatus, device, and storage medium. By constructing a mapping relationship between model version numbers and data processing rules, after acquiring vehicle fault data in the cloud, a target data processing rule corresponding to the current version number of the vehicle fault early warning model can be determined based on this mapping relationship. The vehicle fault data is then processed based on this target data processing rule and input into the model to obtain the fault early warning result. This approach achieves consistent reuse of data processing rules during model training and online inference after cloud-deployed models. It effectively solves the problem that the actual operating accuracy of cloud-deployed vehicle fault early warning models is lower than that during offline training, and that early warning fluctuations are prone to occur due to inconsistencies in data processing rules between offline training and online inference links. This significantly improves the operating accuracy of cloud-deployed models, greatly reduces early warning fluctuations, and ensures the accuracy and stability of fault early warnings.

[0018] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0019] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart of a fault early warning method provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a fault early warning device provided in an embodiment of the present invention. Detailed Implementation

[0020] To better understand the above technical solutions, the following will describe the above technical solutions in detail with reference to the accompanying drawings and specific implementation methods. It should be understood that the embodiments of this disclosure and the specific features in the embodiments are detailed descriptions of the technical solutions of this application, rather than limitations on the technical solutions of this application. Unless otherwise specified, the embodiments of this application and the technical features in the embodiments can be combined with each other.

[0021] Figure 1 This is a flowchart of a fault early warning method provided in an embodiment of the present invention, such as... Figure 1 As shown, this fault warning method is applied in the cloud, where a vehicle fault warning model is deployed. The method includes: Step S110: Obtain vehicle fault data, which is the vehicle operation data before and after the target fault occurred.

[0022] For example, the vehicle-side collects operational data after power-on through pre-embedded sensors, controllers, and related functional modules, and uploads it to the cloud platform via a communication link. The vehicle fault data includes timing signals from at least one or more domains related to the target fault, including but not limited to the power domain, battery management domain, thermal management domain, body domain, vehicle control domain, smart cockpit domain, or assisted driving domain. This allows real-world operational data in complex scenarios to be aggregated to the cloud via a collaborative edge-cloud approach, enabling subsequent early warning analysis to operate without relying on the high computing power requirements of the vehicle-side hardware, achieving a lightweight vehicle-side, cloud-heavy, and feasible engineering architecture.

[0023] To meet the needs of subsequent data alignment, traceability, and closed-loop processing, vehicle fault data uploaded by the vehicle terminal can carry at least: vehicle identification, timestamp, vehicle model / software version identification, and signal identification / sampling caliber information. Among these, the sampling caliber information refers to the unified collection standard followed by the vehicle terminal when collecting vehicle operation signals, including requirements such as sampling frequency, accuracy, and range, ensuring consistent and traceable collected data. There are two methods for uploading vehicle terminal data: real-time upload, where the vehicle terminal sends the collected data to the cloud immediately; and batch upload, sending data collected over a period of time to the cloud at fixed time intervals. Simultaneously, all uploaded data will be organized according to vehicle-time window (i.e., which vehicle and which time period). This provides strong support for subsequent judgment on the continuity of warnings and the generation of abnormal vehicle detection related to warnings, providing comprehensive and standardized basic data support for subsequent data processing and warning analysis.

[0024] Step S120: Obtain the current version number of the vehicle fault warning model, and based on the mapping relationship between the model version number and the data processing rules pre-stored in the cloud, determine the data processing rule corresponding to the current version number as the target data processing rule; wherein, the target data processing rule is the data processing rule adopted by the vehicle fault warning model during the training process of the corresponding version.

[0025] After the vehicle fault warning model processes the data according to a certain data processing rule during the offline training phase, the cloud can define a model version number for the trained vehicle fault warning model and store the mapping relationship between the model version number and the corresponding data processing rule. This realizes the binding management of model version and data processing rule, ensuring that the data processing rule used for subsequent online inference of the model is completely consistent with that used during model training. This fundamentally avoids the problem of inconsistency between offline training and online inference, and provides a guarantee for improving the accuracy of model operation and reducing warning fluctuations.

[0026] Step S130: Process the vehicle fault data based on the target data processing rules, and input the processed data into the vehicle fault early warning model to obtain the fault early warning result output by the model. The fault early warning result includes early warning, fault, and normal.

[0027] For example, when the fault warning result is a warning, the fault warning result may also include a warning level. The warning level can be divided into different levels according to the urgency of the fault evolution, the speed of risk spread, the impact of the warning fault on vehicle operation, and the difficulty of maintenance. This facilitates the implementation of differentiated warning triggering and handling strategies based on different levels, further improving the pertinence and rationality of fault warning and handling, and providing a clear level basis for subsequent generation of graded work orders and multi-channel handling.

[0028] Step S140: Based on the fault warning results, determine whether to trigger a vehicle fault warning.

[0029] This method enables consistent reuse of data processing rules during model training and online inference after model deployment in the cloud. It effectively solves the problem that the actual operating accuracy of the vehicle fault warning model deployed in the cloud is lower than that during offline training and is prone to warning fluctuations due to the inconsistency of data processing rules between offline training and online inference links. It significantly improves the operating accuracy of the cloud-deployed model, greatly reduces warning fluctuations, and ensures the accuracy and stability of fault warnings.

[0030] In some embodiments, the target data processing rules include data standardization rules, data leakage prevention and control rules, key data screening rules, and key data preprocessing rules. Therefore, step S130, which processes vehicle fault data based on the target data processing rules, includes: Step S131: Convert the vehicle fault data into standard fault data with a unified format and time sequence alignment according to the data standardization rules to obtain a standard data set.

[0031] Step S132: According to the data leakage prevention and control rules, remove data containing explicit information after the failure from the standard data set to obtain a candidate data set.

[0032] Step S133: Select key data related to the target fault from the candidate data set according to the key data filtering rules to obtain the key data set.

[0033] Step S134: Perform missing data completion and normalization on the data in the key data set according to the key data preprocessing rules, and divide the data in the key data set into multiple time series samples based on the preset time window. The multiple time series samples are used as input data for input to the vehicle fault warning model.

[0034] The aforementioned method employs a multi-layered and progressively optimized process for vehicle fault data. This process involves standardizing and unifying multi-source heterogeneous data, preventing data leakage by eliminating posterior interference, selecting and refining core features from key data, and preprocessing key data to optimize data integrity and consistency. This effectively eliminates data format differences, temporal deviations, redundant noise, and posterior interference, thereby improving the quality of the data ultimately input into the vehicle fault warning model. This ensures that the input data accurately and comprehensively characterizes the early evolution features of the target fault, providing reliable data support for the model's accurate inference and stable output of fault warning results. Furthermore, this enhances the operational accuracy of the cloud-based vehicle fault warning model and reduces warning fluctuations.

[0035] In some embodiments, the vehicle fault data includes a vehicle identification number and a timestamp corresponding to each data entry. In this case, the data standardization rules in step S131 may include: Vehicle fault data is uniformly parsed and transformed to ensure consistent data format, field definitions, and data types. Based on vehicle identification codes and timestamps, vehicle fault data is time-synchronized and then sorted and integrated into standard fault data according to time series.

[0036] This step achieves a unified standard for multi-source heterogeneous vehicle fault data, eliminating the impact of data format differences and timing deviations on subsequent processing and model inference, and providing a unified data foundation for subsequent data governance and screening.

[0037] For example, unified parsing and data transformation of vehicle fault data can be achieved by using a preset parsing script to convert the format, map fields, and unify the types of heterogeneous data output from different controllers / modules. This converts unstructured and semi-structured raw data into structured data, a conventional technique that will not be elaborated upon here. Time synchronization processing of vehicle fault data based on vehicle identification codes and timestamps can be performed. Using the vehicle identification code as a unique identifier, all operational data of the same vehicle can be sorted by timestamp from smallest to largest. Data with timestamp discrepancies or missing data can be calibrated and supplemented, ensuring the temporal continuity of data from different sources and at different collection times for the same vehicle, thus achieving temporal alignment of multi-source data.

[0038] In some embodiments, during the unified parsing, data conversion, and time synchronization of vehicle fault data, the cloud can simultaneously perform basic data quality control. Specifically, the cloud can perform basic quality marking on data quality issues such as communication interruption segments, data missing rates, and abnormal signal jumps in the vehicle fault data. This marking is only used as reference information for subsequent data missing completion, online consistency verification, and log auditing, to assist in the optimization of subsequent data processing steps, and is not used as an input signal to directly characterize the fault conclusion. This avoids introducing posterior bias and ensures that subsequent data leakage prevention and control, key data screening, and model inference are not interfered with by posterior fault information, thus ensuring the accuracy and reliability of the entire early warning process.

[0039] In some embodiments, the data leakage prevention and control rules in step S132 include: Based on the semantic categories of each field in the standard dataset, data containing conclusive fields are removed; conclusive fields are fields whose semantic categories belong to the fault determination result category, including at least one of the following: fault code field, diagnostic conclusion field, after-sales diagnostic conclusion field, and repair work order field. Based on the temporal change characteristics of each field in the standard dataset, data containing posterior fields are removed. Posterior fields are fields that change significantly only after a fault occurs and are strongly bound to the time of the fault occurrence, including at least one of the following: alarm trigger flag, alarm latch flag, protection degradation result status, fault posterior statistics, and reset status.

[0040] This step avoids the model learning explicit information after a failure occurs, ensuring that the model learns risk representations in the early stages of failure evolution, improving the foresight and effectiveness of early warnings, and avoiding problems such as inflated offline assessment indicators and ineffective online warnings.

[0041] For example, the field removal operation of the above data leakage prevention and control rules can be implemented using a rule base combined with a configurable blacklist / whitelist. For instance, a dedicated field rule base for fault early warning can be pre-built in the cloud, incorporating conclusive and retrospective fields into a configurable blacklist, while including early-stage feature fields in the whitelist. By combining the blacklist and whitelist configurations in the rule base, fields in the standard dataset are matched and filtered one by one, automatically removing conclusive and retrospective fields from the blacklist and retaining early-stage feature fields from the whitelist. This achieves standardization and scalability in field removal, accurately avoiding interference from retrospective information and adapting to field differences across different vehicle models and fault types, further ensuring the accuracy of early warnings and the feasibility of engineering implementation.

[0042] In some embodiments, the key data filtering rules in step S133 include: Based on a pre-constructed multi-strategy comprehensive evaluation method, the data in the candidate dataset are evaluated, and key data are selected from the candidate dataset according to the evaluation results; wherein, the multi-strategy comprehensive evaluation method includes at least one of the following: correlation test evaluation method, statistical significance test evaluation method, and feature importance evaluation method.

[0043] For example, the correlation test evaluation method quantifies the degree of association between data fields and the target fault by calculating the correlation coefficient between each data field and the target fault (such as Pearson correlation coefficient, Spearman correlation coefficient, etc.), and filters out data fields with correlation coefficients higher than a preset threshold, while eliminating redundant data with extremely low correlation to the target fault. The statistical significance test evaluation method determines whether the distribution difference of each data field under normal operating conditions and early fault conditions is significant through hypothesis testing (such as t-test, chi-square test, etc.), retains data fields with significant distribution differences, and ensures that the selected data can effectively distinguish between normal and early fault states. The feature importance evaluation method ranks the feature importance of each data field by training a basic classification model (such as decision tree, random forest, etc.), and selects data fields with importance scores higher than a preset threshold as key data, ensuring that the selected data can accurately represent the core evolution characteristics of the target fault. The multi-strategy comprehensive evaluation method in this application is one or more combinations of the above correlation test evaluation method, statistical significance test evaluation method, and feature importance evaluation method. It can be flexibly configured according to the target fault type, early warning accuracy requirements, etc., and this application does not limit it.

[0044] This step reduces the data dimensionality of the input model, minimizes noise interference, avoids redundant data consuming computing resources and affecting model inference speed, and ensures that the selected data can accurately represent the evolution characteristics of the target fault, providing high-quality input data for the vehicle fault warning model. This, in turn, improves the model's inference efficiency and warning accuracy, providing strong support for the subsequent accurate output of fault warning results by the model.

[0045] In some embodiments, step S134, which involves performing missing data completion and normalization on the data in the key data set according to key data preprocessing rules, may include: The missing data in the key dataset is filled in according to the preset data completion strategy; the completed key data is then normalized to map key data of different dimensions to a unified numerical range.

[0046] For example, the preset data completion strategies may include linear interpolation, mean completion, median completion, and nearest neighbor completion. Data normalization can be performed using min-max normalization, Z-score standardization, etc. The above-mentioned completion strategies and normalization methods are all conventional techniques in this field, and their specific implementation methods are well known to those skilled in the art, and will not be elaborated here. The preset time window can be configured with time length or number of sampling points according to vehicle model, fault object, or business needs. For example, a shorter time window can be configured for power domain faults, and a longer time window can be configured for battery management domain faults. The specific configuration method can be flexibly adjusted according to the actual application scenario, and this invention does not limit it in this regard.

[0047] This step involves filling in missing data in the key dataset to ensure data integrity and prevent missing data from interfering with the model's inference accuracy. Normalization eliminates numerical differences between key data of different dimensions, placing all types of key data within a uniform numerical range and preventing the impact of dimensional differences on model inference. Furthermore, by dividing time-series samples into preset time windows, the temporal correlation characteristics of key data are fully preserved, ensuring that each time-series sample comprehensively reflects the changes in vehicle operating status before and after the target fault occurs. This enhances the model's ability to identify temporal features, providing high-quality, highly available input data for the vehicle fault warning model and further guaranteeing the accuracy and reliability of the warning results.

[0048] In some embodiments, before deploying the current version of the vehicle fault warning model in the cloud, the method may further include: Step S151: Obtain historical fault data for multiple vehicles.

[0049] For example, historical fault data refers to the vehicle's operating data during the historical time period before and after the occurrence of the target fault. It covers data from different vehicle models, different target fault types, and different operating scenarios, providing sufficient and comprehensive sample support for model training and improving the model's generalization ability.

[0050] Step S152: Process the historical fault data according to the target data processing rules.

[0051] For example, the target data processing rule in step S152 is the same target data processing rule used in step S130 when processing vehicle fault data.

[0052] Step S153: Train the pre-built initial vehicle fault warning model based on the processed historical fault data to obtain the current version of the vehicle fault warning model.

[0053] For example, the initial vehicle fault warning model is a prediction model with time series modeling capabilities.

[0054] Step S154: Deploy the current version of the vehicle fault warning model in the cloud and store the mapping relationship between the current version of the model and the target data processing rules in the cloud.

[0055] Steps S151 to S154 ensure that the data processing rules used in training the current version of the model are completely consistent with the data processing rules used in subsequent online inference. This fundamentally avoids the model performance drift problem caused by the inconsistency between offline training and online inference, providing a solid guarantee for the accuracy of model operation. It effectively solves the technical problem in the existing technology that the actual running accuracy of the cloud model is lower than that of offline training and that the warning fluctuation is prone to occur, further improving the accuracy and stability of vehicle fault warning.

[0056] In some embodiments, the version number of the target data processing rule used during the training of the current model version can be recorded. This version number is then bound to the model version number of the vehicle fault warning model and stored together in a cloud-based mapping database. This achieves a one-to-one correspondence and coordinated management between model versions and data processing rule versions. Each version of the rule is independent and traceable, facilitating subsequent review, comparison, and optimization of the input processing logic of different model versions. It also ensures that during online inference, each model version can accurately call the complete data processing rules corresponding to its training phase, preventing inconsistencies between online and offline processing due to rule version confusion. This further guarantees the stability of model operation and the accuracy of warning results. Furthermore, this binding management method can adapt to rule adjustments brought about by vehicle model iterations, fault type upgrades, and changes in business requirements. When the target data processing rule needs optimization and updating, version iteration can achieve synchronous updates of the rule and model, ensuring that model training and online inference always maintain consistency and providing support for the long-term stable operation of the model.

[0057] In some embodiments, step S152, which processes historical fault data according to target data processing rules, includes: Step S1521: Convert historical fault data into standard historical fault data with unified format and time sequence alignment according to data standardization rules to obtain a standard historical data set.

[0058] Step S1522: According to the data leakage prevention and control rules, remove data containing explicit information after the failure from the standard historical data set to obtain a candidate historical data set.

[0059] Step S1523: Construct three-class fault labels for the data in the candidate historical data set. The three-class fault labels include three types of fault labels: normal, warning and fault.

[0060] For example, if the original data labels only include two categories: normal and fault, then using the fault occurrence time as the anchor point, within a preset time window before the fault occurs, samples originally labeled as normal are reconstructed into warning samples, thus forming a label system of normal, warning, and fault. If the original data already has multi-state labels that can be used for early warning, then the existing label system is directly used. This step is used to allow the model to learn the evolution process of "normal → warning → fault," improving the model's sensitivity and distinguishability to the early stages of faults. The fault occurrence time can be derived from preset fault criteria (such as the fault code trigger time, protection strategy trigger time, or manually confirmed event time), and the preset time window can be represented by a configurable time length or a configurable number of sampling points, so that different vehicle models / fault objects can be adapted according to their mechanistic differences.

[0061] Step S1524: Divide the data in the candidate historical data set after constructing the labels into training set, validation set and test set.

[0062] The training set consists of data used for model training and key signal identification. It is used to help the model learn the early evolution characteristics of the target fault, fit model parameters, and screen key signals related to the target fault based on this dataset. The validation set consists of data used to optimize model parameters. It is used to verify model performance in real time during model training, adjust model hyperparameters, optimize training strategies, and avoid model overfitting. The test set consists of data used for independent performance evaluation of the model. It is used to objectively and independently evaluate the final performance of the model after model training is completed, and to test the model's generalization ability and early warning accuracy. It does not participate in any model training or parameter optimization process.

[0063] Step S1525: Select key historical data related to the target fault from the training set according to the key data filtering rules to obtain a key historical data set.

[0064] Step S1526: Perform missing data completion and normalization on the data in the key historical data set according to the key data preprocessing rules, and divide the data in the key historical data set into multiple historical time series samples based on the preset time window. Among them, multiple time series samples are used as training data for the vehicle fault warning model.

[0065] The data standardization rules in step S1521 of this application can be found in the relevant description of step S131 above; the data leakage prevention and control rules in step S1522 can be found in the relevant description of step S132 above; the key data screening rules involved in step S1525 can be found in the relevant description of step S133 above; and the key data preprocessing rules involved in step S1526 can be found in the relevant description of step S134 above, and will not be repeated here.

[0066] In this application, the selection of key data is performed only on the training set. By selecting key data, multiple historical time-series samples are constructed and used as training data for the vehicle fault warning model. This solidifies the data leakage prevention procedure, ensuring that the validation and test sets do not participate in any processes related to model training input, such as key signal determination, data processing rule fitting, and warning threshold learning. They are only used for model validation and evaluation, thereby preventing evaluation data from negatively influencing input feature selection and avoiding the problem of inflated offline evaluation metrics. Specifically, all updates to key signal sets, adjustments to normalization parameters, and optimization of window rules are generated solely based on the training set data. The validation set's role is limited to optimizing model parameters and does not participate in key data selection or preprocessing rule determination, thus ensuring the objectivity of parameter optimization. The test set is used only for a one-time independent evaluation after model training and is prohibited from being returned to the training process for model refitting; it does not intervene in any operations related to model training. The above design can significantly improve the reproducibility of model evaluation results and the consistency of online operation, ensure that the offline evaluation performance of the model is consistent with the actual online operation performance, further avoid the model performance drift problem, and provide a reliable guarantee for the accuracy of model operation.

[0067] In some embodiments, step S153 involves training a pre-built initial vehicle fault warning model based on processed historical fault data to obtain a vehicle fault warning model with the current version number, including: Multiple historical time-series samples are input as training data into the initial vehicle fault warning model to train it, resulting in a preliminarily trained vehicle fault warning model. Based on data from the validation set, parameter tuning and model selection are performed on the preliminarily trained vehicle fault warning model. Specifically, the model's performance is verified in real-time using the validation set, and hyperparameters (such as learning rate, number of iterations, dropout random deactivation, number of network layer nodes, etc.) are adjusted. The model with the best performance on the validation set is selected as the intermediate optimization model to avoid overfitting or underfitting and ensure that the model has good fitting ability and preliminary generalization ability. The intermediate optimization model is independently evaluated based on data from the test set to verify the model's final generalization ability and warning accuracy, ensuring that the model performance meets the requirements of actual engineering applications. If the test set evaluation results do not meet the preset performance standards, the process returns to the parameter tuning stage to readjust the hyperparameters until the model performance meets the standards, ultimately obtaining the current version of the vehicle fault warning model.

[0068] For example, metrics such as accuracy, precision, recall, and F1 score can be used to comprehensively evaluate model performance, so as to fully measure the model's recognition effect on normal, warning, and fault samples. Among them, the recall and precision of warning samples are of particular concern to ensure that the model can accurately identify the early state of faults. At the same time, the false positive rate of normal samples and the recognition accuracy of fault samples are taken into account, providing a clear quantitative basis for whether the model performance meets the standards, and also providing a reference direction for subsequent model iteration and optimization.

[0069] In some embodiments, training strategies to enhance the distinction between the three types of boundaries can be introduced during model training. For example, a higher misjudgment cost can be set for the warning category (by using weighted cross-entropy or cost-sensitive loss to assign higher penalty weights to the warning category and its missed reports) or boundary sample distinction constraints can be introduced (by using hard sample mining training and superimposing comparative / triple metric learning losses to widen the feature interval between normal and warning, and warning and fault) to improve the identification sensitivity in the early stage of fault evolution, further optimize the model's ability to distinguish between the three types of states, reduce the situation of missed and false alarms in warnings, ensure that the model can accurately capture the early evolution characteristics of faults, and improve the foresight and accuracy of warnings.

[0070] In some embodiments, determining whether to trigger a vehicle fault warning based on the fault warning result in step S140 may include: When the fault warning result is a warning and the warning duration reaches the duration threshold, the vehicle fault warning is triggered.

[0071] For example, the duration threshold is a configurable threshold that can be set according to vehicle model, version, or fault object. Through the warning duration threshold triggering mechanism, it can effectively suppress instantaneous false alarms caused by short-term noise, operating condition disturbances, or communication jitter, improving the stability and availability of warning triggering and ensuring that the warning results have practical reference value. Simultaneously, the system records three key pieces of information: the warning start time (the time when the vehicle fault warning model first outputs a "warning" result), the continuous cumulative duration (the continuous duration for which the model continuously outputs a "warning" result from the warning start time), and the threshold hit time (the specific time when the continuous cumulative duration just reaches the preset duration threshold and triggers the warning). This forms a complete warning triggering evidence chain, facilitating review of the triggering process and identification of the cause of the anomaly when it occurs later. It also allows R&D and after-sales personnel to verify whether the warning triggering conforms to the preset rules and to verify the rationality and accuracy of the warning triggering.

[0072] In some embodiments, after triggering a vehicle malfunction warning, the method further includes: Step S161: Generate an abnormal vehicle detection log and send it to the R&D end. The abnormal vehicle detection log shall include at least the vehicle identification code, key data segments within a preset time period before and after the warning time, the current version number of the vehicle fault warning model, and the target data processing rules corresponding to the current version number.

[0073] For example, the abnormal vehicle detection log may also include the model output sequence, threshold hit evidence, and processing rule version number. The model output sequence represents the continuous output results of the vehicle fault warning model within a preset time period before and after the warning time, reflecting the change from normal output to warning output. The threshold hit evidence consists of records related to the warning duration reaching a certain threshold, associated with the previously recorded warning start time, cumulative duration, and threshold hit time, fully corroborating the rationality of the warning trigger. The processing rule version number is the version identifier of the target data processing rule used for training and online inference of the current version of the vehicle fault warning model, and is bound to the model version number. The abnormal vehicle detection log possesses a complete chain of evidence, enabling developers to reproduce the entire model input and output process using the same criteria, clearly tracing every key step in data processing, model inference, and warning triggering. This facilitates rapid identification of the root cause of problems, whether it's abnormal model output, data processing deviation, or unreasonable threshold settings. These issues can be efficiently investigated through this log, providing accurate data support for subsequent model optimization and rule adjustments.

[0074] Step S162: Receive maintenance suggestions from the R&D team based on vehicle inspection logs.

[0075] For example, maintenance recommendations can be derived by R&D personnel by combining early warning information, key data fragments and model operation status. These recommendations should include at least the emergency level, recommended actions and recommended maintenance items, providing structured input for subsequent work order generation.

[0076] Step S163: Determine the urgency of the repair based on the repair recommendations, and generate a repair work order corresponding to the urgency of the repair.

[0077] For example, a repair work order can include Level 1 and Level 2 repair work orders. Level 1 repair work orders are more urgent than Level 2 repair work orders. Level 1 repair work orders correspond to high-urgency faults, meaning the fault has directly affected vehicle driving safety, poses a serious safety hazard, or is likely to worsen rapidly. Level 2 repair work orders correspond to moderate-urgency faults, meaning the fault has not yet affected vehicle driving safety, but prolonged neglect could lead to worsening of the fault, affect normal vehicle operation, or shorten the lifespan of vehicle components. By setting different levels of repair work orders, differentiated responses and resource allocation based on risk levels can be achieved. For Level 1 repair work orders, high-quality repair resources are prioritized and expedited processing procedures are initiated to ensure rapid response and timely handling of high-risk faults, preventing safety accidents. For Level 2 repair work orders, repair resources and processing sequences are rationally arranged to improve resource utilization efficiency while ensuring effective handling, thereby improving the overall targeting and efficiency of fault handling and achieving the hierarchical management goal of prioritizing high-risk and orderly handling of moderate-risk faults.

[0078] Step S164: Based on the level of the repair work order, the work order is sent to the corresponding target terminal, so that the target terminal executes the handling plan corresponding to the level of the repair work order. The target terminal includes at least one of the vehicle terminal, the vehicle owner terminal, and the after-sales service terminal.

[0079] For example, for a Level 1 repair work order, it can be sent to the vehicle and / or the owner's end to notify the user via the vehicle's main control screen and / or via SMS. The corresponding handling plan is as follows: immediately remind the user that the vehicle has a high-risk safety hazard and prohibit further long-distance or high-speed driving. At the same time, the Level 1 repair work order is expedited and sent to the after-sales service department to urge after-sales personnel to proactively contact the owner as soon as possible to confirm the vehicle's current location and fault symptoms, prioritize the allocation of repair resources, schedule an emergency on-site inspection, or guide the owner to the nearest after-sales service center for immediate handling, minimizing safety risks. For a Level 2 repair work order, it can be sent to the after-sales service department and, as needed, to the owner's end for reminders. The corresponding handling plan is as follows: after-sales personnel, based on repair suggestions and the owner's schedule, proactively contact the owner to schedule an in-store inspection time, and simultaneously prepare the corresponding repair tools and parts in advance. The owner goes to the after-sales service center at the scheduled time to complete the fault inspection. After the inspection is completed, the after-sales service department sends the retest results back to the cloud to ensure that the fault is completely resolved, achieving tiered handling and precise response.

[0080] Step S165: Receive the processing result from the target end.

[0081] The handling results include the in-store results, fault confirmation conclusions, repair items, retest status, and whether the warning will be triggered again.

[0082] For example, after receiving the handling results from the target end, the results can be written back to the cloud to form a closed-loop record. The cloud can also optimize the warning duration threshold, optimize the target data processing rules, or iteratively update the vehicle fault warning model based on the handling results, so as to continuously improve the model's warning accuracy and handling efficiency.

[0083] This application utilizes tiered work order processing and closed-loop management to configure differentiated work order levels and processing procedures for faults of varying urgency. This enables closed-loop control of the entire process from triggering, analysis, work order generation, issuance and execution to feedback of processing results, thereby achieving the engineering implementation of early warning results. This effectively improves the targeting and efficiency of fault handling, while optimizing the user experience during the fault handling process and reducing user waiting time and operational costs.

[0084] Based on the same inventive concept, this invention also provides a fault early warning device for implementing the fault early warning method described in the above embodiments. Figure 2 This is a structural block diagram of a fault early warning device provided in an embodiment of the present invention, such as... Figure 2 As shown, the device 200 includes: The acquisition module 210 is used to acquire vehicle fault data and the current version number of the vehicle fault early warning model. The vehicle fault data is the vehicle operation data before and after the target fault occurs. The determination module 220 is used to determine the data processing rule corresponding to the current version number as the target data processing rule based on the mapping relationship between the model version number and the data processing rule pre-stored in the cloud; wherein, the target data processing rule is the data processing rule adopted by the vehicle fault warning model during the training process of the corresponding version. The processing module 230 is used to process vehicle fault data based on target data processing rules, and input the processed data into the vehicle fault early warning model to obtain the fault early warning result output by the model. The fault early warning result includes early warning, fault and normal. The early warning module 240 is used to determine whether to trigger a vehicle fault warning based on the fault warning result.

[0085] In some embodiments, the target data processing rules include data standardization rules, data leakage prevention and control rules, key data screening rules, and key data preprocessing rules; the processing module 230 includes: The first processing unit is used to convert vehicle fault data into standard fault data with unified format and time sequence alignment according to data standardization rules, so as to obtain a standard data set. The second processing unit is used to remove data containing explicit information after a failure occurs from the standard dataset according to the data leakage prevention and control rules, so as to obtain a candidate dataset. The third processing unit is used to filter out key data related to the target fault from the candidate data set according to the key data filtering rules, so as to obtain the key data set; The fourth processing unit is used to perform missing data completion and normalization processing on the data in the key data set according to the key data preprocessing rules, and to divide the data in the key data set into multiple time series samples based on a preset time window. The multiple time series samples are used as input data for input into the vehicle fault warning model.

[0086] In some embodiments, the vehicle fault data includes a vehicle identification number and a timestamp corresponding to each data entry, and the first processing unit is used for: Vehicle fault data is uniformly parsed and transformed to ensure consistent data format, field definitions, and data types. Based on vehicle identification codes and timestamps, vehicle fault data is time-synchronized and then sorted and integrated into standard fault data according to time series.

[0087] In some embodiments, the second processing unit is used for: Based on the semantic categories of each field in the standard dataset, data containing conclusive fields are removed. Conclusive fields are fields whose semantic categories belong to the fault determination result category, including at least one of the following: fault code field, diagnostic conclusion field, after-sales diagnostic conclusion field, and maintenance work order field. Based on the temporal change characteristics of each field in the standard dataset, data containing posterior fields are removed. Posterior fields are fields that only change significantly after the fault occurs and are strongly bound to the time of the fault occurrence, including at least one of the following: alarm trigger flag, alarm latch flag, protection degradation result status, fault posterior statistics, and reset status.

[0088] In some embodiments, the third processing unit is used for: Based on a pre-constructed multi-strategy comprehensive evaluation method, the data in the candidate dataset are evaluated, and key data are selected from the candidate dataset according to the evaluation results; wherein, the multi-strategy comprehensive evaluation method includes at least one of the following: correlation test evaluation method, statistical significance test evaluation method, and feature importance evaluation method.

[0089] In some embodiments, the apparatus may include a model training module for: Acquire historical fault data from multiple vehicles; process the historical fault data according to the target data processing rules; train a pre-built initial vehicle fault warning model based on the processed historical fault data to obtain the current version of the vehicle fault warning model; deploy the current version of the vehicle fault warning model in the cloud and store the mapping relationship between the current version of the model and the target data processing rules in the cloud.

[0090] In some embodiments, the model training module is further configured to: Historical fault data is transformed into standardized historical fault data with a unified format and time sequence alignment according to data standardization rules to obtain a standard historical data set. Data containing explicit information after the fault occurred is removed from the standard historical data set according to data leakage prevention and control rules to obtain a candidate historical data set. Three-class fault labels are constructed for the data in the candidate historical data set, including normal, warning, and fault labels. The data in the candidate historical data set after labeling is divided into training set, validation set, and test set. Key historical data related to the target fault are selected from the training set according to key data screening rules to obtain a key historical data set. The data in the key historical data set is processed by missing data completion and normalization according to key data preprocessing rules, and the data in the key historical data set is divided into multiple historical time series samples based on a preset time window. The multiple time series samples are used as training data for the vehicle fault warning model.

[0091] In some embodiments, the warning module 240 is used for: When the fault warning result is a warning and the warning duration reaches the duration threshold, the vehicle fault warning is triggered.

[0092] In some embodiments, the device further includes a processing module for: The system generates abnormal vehicle detection logs and sends them to the R&D team. These logs include at least the vehicle identification number, key data segments within a preset time period before and after the warning, the current version number of the vehicle fault warning model, and the target data processing rules corresponding to the current version number. It then receives repair suggestions from the R&D team based on the vehicle detection logs. Based on these suggestions, it determines the urgency of the repair and generates a repair work order corresponding to that urgency. Based on the work order's level, it issues the work order to the corresponding target end, enabling the target end to execute the corresponding handling plan. Target ends include at least one of the vehicle end, the vehicle owner end, and the after-sales service end. Finally, it receives the handling results from the target end.

[0093] The specific details of the fault warning method used in the above-mentioned fault warning device can be understood by referring to the relevant descriptions and effects in the above-described fault warning method embodiments, and will not be repeated here.

[0094] Based on the same inventive concept as the aforementioned fault warning method, this invention also provides an electronic device, which may include a processor and a memory, wherein the processor and memory can communicate with each other via a bus or other means. The processor may be a Central Processing Unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations thereof. The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the fault warning method in this embodiment. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby realizing the fault warning in the above method embodiments.

[0095] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. The one or more modules are stored in the memory and, when executed by the processor, perform actions such as... Figure 1 The fault warning method in the illustrated embodiment.

[0096] For specific details regarding the aforementioned electronic devices, please refer to the relevant documentation. Figure 1 The relevant descriptions and effects in the illustrated embodiments are for understanding purposes only and will not be repeated here.

[0097] Based on the same inventive concept as the fault warning method, the present invention also provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the fault warning method in the above embodiments.

[0098] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The storage medium can be read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0099] The technical solutions provided in the above embodiments of this application have at least the following technical effects or advantages: This invention provides a fault early warning method, apparatus, device, and storage medium. By constructing a mapping relationship between model version numbers and data processing rules, after acquiring vehicle fault data in the cloud, a target data processing rule corresponding to the current version number of the vehicle fault early warning model can be determined based on this mapping relationship. The vehicle fault data is then processed based on this target data processing rule and input into the model to obtain the fault early warning result. This approach achieves consistent reuse of data processing rules during model training and online inference after cloud-deployed models. It effectively solves the problem that the actual operating accuracy of cloud-deployed vehicle fault early warning models is lower than that during offline training, and that early warning fluctuations are prone to occur due to inconsistencies in data processing rules between offline training and online inference links. This significantly improves the operating accuracy of cloud-deployed models, greatly reduces early warning fluctuations, and ensures the accuracy and stability of fault early warnings.

[0100] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0101] Similarly, it should be understood that, in order to simplify this disclosure and aid in understanding one or more of the various aspects of the invention, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0102] It should be noted that the above embodiments are illustrative of the invention and not restrictive of the invention, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims.

Claims

1. A fault early warning method, characterized in that, The method is applied in the cloud, where a vehicle fault warning model is deployed. Acquire vehicle fault data, which is vehicle operation data before and after the occurrence of the target fault; Obtain the current version number of the vehicle fault warning model, and based on the mapping relationship between the model version number and data processing rules pre-stored in the cloud, determine the data processing rule corresponding to the current version number as the target data processing rule; wherein, the target data processing rule is the data processing rule adopted by the vehicle fault warning model during the training process of the corresponding version. The vehicle fault data is processed based on the target data processing rules, and the processed data is input into the vehicle fault early warning model to obtain the fault early warning result output by the model. The fault early warning result includes early warning, fault, and normal. Based on the fault warning results, determine whether to trigger a vehicle fault warning.

2. The method according to claim 1, characterized in that, The target data processing rules include data standardization rules, data leakage prevention and control rules, key data screening rules, and key data preprocessing rules; The processing of the vehicle fault data based on the target data processing rules includes: The vehicle fault data is converted into standard fault data with a unified format and time sequence alignment according to the data standardization rules to obtain a standard data set; According to the data leakage prevention and control rules, data containing explicit information after a failure occurs are removed from the standard data set to obtain a candidate data set; According to the key data filtering rules, key data related to the target fault are filtered from the candidate data set to obtain the key data set; According to the key data preprocessing rules, the data in the key data set is filled in for missing data and normalized. Based on a preset time window, the data in the key data set is divided into multiple time-series samples, which are used as input data to the vehicle fault warning model.

3. The method according to claim 2, characterized in that, The vehicle fault data includes a vehicle identification number and a timestamp corresponding to each data entry. The data standardization rules include: The vehicle fault data is uniformly parsed and converted to ensure that the data format, field definition and data type are consistent. Based on the vehicle identification code and the timestamp, the vehicle fault data is time-synchronized, and the vehicle fault data is uniformly sorted and integrated into standard fault data according to the time sequence.

4. The method according to claim 2, characterized in that, The data leakage prevention and control rules include: Based on the semantic category of each field in the standard data set, data containing conclusive fields are removed; the conclusive fields are fields whose semantic category belongs to the fault determination result category, including at least one of the following: fault code field, diagnostic conclusion field, after-sales diagnostic conclusion field, and repair work order field. Based on the temporal change characteristics of each field in the standard data set, data containing posterior fields are removed; the posterior fields are fields that only change significantly after a fault occurs and are strongly bound to the time of the fault occurrence, including at least one of alarm trigger flag, alarm latch flag, protection degradation result status, fault posterior statistics, and reset status.

5. The method according to claim 2, characterized in that, The key data filtering rules include: Based on a pre-constructed multi-strategy comprehensive evaluation method, the data in the candidate data set are evaluated, and key data is selected from the candidate data set according to the evaluation results. The multi-strategy comprehensive evaluation method includes at least one of the following: correlation test evaluation method, statistical significance test evaluation method, and feature importance evaluation method.

6. The method according to claim 2, characterized in that, Before deploying the current version of the vehicle fault warning model in the cloud, the method further includes: Acquire historical fault data for multiple vehicles; The historical fault data is processed according to the target data processing rules. The pre-constructed initial vehicle fault warning model is trained based on the processed historical fault data to obtain the current version of the vehicle fault warning model. The current version of the vehicle fault warning model is deployed in the cloud, and the mapping relationship between the current version of the model and the target data processing rules is stored in the cloud.

7. The method according to claim 6, characterized in that, The process of processing the historical fault data according to the target data processing rules includes: The historical fault data is converted into standard historical fault data with a unified format and time sequence alignment according to the data standardization rules to obtain a standard historical data set; According to the data leakage prevention and control rules, data containing explicit information after the failure occurred is removed from the standard historical data set to obtain a candidate historical data set; A three-class fault label is constructed for the data in the candidate historical data set, and the three-class fault label includes three types of fault labels: normal, warning and fault. The data in the candidate historical data set after the labels are constructed are divided into a training set, a validation set, and a test set; According to the key data filtering rules, key historical data related to the target fault are filtered from the training set to obtain a key historical data set; According to the key data preprocessing rules, the data in the key historical data set is filled in for missing data and normalized. Based on a preset time window, the data in the key historical data set is divided into multiple historical time series samples, wherein the multiple time series samples are used as training data for the vehicle fault warning model.

8. The method according to claim 1, characterized in that, The step of determining whether to trigger a vehicle fault warning based on the fault warning result includes: When the fault warning result is a warning and the warning duration reaches the duration threshold, a vehicle fault warning is triggered.

9. The method according to claim 1, characterized in that, After triggering the vehicle malfunction warning, the method further includes: An abnormal vehicle detection log is generated and sent to the R&D end. The abnormal vehicle detection log includes at least the vehicle identification code, key data segments within a preset time period before and after the warning time, the current version number of the vehicle fault warning model, and the target data processing rule corresponding to the current version number. Receive maintenance suggestions from the R&D team based on the vehicle inspection logs; Based on the maintenance recommendations, the urgency level of the maintenance is determined, and a maintenance work order corresponding to the urgency level is generated; Based on the level of the repair work order, the work order is sent to the corresponding target terminal, so that the target terminal executes the handling plan corresponding to the level of the repair work order. The target terminal includes at least one of the vehicle terminal, the vehicle owner terminal, and the after-sales service terminal. Receive the processing results fed back from the target terminal.

10. A fault early warning device, characterized in that, The device is applied in the cloud and has a vehicle fault warning model deployed therein. The device includes: The acquisition module is used to acquire vehicle fault data and the current version number of the vehicle fault early warning model. The vehicle fault data is the vehicle operation data before and after the target fault occurs. The determination module is used to determine the data processing rule corresponding to the current version number as the target data processing rule based on the mapping relationship between the model version number and the data processing rule pre-stored in the cloud; wherein, the target data processing rule is the data processing rule adopted by the vehicle fault warning model during the training process of the corresponding version; The processing module is used to process the vehicle fault data based on the target data processing rules, and input the processed data into the vehicle fault early warning model to obtain the fault early warning result output by the model. The fault early warning result includes early warning, fault, and normal. The early warning module is used to determine whether to trigger a vehicle fault warning based on the fault warning result.

11. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the fault warning method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the fault warning method according to any one of claims 1 to 9.

Images