Vehicle fault warning method, device and equipment and storage medium

Abstract

The invention discloses a vehicle fault warning method, device and equipment and a storage medium, relates to the technical field of data processing, and discloses a vehicle fault warning method comprising the following steps: obtaining current driving data, a current fault code and a current log of a vehicle; taking at least one of the current driving data, the current fault code and the current log as a to-be-identified factor; obtaining a factor state of the to-be-identified factor based on a preset data exception identification model; when the factor state is a fault state, vehicle fault warning is carried out based on the to-be-identified factor; according to the method, the vehicle end real-time operation data, the fault code and the log are acquired, remote real-time fault analysis and fault warning are performed on the vehicle according to at least one parameter of the vehicle end real-time operation data, the fault code and the log based on the preset data anomaly recognition model, and the vehicle fault can be remotely, rapidly and accurately recognized. Dependence on professional technicians is reduced, diagnosis efficiency is improved, the maintenance process is accelerated, and meanwhile user experience is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a vehicle fault alarm method, device, equipment and storage medium. Background Art

[0002] As the penetration rate of electric, connected, and intelligent vehicles continues to increase, vehicle functions are becoming more and more abundant, and the number of electronic and electrical components on the vehicle side has also increased significantly. The corresponding vehicle failure rate and the complexity of failures have also increased significantly. The efficiency of failure response directly affects consumers' car experience and in turn affects the brand image of car companies. In recent years, especially the new forces of car companies that have entered the automotive industry, based on their emphasis on and heavy investment in the construction of after-sales systems, they have gradually built differentiated advantages in terms of consumer-perceivable failure response and proactive care experience.

[0003] However, manufacturers are currently unable to quickly and remotely identify possible problems with vehicles in advance. Vehicles are repaired only after problems arise after they are sold, which makes fault analysis difficult, increases the after-sales workload, and results in a poor user experience.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a vehicle fault alarm method, device, equipment and storage medium, aiming to solve the current technical problems that manufacturers are unable to remotely and quickly identify possible problems with vehicles in advance, and repair vehicles only when problems occur after they are sold, making fault analysis difficult, increasing after-sales workload, and causing poor user experience.

[0006] To achieve the above purpose, the present application proposes a vehicle fault alarm method, the vehicle fault alarm method comprising: Get the vehicle's current driving data, current fault code, and current log; taking at least one of the current driving data, the current fault code and the current log as a factor to be identified; Obtaining the factor state of the factor to be identified based on a preset data anomaly identification model; When the factor state is a fault state, a vehicle fault alarm is issued based on the factor to be identified.

[0007] In one embodiment, obtaining the factor state of the factor to be identified based on a preset data anomaly identification model includes: Identifying the factor type of the factor to be identified according to the preset data anomaly identification model; Comparing the factor to be identified with a preset driving data fault threshold, a preset warning fault code, a preset warning log information, or a preset combined fault information based on the factor type to obtain a comparison result; The factor state is obtained according to the comparison result.

[0008] In one embodiment, before obtaining the factor state of the factor to be identified based on the preset data anomaly identification model, the method further includes: Obtaining historical driving data, historical fault codes and historical logs of the vehicle; Obtaining a driving data fault threshold according to the historical driving data, determining an alarm fault code according to the historical fault code, and determining alarm log information according to the historical log; taking at least two of the historical driving data, the historical fault codes and the historical logs as combination factors; Determine combined fault information according to the combined factor; A preset data anomaly recognition model is obtained according to the driving data fault threshold, the warning fault code, the warning log information and the combined fault information.

[0009] In one embodiment, after obtaining the preset data anomaly recognition model according to the driving data fault threshold, the warning fault code, the warning log information and the combined fault information, the method further includes: Obtain test driving data, test fault codes, test logs, and test combination factors; Testing the preset data anomaly recognition model according to the test driving data, the test fault code, the test log, and the test combination factor to obtain a test result; Obtaining an optimization coefficient according to a preset loss function and the test results; The category weight and correction coefficient of the preset data anomaly recognition model are adjusted according to the optimization coefficient until the test result meets the preset test requirement.

[0010] In one embodiment, when the factor state is a fault state, issuing a vehicle fault alarm based on the to-be-identified factor includes: When the factor state is a fault state, obtaining the fault type of the factor to be identified according to the factor state; Identify the maintenance strategy of the fault type according to the preset fault map; The maintenance strategy and the fault type are fed back to the user of the vehicle to complete the vehicle fault warning.

[0011] In one embodiment, before the maintenance strategy of the fault type is identified according to the preset fault map, the method further includes: Obtain one-to-one correspondence between historical fault types and historical fault repair strategies; A preset fault map is obtained according to the historical fault types and the historical fault maintenance strategies.

