Vehicle fault processing method and device, equipment and storage medium
By analyzing vehicle fault tag data in the cloud, configuring safe execution conditions, and sending recovery commands, the problem of limited vehicle fault range is solved, enabling broader and more efficient fault recovery and improving the safety and efficiency of vehicle fault handling.
Patent Information
- Application Number
- CN202511580261.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-31
- Publication Date
- 2026-01-16
AI Technical Summary
In existing technologies, vehicle fault monitoring and recovery are mainly carried out at the vehicle end, which is limited in scope. In particular, it is difficult to effectively deal with occasional low-probability failures of in-vehicle software, resulting in a lot of time and effort being spent on reproduction and troubleshooting.
By leveraging the powerful data processing capabilities of the cloud, the cause and level of the fault can be determined by analyzing the tag data related to vehicle faults, configuring safe execution conditions, and sending fault recovery commands to the vehicle for execution, thereby expanding the scope and capability of fault handling.
By employing a collaborative solution that combines cloud-based decision-making with vehicle-side execution, the safety of vehicle malfunctions is ensured, the scope of malfunction recovery is expanded, the efficiency and success rate of malfunction handling are improved, and user waiting time is reduced.
Smart Images
Figure CN121349048A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of vehicle fault handling technology, and particularly relates to a method, apparatus, equipment and storage medium for handling vehicle faults. Background Technology
[0002] With the rapid development of "software-defined vehicle" technology and the evolution of electronic and electrical architectures from distributed to domain-controlled and centrally integrated architectures, in-vehicle software has become the core driving force for realizing vehicle functions and user experience. As the amount of code in in-vehicle software surges, its importance and complexity also increase accordingly. Although the software undergoes extensive testing and verification before release, low-probability, sporadic software failures still exist. Reproducing and troubleshooting such problems not only consumes a significant amount of time and effort but also causes considerable inconvenience for users.
[0003] In related technologies, fault monitoring and recovery are typically performed at the vehicle controller on the vehicle side, mainly for monitoring and recovering from faults in the three-electric systems of new energy vehicles. However, this solution has a limited scope for handling vehicle faults. Therefore, how to leverage the powerful data processing capabilities of the cloud to perform fault recovery on the vehicle side, thereby expanding the scope of vehicle fault handling, is an urgent problem to be solved. Summary of the Invention
[0004] The embodiments of this application provide a method, apparatus, device, and storage medium for handling vehicle faults, thereby enabling the use of the powerful data processing capabilities of the cloud to perform fault recovery on the vehicle side, thus expanding the scope of vehicle fault handling.
[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.
[0006] According to a first aspect of the embodiments of this application, a method for handling vehicle malfunctions is provided, applied to a cloud server. The method for handling vehicle malfunctions includes: Based on the first tag data related to vehicle malfunctions, determine the target malfunction cause and target malfunction level; Determine the target fault recovery instructions based on the cause of the target fault; Configure target safe execution conditions based on at least one of the target fault recovery command and the target fault level; The target fault recovery command and the target safety execution conditions are sent to the vehicle so that the vehicle executes the target fault recovery command if the target safety execution conditions are met.
[0007] In some embodiments, the security execution conditions include basic security execution conditions and / or multiple additional security execution conditions. Configuring the target security execution conditions based on at least one of a target fault recovery instruction and a target fault level includes: If the target fault recovery instruction is a diagnostic recovery instruction, then the basic safety execution conditions will be determined as the target safety execution conditions; If the target fault recovery command is a power failure recovery command, then configure the target safety execution conditions according to the target fault level.
[0008] In some embodiments, configuring target safe execution conditions according to the target fault level includes: If the target fault level represents a minor fault, then the basic safety execution conditions are determined as the target safety execution conditions. If the target fault level represents a moderate or severe fault, the target safety execution conditions are determined based on the basic safety execution conditions and multiple additional safety execution conditions.
[0009] In some embodiments, the target security execution condition is determined based on the basic security execution condition and multiple additional security execution conditions, including: Identify the recovery target indicated by the target fault recovery command; The target additional security condition is determined from multiple additional security execution conditions based on the recovery object; The basic security execution conditions and the target additional security conditions are defined as the target security execution conditions.
[0010] In some embodiments, the first tag data includes at least one of fault codes, communication data, and log data. Determining the target fault cause and target fault level based on the vehicle fault-related first tag data includes: Determine the target fault cause and target fault level based on at least one of the fault codes, communication data, and log data.
[0011] In some embodiments, determining the target fault cause and target fault level based on at least one of fault codes, communication data, and log data includes: Vehicle fault verification is performed based on fault codes, communication data, and log data to obtain the first verification result; If the first verification result indicates that the vehicle has a fault, the target fault cause and target fault level are determined based on the fault code, communication data and log data.
[0012] In some embodiments, determining the cause of a target fault based on fault codes, communication data, and log data includes: Determine the cause of the fault based on the fault code; If the cause of the fault cannot be determined based on the fault code, then the cause of the fault should be determined based on the communication data. If the cause of the fault cannot be determined based on the communication data, then the cause of the fault should be determined based on the log data. If the cause of the fault is determined based on the log data, then the determined cause of the fault will be taken as the target cause of the fault.
[0013] In some embodiments, determining a target fault recovery instruction based on the cause of the target fault includes: Search for the target fault cause in the preset fault database; the preset database includes multiple fault causes and corresponding diagnostic and recovery instructions for each fault cause. If the preset fault database contains the target fault cause, then the diagnostic recovery instruction corresponding to the target fault cause will be determined as the target fault recovery instruction.
[0014] In some embodiments, the method for handling vehicle malfunctions further includes: Obtain the second tag data returned by the vehicle based on the execution of the target fault recovery command; Vehicle fault verification is performed based on the second tag data to obtain the second verification result; If the second verification result indicates that the vehicle has a fault, a power-off recovery command will be sent to the vehicle.
[0015] In some embodiments, the method for handling vehicle malfunctions further includes: If the target fault cause is not included in the preset fault database, the power failure recovery command will be identified as the target fault recovery command.
[0016] In some embodiments, the method for handling vehicle malfunctions further includes: Obtain the third tag data returned by the vehicle based on the executed target fault recovery command; Perform vehicle fault verification on the third tag data to obtain the third verification result; If the third verification result indicates that the vehicle has a fault, then output a prompt message indicating that the vehicle fault recovery has failed.
[0017] According to a second aspect of the embodiments of this application, a vehicle fault handling apparatus is provided, applied to a cloud server, the apparatus comprising: The tag data analysis module is used to determine the target fault cause and target fault level based on the first tag data related to vehicle faults; The recovery instruction determination module is used to determine the target fault recovery instruction based on the cause of the target fault. The safety condition determination module is used to configure the target safety execution conditions based on at least one of the target fault recovery command and the target fault level; The fault recovery module is used to send the target fault recovery command and the target safety execution conditions to the vehicle, so that the vehicle can execute the target fault recovery command if the target safety execution conditions are met.
[0018] According to a third aspect of the embodiments of this application, a vehicle fault processing device is provided, including a processor and a memory, wherein the memory stores computer program instructions that can be executed by the processor, and when the processor executes the computer program instructions, it implements the steps of the method as described in any of the first aspects above.
[0019] According to a fourth aspect of the embodiments of this application, a vehicle fault handling system is provided, including a vehicle and a vehicle fault handling device as described in the third aspect above, wherein the vehicle and the vehicle fault handling device are communicatively connected, and the vehicle is used to receive a target fault recovery instruction and a target safety execution condition sent by the vehicle fault handling device, and execute the target fault recovery instruction when the target safety execution condition is met.
[0020] According to a fifth aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any of the first aspects above.
[0021] In this application, leveraging the powerful data processing capabilities of the cloud for fault analysis and decision-making can cover more fault scenarios that are difficult to identify when the vehicle autonomously recovers from faults. After the cloud receives the target safety execution conditions and the target fault recovery instructions, the vehicle executes the target fault recovery instructions provided that the target safety execution conditions are met. This vehicle-cloud collaborative solution, which involves "cloud decision-making - vehicle execution," not only ensures vehicle safety but also greatly expands the boundaries of the vehicle's fault recovery capabilities, increasing the scope of vehicle fault handling.
[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A schematic flowchart of a vehicle malfunction handling method according to some embodiments of this application is shown; Figure 2 It shows Figure 1 A diagram illustrating the flow of data in the middle; Figure 3 A flowchart illustrating a method for handling vehicle malfunctions according to other embodiments of this application is shown; Figure 4A block diagram of a vehicle malfunction handling apparatus according to some embodiments of this application is shown; Figure 5 A schematic diagram of a vehicle fault handling device according to some embodiments of this application is shown; Figure 6 A schematic diagram of the structure of a vehicle fault handling system according to some embodiments of this application is shown. Detailed Implementation
[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0025] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.
[0026] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.
[0027] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.
[0028] It should also be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such uses of these terms can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described.
[0029] To enable those skilled in the art to better understand this application, firstly, in conjunction with Figure 1 This application provides a brief description of the methods for handling vehicle malfunctions.
[0030] In related technologies, fault monitoring and recovery are typically performed at the vehicle controller on the vehicle side, mainly for monitoring and recovering faults in the three-electric system of new energy vehicles. However, this solution has a limited scope for handling vehicle faults. Alternatively, some technologies focus on fault monitoring and recovery through optimization of the processing logic of the fault handling software within the vehicle controller. This solution requires separate development of fault handling software for different vehicle controllers, resulting in a weakness in the applicability of the fault handling software.
[0031] The technical solution of this application includes: a cloud server determining the target fault cause and target fault level based on the first tag data related to the vehicle fault; determining the target fault recovery instruction based on the target fault cause; configuring target safety execution conditions based on at least one of the target fault recovery instruction and the target fault level; and sending the target fault recovery instruction and the target safety execution conditions to the vehicle so that the vehicle executes the target fault recovery instruction when the target safety execution conditions are met.
[0032] The above solution leverages the powerful data processing capabilities of the cloud for fault analysis and decision-making, covering more fault scenarios that are difficult to identify when the vehicle autonomously recovers from faults. After the cloud receives the target safety execution conditions and the target fault recovery instructions, the vehicle executes the target fault recovery instructions provided that the target safety execution conditions are met. This vehicle-cloud collaborative solution, which involves "cloud decision-making - vehicle execution," not only ensures vehicle safety but also significantly expands the boundaries of the vehicle's fault recovery capabilities, increasing the scope of vehicle fault handling.
[0033] Figure 1 A flowchart illustrating a method for handling vehicle malfunctions according to some embodiments of this application is shown. Figure 1 As shown, a method for handling vehicle malfunctions is provided, which may include the following steps: Step 101: Determine the target fault cause and target fault level based on the first tag data related to the vehicle fault; Step 102: Determine the target fault recovery instruction based on the cause of the target fault; Step 103: Configure target safe execution conditions according to at least one of the target fault recovery instruction and the target fault level; Step 104: Send the target fault recovery command and the target safety execution conditions to the vehicle so that the vehicle executes the target fault recovery command if the target safety execution conditions are met.
[0034] In step 101, the cloud server can determine the target fault cause and target fault level based on the first tag data related to the vehicle fault.
[0035] During the implementation process, after the cloud server is configured with the detection content and rules related to vehicle faults, it can send the detection content and rules to the vehicle. After each wake-up, the vehicle will perform a self-check based on the detection content and rules, and identify whether there is a fault in the vehicle by reading the vehicle fault code, vehicle communication data and other data. If a vehicle fault is identified, the data related to the vehicle fault is marked and uploaded to the cloud server as the first tag data.
[0036] The first tag data includes at least one of fault codes, communication data, and log data. After receiving at least one of the fault codes, communication data, and log data, the cloud server can determine the target fault cause and the target fault level based on at least one of the fault codes, communication data, and log data.
[0037] Specifically, if the cloud server only receives fault codes, it can determine the target fault cause and target fault level based on the fault codes; if it only receives communication data, it can determine the target fault cause and target fault level based on the communication data; if it only receives log data, it can determine the target fault cause and target fault level based on the log data; if it receives two or three of the fault codes, communication data, and log data simultaneously, it can determine the target fault cause and target fault level based on two or three of the fault codes, communication data, and log data respectively.
[0038] In some embodiments, the cloud server can perform vehicle fault verification based on fault codes, communication data, and log data to obtain a first verification result; if the first verification result indicates that the vehicle has a fault, then the target fault cause and target fault level are determined based on the fault codes, communication data, and log data.
[0039] During implementation, if the cloud server receives fault codes, communication data, and log data simultaneously, it can perform comprehensive analysis of these data to determine whether a vehicle has actually experienced a fault. For example, if the cloud server can determine a serious fault based on the fault code, but the log data indicates that the vehicle's driving data is normal, this means the vehicle does not have a fault, and further analysis of the target fault cause and level is unnecessary.
[0040] By verifying vehicle faults based on fault codes, communication data, and log data, subsequent analysis is only performed when a fault is confirmed in the vehicle. This avoids incorrectly identifying the cause and level of the target fault, which could lead to unnecessary recovery measures being taken.
[0041] In some embodiments, the cloud server can determine the cause of the fault based on the fault code; if the cause of the fault cannot be determined based on the fault code, the cause of the fault can be determined based on the communication data; if the cause of the fault cannot be determined based on the communication data, the cause of the fault can be determined based on the log data; if the cause of the fault is determined based on the log data, the determined cause of the fault is taken as the target cause of the fault.
[0042] Understandably, fault codes typically indicate where a problem is occurring inside the vehicle, not the cause. For example, fault code P0301 usually indicates a misfire in cylinder 1, but there are many possible causes for this misfire. These could include: ignition system issues (carbon buildup, damage, or incorrect spark plug clearance); fuel system issues (clogged, damaged, or faulty fuel injectors leading to insufficient or excessive fuel injection); mechanical system issues (insufficient cylinder pressure, such as valve leaks or worn piston rings); or sensor problems (although the fault code points to cylinder 1, a faulty airflow or oxygen sensor signal could cause incorrect fuel calculations for all cylinders, with cylinder 1 being the first to show the error). A cloud server can load the corresponding vehicle data based on the fault code and analyze it to determine the cause of the fault.
[0043] It should be noted that non-vehicle internal faults typically include communication failures between the vehicle and the other vehicle, power supply failures of the vehicle itself, and faults of the other vehicle. These faults are difficult to identify through fault codes, but can be identified through communication data and log data.
[0044] Specifically, communication data includes many fault signals. If certain signals in the communication data exceed a threshold or are lost, the cause of the communication fault or power supply fault can be determined based on the signals exceeding the threshold or the lost signals. For example, if the power supply voltage signal of an ECU is abnormal, the cause of the fault can be determined to be a power supply fault of that ECU.
[0045] Specifically, the log data includes a lot of interface status data. Based on the functional logic, the status of the interface that the function depends on at the time of the failure can be determined. By reasoning backward from the problematic interface, the cause of the failure of the other vehicle can be located step by step.
[0046] By combining fault codes, communication data, and log data, various causes related to vehicle faults can be accurately identified, not just those internal to the vehicle. This expands the vehicle's ability to autonomously recover from faults and covers more fault scenarios that are difficult for the vehicle to identify, enabling the vehicle to recover from faults caused by more specific reasons.
[0047] In some embodiments, the cloud server may also determine the target fault level based on fault codes, communication data, and log data.
[0048] The fault level can be set according to the actual situation. For example, a fault level of three represents a minor fault; a fault level of two represents a moderate fault; and a fault level of one represents a serious fault.
[0049] During implementation, fault codes, communication data, and log data can be used to determine where the fault occurred and further determine the target fault level. For example, after determining that the engine fault is detected, the target fault level can be determined as level one.
[0050] In step 102, the cloud server can determine the target fault recovery instruction based on the cause of the target fault.
[0051] Understandably, cloud servers can determine target fault recovery instructions in various ways based on the cause of the target fault. For example, the target fault cause can be input into the fault analysis model, and the fault analysis model can output the target fault recovery instructions. Alternatively, the target fault cause can be searched in a preset fault database stored in the cloud server to obtain the corresponding target fault recovery instructions.
[0052] In some embodiments, the cloud server can search for the target fault cause in a preset fault database; wherein, the preset fault database includes multiple fault causes and diagnostic recovery instructions corresponding to each fault cause; if the preset fault database includes the target fault cause, then the diagnostic recovery instruction corresponding to the target fault cause is determined as the target fault recovery instruction.
[0053] Among them, the diagnostic recovery instructions are recovery instructions determined based on Unified Diagnostic Services (UDS).
[0054] Specifically, the cloud server can build a preset fault database based on the historical fault causes and corresponding historical diagnostic recovery instructions of this vehicle or similar vehicles. After identifying the target fault cause, it can check whether the target fault cause is included in the preset fault database. If the target fault cause is included, it indicates a known fault, and its corresponding diagnostic recovery instruction is used as the target fault recovery instruction. If the target fault cause is not included, it indicates an unknown fault, and special recovery processing can be applied to it.
[0055] In some embodiments, if the target fault cause is not included in the preset fault database, the power failure recovery command is determined as the target fault recovery command.
[0056] Among them, the power-off recovery command is a recovery command that restores power after a power outage. For unknown faults, the faulty ECU can be restored by powering off and then powering on the ECU corresponding to the cause of the target fault.
[0057] During the implementation process, for unknown faults, the cloud server can also analyze the corresponding communication data and log data to determine whether it will cause the vehicle to break down or affect driving safety. If it will cause the vehicle to break down or affect driving safety, a breakdown warning task can be sent to the after-sales service platform, and after-sales personnel can intervene to restore the fault.
[0058] In step 103, the cloud server can configure target security execution conditions according to at least one of the target fault recovery instruction and the target fault level.
[0059] The safety execution conditions include basic safety execution conditions and / or multiple additional safety execution conditions. Basic safety execution conditions are those that must be met before the vehicle executes the target fault recovery command, while additional safety execution conditions are those that are not mandatory before the vehicle executes the target fault recovery command. Basic safety execution conditions may include the vehicle being locked, the vehicle being in a non-high-voltage state, the vehicle being in a non-charging state, the vehicle being in Park (P) gear, and the vehicle speed being less than a preset speed (e.g., 3 km / h). Additional safety execution conditions may include the fuel filler cap being closed, the ambient temperature being greater than a preset temperature (e.g., -35°C), the vehicle being in a non-upgraded state, the vehicle's hood not being opened, and the battery charge being greater than a preset charge.
[0060] In some embodiments, if the target fault recovery instruction is a diagnostic recovery instruction, the basic safety execution condition is determined as the target safety execution condition; if the target fault recovery instruction is a power failure recovery instruction, the target safety execution condition is configured according to the target fault level.
[0061] Understandably, for diagnostic recovery commands, regardless of whether the corresponding target fault level is level one, level two, or level three, the basic safety execution conditions are used as the target safety execution conditions. However, for power outage recovery commands, it is necessary to further configure the target safety execution conditions according to the target fault level. By using the target fault level to configure the target safety execution conditions, the complexity of configuring safety execution conditions can be reduced.
[0062] In some embodiments, if the target fault level represents a minor fault, the basic safety execution condition is determined as the target safety execution condition; if the target fault level represents a moderate or severe fault, the target safety execution condition is determined based on the basic safety execution condition and multiple additional safety execution conditions.
[0063] Specifically, the configuration rules for target security execution conditions can be found in Table 1 below: Table 1
[0064] As shown in Table 1, for power failure recovery commands, if the target fault level is level three, no additional safety execution conditions are configured; if the target fault level is level one or level two, additional safety execution conditions need to be configured.
[0065] In some embodiments, the cloud server may determine the recovery object indicated by the target fault recovery instruction; determine the target additional security condition from multiple additional security execution conditions based on the recovery object; and determine the basic security execution condition and the target additional security condition as the target security execution condition.
[0066] Taking the target fault recovery command as an example of a power failure recovery command for the entire vehicle, the target fault recovery command indicates the recovery object of all controllers of the entire vehicle. It can select the battery charge being greater than the preset charge as the target additional safety condition from multiple additional safety execution conditions, and then use the vehicle being locked, the vehicle being in a non-high voltage state, the vehicle being in a non-charging state, the vehicle being in P gear, the vehicle speed being less than the preset speed, and the battery charge being greater than the preset charge as the target safety execution conditions.
[0067] Taking the target fault recovery command as an example of a power-off recovery command for the engine controller of a hybrid vehicle, the target fault recovery command indicates the recovery object of the engine controller of the hybrid vehicle. It can select the fuel filler cap closure as the target additional safety condition from multiple additional safety execution conditions, and then select the vehicle being locked, the vehicle being in a non-high voltage state, the vehicle being in a non-charging state, the vehicle being in P gear, the vehicle speed being less than the preset speed, and the fuel filler cap being closed as the target safety execution conditions.
[0068] By specifically matching target additional safety conditions to the recovery object indicated by the target fault recovery command, the vehicle is always in a safe state that is adapted to the operational risks corresponding to the target fault recovery command. This effectively prevents secondary faults or chain safety risks that may be caused when the recovery object is restored, and fundamentally improves the safety of the vehicle.
[0069] In step 104, the cloud server can send the target fault recovery command and the target safety execution conditions to the vehicle, so that the vehicle can execute the target fault recovery command if the target safety execution conditions are met.
[0070] Understandably, after receiving the target fault recovery command and the target safety execution conditions, the vehicle can first check whether the current state meets the target safety execution conditions. If the target safety execution conditions are met, the target fault recovery command can be used to perform a software reset on the recovery object. After the vehicle executes the target fault recovery command for a preset duration (e.g., 5 seconds), it can collect fault codes, communication data, and log data again to determine whether the vehicle fault has been recovered. The judgment result is then reported to the cloud server. If the vehicle fault has been recovered, the tags on the fault codes, communication data, and log data can be cleared, and a successful fault recovery report can be sent to the cloud server. If the vehicle fault has not been recovered, if the target fault recovery command is a diagnostic recovery command, the fault codes, communication data, and log data need to be sent to the cloud server again for further processing. If the target fault recovery command is a power-off recovery command, a prompt message indicating that the vehicle fault recovery has failed can be output so that after-sales personnel can handle the fault in a timely manner.
[0071] In some embodiments, the cloud server can obtain the second tag data returned by the vehicle based on the execution of the target fault recovery command; perform vehicle fault verification based on the second tag data to obtain a second verification result; if the second verification result indicates that the vehicle has a fault, then send the power failure recovery command to the vehicle.
[0072] The second tag data may include at least one of the following: fault codes, communication data, and log data collected again.
[0073] When the target fault recovery command is a diagnostic recovery command, after the vehicle executes the target fault recovery command, the cloud server can use the second tag data to verify the vehicle fault and determine whether the vehicle actually has a fault. If the vehicle does have a fault, it means that the fault has not been recovered. At this time, another recovery measure can be taken, namely, sending a power-off recovery command to the vehicle.
[0074] After the vehicle executes the power-off recovery command, it can collect fault codes, communication data, and log data for the third time to determine whether the vehicle fault has been recovered. The judgment result is then reported to the cloud server. If the vehicle fault has been recovered, the labels of the fault codes, communication data, and log data can be cleared, and a successful fault recovery report can be sent to the cloud server. If the vehicle fault has not been recovered, the fault codes, communication data, and log data need to be sent to the cloud server again for further processing.
[0075] In some embodiments, the cloud server can obtain third tag data returned by the vehicle based on the execution of the target fault recovery instruction; perform vehicle fault verification on the third tag data to obtain a third verification result; if the third verification result indicates that the vehicle has a fault, then output a prompt message indicating that the vehicle fault recovery has failed.
[0076] The third tag data includes at least one of the fault codes, communication data, and log data collected in the third collection.
[0077] When the target fault recovery command is a power-off recovery command, after the vehicle executes the target fault recovery command, the cloud server can use third-party tag data to verify the vehicle fault and determine whether the vehicle actually has a fault. If the vehicle does have a fault, it means that the fault has not been recovered. At this time, a prompt message indicating that the vehicle fault recovery has failed can be output so that after-sales personnel can handle the fault in a timely manner.
[0078] Figure 2 It shows Figure 1 A diagram illustrating the flow of data in the middle. (Example) Figure 2 As shown, after the vehicle reports tag data, the cloud analyzes the tag data and inputs the analysis results into a preset fault database. The preset fault database then outputs a fault recovery strategy, namely the target fault recovery command and the target safety execution conditions. The cloud sends the target fault recovery command and the target safety execution conditions to the fault handling module on the vehicle. If the target fault recovery command is a diagnostic recovery command, the fault handling module sends the diagnostic recovery command directly to the corresponding faulty ECU. If the target fault recovery command is a power-off recovery command, the fault handling module sends the power-off recovery command to the power management control unit, which then controls the corresponding faulty ECU to power off and then power on again.
[0079] This application's embodiments leverage the powerful data processing capabilities of the cloud for fault analysis and decision-making, covering more fault scenarios that are difficult to identify when the vehicle autonomously recovers from faults. After the cloud receives the target safety execution conditions and the target fault recovery command, the vehicle executes the target fault recovery command provided that the target safety execution conditions are met. This vehicle-cloud collaborative solution, through "cloud decision-making - vehicle execution," not only ensures vehicle security but also significantly expands the boundaries of the vehicle's fault recovery capabilities, increasing the scope of vehicle fault handling.
[0080] Figure 3 A flowchart illustrating a method for handling vehicle malfunctions according to other embodiments of this application is shown. For example... Figure 3 As shown, another method for handling vehicle malfunctions is provided, including the following steps: Step 301: Perform vehicle fault verification based on the first tag data to obtain a first verification result, wherein the first tag data includes at least one of fault code, communication data and log data; Step 302: If the first verification result indicates that the vehicle has a fault, then determine the target fault cause and target fault level based on the fault code, communication data and log data. Step 303: Search for the target fault cause in the preset fault database. The preset fault database includes multiple fault causes and diagnostic recovery instructions corresponding to each fault cause. If the preset fault database includes the target fault cause, the diagnostic recovery instruction corresponding to the target fault cause is determined as the target fault recovery instruction. If the preset fault database does not include the target fault cause, the power outage recovery instruction is determined as the target fault recovery instruction. Step 304: If the target fault recovery instruction is a diagnostic recovery instruction, then the basic safety execution condition is determined as the target safety execution condition. If the target fault recovery instruction is a power outage recovery instruction and the target fault level represents a minor fault, then the basic safety execution condition is determined as the target safety execution condition. If the target fault recovery instruction is a power outage recovery instruction and the target fault level represents a moderate or severe fault, then the recovery object indicated by the target fault recovery instruction is determined. Based on the recovery object, the target additional safety condition is determined from multiple additional safety execution conditions, and the basic safety execution condition and the target additional safety condition are determined as the target safety execution condition. Step 305: Send the target fault recovery command and the target safety execution conditions to the vehicle, so that the vehicle executes the target fault recovery command if the target safety execution conditions are met; Step 306: Obtain the second tag data returned by the vehicle based on the executed diagnostic recovery command, perform vehicle fault verification based on the second tag data, and obtain the second verification result. If the second verification result indicates that the vehicle has a fault, then send the power-off recovery command to the vehicle. Step 307: Obtain the third tag data returned by the vehicle based on the execution of the power failure recovery command, perform vehicle fault verification on the third tag data, and obtain the third verification result. If the third verification result indicates that the vehicle has a fault, output a prompt message indicating that the vehicle fault recovery has failed.
[0081] This application's embodiments, by verifying tag data, can rule out situations where the vehicle is not faulty, avoiding incorrect analysis of the target fault cause and level, which could lead to unnecessary recovery measures. By designing targeted safety execution conditions for different target fault recovery commands and target fault levels, vehicle safety is improved. By re-verifying the tag data after the vehicle executes the diagnostic recovery command, it can be determined whether the vehicle fault has been recovered. If not, a power-off recovery command is issued to the vehicle as a remedial measure, further improving the success rate of fault recovery. The above solution effectively addresses the issue of occasional software problems causing vehicle unavailability after delivery to users, reducing user waiting time and improving after-sales service operational efficiency.
[0082] The following describes an embodiment of the apparatus described in this application, which can be used to execute the vehicle malfunction handling method described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the vehicle malfunction handling method described above in this application.
[0083] See Figure 4 This diagram illustrates a block diagram of a vehicle malfunction handling apparatus according to an embodiment of this application. Figure 4 As shown in the figure, the vehicle fault processing device of this application embodiment is applied to a cloud server. The vehicle fault processing device includes: a tag data analysis module 401, a recovery instruction determination module 402, a safety condition determination module 403, and a fault recovery module 404. The tag data analysis module 401 is used to determine the target fault cause and the target fault level based on the first tag data related to the vehicle fault. The recovery instruction determination module 402 is used to determine the target fault recovery instruction based on the target fault cause. The safety condition determination module 403 is used to configure the target safety execution conditions based on at least one of the target fault recovery instruction and the target fault level. The fault recovery module 404 is used to send the target fault recovery instruction and the target safety execution conditions to the vehicle so that the vehicle executes the target fault recovery instruction when the target safety execution conditions are met.
[0084] In some embodiments, based on the foregoing scheme, the safety execution conditions include basic safety execution conditions and / or multiple additional safety execution conditions. The safety condition determination module 403 can also be used to determine the basic safety execution conditions as the target safety execution conditions if the target fault recovery instruction is a diagnostic recovery instruction; and to configure the target safety execution conditions according to the target fault level if the target fault recovery instruction is a power failure recovery instruction.
[0085] In some embodiments, based on the foregoing scheme, the safety condition determination module 403 can also be used to determine the basic safety execution condition as the target safety execution condition if the target fault level represents a minor fault; and to determine the target safety execution condition based on the basic safety execution condition and multiple additional safety execution conditions if the target fault level represents a moderate or severe fault.
[0086] In some embodiments, based on the foregoing scheme, the security condition determination module 403 may also be used to determine the recovery object indicated by the target fault recovery instruction; determine the target additional security condition from multiple additional security execution conditions based on the recovery object; and determine the basic security execution condition and the target additional security condition as the target security execution condition.
[0087] In some embodiments, based on the foregoing scheme, the first tag data includes at least one of fault codes, communication data, and log data. The tag data analysis module 401 can also be used to determine the target fault cause and the target fault level based on at least one of fault codes, communication data, and log data.
[0088] In some embodiments, based on the foregoing scheme, the tag data analysis module 401 can also be used to perform vehicle fault verification based on fault codes, communication data and log data to obtain a first verification result; if the first verification result indicates that the vehicle has a fault, then the target fault cause and target fault level are determined based on the fault codes, communication data and log data.
[0089] In some embodiments, based on the aforementioned scheme, the tag data analysis module 401 can also be used to determine the cause of the fault based on the fault code; if the cause of the fault cannot be determined based on the fault code, then the cause of the fault is determined based on the communication data; if the cause of the fault cannot be determined based on the communication data, then the cause of the fault is determined based on the log data; if the cause of the fault is determined based on the log data, then the determined cause of the fault is taken as the target cause of the fault.
[0090] In some embodiments, based on the foregoing scheme, the recovery instruction determination module 402 can also be used to search for the target fault cause in a preset fault database; wherein, the preset database includes multiple fault causes and diagnostic recovery instructions corresponding to each fault cause; if the preset fault database includes the target fault cause, then the diagnostic recovery instruction corresponding to the target fault cause is determined as the target fault recovery instruction.
[0091] In some embodiments, based on the foregoing scheme, the fault recovery module 404 can also be used to obtain the second tag data returned by the vehicle based on the execution of the target fault recovery command; perform vehicle fault verification based on the second tag data to obtain a second verification result; if the second verification result indicates that the vehicle has a fault, then send the power failure recovery command to the vehicle.
[0092] In some embodiments, based on the foregoing scheme, the recovery instruction determination module 402 can also be used to determine the power failure recovery instruction as the target fault recovery instruction if the preset fault database does not contain the target fault cause.
[0093] In some embodiments, based on the foregoing scheme, the fault recovery module 404 can also be used to obtain the third tag data returned by the vehicle based on the execution of the target fault recovery instruction; perform vehicle fault verification on the third tag data to obtain the third verification result; if the third verification result indicates that the vehicle has a fault, then output a prompt message indicating that the vehicle fault recovery has failed.
[0094] Based on the same inventive concept, embodiments of this application also provide a vehicle malfunction processing device, see reference. Figure 5 The diagram shows a schematic of the structure of a vehicle fault processing device according to an embodiment of this application. The vehicle fault processing device includes one or more memories 504, one or more processors 502, and at least one computer program (computer program instruction) stored in the memory 504 and executable on the processor 502. When the processor 502 executes the computer program, it implements the method described above.
[0095] Among them, Figure 5 In this document, a bus architecture (represented by bus 500) is used. Bus 500 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 502 and memory represented by memory 504. Bus 500 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 505 provides an interface between bus 500 and receiver 501 and transmitter 503. Receiver 501 and transmitter 503 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 502 is responsible for managing bus 500 and general processing, while memory 504 can be used to store data used by processor 502 during operation.
[0096] Based on the same inventive concept, this application provides a vehicle fault handling system, including a vehicle 601 and the aforementioned vehicle fault handling device 602. The vehicle 601 is communicatively connected to the vehicle fault handling device 602. The vehicle 601 is used to receive a target fault recovery instruction and a target safety execution condition sent by the vehicle fault handling device 602, and executes the target fault recovery instruction when the target safety execution condition is met.
[0097] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the method described above.
[0098] Based on the same inventive concept, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.
[0099] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit.
[0100] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0101] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.
[0102] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.
[0103] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A method of handling a vehicle malfunction, characterized by, The method is applied to a cloud server and comprises the following steps: determining a target fault cause and a target fault level according to first label data related to a vehicle fault; determining a target fault recovery instruction according to the target fault cause; configuring a target safety execution condition according to at least one of the target fault recovery instruction and the target fault level; sending the target fault recovery instruction and the target safety execution condition to a vehicle, so that the vehicle executes the target fault recovery instruction when the target safety execution condition is met.
2. The method of handling a vehicle malfunction according to claim 1, characterized by, The safety execution condition comprises a basic safety execution condition and / or a plurality of additional safety execution conditions, and the configuration of the target safety execution condition according to at least one of the target fault recovery instruction and the target fault level comprises the following steps: if the target fault recovery instruction is a diagnosis recovery instruction, the basic safety execution condition is determined as the target safety execution condition; if the target fault recovery instruction is a power-off recovery instruction, the target safety execution condition is configured according to the target fault level.
3. The method of handling a vehicle malfunction according to claim 2, characterized in that, The configuration of the target safety execution condition according to the target fault level comprises the following steps: if the target fault level represents a mild fault, the basic safety execution condition is determined as the target safety execution condition; if the target fault level represents a moderate fault or a severe fault, the target safety execution condition is determined based on the basic safety execution condition and the plurality of additional safety execution conditions.
4. The method of handling a vehicle malfunction according to claim 3, characterized by The determination of the target safety execution condition based on the basic safety execution condition and the plurality of additional safety execution conditions comprises the following steps: determining a recovery object indicated by the target fault recovery instruction; determining a target additional safety condition from the plurality of additional safety execution conditions based on the recovery object; determining the basic safety execution condition and the target additional safety condition as the target safety execution condition.
5. The method of handling a vehicle malfunction according to claim 1, characterized by, The first label data comprises at least one of a fault code, communication data and log data, and the determination of the target fault cause and the target fault level according to the first label data related to a vehicle fault comprises the following steps: determining the target fault cause and the target fault level according to at least one of the fault code, the communication data and the log data.
6. The method of handling a vehicle malfunction according to claim 5, characterized by The determination of the target fault cause and the target fault level according to at least one of the fault code, the communication data and the log data comprises the following steps: performing vehicle fault verification according to the fault code, the communication data and the log data to obtain a first verification result; if the first verification result indicates that the vehicle has a fault, determining the target fault cause and the target fault level according to the fault code, the communication data and the log data.
7. The method of handling a vehicle malfunction according to claim 6, characterized by The determination of the target fault cause according to the fault code, the communication data and the log data comprises the following steps: performing fault cause judgment according to the fault code; if the fault cause cannot be determined according to the fault code, performing fault cause judgment according to the communication data; if the fault cause cannot be determined according to the communication data, performing fault cause judgment according to the log data; If a fault cause is determined according to the log data, the determined fault cause is determined as the target fault cause.
8. The method of handling a vehicle malfunction according to claim 1, characterized by, The determining a target fault recovery instruction according to the target fault cause comprises: searching for the target fault cause in a preset fault database; wherein the preset database comprises a plurality of fault causes and diagnostic recovery instructions corresponding to each of the fault causes; If the target fault cause is included in the preset fault database, the diagnostic recovery instruction corresponding to the target fault cause is determined as the target fault recovery instruction.
9. The method of handling a vehicle fault according to claim 8, characterized in that, Further comprising: obtaining second label data returned by the vehicle based on execution of the target fault recovery instruction; performing vehicle fault checking according to the second label data to obtain a second checking result; If the second checking result indicates that the vehicle has a fault, a power-off recovery instruction is sent to the vehicle.
10. The method of handling a vehicle malfunction according to claim 8, wherein Further comprising: If the target fault cause is not included in the preset fault database, a power-off recovery instruction is determined as the target fault recovery instruction.
11. The method of handling a vehicle malfunction according to claim 10, wherein Further comprising: obtaining third label data returned by the vehicle based on execution of the target fault recovery instruction; performing vehicle fault checking on the third label data to obtain a third checking result; If the third checking result indicates that the vehicle has a fault, prompt information indicating that the vehicle fault recovery fails is output.
12. A processing device of a vehicle failure, characterized by, Applied to a cloud server, the device comprises: a label data analysis module configured to determine a target fault cause and a target fault level according to vehicle fault-related first label data; a recovery instruction determination module configured to determine a target fault recovery instruction according to the target fault cause; a safety condition determination module configured to configure a target safety execution condition according to at least one of the target fault recovery instruction and the target fault level; a fault recovery module configured to send the target fault recovery instruction and the target safety execution condition to a vehicle, so that the vehicle executes the target fault recovery instruction under the condition that the target safety execution condition is met.
13. A vehicle fault handling device comprising a processor and a memory, characterized in that The memory stores computer program instructions executable by the processor, and the processor executes the computer program instructions to implement the steps of the method according to any one of claims 1 to 11.
14. A system for handling vehicle malfunctions, characterized in that The vehicle and the vehicle fault processing device according to claim 13 are in communication connection, and the vehicle is configured to receive the target fault recovery instruction and the target safety execution condition sent by the vehicle fault processing device, and execute the target fault recovery instruction under the condition that the target safety execution condition is met.
15. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to cause the processor to implement the steps of the method according to any one of claims 1 to 11.