Abnormality troubleshooting method, device, server and storage medium
By acquiring vehicle component status data and combining it with abnormal vehicle condition data, the cause of vehicle malfunctions can be directly identified, solving the problem of low efficiency in processing abnormal vehicle condition data in existing technologies and achieving efficient fault location and repair guidance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GREAT WALL MOTOR CO LTD
- Filing Date
- 2023-10-31
- Publication Date
- 2026-05-19
AI Technical Summary
In existing technologies, the process of investigating abnormal vehicle condition data involves repeatedly executing the same steps, resulting in low processing efficiency and an inability to efficiently locate vehicle faults.
By acquiring the status data of vehicle components and combining it with abnormal vehicle condition data, anomaly investigations can be conducted to directly determine whether the target vehicle component is faulty. If it is not faulty, other components or external factors are investigated, and corresponding reminders or warnings are sent to improve efficiency.
It avoids repeatedly analyzing vehicle condition data at different times, improves the efficiency of anomaly troubleshooting, promptly alerts users to vehicle problems and guides them in repairs, reduces unnecessary panic, and quickly resolves faults.
Smart Images
Figure CN117409500B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicles, and more specifically, to methods, apparatus, servers, and storage media for anomaly detection in the field of vehicles. Background Technology
[0002] With the development of vehicle technology, more and more vehicles are entering people's lives.
[0003] In related technologies, there are vehicle condition display applications (APPs) that can display abnormal vehicle condition data and the time when the data was collected. Vehicle users can obtain information about specific vehicle malfunctions by reporting these abnormal data to the APP's backend. Specifically, after the APP's backend receives the abnormal data, its staff investigates it through multiple steps to pinpoint the vehicle's fault. However, during this investigation, the staff may repeatedly perform the same steps in a loop.
[0004] For example, during the anomaly investigation of tire pressure data collected at the first moment, since this data is transmitted from the vehicle's Telematics Box (TBOX) to the vehicle condition anomaly data app, the back-end personnel will check for faults in the transmission link. If the transmission link is fault-free, it is necessary to obtain the tire pressure data from the moment preceding the first moment. If anomalies are found in this previous moment's data, to accurately determine if the anomaly is caused by the data collection process, tire pressure data from the moment before that previous moment will also be collected to determine if there is a problem with the collection process. This involves multiple steps of obtaining and analyzing tire pressure data from different moments, which leads to low efficiency in the back-end troubleshooting process.
[0005] Therefore, there is an urgent need for a method to optimize the backend's ability to troubleshoot problems, so as to improve the efficiency of processing abnormal vehicle condition data. Summary of the Invention
[0006] This application provides a method, apparatus, server, and storage medium for anomaly detection. The method can improve the processing efficiency of anomaly detection for vehicle condition data.
[0007] In a first aspect, a method for anomaly detection is provided, the method comprising: acquiring vehicle condition anomaly data collected at a first moment; acquiring status data of at least one vehicle component associated with the vehicle condition anomaly data, the status data being used to indicate the working status of the at least one vehicle component at the first moment; and performing anomaly detection on the vehicle condition anomaly data based on the status data and the vehicle condition anomaly data.
[0008] In the above technical solution, after acquiring the abnormal vehicle condition data collected at the first moment, this application acquires the status data of at least one vehicle component associated with the abnormal vehicle condition data, and performs anomaly investigation on the abnormal vehicle condition data based on the status data and the abnormal vehicle condition data. This avoids the situation in the prior art where anomaly investigation of abnormal vehicle condition data is performed based on multiple stages, and the same step may be repeatedly executed during the anomaly investigation process. For example, in order to accurately determine whether there is an anomaly in the data collection process, vehicle condition data at different times is acquired and analyzed. Therefore, the solution of this application, by acquiring the status data of at least one vehicle component associated with the abnormal vehicle condition data, and performing anomaly investigation on the abnormal vehicle condition data based on the status data and the abnormal vehicle condition data, does not require multi-stage judgment, nor does it require the repetitive steps of acquiring vehicle condition data at different times and analyzing whether there is anomaly in the vehicle condition data. This solution can improve the processing efficiency of anomaly investigation of abnormal vehicle condition data.
[0009] In conjunction with the first aspect, in some possible implementations, based on the status data and the vehicle condition anomaly data, anomaly investigation is performed on the vehicle condition anomaly data, including: determining whether a target vehicle component among the at least one vehicle component has malfunctioned, the target vehicle component being used to collect the vehicle condition anomaly data; if the target vehicle component has not malfunctioned, determining, based on the status data, whether other vehicle components among the at least one vehicle component besides the target vehicle component have malfunctioned; if other vehicle components have not malfunctioned, determining that the cause of the anomaly in the vehicle condition anomaly data includes external environmental factors; sending a first reminder message to a target terminal, the first reminder message being used to remind the user to ignore the vehicle condition anomaly data, the target terminal being the terminal that provides feedback on the vehicle condition anomaly data; if other vehicle components have malfunctioned, determining that the cause of the anomaly in the vehicle condition anomaly data includes malfunctions in other vehicle components and is unrelated to the target vehicle component; sending a first warning message to the target terminal, the first warning message being used to remind the user to repair the other vehicle components.
[0010] In the above technical solution, priority is given to detecting whether a target vehicle component has malfunctioned. If the target vehicle component has not malfunctioned, the abnormal vehicle condition data is investigated based on the status data. That is, if the target vehicle component used to collect the abnormal vehicle condition data has not malfunctioned, it is possible that other vehicle components used to help determine the abnormal vehicle condition data have malfunctioned. Therefore, the abnormal vehicle condition data is investigated based on the status data. Specifically, if other vehicle components have also not malfunctioned, the cause of the abnormal vehicle condition data is directly determined to include external environmental factors, and a first alert is sent to the target terminal. This allows the vehicle user to understand, based on the target terminal, that the abnormal situation corresponding to the abnormal vehicle condition data is caused by external environmental factors and can be ignored. This avoids causing unnecessary panic for the vehicle user. Furthermore, if other vehicle components have malfunctioned, the cause of the abnormal vehicle condition data is determined to include malfunctions in other vehicle components unrelated to the target vehicle component, and a first warning is sent to the target terminal. This alerts the vehicle user to repair the other vehicle components, enabling the vehicle user to quickly identify and resolve vehicle problems.
[0011] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, after determining whether the target vehicle component in the at least one vehicle component has malfunctioned, the method further includes: in the case that the target vehicle component has malfunctioned, determining that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component; and sending a second warning message to the target terminal, the second warning message being used to remind the target vehicle component to be repaired.
[0012] In the above technical solution, after detecting whether a target vehicle component has malfunctioned, if the target vehicle component has malfunctioned, the cause of the abnormal vehicle condition data is determined to include the malfunction of the target vehicle component; a second warning message is sent to the target terminal, which is used to remind the vehicle user to repair the target vehicle component. In other words, if it is determined that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, a second warning message can be sent to the target terminal, which can promptly remind the vehicle user to repair the target vehicle component, so that the vehicle user can quickly identify and resolve vehicle problems.
[0013] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, when the target vehicle component malfunctions, after determining that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, the method further includes: when other vehicle components do not malfunction, determining that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component and is unrelated to the other vehicle components, wherein the second warning information is also used to remind that the abnormal cause of the abnormal vehicle condition data is unrelated to the other vehicle components; when other vehicle components malfunction, determining that the abnormal cause of the abnormal vehicle condition data includes both the malfunction of the target vehicle component and the malfunction of the other vehicle components; and sending a third warning information to the target terminal, wherein the third warning information is used to remind the target vehicle component and the other vehicle components to be repaired.
[0014] In the above technical solution, when a target vehicle component malfunctions, after determining that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, and when the status data indicates that other vehicle components are not malfunctioning, it is determined that the cause of the abnormality includes the malfunction of the target vehicle component and is unrelated to other vehicle components. The second warning information is also used to remind that the cause of the abnormality is unrelated to other vehicle components. In other words, the cause of the abnormal vehicle condition data only includes the malfunction of the target vehicle component, which allows vehicle users to clearly understand the cause of the abnormality and address vehicle problems promptly. When the status data indicates that other vehicle components malfunction, it is determined that the cause of the abnormality includes both the malfunction of the target vehicle component and the malfunction of other vehicle components; a third warning information is sent to the target terminal, which reminds the user to repair both the target vehicle component and the other vehicle components. This allows vehicle users to repair both the target vehicle component and the other vehicle components simultaneously, improving the efficiency of handling vehicle problems.
[0015] In combination with the first aspect and the above implementation methods, in some possible implementation methods, determining whether other vehicle components besides the target vehicle component in the at least one vehicle component have malfunctioned based on the status data includes: determining that the other vehicle component has malfunctioned when the status data is in an abnormal value range; and determining that the other vehicle component has not malfunctioned when the status data is in a normal value range.
[0016] In the above technical solution, since the status data is used to indicate the operating status of at least one vehicle component at the first moment, if the status data is within the normal range, the operating status of other vehicle components is normal, and the other vehicle components have not malfunctioned. Conversely, if the status data is outside the normal range, the other vehicle components have malfunctioned.
[0017] In combination with the first aspect and the above implementation methods, in some possible implementation methods, determining whether the target vehicle component in the at least one vehicle component has malfunctioned includes: acquiring raw vehicle condition data collected by the target vehicle component at a second time point corresponding to the abnormal vehicle condition data, the second time point being after the first time point; determining that the target vehicle component has malfunctioned if the raw vehicle condition data is abnormal; and determining that the target vehicle component has not malfunctioned if the raw vehicle condition data is normal.
[0018] In the above technical solution, the causes of abnormal vehicle condition data are varied. It could be a malfunction of the target terminal displaying the abnormal data, or a problem with the data link used to transmit the data to the target terminal. Therefore, it is possible to verify whether the target vehicle component has malfunctioned by obtaining the original vehicle condition data corresponding to the abnormal data collected from the target vehicle component at other times.
[0019] In combination with the first aspect and the above implementation methods, in some possible implementation methods, after acquiring the abnormal vehicle condition data collected at the first moment, the method further includes: displaying the abnormal vehicle condition data; and in response to a triggering operation on the abnormal vehicle condition data, performing the step of acquiring the status data of at least one vehicle component associated with the abnormal vehicle condition data.
[0020] In the above technical solution, after acquiring the vehicle's abnormal condition data collected at the first moment, the abnormal condition data is displayed; only when the abnormal condition data is triggered is the status data of at least one vehicle component associated with the abnormal condition data acquired. This allows the anomaly investigation process to be carried out only after it is clearly determined that the abnormal vehicle data needs to be investigated.
[0021] Secondly, an anomaly detection device is provided, comprising: an acquisition module, configured to: acquire vehicle condition anomaly data collected at a first moment; acquire status data of at least one vehicle component associated with the vehicle condition anomaly data, the status data indicating the working status of the at least one vehicle component at the first moment; and a detection module, configured to perform anomaly detection on the vehicle condition anomaly data based on the status data and the vehicle condition anomaly data.
[0022] In conjunction with the second aspect, in some possible implementations, the device further includes: a determining module, configured to: determine whether a target vehicle component among the at least one vehicle component has malfunctioned, the target vehicle component being used to collect the abnormal vehicle condition data; if the target vehicle component has not malfunctioned, determine, based on the status data, whether other vehicle components among the at least one vehicle component besides the target vehicle component have malfunctioned; if other vehicle components have not malfunctioned, determine that the abnormal cause of the abnormal vehicle condition data includes external environmental factors; the device further includes: a sending module, configured to send a first reminder message to a target terminal, the first reminder message being used to remind the user to ignore the abnormal vehicle condition data, the target terminal being a terminal that provides feedback on the abnormal vehicle condition data; the determining module is further configured to, if other vehicle components have malfunctioned, determine that the abnormal cause of the abnormal vehicle condition data includes malfunctions of other vehicle components and is unrelated to the target vehicle component; the sending module is further configured to send a first warning message to the target terminal, the first warning message being used to remind the user to repair the other vehicle components.
[0023] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after determining whether the target vehicle component in the at least one vehicle component has malfunctioned, the determining module is further configured to determine, in the case of the target vehicle component malfunctioning, that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component; the sending module is further configured to send a second warning message to the target terminal, the second warning message being used to remind the target vehicle component to be repaired.
[0024] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, when the target vehicle component malfunctions, after determining that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, the determining module is further configured to: determine that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component and is unrelated to the other vehicle components when no other vehicle components malfunction; the second warning information is further configured to remind that the cause of the abnormal vehicle condition data is unrelated to the other vehicle components; and determine that the cause of the abnormal vehicle condition data includes both the malfunction of the target vehicle component and the malfunction of the other vehicle components when other vehicle components malfunction; the sending module is further configured to send a third warning information to the target terminal, the third warning information being used to remind the target vehicle component and the other vehicle components to be repaired.
[0025] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is specifically used to: determine that the other vehicle component has malfunctioned when the status data is in an abnormal value range; and determine that the other vehicle component has not malfunctioned when the status data is in a normal value range.
[0026] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the acquisition module is further configured to acquire the original vehicle condition data collected by the target vehicle component at a second time corresponding to the abnormal vehicle condition data, the second time being after the first time; the determination module is further configured to: determine that the target vehicle component has malfunctioned when the original vehicle condition data is abnormal; and determine that the target vehicle component has not malfunctioned when the original vehicle condition data is normal.
[0027] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after acquiring the vehicle condition abnormality data collected at the first moment, the device further includes: a display module for displaying the vehicle condition abnormality data; the investigation module is also used to perform the step of acquiring the status data of at least one vehicle component associated with the vehicle condition abnormality data in response to the triggering operation of the vehicle condition abnormality data.
[0028] Thirdly, a server is provided, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, the server performs the method described in the first aspect or any possible implementation thereof.
[0029] Fourthly, a computer-readable storage medium is provided that stores instructions which, when executed on a computer or processor, cause the computer or processor to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description
[0030] Figure 1 This is a schematic diagram of a process for processing abnormal vehicle condition data provided in an embodiment of this application;
[0031] Figure 2 This is a schematic flowchart illustrating an anomaly detection method provided in an embodiment of this application;
[0032] Figure 3 This is a schematic diagram of the structure of a backend server provided in an embodiment of this application;
[0033] Figure 4 This is a schematic flowchart illustrating the acquisition of status data provided in an embodiment of this application;
[0034] Figure 5 This is a flowchart illustrating an anomaly investigation of abnormal vehicle condition data provided in an embodiment of this application.
[0035] Figure 6 This is a schematic diagram of a vehicle condition problem tracing tool provided in an embodiment of this application;
[0036] Figure 7 This is a schematic diagram of the structure of an anomaly detection device provided in an embodiment of this application;
[0037] Figure 8 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation
[0038] The technical solutions of this application will now be described clearly and in detail with reference to the accompanying drawings. In the description of the embodiments of this application, "multiple" refers to two or more. The terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.
[0039] Figure 1 This is a schematic diagram of a process for processing abnormal vehicle condition data provided in an embodiment of this application.
[0040] In existing technologies, after the back-end personnel of a vehicle status display app obtain abnormal vehicle status data, they investigate this data through multiple steps to pinpoint the problem. However, during the investigation process, back-end personnel may encounter situations where the same steps are repeatedly executed, resulting in low efficiency in troubleshooting.
[0041] For example, such as Figure 1As shown, the front end of the vehicle condition display app can receive abnormal tire pressure data, the first-time collected data on the abnormal tire pressure, and the geographical location. Based on this data, the front end generates a vehicle condition data anomaly issue ticket. The front end then conducts team discussions based on this ticket, determining that the cause of the abnormal tire pressure data is a problem with the back end of the vehicle condition display app. The front end then sends the ticket to the app's backend server, which receives it. Since the abnormal vehicle condition data on the app is reported by the vehicle's Telematics Box (TBOX), the backend server can find the tire pressure reported by the TBOX at the first moment (the tire pressure reported by the TBOX at the vehicle end) and query the specific first tire pressure value. The target terminal has the vehicle condition display app installed and is a terminal with control permissions over the vehicle. The backend server then determines whether the first tire pressure value is valid. If the first tire pressure value is valid, the backend server compares the abnormal tire pressure data with the first tire pressure value and returns the comparison result to the frontend so that the vehicle user can respond. If the first tire pressure value is invalid, the backend server reviews the handling plan based on the vehicle condition anomaly handling strategy to determine whether it is necessary to obtain the tire pressure from the previous moment. If it is not necessary to obtain the tire pressure from the previous moment, the backend server does not further investigate the cause of the abnormal tire pressure data. If it is necessary to obtain the tire pressure from the previous moment, the backend server queries the second tire pressure value from the previous moment to determine whether the second tire pressure value is valid, and repeats the check.
[0042] The process of troubleshooting anomalies is complex and may involve repeatedly checking tire pressure values at different times, which can significantly reduce the efficiency of anomaly detection.
[0043] It should be understood that the vehicle condition anomaly handling strategy in the above scheme is used to describe the processing method for anomaly investigation of vehicle condition anomaly data, specifically indicating the acquisition of status data of at least one vehicle component associated with the tire pressure anomaly data.
[0044] To improve the efficiency of anomaly detection in vehicle condition data, this application proposes an anomaly detection method. Specific embodiments can be found in the details. Figure 2 .
[0045] Figure 2 This is a schematic flowchart illustrating an anomaly detection method provided in an embodiment of this application.
[0046] It should be understood that the anomaly detection method provided in this application embodiment can be applied to... Figure 1 The image shows the backend server of the vehicle status display app. Specifically, this anomaly investigation method can also be applied to the vehicle status problem tracing tool on this backend server. This vehicle status problem tracing tool is an application that can perform anomaly investigation on abnormal vehicle status data through a graphical interface.
[0047] For example, such as Figure 2 As shown, the method 200 includes:
[0048] Step 201: The backend server obtains the vehicle condition anomaly data collected at the first moment.
[0049] It should be understood that the "abnormal vehicle condition data" in step 201 is collected at the first moment and reported by TBOX to the vehicle condition display APP, which is used to indicate the abnormal working status of any vehicle component in the vehicle.
[0050] In some embodiments, the vehicle component is a tire, and the vehicle abnormality data is an abnormal tire pressure value.
[0051] In some embodiments, step 201 includes: the backend server obtaining abnormal vehicle condition data fed back by the frontend of the vehicle condition display APP, the abnormal vehicle condition data being status data collected at the first moment to indicate that the working state of any vehicle component has become abnormal, and the frontend feeding back the abnormal vehicle condition data to the frontend of the backend server in response to the triggering operation of the abnormal vehicle condition data.
[0052] In some embodiments, if the front end determines that the cause of the abnormal vehicle condition data is not a display problem of the vehicle condition display APP, it can respond to the trigger operation of the abnormal vehicle condition data and feed back the abnormal vehicle condition data collected at the first moment to the backend server.
[0053] The above technical solution ensures that abnormal vehicle condition data is only reported to the backend server when the issue is not related to the vehicle condition display app. This allows for a step-by-step analysis of the cause of the abnormal data, helping to expedite the determination of the cause.
[0054] Step 202: The backend server obtains the status data of at least one vehicle component associated with the abnormal vehicle condition data. The status data is used to indicate the working status of the at least one vehicle component at the first moment.
[0055] It should be understood that both "status data of at least one vehicle component" and "abnormal vehicle condition data" in step 202 are used to indicate the working status of vehicle components. The difference is that "abnormal vehicle condition data" is used to indicate that the working status of any vehicle component is abnormal, emphasizing the abnormal working status of the vehicle component. "Status data of at least one vehicle component" is used to indicate the working status of at least one vehicle component at that first moment, but does not specify whether the working status of the at least one vehicle component is abnormal.
[0056] It should also be understood that "at least one vehicle component" in step 202 above specifically includes: the target vehicle component and other vehicle components, wherein the target vehicle component is used to collect the abnormal vehicle condition data, and the other vehicle components refer to other vehicle components besides the target vehicle component used to assist in determining the abnormal vehicle condition data.
[0057] In some embodiments, the abnormal vehicle condition data is an abnormal tire pressure value. The target vehicle component is the tire pressure sensor, and the other vehicle component is the vehicle battery. Specifically, upon receiving an abnormal tire pressure value, the backend server obtains the status data of the vehicle battery that supplies power to the tire pressure sensor.
[0058] In one possible implementation, after step 201, method 200 further includes: a background server displaying the vehicle condition abnormality data; and the background server, in response to a triggering operation on the vehicle condition abnormality data, performing a step of obtaining status data of at least one vehicle component associated with the vehicle condition abnormality data.
[0059] In the above technical solution, after acquiring the vehicle's abnormal condition data collected at the first moment, the abnormal condition data is displayed; only when the abnormal condition data is triggered is the status data of at least one vehicle component associated with the abnormal condition data acquired. This allows the anomaly investigation process to be carried out only after it is clearly determined that the abnormal vehicle data needs to be investigated.
[0060] In some embodiments, the triggering operation includes any one of the following: clicking on the abnormal vehicle condition data, triggering the abnormal vehicle condition data with voice, triggering the abnormal vehicle condition data with eye contact, and triggering the abnormal vehicle condition data with a target gesture.
[0061] In some embodiments, the backend server also displays the physical meaning and first moment indicated by the vehicle condition anomaly data.
[0062] Optionally, the physical meaning indicated by the first tire pressure value is tire pressure.
[0063] In some embodiments, after step 202, the backend server displays the current time, vehicle condition abnormality data, the physical meaning of the vehicle condition abnormality data, the vehicle condition abnormality handling strategy, the status data of at least one vehicle component, the first time, and the vehicle identification number (VIN) of the vehicle. The vehicle condition abnormality handling strategy is used to instruct the acquisition of the status data of at least one vehicle component associated with the vehicle condition abnormality data.
[0064] Step 203: Based on the status data and the abnormal vehicle condition data, the backend server performs anomaly investigation on the abnormal vehicle condition data.
[0065] It should be understood that step 203 can be interpreted as: based on the status data and the abnormal vehicle condition data, analyzing whether the abnormality of the abnormal vehicle condition data is due to a failure of the target vehicle component used to collect the abnormal vehicle condition data, a failure of other vehicle components used to assist in determining the abnormal vehicle condition data, or no failure of the target vehicle component and other vehicle components, but only affected by external environmental factors, etc.
[0066] In some embodiments, the abnormal vehicle condition data is an abnormal tire pressure value. The cause of the abnormal tire pressure value is a malfunction of the tire pressure sensor used to collect the abnormal tire pressure value, a malfunction of the vehicle battery that provides power to the tire pressure sensor, or a malfunction of both the tire pressure sensor and the vehicle battery, and the tire pressure sensor is only damaged by a collision.
[0067] In one possible implementation, step 203 includes: a backend server determining whether a target vehicle component among the at least one vehicle component has malfunctioned, the target vehicle component being used to collect the abnormal vehicle condition data; if the target vehicle component has not malfunctioned, the backend server determining, based on the status data, whether other vehicle components among the at least one vehicle component besides the target vehicle component have malfunctioned; if the other vehicle components have not malfunctioned, the backend server determining that the abnormal cause of the abnormal vehicle condition data includes external environmental factors; the backend server sending a first reminder message to a target terminal, the first reminder message being used to remind the user to ignore the abnormal vehicle condition data, the target terminal being the terminal that provides feedback on the abnormal vehicle condition data; if other vehicle components have malfunctioned, the backend server determining that the abnormal cause of the abnormal vehicle condition data includes malfunctions in other vehicle components and is unrelated to the target vehicle component; the backend server sending a first warning message to the target terminal, the first warning message being used to remind the user to repair the other vehicle components.
[0068] In the above technical solution, priority is given to detecting whether a target vehicle component has malfunctioned. If the target vehicle component has not malfunctioned, the abnormal vehicle condition data is investigated based on the status data. That is, if the target vehicle component used to collect the abnormal vehicle condition data has not malfunctioned, it is possible that other vehicle components used to help determine the abnormal vehicle condition data have malfunctioned. Therefore, the abnormal vehicle condition data is investigated based on the status data. Specifically, if other vehicle components have also not malfunctioned, the cause of the abnormal vehicle condition data is directly determined to include external environmental factors, and a first alert is sent to the target terminal. This allows the vehicle user to understand, based on the target terminal, that the abnormal situation corresponding to the abnormal vehicle condition data is caused by external environmental factors and can be ignored. This avoids causing unnecessary panic for the vehicle user. Furthermore, if other vehicle components have malfunctioned, the cause of the abnormal vehicle condition data is determined to include malfunctions in other vehicle components unrelated to the target vehicle component, and a first warning is sent to the target terminal. This alerts the vehicle user to repair the other vehicle components, enabling the vehicle user to quickly identify and resolve vehicle problems.
[0069] In some embodiments, the target terminal is capable of displaying the first reminder information and / or broadcasting the first reminder information via voice. The target terminal is also capable of displaying the first warning information and / or broadcasting the first warning information via voice.
[0070] In some embodiments, the backend server determines a target shop near the vehicle that can repair the other vehicle parts based on the vehicle's geographical location and information about the malfunction of the other vehicle parts; the backend server then sends the information of the target shop and the vehicle's travel route from the geographical location to the target shop to the target terminal.
[0071] In the above technical solution, the backend server sends the target store's information and the vehicle's driving route from that geographical location to the target store to the target terminal. This method enables vehicle users to quickly determine the relevant information of the target store for repairing other vehicle parts through the target terminal, and reach the target store as soon as possible via the driving route to quickly repair the other vehicle parts.
[0072] In some embodiments, the backend server determines whether a target vehicle component among the at least one vehicle component has malfunctioned, including: the backend server acquiring raw vehicle condition data collected by the target vehicle component at a second time point corresponding to the abnormal vehicle condition data, the second time point being after the first time point; if the raw vehicle condition data is abnormal, the backend server determines that the target vehicle component has malfunctioned; if the raw vehicle condition data is normal, the backend server determines that the target vehicle component has not malfunctioned.
[0073] It should be understood that the "raw vehicle condition data" in the above scheme refers to the status data collected by the target vehicle components in the vehicle at the second moment, which has not been reported to the vehicle condition display APP by the TBOX. "Raw vehicle condition data corresponding to the abnormal vehicle condition data" can be specifically understood as: the raw vehicle condition data and the abnormal vehicle condition data were collected at different times, but have the same physical meaning; the raw vehicle condition data was not reported to the vehicle condition display APP, while the abnormal vehicle condition data has been reported to the vehicle condition display APP. The second moment is any moment after the first moment, equivalent to the second moment; the first moment is a historical moment. In some embodiments, the second moment can be the current moment when anomaly investigation of the abnormal vehicle condition data is performed.
[0074] It should also be understood that the above scheme can be interpreted as: using the original vehicle condition data at the second moment as a basis to infer whether the target vehicle component has malfunctioned. Since the status data is used to indicate the operating status of at least one vehicle component at the first moment, if the status data is within the normal range, the operating status of the target vehicle component is normal, and the target vehicle component has not malfunctioned. Conversely, the target vehicle component has malfunctioned.
[0075] In the above technical solution, the causes of abnormal vehicle condition data are varied. It could be a malfunction of the target terminal displaying the abnormal data, or a problem with the data link used to transmit the data to the target terminal. Therefore, it is possible to verify whether the target vehicle component has malfunctioned by obtaining the original vehicle condition data corresponding to the abnormal data collected from the target vehicle component at other times.
[0076] In some embodiments, after the backend server determines whether the target vehicle component among the at least one vehicle component has malfunctioned, the method further includes: in the case that the target vehicle component has malfunctioned, the backend server determines that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component; the backend server sends a second warning message to the target terminal, the second warning message being used to remind the target vehicle component to be repaired.
[0077] In the above technical solution, after detecting whether a target vehicle component has malfunctioned, if the target vehicle component has malfunctioned, the cause of the abnormal vehicle condition data is determined to include the malfunction of the target vehicle component; a second warning message is sent to the target terminal, which is used to remind the vehicle user to repair the target vehicle component. In other words, if it is determined that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, a second warning message can be sent to the target terminal, which can promptly remind the vehicle user to repair the target vehicle component, so that the vehicle user can quickly identify and resolve vehicle problems.
[0078] In some embodiments, the target terminal may be able to display the second warning information and / or broadcast the second warning information via voice.
[0079] In some embodiments, when the target vehicle component malfunctions, after the backend server determines that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, the method 200 further includes: when other vehicle components do not malfunction, the backend server determines that the abnormal cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component and is unrelated to the other vehicle components, and the second warning information is further used to remind that the abnormal cause of the abnormal vehicle condition data is unrelated to the other vehicle components; when other vehicle components malfunction, the backend server determines that the abnormal cause of the abnormal vehicle condition data includes both the malfunction of the target vehicle component and the malfunction of the other vehicle components; the backend server sends a third warning information to the target terminal, the third warning information being used to remind the target vehicle component and the other vehicle components to be repaired.
[0080] In the above technical solution, when a target vehicle component malfunctions, after determining that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, and when the status data indicates that other vehicle components are not malfunctioning, it is determined that the cause of the abnormality includes the malfunction of the target vehicle component and is unrelated to other vehicle components. The second warning information is also used to remind that the cause of the abnormality is unrelated to other vehicle components. In other words, the cause of the abnormal vehicle condition data only includes the malfunction of the target vehicle component, which allows vehicle users to clearly understand the cause of the abnormality and address vehicle problems promptly. When the status data indicates that other vehicle components malfunction, it is determined that the cause of the abnormality includes both the malfunction of the target vehicle component and the malfunction of other vehicle components; a third warning information is sent to the target terminal, which reminds the user to repair both the target vehicle component and the other vehicle components. This allows vehicle users to repair both the target vehicle component and the other vehicle components simultaneously, improving the efficiency of handling vehicle problems.
[0081] In some embodiments, the target terminal may display the third warning information and / or broadcast the third warning information via voice.
[0082] In some embodiments, the backend server determines whether other vehicle components besides the target vehicle component have malfunctioned based on the status data, including: if the status data is within an abnormal value range, the backend server determines that the other vehicle component has malfunctioned; if the status data is within a normal value range, the backend server determines that the other vehicle component has not malfunctioned.
[0083] In the above technical solution, since the status data is used to indicate the operating status of at least one vehicle component at the first moment, if the status data is within the normal range, the operating status of other vehicle components is normal, and the other vehicle components have not malfunctioned. Conversely, if the status data is outside the normal range, the other vehicle components have malfunctioned.
[0084] Figure 3 This is a schematic diagram of the structure of a backend server provided in an embodiment of this application.
[0085] For example, such as Figure 3As shown, the backend server can be implemented by a Telematics Service Provider (TSP) platform. The TSP platform's operational interface (TSP operational interface) includes a vehicle condition problem tracing tool, as well as remote control debugging tools, vehicle condition analysis and debugging tools, single-vehicle visualization monitoring tools, and gateway configuration tools. Specifically, the remote control debugging tool is used for remote testing and control of the vehicle; the vehicle condition analysis and debugging tool is used for analyzing and controlling the status of vehicle components; the single-vehicle visualization monitoring tool is used for monitoring individual vehicles; and the gateway configuration tool is used for configuring secure communication links between the vehicle and external networks. Multiple vehicle services can be provided through these tools. Examples of services include: travel services, remote vehicle control, vehicle status analysis, V2X (Vehicle to Everything) services, adaptation of various application protocols within the vehicle, human-vehicle relationship, electronic fences (vehicle anti-theft alarm systems), vehicle sharing, high-speed autonomous driving assistance (Navigation On HIPilot, NOH), automatic cruise control, service packages (providing a range of related services to meet various user needs), Bluetooth keys, energy management, Automated Valet Parking (AVP) systems, remote diagnostics, subscription centers (providing regularly updated e-newspapers), security alarms, ECALL (emergency vehicle assistance call), data analysis and distribution, and FOTA (Firmware Over-The-Air) updates (updating vehicle software via network connection). These vehicle services obtain vehicle and device data, enabling data query / synchronization services for various third-party applications (location, navigation, and autonomous driving applications, etc.). The core business domains offered by this TSP platform include a message center (user messages and user SMS) and a user center (account registration, account binding, and security passwords). The corresponding business execution terminals provided by the TSP platform include TBOX, in-vehicle head-up displays, and various applications (APPs). Among these, the front-end customer service of the vehicle status display APP and the after-sales service (back-end server) of the TSP operation can utilize tools within the TSP platform to provide various vehicle services.
[0086] Figure 4 This is a schematic flowchart illustrating the acquisition of status data provided in an embodiment of this application.
[0087] For example, such as Figure 4As shown, the vehicle condition problem tracing tool acquires abnormal vehicle condition data collected at the first moment. The tool then acquires status data of at least one vehicle component reported by the TBOX and parsed according to the protocol, which is associated with this abnormal vehicle condition data. This status data indicates the operating status of the at least one vehicle component at that first moment. Furthermore, based on this status data and the abnormal vehicle condition data, the tool performs anomaly investigation on the abnormal vehicle condition data.
[0088] Figure 5 This is a flowchart of an anomaly investigation for abnormal vehicle condition data provided in an embodiment of this application.
[0089] For example, such as Figure 5 The diagram illustrates a multi-terminal interaction process. These multiple terminals include the user, the front-end of the vehicle display app, the back-end server, and the TBOX. Specifically, the front-end of the vehicle display app receives user feedback, specifically receiving abnormal vehicle condition data, the first moment the abnormal data was collected, and the geographical location. Based on the abnormal data, the first moment, and the geographical location, the front-end generates a vehicle condition data anomaly issue ticket. The front-end then conducts a team discussion based on this ticket to determine if the anomaly is due to a display problem within the vehicle display app. If the anomaly is determined to be a display problem, the vehicle display app processes the display issue and outputs the processing result. If the anomaly is determined not to be a display problem, the front-end sends the vehicle condition data anomaly issue ticket to the vehicle display app's back-end server, which receives the ticket. The back-end server then determines if the problem is with the TBOX. If the back-end server determines it is not with the TBOX, it processes the abnormal vehicle condition data, obtains the processing result, and sends the result back to the front-end. If the backend server determines the issue is with the TBOX, it sends a work order for the abnormal vehicle data to the TBOX. The TBOX receives the work order, analyzes the problem, obtains a resolution, and sends the resolution to the frontend. The vehicle status display app then outputs the resolution to allow the user to respond.
[0090] Figure 6 This is a schematic diagram of a vehicle condition problem tracing tool provided in an embodiment of this application.
[0091] For example, after the vehicle condition tracking tool obtains the abnormal vehicle condition data collected at the first moment, it displays as follows: Figure 6The first interface shown in (a) displays the vehicle's VIN code (LUAU2AUB3GE383467), the current time (2023 / 10 / 1 12:15), and a table containing abnormal vehicle condition data (1.5 bar), the physical meaning of the abnormal data (tire pressure), and the first time (2023 / 10 / 1 12:10). In response to a click on this abnormal vehicle condition data, the vehicle condition problem tracing tool displays the following... Figure 6 The second interface shown in (b) displays, in addition to the first interface, a vehicle condition anomaly handling strategy and status data of at least one vehicle component (the vehicle battery is at 50% charge and ON). The vehicle condition anomaly handling strategy is used to instruct the acquisition of status data of at least one vehicle component associated with the vehicle condition anomaly data (specifically, the target vehicle component is the tire pressure sensor, and other vehicle components include the vehicle battery).
[0092] Figure 7 This is a schematic diagram of the structure of an anomaly detection device provided in an embodiment of this application.
[0093] For example, such as Figure 7 As shown, the device 700 includes:
[0094] The receiving module 701 is used to acquire abnormal vehicle condition data collected in the first moment.
[0095] The acquisition module 702 is used to acquire status data of at least one vehicle component associated with the abnormal vehicle condition data, the status data being used to indicate the working status of the at least one vehicle component at the first moment.
[0096] The investigation module 703 is used to investigate the abnormal vehicle condition data based on the status data and the abnormal vehicle condition data.
[0097] Optionally, the device 700 further includes: a determining module, configured to: determine whether a target vehicle component among the at least one vehicle component has malfunctioned, the target vehicle component being used to collect the abnormal vehicle condition data; if the target vehicle component has not malfunctioned, determine, based on the status data, whether other vehicle components among the at least one vehicle component besides the target vehicle component have malfunctioned; if other vehicle components have not malfunctioned, determine that the abnormal cause of the abnormal vehicle condition data includes external environmental factors; the device 700 further includes: a sending module, configured to send a first reminder message to a target terminal, the first reminder message being used to remind the user to ignore the abnormal vehicle condition data, the target terminal being a terminal that provides feedback on the abnormal vehicle condition data; the determining module is further configured to, if other vehicle components have malfunctioned, determine that the abnormal cause of the abnormal vehicle condition data includes malfunctions of other vehicle components and is unrelated to the target vehicle component; the sending module is further configured to send a first warning message to the target terminal, the first warning message being used to remind the user to repair the other vehicle components.
[0098] Optionally, after determining whether the target vehicle component in the at least one vehicle component has malfunctioned, the determining module is further configured to determine, in the case of the target vehicle component malfunctioning, that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component; the sending module is further configured to send a second warning message to the target terminal, the second warning message being used to remind the target vehicle component to be repaired.
[0099] Optionally, in the event of a malfunction in the target vehicle component, after determining that the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component, the determining module is further configured to: determine that, in the case where no other vehicle component has malfunctioned, the cause of the abnormal vehicle condition data includes the malfunction of the target vehicle component and is unrelated to the other vehicle components, and the second warning information is further configured to remind that the cause of the abnormal vehicle condition data is unrelated to the other vehicle components; in the case where other vehicle components have malfunctioned, determine that the cause of the abnormal vehicle condition data includes both the malfunction of the target vehicle component and the malfunction of the other vehicle components; the sending module is further configured to send a third warning information to the target terminal, the third warning information being used to remind the target vehicle component and the other vehicle components to be repaired.
[0100] Optionally, the determining module is specifically used to: determine that the other vehicle component has malfunctioned when the status data is within an abnormal value range; and determine that the other vehicle component has not malfunctioned when the status data is within a normal value range.
[0101] Optionally, the acquisition module 702 is further configured to acquire the original vehicle condition data collected by the target vehicle component at a second time point, corresponding to the abnormal vehicle condition data, the second time point being after the first time point; the determination module is further configured to: determine that the target vehicle component has malfunctioned when the original vehicle condition data is abnormal; and determine that the target vehicle component has not malfunctioned when the original vehicle condition data is normal.
[0102] Optionally, after acquiring the vehicle condition abnormality data collected at the first moment, the device 700 further includes: a display module for displaying the vehicle condition abnormality data; the investigation module 703 is also used to perform the step of acquiring the status data of at least one vehicle component associated with the vehicle condition abnormality data in response to the triggering operation of the vehicle condition abnormality data.
[0103] Figure 8 This is a schematic diagram of the structure of a server provided in an embodiment of this application.
[0104] For example, such as Figure 8 As shown, the server 800 includes: a memory 801, a processor 802, and a computer program 803 stored in the memory 801 and running on the processor 802, wherein when the processor 802 executes the computer program 803, the server can perform any of the aforementioned anomaly troubleshooting methods.
[0105] In some embodiments, the server is the backend server of the vehicle status display APP.
[0106] This embodiment can divide the server into functional modules according to the above method example. For example, each module can correspond to a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.
[0107] When each functional module is divided according to its corresponding function, the server may include: an acquisition module, a screening module, a detection module, a sending module, a determination module, and a display module. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.
[0108] The server provided in this embodiment is used to execute the above-described method for troubleshooting anomalies, and thus can achieve the same effect as the above-described implementation method.
[0109] When using integrated units, a server can include a processing module and a storage module. The processing module is used to control and manage the server's operations. The storage module is used for the server to execute program code and store data.
[0110] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as disclosed in this application. The processor may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory.
[0111] This embodiment provides a computer-readable storage medium storing instructions that, when executed on a computer or processor, cause the computer or processor to perform any of the aforementioned anomaly troubleshooting methods.
[0112] This embodiment also provides a computer program product containing instructions. When the computer program product is run on a computer or processor, it causes the computer or processor to perform the aforementioned related steps to implement any of the anomaly troubleshooting methods described above.
[0113] In this embodiment, the server, computer-readable storage medium, computer program product containing instructions, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.
[0114] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0115] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0116] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for anomaly detection, characterized in that, The method includes: Acquire vehicle condition anomaly data collected in the first moment; Acquire status data of at least one vehicle component associated with the vehicle condition anomaly data, the status data being used to indicate the operating status of the at least one vehicle component at the first moment; Determine whether a target vehicle component among the at least one vehicle component has malfunctioned, wherein the target vehicle component is used to collect the abnormal vehicle condition data; If the target vehicle component does not malfunction, the status data is used to determine whether other vehicle components besides the target vehicle component have malfunctioned. If no other vehicle components malfunction, the cause of the abnormal vehicle condition data is determined to include external environmental factors; a first reminder message is sent to the target terminal, which is the terminal that provides feedback on the abnormal vehicle condition data, to remind users to ignore the abnormal vehicle condition data.
2. The method according to claim 1, characterized in that, The method further includes: In the event of a malfunction in other vehicle components, the cause of the abnormal vehicle condition data is determined to include malfunctions in other vehicle components that are unrelated to the target vehicle component; a first warning message is sent to the target terminal, the first warning message being used to remind the other vehicle components to be repaired.
3. The method according to claim 2, characterized in that, After determining whether the target vehicle component in the at least one vehicle component has malfunctioned, the method further includes: In the event of a malfunction in the target vehicle component, the cause of the abnormal vehicle condition data is determined to include the malfunction in the target vehicle component. A second warning message is sent to the target terminal, the second warning message being used to remind the target vehicle components to be repaired.
4. The method according to claim 3, characterized in that, In the event of a malfunction in the target vehicle component, determining the cause of the abnormal vehicle condition data includes, after the target vehicle component malfunctions, the method further includes: If no other vehicle components have malfunctioned, the abnormal cause of the abnormal vehicle condition data is determined to include a malfunction of the target vehicle component that is unrelated to the other vehicle components. The second warning information is also used to remind that the abnormal cause of the abnormal vehicle condition data is unrelated to the other vehicle components. In the event of a malfunction in other vehicle components, the cause of the abnormal vehicle condition data is determined to include both a malfunction in the target vehicle component and a malfunction in the other vehicle components; a third warning message is sent to the target terminal, the third warning message being used to remind the target vehicle component and the other vehicle components to be repaired.
5. The method according to claim 2, characterized in that, Determining whether other vehicle components besides the target vehicle component have malfunctioned based on the status data includes: If the status data is within an abnormal range, it is determined that the other vehicle components have malfunctioned. If the status data is within the normal range, it is determined that the other vehicle components have not malfunctioned.
6. The method according to claim 2, characterized in that, Determining whether a target vehicle component in the at least one vehicle component has malfunctioned includes: Obtain the raw vehicle condition data corresponding to the abnormal vehicle condition data collected by the target vehicle components at a second time point, where the second time point is after the first time point; If the original vehicle condition data is abnormal, it is determined that a component of the target vehicle has malfunctioned. If the original vehicle condition data is normal, it is determined that the target vehicle components are not faulty.
7. The method according to claim 1, characterized in that, After acquiring the vehicle condition anomaly data collected at the first moment, the method further includes: Display the abnormal vehicle condition data; In response to a triggering operation on the abnormal vehicle condition data, the step of acquiring status data of at least one vehicle component associated with the abnormal vehicle condition data is performed.
8. An anomaly detection device, characterized in that, The device includes: The determination module is used to acquire abnormal vehicle condition data collected in the first moment; The acquisition module is used to acquire status data of at least one vehicle component associated with the vehicle condition anomaly data, the status data being used to indicate the working status of the at least one vehicle component at the first moment. The troubleshooting module is used to determine whether a target vehicle component among the at least one vehicle component has malfunctioned, the target vehicle component being used to collect the abnormal vehicle condition data; if the target vehicle component has not malfunctioned, it determines, based on the status data, whether other vehicle components among the at least one vehicle component besides the target vehicle component have malfunctioned; if other vehicle components have not malfunctioned, it determines that the abnormal cause of the abnormal vehicle condition data includes external environmental factors; and sends a first reminder message to a target terminal, the first reminder message being used to remind users to ignore the abnormal vehicle condition data, the target terminal being the terminal that provides feedback on the abnormal vehicle condition data.
9. A server, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it causes the server to perform the anomaly detection method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer or processor, cause the computer or processor to perform the anomaly detection method as described in any one of claims 1 to 7.