[0012] In one embodiment, when the factor state is a fault state, after issuing a vehicle fault alarm based on the to-be-identified factor, the method further includes: Determining an alarm type according to the diagnostic information of the vehicle fault alarm, and searching for historical alarms of the same type based on the alarm type; Obtaining a factor to be updated based on the historical alarms of the same type; When the alarm type meets the preset false alarm condition, the preset data anomaly recognition model is updated according to the factor to be updated.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a vehicle fault warning device, the vehicle fault warning device comprising: The acquisition module is used to obtain the current driving data, current fault code and current log of the vehicle; a fault identification module, configured to use at least one of the current driving data, the current fault code and the current log as a factor to be identified; The fault identification module is further used to obtain the factor state of the factor to be identified based on a preset data anomaly identification model; A fault warning module is used to issue a vehicle fault warning based on the factor to be identified when the factor state is a fault state.

[0014] In addition, to achieve the above-mentioned purpose, the present application also proposes a vehicle fault alarm device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the vehicle fault alarm method described above.

[0015] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the vehicle fault alarm method described above are implemented.

[0016] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the vehicle fault warning method described above are implemented.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: By obtaining real-time operation data, fault codes and logs from the vehicle, and based on a preset data anomaly recognition model, remote real-time fault analysis and fault alarm are performed on the vehicle according to at least one parameter of the real-time operation data, fault codes and logs from the vehicle. This enables rapid and accurate remote identification of vehicle fault problems, reduces dependence on professional technicians, improves diagnostic efficiency, speeds up the maintenance process, and improves user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 A flow chart of the first embodiment of the vehicle fault alarm method of the present application; Figure 2 A schematic diagram of the execution steps of the vehicle fault alarm method of the vehicle fault alarm platform provided in the first embodiment of the vehicle fault alarm method of the present application; Figure 3 A flow chart of the second embodiment of the vehicle fault alarm method of the present application; Figure 4 This is a schematic diagram of the module structure of the vehicle fault warning device according to an embodiment of the present application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the vehicle fault alarm method in the embodiment of the present application. DETAILED DESCRIPTION

[0021] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0022] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of the embodiment of the present application is: obtaining the current driving data, current fault code and current log of the vehicle; taking at least one of the current driving data, current fault code and current log as the factor to be identified; obtaining the factor state of the factor to be identified based on a preset data anomaly recognition model; when the factor state is a fault state, issuing a vehicle fault alarm based on the factor to be identified.

[0024] In this embodiment, for the convenience of description, the following description is made by taking the identification of the vehicle fault alarm device as the execution subject.

[0025] As the penetration rate of existing technologies continues to increase with the electrification, networking, and intelligence of automobiles, vehicle functions are becoming more and more abundant, and the number of electronic and electrical components on the vehicle side has also increased significantly. The corresponding vehicle failure rate and the complexity of failures have also increased significantly. The efficiency of fault response directly affects consumers' car experience, and in turn affects the brand image of car companies. In recent years, especially the new forces of car companies that have entered the automotive industry, based on their emphasis on and heavy investment in the construction of after-sales systems, they have gradually built differentiated advantages in terms of consumer-perceivable fault response and proactive care experience. However, at present, manufacturers are unable to remotely and quickly identify possible problems with vehicles in advance. When problems occur after the vehicle is sold, it will be repaired, which makes fault analysis difficult, increases the workload of after-sales, and poor user experience.

[0026] The present application provides a solution, which obtains real-time operation data, fault codes and logs on the vehicle side, and performs remote real-time fault analysis and fault alarm on the vehicle based on a preset data anomaly recognition model according to at least one parameter of the real-time operation data, fault codes and logs on the vehicle side. It can remotely, quickly and accurately identify automobile fault problems, reduce dependence on professional technicians, improve diagnostic efficiency, speed up the maintenance process, and also improve user experience.

[0027] It can be seen from the above embodiments that the present application discloses a vehicle fault alarm method, device, equipment and storage medium, which relates to the field of data processing technology, and discloses a vehicle fault alarm method, including: obtaining the current driving data, current fault code and current log of the vehicle; taking at least one of the current driving data, current fault code and current log as a factor to be identified; obtaining the factor state of the factor to be identified based on a preset data anomaly recognition model; when the factor state is a fault state, a vehicle fault alarm is performed based on the factor to be identified; the method obtains the real-time operation data, fault code and log of the vehicle, and performs remote real-time fault analysis and fault alarm on the vehicle based on the preset data anomaly recognition model according to the real-time operation data, fault code and at least one parameter of the log of the vehicle, so that the vehicle fault problem can be identified remotely, quickly and accurately, and the dependence on professional technicians can be reduced, the diagnosis efficiency can be improved, the maintenance process can be accelerated, and the user experience can be improved.

