Vehicle fault processing method and device, electronic equipment and storage medium
By obtaining driving data in vehicle fault processing to judge faults and establishing a time window to accumulate the number of faults, the problem of message backlog and repeated judgment is solved, the accuracy and timeliness of fault processing are improved, and the user satisfaction is improved.
Patent Information
- Application Number
- CN202411568981.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-05
- Publication Date
- 2025-02-25
AI Technical Summary
The prior art can easily lead to message backlog and repeated judgment of fault results in vehicle fault processing, resulting in low accuracy and poor timeliness.
By obtaining the driving data of the vehicle, we judge whether the vehicle triggers a fault and whether the fault is the first reported on the same day. If it is the first time reporting, the cumulative number of fault reporting times in the establishment time window will be determined as a pending fault when the preset target is reached. Save fault information, query vehicle information and location, determine the nearest service station information, splice it into a fault work order and push it to the terminal.
Effectively eliminate repeated reporting and false alarm data, avoid message backlog, improve the accuracy and timeliness of faulty work orders, significantly improve work order conversion rate, and improve user satisfaction.
Smart Images
Figure CN119512032A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle technology, and in particular to a method, device, electronic device and storage medium for handling vehicle failures. Background Art
[0002] TBOX (Telematics Box) establishes communication with the vehicle through CAN bus technology, collects CAN messages from the vehicle controller, parses and packages these messages, and sends them to the TSP (Telematics Service Provider) platform through wireless communication. The TSP platform further decrypts and parses these data for analysis and processing.
[0003] However, the relevant technology mainly analyzes the real-time data reported by the car's Tbox, which can easily lead to message backlogs and repeated fault judgments, resulting in low accuracy and poor timeliness in vehicle fault handling. Summary of the invention
[0004] The present application provides a vehicle fault processing method, device, electronic device and storage medium to solve the problem that related technologies easily lead to message backlogs and repeated fault judgments, thereby resulting in low accuracy and poor timeliness in vehicle fault processing. It can effectively eliminate repeatedly reported fault data and false alarm fault data, avoid message backlogs, improve the accuracy of vehicle fault work orders, and combine with the timeliness of real-time work orders to significantly improve the work order conversion rate and improve user satisfaction.
[0005] The first embodiment of the present application provides a method for handling a vehicle failure, comprising the following steps:
[0006] Obtaining driving data of the vehicle;
[0007] Determining whether the vehicle triggers a fault based on the driving data, and if the vehicle triggers a fault, determining whether the fault is reported for the first time on that day;
[0008] If the fault is reported for the first time on the day, a time window is established to accumulate the number of reports of the same type of fault reported by the vehicle within the time window. When the number of reports reaches a preset target, it is determined that the vehicle has a pending fault.
[0009] Save the fault information of the pending fault and obtain the vehicle identification code of the vehicle, query the vehicle information, owner information and vehicle location information of the vehicle based on the vehicle identification code, determine the service station information closest to the vehicle according to the vehicle location information, splice the fault information, vehicle information, owner information and service station information to obtain a fault work order, and push the fault work order to a preset terminal.
[0010] Optionally, in some embodiments, determining whether the vehicle triggers a fault according to the driving data includes:
[0011] Parsing the driving data to obtain a parsed message;
[0012] When a controller fault name and a controller fault code exist in the parsed message, determining that the vehicle triggers a controller fault;
[0013] When the battery fault name and the battery fault code exist in the parsed message, it is determined that the vehicle triggers a battery fault;
[0014] When the power battery fault name and the power battery fault code exist in the parsed message, it is determined that the vehicle triggers a power battery fault;
[0015] When the instrument light fault name and the instrument light fault code are present in the parsed message, it is determined that the vehicle triggers an instrument light fault;
[0016] When the engine fault name and the engine fault code exist in the parsed message, it is determined that the vehicle triggers an engine fault;
[0017] According to the parsed message, when the state of the safety airbag is a pop-up state, determining that the vehicle has a safety airbag triggering failure;
[0018] According to the parsed message, when any tire pressure value of the vehicle is lower than a tire pressure threshold, it is determined that the vehicle triggers a tire pressure fault.
[0019] Optionally, in some embodiments, determining whether the fault is reported for the first time on the day includes:
[0020] Determine whether there is fault information corresponding to the fault in the local database;
[0021] If the local database does not contain the same type of fault information corresponding to the fault, it is determined that the fault is reported for the first time on that day.
[0022] Optionally, in some embodiments, the fault information includes: at least one of a fault type, a fault module, a fault code, a fault description, and a reporting time;
[0023] The vehicle information includes: at least one of: VIN code, license plate number, vehicle model, vehicle series, purchase date, and current mileage;
[0024] The vehicle owner information includes: at least one of name and contact information;
[0025] The service station information includes at least one of a service station number, a service station location, and a service station contact method.
[0026] A second aspect of the present application provides a vehicle fault processing device, including:
[0027] An acquisition module, used for acquiring driving data of a vehicle;
[0028] A judgment module, used to judge whether the vehicle triggers a fault according to the driving data, and if the vehicle triggers a fault, judge whether the fault is reported for the first time on that day;
[0029] A determination module, configured to establish a time window if the fault is reported for the first time on the day, accumulate the number of reports of the same type of fault reported by the vehicle within the time window, and determine that the vehicle has a pending fault when the number of reports reaches a preset target;
[0030] A processing module is used to save the fault information of the fault to be processed, and obtain the vehicle identification code of the vehicle, query the vehicle information, owner information and vehicle location information of the vehicle based on the vehicle identification code, determine the service station information closest to the vehicle according to the vehicle location information, splice the fault information, vehicle information, owner information and service station information to obtain a fault work order, and push the fault work order to a preset terminal.
[0031] Optionally, in some embodiments, the judgment module is specifically used to:
[0032] Parsing the driving data to obtain a parsed message;
[0033] When a controller fault name and a controller fault code exist in the parsed message, determining that the vehicle triggers a controller fault;
[0034] When the battery fault name and the battery fault code exist in the parsed message, it is determined that the vehicle triggers a battery fault;
[0035] When the power battery fault name and the power battery fault code exist in the parsed message, it is determined that the vehicle triggers a power battery fault;
[0036] When the instrument light fault name and the instrument light fault code are present in the parsed message, it is determined that the vehicle triggers an instrument light fault;
[0037] When the engine fault name and the engine fault code exist in the parsed message, it is determined that the vehicle triggers an engine fault;
[0038] According to the parsed message, when the state of the safety airbag is a pop-up state, determining that the vehicle has a safety airbag triggering failure;
[0039] According to the parsed message, when any tire pressure value of the vehicle is lower than a tire pressure threshold, it is determined that the vehicle triggers a tire pressure fault.
[0040] Optionally, in some embodiments, the judgment module is further used to:
[0041] Determine whether there is fault information corresponding to the fault in the local database;
[0042] If the local database does not contain the same type of fault information corresponding to the fault, it is determined that the fault is reported for the first time on that day.
[0043] Optionally, in some embodiments, the fault information includes: at least one of a fault type, a fault module, a fault code, a fault description, and a reporting time;
[0044] The vehicle information includes: at least one of: VIN code, license plate number, vehicle model, vehicle series, purchase date, and current mileage;
[0045] The vehicle owner information includes: at least one of name and contact information;
[0046] The service station information includes at least one of a service station number, a service station location, and a service station contact method.
[0047] A third aspect of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle fault processing method as described in the above embodiment.
[0048] The fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the vehicle fault processing method as described in the above embodiment.
[0049] Thus, by obtaining the driving data of the vehicle and judging whether the vehicle triggers a fault according to the driving data, if the vehicle triggers a fault, it is judged whether the fault is reported for the first time on the day; if the fault is reported for the first time on the day, a time window is established, and the number of reports of the same type of fault reported by the vehicle within the time window is accumulated. When the number of reports reaches the preset target, it is judged that the vehicle has a pending fault; the fault information of the pending fault is saved, and the vehicle identification code of the vehicle is obtained, and the vehicle information, owner information and vehicle location information of the vehicle are queried based on the vehicle identification code. According to the vehicle location information, the information of the service station closest to the vehicle is determined, and the fault information, vehicle information, owner information and service station information are spliced to obtain the fault work order, and the fault work order is pushed to the preset terminal. Thus, the problem that the related technology is prone to message backlog and repeated judgment of fault results, thereby resulting in low accuracy and poor timeliness of vehicle fault processing, can be solved, and the repeatedly reported fault data and falsely reported fault data can be effectively eliminated, message backlog can be avoided, and the accuracy of vehicle fault work orders can be improved. Combined with the timeliness of real-time work orders, the work order conversion rate is significantly improved, and user satisfaction is improved.
[0050] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0051] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:
[0052] Figure 1 A flowchart of a method for handling a vehicle failure provided according to an embodiment of the present application;
[0053] Figure 2 A block diagram of a vehicle fault processing device provided according to an embodiment of the present application;
[0054] Figure 3 This is an example diagram of a vehicle fault processing device provided according to an embodiment of the present application;
[0055] Figure 4 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION
[0056] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.
[0057] The following describes the vehicle fault processing method, device, electronic device and storage medium of the embodiment of the present application with reference to the accompanying drawings. In view of the problem that the related technologies mentioned in the above background technology are prone to message backlog and repeated judgment of fault results, thereby resulting in low accuracy and poor timeliness in vehicle fault processing, the present application provides a vehicle fault processing method, in which the driving data of the vehicle is obtained, and whether the vehicle triggers a fault is determined according to the driving data. If the vehicle triggers a fault, it is determined whether the fault is reported for the first time on the day; if the fault is reported for the first time on the day, a time window is established, and the number of reports of the same type of fault reported by the vehicle within the time window is accumulated. When the number of reports reaches a preset target, it is determined that the vehicle has a pending fault; the fault information of the pending fault is saved, and the vehicle identification code of the vehicle is obtained, and the vehicle information, owner information and vehicle location information of the vehicle are queried based on the vehicle identification code. According to the vehicle location information, the service station information closest to the vehicle is determined, and the fault information, vehicle information, owner information and service station information are spliced to obtain a fault work order, and the fault work order is pushed to the preset terminal. As a result, the problem that related technologies easily lead to message backlogs and repeated fault judgments, resulting in low accuracy and poor timeliness in vehicle fault handling, is solved. It can effectively eliminate repeatedly reported fault data and false alarm fault data, avoid message backlogs, and improve the accuracy of vehicle fault work orders. Combined with the timeliness of real-time work orders, the work order conversion rate is significantly improved, thereby improving user satisfaction.
[0058] Specifically, Figure 1 A flowchart of a method for handling vehicle failure provided in an embodiment of the present application.
[0059] like Figure 1 As shown, the method for handling the vehicle failure includes the following steps:
[0060] In step S101 , driving data of the vehicle is acquired.
[0061] Specifically, the vehicle generates driving data during the driving process. The embodiment of the present application can receive the driving data reported by Tbox through the background, so as to determine whether the vehicle has a fault by analyzing the driving data.
[0062] In step S102, it is determined whether the vehicle has triggered a fault based on the driving data. If the vehicle has triggered a fault, it is determined whether the fault is reported for the first time that day.
[0063] Further, in some embodiments, determining whether a vehicle triggers a fault is based on driving data, including: parsing the driving data to obtain a parsed message; when a controller fault name and a controller fault code exist in the parsed message, determining that the vehicle triggers a controller fault; when a battery fault name and a battery fault code exist in the parsed message, determining that the vehicle triggers a battery fault; when a power battery fault name and a power battery fault code exist in the parsed message, determining that the vehicle triggers a power battery fault; when an instrument light fault name and an instrument light fault code exist in the parsed message, determining that the vehicle triggers an instrument light fault; when an engine fault name and an engine fault code exist in the parsed message, determining that the vehicle triggers an engine fault; according to the parsed message, when the state of the airbag is a pop-up state, determining that the vehicle triggers an airbag fault; according to the parsed message, when any tire pressure value of the vehicle is lower than the tire pressure threshold, determining that the vehicle triggers a tire pressure fault.
[0064] Specifically, after acquiring the driving data, the embodiment of the present application can parse the driving data frame by frame to obtain parsed messages, and determine whether the vehicle has a fault and the type of vehicle fault by parsing the messages, where vehicle faults include: controller failure, battery failure, power battery failure, instrument light failure, tire pressure failure, airbag failure, engine failure, etc.
[0065] The judgment of vehicle failure can be based on the thresholds of various types of faults pre-set in the program to determine whether this frame message triggers a fault. When the vehicle has a controller failure, battery failure, power battery failure, instrument light failure or engine failure, the parsed message should include the specific fault module name and the corresponding fault code; airbag failure includes the non-pop-up state and the pop-up state; tire pressure failure includes the tire number and the specific tire pressure value.
[0066] For controller failure, battery failure, power battery failure, instrument light failure, and engine failure: if the parsing result message contains the fault module name and fault code, it is determined that a fault has occurred; if the fault module name and fault code in the parsing message are empty, it is determined that no fault has occurred.
[0067] For airbag failure, if the result of parsing the message is a pop-up state, it is determined that a failure has occurred; if the result of parsing the message is "not popped out", it is determined that no failure has occurred.
[0068] For tire pressure failure, if the analysis result of the message is that the tire pressure value of a certain tire is 0, it is determined that a failure has occurred. If the analysis result of the message is that the tire pressure values of all four tires are not 0, it is determined that no failure has occurred.
[0069] Optionally, in some embodiments, determining whether the fault is reported for the first time on the day includes: determining whether there is fault information corresponding to the fault in the local database; if there is no fault information of the same type corresponding to the fault in the local database, determining that the fault is reported for the first time on the day.
[0070] Specifically, the embodiment of the present application queries the local database for a table of vehicle information on faulty vehicles based on the vehicle VIN code, fault module name, fault code, and message time in the message, and determines whether the frame message is the first time the vehicle has reported the fault that day. If it is the first report, the fault information is loaded into the local cache; if it is not the first report, the frame data is discarded.
[0071] In step S103, if the fault is reported for the first time on the day, a time window is established to accumulate the number of reports of the same type of fault reported by the vehicle within the time window. When the number of reports reaches a preset target, it is determined that the vehicle has a pending fault.
[0072] It can be understood that the embodiments of the present application can reduce false alarms caused by occasional or transient faults by setting a time window and a reporting threshold (such as 3 times). If a fault is reported multiple times in a short period of time, then it is more likely to be a real and persistent problem. By counting the number of reports of the same type of faults within a specific time period, it can be more accurately determined whether the fault has actually occurred, thereby improving the accuracy of fault detection.
[0073] Specifically, the embodiment of the present application establishes a time window of 60 seconds for each frame of fault data in the cache, and calculates the number of times the same type of fault data of the same vehicle is reported within a time window. If the number of reports is less than 3 times, it is determined that the vehicle has not failed, and all data in the window are discarded. If the number of reports reaches 3 times, it is determined that the vehicle has failed, and the data of the third fault report within the time window is saved in the cache, and the remaining data is discarded.
[0074] In step S104, the fault information of the fault to be processed is saved, and the vehicle identification code of the vehicle is obtained. The vehicle information, owner information and vehicle location information of the vehicle are queried based on the vehicle identification code. According to the vehicle location information, the service station information closest to the vehicle is determined, and the fault information, vehicle information, owner information and service station information are spliced together to obtain a fault work order, and the fault work order is pushed to the preset terminal.
[0075] Among them, the fault information includes: at least one of the fault type, fault module, fault code, fault description, and reporting time; the vehicle information includes: at least one of the VIN code, license plate number, vehicle model, vehicle series, purchase date, and current mileage; the owner information includes: at least one of the name and contact information; the service station information includes: at least one of the service station number, service station location, and service station contact information.
[0076] Specifically, when a vehicle has an unprocessed fault, the fault information corresponding to the unprocessed fault can be parsed, and the database can be queried based on the VIN code to query the vehicle information and owner information, and the actual location of the vehicle can be mapped based on the vehicle's longitude and latitude in the message, and the information of the cooperative repair service station closest to the vehicle's current location can be calculated. Finally, the fault information, vehicle information, owner information, and service station information are spliced into a complete fault work order. The embodiment of the present application can push the complete fault work order information to the downstream work order system through relevant applications, and generate an electronic fault work order that can be recognizable by operators. The fault work order has high accuracy and timeliness, and can better guide operators to refine operations.
[0077] The application stores the pushed fault data in the local database as a basis for determining in step S102 whether the vehicle fault occurs for the first time on that day, thereby achieving a closed data loop and avoiding a backlog of fault data.
[0078] During the actual execution process, the embodiments of the present application can use fastjson and the like as parsing tools, use mysql, redis and the like as database tools; use JDBC and the like as database connection tools, and use kafka, hdfs and the like as message middleware.
[0079] In order to enable relevant technical personnel in the field to further understand the vehicle failure handling method of the embodiment of the present application, it is elaborated in detail below in conjunction with specific embodiments.
[0080] like Figure 2 As shown, Figure 2 A flowchart of a method for handling vehicle failure is provided according to an embodiment of the present application.
[0081] Step 1: When the application parses the Tbox real-time data, it first determines whether it is vehicle fault data. If it is not fault data, the frame data is discarded. If it is fault data, it proceeds to the next step to parse the specific fault module.
[0082] Step 2: When the application parses the data content of the specific fault module according to the fault data, it determines whether the set fault threshold is reached. If the threshold is not reached, the frame data is discarded. If the threshold is reached, it determines whether it is the first report of the day.
[0083] Step 3: Check the vehicle data of the fault reported on the day in the database to determine whether the fault data in step 2 is the first report on the day. If it is not the first report on the day, discard the frame data. If it is the first report on the day, enter the time window judgment mechanism.
[0084] Step 4: Data that is determined not to have a fault through the time window judgment mechanism is discarded, and key data in the message for data that is determined to have a fault is extracted for further correlation query.
[0085] Step 5: According to the VIN code and longitude and latitude in the fault data in step 4, the database is queried to obtain the vehicle information, owner information, and service station information, and then combined with the fault information to form complete fault work order information.
[0086] Step 6: Push the complete fault ticket information generated in step 5 to the downstream electronic fault ticket generation system.
[0087] Step 7: Store the pushed electronic fault work order information into the local database as a basis for determining whether the fault occurs for the first time in step 3.
[0088] The embodiment of the present application completes the data closed loop through the processing of step 1 to step 7. The operator actively visits the customer based on the electronic fault work order and records the visit results in order to calculate the conversion rate. Thus, the entire link from fault data collection, to calculation of fault results, to generation of complete fault work orders, to real-time processing of work orders is completed.
[0089] According to the vehicle fault processing method proposed in the embodiment of the present application, the driving data of the vehicle is obtained, and it is determined whether the vehicle has triggered a fault based on the driving data. If the vehicle has triggered a fault, it is determined whether the fault is reported for the first time on that day. If the fault is reported for the first time on that day, a time window is established, and the number of reports of the same type of fault reported by the vehicle within the time window is accumulated. When the number of reports reaches a preset target, it is determined that the vehicle has a pending fault; the fault information of the pending fault is saved, and the vehicle identification code of the vehicle is obtained, and the vehicle information, owner information and vehicle location information of the vehicle are queried based on the vehicle identification code. According to the vehicle location information, the service station information closest to the vehicle is determined, and the fault information, vehicle information, owner information and service station information are spliced to obtain a fault work order, and the fault work order is pushed to a preset terminal. As a result, the problem that related technologies easily lead to message backlogs and repeated fault judgments, resulting in low accuracy and poor timeliness in vehicle fault handling, is solved. It can effectively eliminate repeatedly reported fault data and false alarm fault data, avoid message backlogs, and improve the accuracy of vehicle fault work orders. Combined with the timeliness of real-time work orders, the work order conversion rate is significantly improved, thereby improving user satisfaction.
[0090] Next, a vehicle fault processing device proposed in an embodiment of the present application will be described with reference to the accompanying drawings.
[0091] Figure 3 It is a block diagram of a vehicle fault processing device according to an embodiment of the present application.
[0092] like Figure 3 As shown, the vehicle fault processing device 10 includes: an acquisition module 100, a judgment module 200, a determination module 300 and a processing module 400.
[0093] The acquisition module 100 is used to acquire driving data of the vehicle.
[0094] The judgment module 200 is used to judge whether the vehicle triggers a fault according to the driving data, and if the vehicle triggers a fault, judge whether the fault is reported for the first time on that day.
[0095] The determination module 300 is used to establish a time window when the fault is reported for the first time on the day, accumulate the number of reports of the same type of fault reported by the vehicle within the time window, and determine that the vehicle has an unprocessed fault when the number of reports reaches a preset target.
[0096] The processing module 400 is used to save the fault information of the fault to be processed, and obtain the vehicle identification code of the vehicle, query the vehicle information, owner information and vehicle location information of the vehicle based on the vehicle identification code, determine the service station information closest to the vehicle according to the vehicle location information, splice the fault information, vehicle information, owner information and service station information to obtain a fault work order, and push the fault work order to a preset terminal.
[0097] Optionally, in some embodiments, the judgment module 200 is specifically used to: parse the driving data to obtain a parsed message; when a controller fault name and a controller fault code exist in the parsed message, determine that the vehicle has triggered a controller fault; when a battery fault name and a battery fault code exist in the parsed message, determine that the vehicle has triggered a battery fault; when a power battery fault name and a power battery fault code exist in the parsed message, determine that the vehicle has triggered a power battery fault; when an instrument light fault name and an instrument light fault code exist in the parsed message, determine that the vehicle has triggered an instrument light fault; when an engine fault name and an engine fault code exist in the parsed message, determine that the vehicle has triggered an engine fault; according to the parsed message, when the state of the airbag is a pop-up state, determine that the vehicle has triggered an airbag fault; according to the parsed message, when any tire pressure value of the vehicle is lower than the tire pressure threshold, determine that the vehicle has triggered a tire pressure fault.
[0098] Optionally, in some embodiments, the judgment module 200 is further used to: judge whether there is fault information corresponding to the fault in the local database; if there is no fault information of the same type corresponding to the fault in the local database, determine that the fault is reported for the first time on that day.
[0099] Optionally, in some embodiments, the fault information includes: at least one of fault type, fault module, fault code, fault description, and reporting time; the vehicle information includes: at least one of VIN code, license plate number, vehicle model, vehicle series, purchase date, and current mileage; the owner information includes: at least one of name and contact information; the service station information includes: at least one of service station number, service station location, and service station contact information.
[0100] It should be noted that the above explanation of the embodiment of the method for handling vehicle faults is also applicable to the vehicle fault handling device of this embodiment, and will not be repeated here.
[0101] According to the vehicle fault processing device proposed in the embodiment of the present application, the driving data of the vehicle is obtained, and it is determined whether the vehicle has triggered a fault based on the driving data. If the vehicle has triggered a fault, it is determined whether the fault is reported for the first time on that day; if the fault is reported for the first time on that day, a time window is established, and the number of reports of the same type of fault reported by the vehicle within the time window is accumulated. When the number of reports reaches a preset target, it is determined that the vehicle has a pending fault; the fault information of the pending fault is saved, and the vehicle identification code of the vehicle is obtained, and the vehicle information, owner information and vehicle location information of the vehicle are queried based on the vehicle identification code. According to the vehicle location information, the service station information closest to the vehicle is determined, the fault information, vehicle information, owner information and service station information are spliced together to obtain a fault work order, and the fault work order is pushed to a preset terminal. As a result, the problem that related technologies easily lead to message backlogs and repeated fault judgments, resulting in low accuracy and poor timeliness in vehicle fault handling, is solved. It can effectively eliminate repeatedly reported fault data and false alarm fault data, avoid message backlogs, and improve the accuracy of vehicle fault work orders. Combined with the timeliness of real-time work orders, the work order conversion rate is significantly improved, thereby improving user satisfaction.
[0102] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:
[0103] Memory 401 , processor 402 , and a computer program stored in the memory 401 and executable on the processor 402 .
[0104] When the processor 402 executes the program, the vehicle fault processing method provided in the above embodiment is implemented.
[0105] Furthermore, the electronic device further comprises:
[0106] The communication interface 403 is used for communication between the memory 401 and the processor 402 .
[0107] The memory 401 is used to store computer programs that can be executed on the processor 402 .
[0108] The memory 401 may include a high-speed RAM (Random Access Memory) memory, and may also include a non-volatile memory, such as at least one disk memory.
[0109] If the memory 401, the processor 402 and the communication interface 403 are implemented independently, the communication interface 403, the memory 401 and the processor 402 can be connected to each other through a bus and communicate with each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.
[0110] Optionally, in a specific implementation, if the memory 401, the processor 402 and the communication interface 403 are integrated on a chip, the memory 401, the processor 402 and the communication interface 403 can communicate with each other through an internal interface.
[0111] The processor 402 may be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application.
[0112] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned method for handling vehicle failures.
[0113] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.
[0114] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.
[0115] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.
[0116] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.
[0117] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.
[0118] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in the field can change, modify, replace and modify the above embodiments within the scope of the present application.
Claims
1. A method for handling vehicle failure, characterized in that: The following steps are involved: Obtaining driving data of the vehicle; Determining whether the vehicle triggers a fault based on the driving data, and if the vehicle triggers a fault, determining whether the fault is reported for the first time on that day; If the fault is reported for the first time on the day, a time window is established to accumulate the number of reports of the same type of fault reported by the vehicle within the time window. When the number of reports reaches a preset target, it is determined that the vehicle has a pending fault. Save the fault information of the pending fault and obtain the vehicle identification code of the vehicle, query the vehicle information, owner information and vehicle location information of the vehicle based on the vehicle identification code, determine the service station information closest to the vehicle according to the vehicle location information, splice the fault information, vehicle information, owner information and service station information to obtain a fault work order, and push the fault work order to a preset terminal.
2. The method according to claim 1, characterized in that The determining, according to the driving data, whether the vehicle triggers a fault includes: Parsing the driving data to obtain a parsed message; When a controller fault name and a controller fault code exist in the parsed message, determining that the vehicle triggers a controller fault; When the battery fault name and the battery fault code exist in the parsed message, it is determined that the vehicle triggers a battery fault; When the power battery fault name and the power battery fault code exist in the parsed message, it is determined that the vehicle triggers a power battery fault; When the instrument light fault name and the instrument light fault code are present in the parsed message, it is determined that the vehicle triggers an instrument light fault; When the engine fault name and the engine fault code exist in the parsed message, it is determined that the vehicle triggers an engine fault; According to the parsed message, when the state of the safety airbag is a pop-up state, determining that the vehicle has an airbag triggering failure; According to the parsed message, when any tire pressure value of the vehicle is lower than a tire pressure threshold, it is determined that the vehicle triggers a tire pressure fault.
3. The method according to claim 1, characterized in that The determining whether the fault is reported for the first time on the day includes: Determine whether there is fault information corresponding to the fault in the local database; If the local database does not contain the same type of fault information corresponding to the fault, it is determined that the fault is reported for the first time on that day.
4. The method according to claim 1, characterized in that The fault information includes: at least one of a fault type, a fault module, a fault code, a fault description, and a reporting time; The vehicle information includes: at least one of: VIN code, license plate number, vehicle model, vehicle series, purchase date, and current mileage; The vehicle owner information includes: at least one of name and contact information; The service station information includes at least one of a service station number, a service station location, and a service station contact method.
5. A vehicle fault processing device, characterized in that: include: An acquisition module, used for acquiring driving data of a vehicle; A judgment module, used to judge whether the vehicle triggers a fault according to the driving data, and if the vehicle triggers a fault, judge whether the fault is reported for the first time on that day; A determination module, configured to establish a time window if the fault is reported for the first time on the day, accumulate the number of reports of the same type of fault reported by the vehicle within the time window, and determine that the vehicle has a pending fault when the number of reports reaches a preset target; A processing module is used to save the fault information of the fault to be processed, and obtain the vehicle identification code of the vehicle, query the vehicle information, owner information and vehicle location information of the vehicle based on the vehicle identification code, determine the service station information closest to the vehicle according to the vehicle location information, splice the fault information, vehicle information, owner information and service station information to obtain a fault work order, and push the fault work order to a preset terminal.
6. The device according to claim 5, characterized in that The judgment module is specifically used for: Parsing the driving data to obtain a parsed message; When a controller fault name and a controller fault code exist in the parsed message, determining that the vehicle triggers a controller fault; When the battery fault name and the battery fault code exist in the parsed message, it is determined that the vehicle triggers a battery fault; When the power battery fault name and the power battery fault code exist in the parsed message, it is determined that the vehicle triggers a power battery fault; When the instrument light fault name and the instrument light fault code are present in the parsed message, it is determined that the vehicle triggers an instrument light fault; When the engine fault name and the engine fault code exist in the parsed message, it is determined that the vehicle triggers an engine fault; According to the parsed message, when the state of the safety airbag is a pop-up state, determining that the vehicle has an airbag triggering failure; According to the parsed message, when any tire pressure value of the vehicle is lower than a tire pressure threshold, it is determined that the vehicle triggers a tire pressure fault.
7. The device according to claim 5, characterized in that The judging module is further used for: Determine whether there is fault information corresponding to the fault in the local database; If the local database does not contain the same type of fault information corresponding to the fault, it is determined that the fault is reported for the first time on that day.
8. The device according to claim 5, characterized in that The fault information includes: at least one of a fault type, a fault module, a fault code, a fault description, and a reporting time; The vehicle information includes: at least one of: VIN code, license plate number, vehicle model, vehicle series, purchase date, and current mileage; The vehicle owner information includes: at least one of name and contact information; The service station information includes at least one of a service station number, a service station location, and a service station contact method.
9. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle fault processing method as described in any one of claims 1 to 4.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the vehicle fault processing method as described in any one of claims 1-4.