[0028] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a vehicle fault alarm device, etc. The following takes the vehicle fault alarm device as an example to illustrate this embodiment and the following embodiments.

[0029] Based on this, the embodiment of the present application provides a vehicle fault alarm method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the vehicle fault alarm method of the present application.

[0030] In this embodiment, the vehicle fault alarm method includes steps S10 to S40: Step S10, obtaining the current driving data, current fault code and current log of the vehicle.

[0031] It is understandable that the vehicle's current driving data, current fault code and current log can be collected by the vehicle and uploaded to the cloud.

[0032] It should be noted that the current driving data may include driving data such as engine speed, vehicle speed, fuel consumption, etc.; the log file can be read through the vehicle's bus; the fault code can be a vehicle detection code obtained by periodic or real-time detection on the vehicle side, and the fault code can be sent to the cloud alone by the vehicle side, or the vehicle side can implement log feedback to the cloud.

[0033] It should be noted that the vehicle fault alarm method can be executed based on a vehicle fault alarm platform, which can be understood as the cloud and is also the executor of the present invention. The cloud obtains the current driving data, current fault code and current log of the vehicle, analyzes the vehicle fault, and issues an alarm based on the analysis results.

[0034] It should be noted that the cloud of the vehicle fault alarm can exchange information with the staff who perform operation and monitoring in the cloud based on the user interaction interface. Technicians can operate and understand the diagnostic results more easily, thereby speeding up the maintenance process and improving the user experience.

[0035] In the specific implementation, the vehicle fault alarm method execution step diagram of the vehicle fault alarm platform can refer to Figure 2 ,The status monitoring in the figure, conducts root cause analysis on the factors that trigger the alarm. The following is the basis for gradually improving the model. An alarm occurs, but there are many influencing factors. At this time, it is necessary to check the vehicle's signal data, log data, fault code, version and other information to improve the accuracy of the model.

[0036] In specific implementation, the vehicle fault alarm platform also includes status monitoring: real-time query of vehicle status across the entire network, including but not limited to vehicle type, sales status, vehicle / component version, alarm and log information. Remote diagnosis: remote data acquisition and diagnosis of vehicles based on fault tree and end-cloud collaboration. Data analysis: online analysis and download of bus data and log data periodically reported or actively retrieved by the vehicle end. Data management: management of vehicle model metadata such as fault codes to facilitate the access of new models. Domain analysis: providing fault analysis models for Huawei smart components to support rapid response to related issues in after-sales service. Fault tree design platform: providing a fault tree development, testing and release platform to support Lantu professionals and after-sales personnel to continuously accumulate and operate fault analysis models and improve after-sales service efficiency. Risk warning: supporting monitoring of the health of disks and risk prediction of vehicles that are about to reach their life limit or exceed their lifespan. Problem management: supporting docking with the work order system, automatically generating related issues, recording the process and results of problem analysis, signal details of related analysis, alarms, etc. Business dashboard: Provides real-time business overview, supports visual viewing of online vehicle trends, component failure rankings, alarm trend analysis, and version TOP alarm statistics. System configuration: Performs VHR system-level configuration management, including CAN acquisition item configuration and digital twin mapping relationship configuration. Data export: Supports management of data export tasks, viewing task lists, task details, and data download.

[0037] It is understandable that parsing the real-time log can clearly reveal the condition of the vehicle, such as power failure, black screen and other problems.

[0038] It should be noted that the current log can be obtained by the vehicle side recording the data changes occurring on the vehicle side in real time and then feeding back to the cloud.

[0039] It should be noted that vehicle fault codes, also known as diagnostic trouble codes (DTCs-Diagnostic Trouble Codes), are codes used to identify specific faults or abnormal conditions in automotive electronic systems. When the vehicle's electronic control system detects that a component or system is not within the normal operating range, it will record a fault code. Vehicle fault codes follow certain standards, and the most common standard is OBD-II (On-Board Diagnostics Second Generation), which is an internationally accepted automotive fault diagnosis standard. The OBD-II system not only requires the vehicle to have self-diagnosis capabilities, but also specifies the format and interpretation of fault codes.

[0040] It should be noted that the vehicle may have various faults of varying sizes during use. Some faults may occur suddenly, and some fault codes may only represent an abnormality in certain data and cannot fully indicate that there is a fault with the vehicle.

[0041] Step S20: taking at least one of the current driving data, the current fault code and the current log as a factor to be identified.

[0042] It should be noted that the factor to be identified can be any one of the previous driving data, the current fault code and the current log; it can also be a combination of any two of the previous driving data, the current fault code and the current log; it can also be a combination of three data of the previous driving data, the current fault code and the current log. The familiar factors to be identified in the following embodiments include any one of these three situations and will not be repeated here.

[0043] Step S30, obtaining the factor state of the factor to be identified based on a preset data anomaly identification model.

[0044] It is understandable that the preset data anomaly recognition model can be based on the Light GBM model to identify whether the vehicle data represented by each factor to be identified needs to be alarmed; if an alarm is required, the factor state is a fault state, and if an alarm is not required, the factor state is a normal state.

[0045] It should be understood that a certain parameter in the data uploaded by the vehicle may be abnormal, but the abnormality of the parameter may not be enough to trigger an alarm.

[0046] It should be noted that the factor state may include a fault state and a normal state.

[0047] It should be understood that the preset data anomaly recognition model can be a pre-collected collection of different vehicle faults that require warnings, as well as the factors to be identified corresponding to each vehicle fault. The preset data anomaly recognition model can be obtained by training the Light GBM model based on the pre-collected vehicle faults and the corresponding factors to be identified.

[0048] It should be emphasized that for the data uploaded from the vehicle to the cloud, data access, cleaning and calculation are performed based on the vehicle-to-cloud connection method. The original driving data of the vehicle is collected according to the collection cycle, and then the data is cleaned and stored as denoised driving data. By traversing the data generated by denoising driving, based on the collection time and the current time, a large amount of cleaned original driving data can be divided according to the vehicle journey. Data types include but are not limited to vehicle-side communication data (i.e., vehicle operation data), vehicle-side diagnostic data (i.e., fault codes), vehicle-side system logs (i.e., real-time logs), and data related to cloud business systems.

[0049] Step S40: When the factor state is a fault state, a vehicle fault alarm is issued based on the factor to be identified.

[0050] It is understandable that when the factor state is a fault state, it can represent that the vehicle fault at this time needs to be taken seriously and an alarm needs to be issued, but how to specifically maintain the fault and how to issue an alarm requires identifying the identification factor through the preset fault map.

[0051] It should be noted that the alarm can be sent in the form of text message reminders, voice call reminders, etc. to the vehicle-bound user.

[0052] In a feasible implementation, step S40 may include steps A41 to A43: Step A41, when the factor state is a fault state, obtaining the fault type of the factor to be identified according to the factor state.

[0053] It is understandable that the fault type of the factor to be identified according to the factor state can be obtained by identifying a fault classification model based on a machine learning model and a graph algorithm.

[0054] It should be understood that the fault classification model can be trained through the vehicle's historical driving conditions and faults, the loss function of the model can be corrected by setting category weights and L_1 regularization terms, and the value of the correction term coefficient can be obtained by using Bayesian optimization to improve the training speed and recall rate.

[0055] Step A42, identifying a maintenance strategy for the fault type according to a preset fault map.

[0056] It is understandable that the preset fault map can be established using machine learning models and graph algorithms, which can achieve automatic matching of faults and maintenance solutions.

[0057] It should be noted that the preset fault map can be updated in real time based on the input of new fault types or new maintenance plans.

[0058] It should be emphasized that the Apriori algorithm can be used to mine driving data and fault data. Vehicle data is uploaded to the cloud through flexible data acquisition tools, once per second, with about 4,000+ core alarm-related signals each time. Fault codes are uploaded through the UDP protocol, and fault information is uploaded after ignition. The background continuously improves the fault map to improve the accuracy of fault control.

[0059] It should be further explained that driving data and fault data can also be mined based on DSP signal deep processing technology to improve the fault map. It is understandable that the update or mining of the map data can be the algorithm used in this embodiment or other algorithms, and this embodiment does not limit this.

[0060] It should be noted that, before identifying the maintenance strategy of the fault type according to the preset fault map, one-to-one corresponding historical fault types and historical fault maintenance strategies are obtained; and the preset fault map is obtained according to the historical fault types and the historical fault maintenance strategies.

[0061] Step A43, feeding back the maintenance strategy and the fault type to the user of the vehicle to complete the vehicle fault alarm.

[0062] It is understandable that different maintenance strategies are used based on different fault types / fault problems, which may include downloading an update package or patch package, or reminding the user to conduct further detailed inspection / repair of a problem offline.

[0063] In this embodiment, by determining that the state of the factor to be identified is a fault state, the cause of the fault is identified through the factors to be identified, and a corresponding maintenance strategy is generated according to the cause of the fault. The vehicle owner is warned based on the maintenance strategy and the cause of the fault, which can avoid more serious harm to the vehicle side due to potential faults, and at the same time, the vehicle maintenance efficiency can be improved based on the maintenance strategy.

[0064] The above are only feasible implementations of step S40 provided in this embodiment, and this embodiment does not specifically limit the specific implementation of step S40.

[0065] It should be noted that when the factor state is a fault state, after issuing a vehicle fault alarm based on the factor to be identified, it also includes: determining the alarm type based on the diagnostic information of the vehicle fault alarm, searching for historical alarms of the same type based on the alarm type; obtaining the factor to be updated based on the historical alarms of the same type; and when the alarm type meets the preset false alarm condition, updating the preset data anomaly recognition model according to the factor to be updated.

[0066] It is understandable that when the vehicle determines whether an alarm is required based on the factors to be identified, it is also necessary to determine whether the alarm values ​​for each factor to be identified in the model are reasonable.

[0067] Among them, for example, the alarm value of vehicle operation data A is 90, that is, as long as the value of vehicle operation data A reaches 90, a vehicle alarm should be issued; however, the maintenance results after the alarm due to vehicle operation data A exceeding the alarm value can be viewed in the historical data, that is, the same type of historical alarms. If the maintenance result of the same type of historical alarm is that damage has occurred, it can be understood that the alarm value of vehicle operation data A is 90 and damage has already occurred, and the effect of fault warning to avoid losses cannot be achieved. The alarm value can be changed to 95% of the original alarm value or other new alarm values, and the preset data anomaly recognition model can be updated based on the new alarm value.

[0068] It should be understood that obtaining the factor to be updated based on the same type of historical alarms can be based on the maintenance results corresponding to the same type of historical alarms to determine whether the setting of the alarm value of this type is reasonable. If it is reasonable, no feedback is given; if it is unreasonable, the factor of the historical alarm of this type is used as the factor to be updated.

[0069] It should be noted that when the alarm type meets the preset false alarm condition, it can be the above-mentioned "judging whether the setting of the alarm value of this type is reasonable based on the maintenance results corresponding to the historical alarms of the same type". If it is unreasonable, the preset false alarm condition is met.

[0070] Among them, it can be understood that if more than 80% of the maintenance results corresponding to the historical alarm are damaged, it can be understood that the alarm value setting of the factor is unreasonable; if the alarm frequency of the historical alarm exceeds the preset frequency, it is considered that the alarm value setting of the factor is unreasonable. The preset frequency can be set according to actual needs, and this embodiment does not limit this.

[0071] In the specific implementation, the system is connected to the car's ECU through an interface to collect signal data such as engine speed, vehicle speed, fuel consumption, etc. in real time, and read log files through the vehicle's CAN bus. The collected signal data is filtered and normalized, and the log files are parsed to extract key information such as fault codes, warning information, sensor readings, etc., and convert these information into feature vectors; a convolutional neural network is used to analyze the feature vectors to identify the type and possible causes of software problems. It can also use online learning functions to continuously optimize the diagnostic model based on newly collected data; at the same time, technicians can input diagnostic instructions through the interface, view real-time data charts and historical trend analysis, and export diagnostic reports.

[0072] This embodiment provides a vehicle fault alarm method, which obtains real-time operation data, fault codes and logs on the vehicle side, and performs remote real-time fault analysis and fault alarm on the vehicle based on a preset data anomaly recognition model according to the real-time operation data, fault codes and at least one parameter of the log on the vehicle side. It can remotely, quickly and accurately identify automobile fault problems, reduce dependence on professional technicians, improve diagnostic efficiency, speed up the maintenance process, and also improve user experience.

[0073] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 2 , step S30, the vehicle fault alarm method further includes steps S31-S32: Step S31, identifying the factor type of the factor to be identified according to the preset data anomaly identification model.

[0074] It is understandable that the factor type may include a single factor type, a combined factor type, and a mixed factor type.

[0075] It should be understood that a single factor type only needs to determine whether this parameter meets the early warning requirements; a combined factor or a mixed factor requires that each factor meets the corresponding early warning requirements.

[0076] It should be noted that in the preset data anomaly recognition model, different parameter alarm conditions for single factors are preset; as well as alarm conditions for each parameter under the combination factor and mixed factor types.

[0077] In a feasible implementation manner, step S31 may include steps A3101 to A3105: Step A3101, obtaining the historical driving data, historical fault codes and historical logs of the vehicle.

[0078] It is understandable that the purpose of obtaining the vehicle's historical driving data, historical fault codes and historical logs is to build a preset data anomaly recognition model. At this time, the historical driving data, historical fault codes and historical logs can be collected in real time on the vehicle side and then obtained from the vehicle side.

[0079] It should be understood that the historical data may be the driving data, fault codes and logs of the vehicle within a preset mileage of the vehicle, or the driving data, fault codes and logs of the vehicle within a preset driving duration of the vehicle.

[0080] Step A3102, obtaining a driving data fault threshold according to the historical driving data, determining an alarm fault code according to the historical fault code, and determining alarm log information according to the historical log.

[0081] It is understandable that the faults that need to be warned can be determined in advance, and then the historical driving data / historical fault codes / historical logs / historical driving data + historical fault codes / historical driving data + historical logs / historical fault codes + historical dates / historical driving data / historical fault codes / historical logs corresponding to the faults that need to be warned can be further screened out.

[0082] It should be noted that when building the model, it is necessary to determine the data involved in order to accurately determine a certain fault that requires early warning. For example, the faults that require alarms are A, B, C, D, E, and F. If you want to determine whether the vehicle has fault A, you only need to determine whether the vehicle driving data meets the requirements; if you want to determine whether the vehicle has fault B, you need to determine whether the vehicle driving data meets the requirements and whether the fault meets the requirements. The same applies to C, D, E, and F.

[0083] It should be noted that the driving data fault threshold may be a driving data threshold corresponding to a fault type that only requires a single driving data to issue an alarm. Once the driving data exceeds the threshold or is lower than the threshold, an alarm is required.

[0084] Furthermore, there are many kinds of driving data, and the alarm requirements for different data may be not exceeding a certain value, or not being less than a certain value. The driving data fault threshold can be understood as a general expression of this limit value.

[0085] It should be noted that many types of fault codes may appear during the operation of the vehicle. Both very small problems and very serious problems can generate faults. It is necessary to pre-screen the fault codes corresponding to the fault problems that need to be solved as soon as they appear, or the fault codes corresponding to the fault problems that will cause very serious problems if not solved after they appear. These two types of fault codes should be used as warning fault codes for warnings through a single fault code.

[0086] It should be noted that it is necessary to pre-screen the log information corresponding to the fault problems that need to be solved as soon as they occur, or the log information corresponding to the fault problems that will cause very serious problems if not solved after they occur, and use these two fault codes as alarm log information for alarming through a single log.

[0087] Step A3103: Use at least two of the historical driving data, the historical fault codes and the historical logs as combination factors.

[0088] It is understandable that some faults not only affect a single driving data, fault code and log when they occur, but also may lead to the neglect of the fault because a single value does not meet the alarm requirements.

[0089] It should be noted that a comprehensive judgment is made based on the driving data, fault code and any two or three of the logs to determine whether a fault requiring an alarm has occurred.

[0090] It is understandable that the combination factor is to combine the parameters of each factor in the factor to simultaneously satisfy the corresponding driving data fault threshold / warning fault code / warning log information.

[0091] It should be emphasized that the alarm threshold of the same parameter in a single factor may be different from or the same as the alarm threshold of the same parameter in a combined factor.

[0092] Step A3104, determining combined fault information according to the combined factor.

[0093] It is understandable that the combination factor can be determined based on the fault type to determine the factors related to the fault: driving data, fault code and log, and then the combined fault information of the combination factor is determined according to the values ​​of each factor when the same fault occurs during the historical vehicle maintenance process.

[0094] In a specific implementation, it is first determined that fault A requires an alarm. After analysis, it is determined that the occurrence of fault A is related to both driving data 1 and fault code 2. The value a1 of the driving data and the state a2 of the fault code when fault A occurs are queried from the vehicle's historical maintenance records. The value a1 of the driving data and the state a2 of the fault code can be used as combined fault information of fault A. The next time the driving data tends to a1 or is equal to a1 and the state of the fault code is a2, it can be considered that a condition that requires an alarm has occurred, and the type of fault that requires an alarm is fault A.

[0095] Step A3105, obtaining a preset data anomaly recognition model according to the driving data fault threshold, the alarm fault code, the alarm log information and the combined fault information.

[0096] It is understandable that the data of various single factor alarms or combined factor alarms when failures occur during the historical maintenance process are used as identification of the occurrence of failures.

[0097] It should be understood that the preset data anomaly recognition model can analyze whether the vehicle is in a situation that requires an alarm based on a single factor or multiple combined factors.

[0098] It should be noted that after obtaining the preset data anomaly recognition model according to the driving data fault threshold, the alarm fault code, the alarm log information and the combined fault information, the test driving data, the test fault code, the test log and the test combination factor are obtained; the preset data anomaly recognition model is tested according to the test driving data, the test fault code, the test log and the test combination factor to obtain the test result; the optimization coefficient is obtained according to the preset loss function and the test result; the category weight and the correction coefficient of the preset data anomaly recognition model are adjusted according to the optimization coefficient until the test result meets the preset test requirements.

[0099] Among them, it is understandable that the model needs to be tested after it is successfully built to ensure the accuracy of the model, and a loss function is constructed based on the test results to optimize the model, so that possible fault hazards can be discovered more promptly and alarm reminders can be issued.

[0100] In this embodiment, by predetermining the fault category that requires an alarm, and then further confirming the relevant data of the fault category, and then finding the characteristic data of each fault type from the historical maintenance data, a model is constructed based on the relevant characteristic data of each fault type in the historical data, which can quickly and accurately identify the type of factor to be identified.

[0101] The above are merely feasible implementations before step S31 provided in this embodiment, and this embodiment does not specifically limit the specific implementations before step S31.

[0102] Step S32: based on the factor type, the factor to be identified is compared with a preset driving data fault threshold, a preset warning fault code, a preset warning log information, or a preset combined fault information to obtain a comparison result.

[0103] It is understandable that the factor types here can be understood as various situations for analysis. Upload vehicle operation data, fault codes and logs to the cloud in real time It should be noted that the comparison result may be satisfied or not satisfied. Satisfying the requirement can be understood as the parameter value of a single factor in the factors to be identified meeting the single factor fault threshold; there may be multiple single factors that meet the single factor alarm threshold of the factor. It may also be that each factor in the combined factor meets the fault threshold of each factor in the preset combined fault information.

[0104] Step S33, obtaining the factor state according to the comparison result.

[0105] It is understandable that if the comparison result satisfies the fault threshold of a single factor or satisfies the fault threshold of each factor in the combination factor, the comparison result may be satisfied; if neither the fault threshold of a single factor nor the fault threshold of each factor in the combination factor is satisfied, the comparison result may be not satisfied.

[0106] It can be understood that if the requirements are met, the factor state is a fault state, and if the requirements are not met, the factor state is a normal state.

[0107] This embodiment provides a vehicle fault alarm method, which analyzes factors through a pre-built fault prediction model to determine whether the parameters of each factor are the same as the factor parameters when the vehicle fails, thereby identifying the factor state based on the model, which can quickly and accurately identify the factor state and issue an alarm based on the factor state.

[0108] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the vehicle fault alarm method of the present application. More simple transformations based on this technical concept are all within the protection scope of the present application.

[0109] This application also provides a vehicle fault warning device, please refer to Figure 4 , the vehicle fault warning device comprises: The acquisition module 10 is used to acquire the current driving data, current fault code and current log of the vehicle; A fault identification module 20, configured to use at least one of the current driving data, the current fault code and the current log as a factor to be identified; The fault identification module 20 is further used to obtain the factor state of the factor to be identified based on a preset data anomaly identification model; The fault warning module 30 is used to issue a vehicle fault warning based on the factor to be identified when the factor state is a fault state.

[0110] The vehicle fault alarm device provided by the present application adopts the vehicle fault alarm method in the above embodiment, which can solve the technical problems that manufacturers are currently unable to remotely and quickly identify possible problems with vehicles in advance, and repair vehicles after they are sold when problems occur, which makes fault analysis difficult, increases the workload of after-sales service, and leads to poor user experience. Compared with the prior art, the beneficial effects of the vehicle fault alarm device provided by the present application are the same as the beneficial effects of the vehicle fault alarm method provided by the above embodiment, and the other technical features of the vehicle fault alarm device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0111] The present application provides a vehicle fault alarm device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the vehicle fault alarm method in the above-mentioned embodiment one.

[0112] Reference below Figure 5 , which shows a schematic diagram of the structure of a vehicle fault alarm device suitable for implementing an embodiment of the present application. The vehicle fault alarm device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The vehicle fault warning device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0113] like Figure 5 As shown, the vehicle fault warning device may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the vehicle fault warning device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the vehicle fault warning device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a vehicle fault warning device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0114] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0115] The vehicle fault alarm device provided by the present application adopts the vehicle fault alarm method in the above embodiment, which can solve the technical problems that manufacturers are currently unable to remotely and quickly identify possible problems with vehicles in advance, and that the vehicle is repaired only after problems occur after it is sold, which makes fault analysis difficult, increases the workload of after-sales service, and leads to poor user experience. Compared with the prior art, the beneficial effects of the vehicle fault alarm device provided by the present application are the same as the beneficial effects of the vehicle fault alarm method provided by the above embodiment, and the other technical features of the vehicle fault alarm device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0116] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0117] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0118] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the vehicle fault alarm method in the above-mentioned embodiment.

[0119] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0120] The computer-readable storage medium may be included in the vehicle fault warning device; or may exist independently without being assembled into the vehicle fault warning device.

[0121] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the vehicle fault alarm device, the vehicle fault alarm device: obtains the current driving data, current fault code and current log of the vehicle; uses at least one of the current driving data, current fault code and current log as a factor to be identified; obtains the factor state of the factor to be identified based on a preset data anomaly recognition model; and when the factor state is a fault state, performs a vehicle fault alarm based on the factor to be identified.

[0122] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Small talk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0123] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0124] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0125] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned vehicle fault alarm method, and can solve the current technical problems that manufacturers cannot remotely and quickly identify possible problems of vehicles in advance, and repair vehicles after they are sold when problems occur, which makes fault analysis difficult, increases the workload of after-sales service, and leads to poor user experience. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the vehicle fault alarm method provided by the above-mentioned embodiment, and will not be elaborated here.

[0126] The present application also provides a computer program product, including a computer program, which implements the steps of the vehicle fault warning method as described above when executed by a processor.

[0127] The computer program product provided by this application can solve the technical problems that manufacturers are currently unable to remotely and quickly identify possible problems with vehicles in advance, and that vehicles are repaired after they are sold when problems occur, which makes fault analysis difficult, increases the workload of after-sales service, and leads to poor user experience. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as those of the vehicle fault alarm method provided in the above embodiment, and will not be elaborated here.

[0128] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A vehicle fault alarm method, characterized in that: The vehicle fault alarm method comprises: Get the vehicle's current driving data, current fault code, and current log; taking at least one of the current driving data, the current fault code and the current log as a factor to be identified; Obtaining the factor state of the factor to be identified based on a preset data anomaly identification model; When the factor state is a fault state, a vehicle fault alarm is issued based on the factor to be identified.

2. The vehicle fault alarm method according to claim 1, characterized in that: The step of obtaining the factor state of the factor to be identified based on the preset data anomaly identification model includes: Identifying the factor type of the factor to be identified according to the preset data anomaly identification model; Comparing the factor to be identified with a preset driving data fault threshold, a preset warning fault code, a preset warning log information, or a preset combined fault information based on the factor type to obtain a comparison result; The factor state is obtained according to the comparison result.

3. The vehicle fault warning method according to claim 1, characterized in that: Before obtaining the factor state of the factor to be identified based on the preset data anomaly identification model, the method further includes: Obtaining historical driving data, historical fault codes and historical logs of the vehicle; Obtaining a driving data fault threshold according to the historical driving data, determining an alarm fault code according to the historical fault code, and determining alarm log information according to the historical log; taking at least two of the historical driving data, the historical fault codes and the historical logs as combination factors; Determine combined fault information according to the combined factor; A preset data anomaly recognition model is obtained according to the driving data fault threshold, the warning fault code, the warning log information and the combined fault information.

4. The vehicle fault warning method according to claim 3, characterized in that: After obtaining the preset data anomaly recognition model according to the driving data fault threshold, the warning fault code, the warning log information and the combined fault information, the method further includes: Obtain test driving data, test fault codes, test logs, and test combination factors; Testing the preset data anomaly recognition model according to the test driving data, the test fault code, the test log, and the test combination factor to obtain a test result; Obtaining an optimization coefficient according to a preset loss function and the test results; The category weight and correction coefficient of the preset data anomaly recognition model are adjusted according to the optimization coefficient until the test result meets the preset test requirement.

5. The vehicle fault warning method according to claim 1, characterized in that: When the factor state is a fault state, issuing a vehicle fault alarm based on the to-be-identified factor includes: When the factor state is a fault state, obtaining the fault type of the factor to be identified according to the factor state; Identify the maintenance strategy of the fault type according to the preset fault map; The maintenance strategy and the fault type are fed back to the user of the vehicle to complete the vehicle fault warning.

6. The vehicle fault warning method according to claim 5, characterized in that: Before the maintenance strategy of the fault type is identified according to the preset fault map, the method further includes: Obtain one-to-one correspondence between historical fault types and historical fault repair strategies; A preset fault map is obtained according to the historical fault types and the historical fault maintenance strategies.

7. The vehicle fault warning method according to claim 1, characterized in that: When the factor state is a fault state, after the vehicle fault alarm is issued based on the factor to be identified, the method further includes: Determine an alarm type according to the diagnostic information of the vehicle fault alarm, and search for historical alarms of the same type based on the alarm type; Obtaining a factor to be updated based on the historical alarms of the same type; When the alarm type meets the preset false alarm condition, the preset data anomaly recognition model is updated according to the factor to be updated.

8. A vehicle fault warning device, characterized in that: The vehicle fault warning device comprises: The acquisition module is used to obtain the current driving data, current fault code and current log of the vehicle; a fault identification module, configured to use at least one of the current driving data, the current fault code and the current log as a factor to be identified; The fault identification module is further used to obtain the factor state of the factor to be identified based on a preset data anomaly identification model; A fault warning module is used to issue a vehicle fault warning based on the factor to be identified when the factor state is a fault state.

9. A vehicle fault warning device, characterized in that: The device comprises: a memory, a processor, and a vehicle fault warning program stored in the memory and executable on the processor, wherein the vehicle fault warning program is configured to implement the vehicle fault warning method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a vehicle fault warning program, and when the vehicle fault warning program is executed by the processor, the vehicle fault warning method according to any one of claims 1 to 7 is implemented.

Images