Vehicle failure handling method and cloud server, server and storage medium

Abstract

The present application relates to a method for handling vehicle faults and a cloud server, server, and storage medium. The method includes: maintaining a diagnostic package consisting of a set of fault trees, and establishing a push task, wherein each fault tree in the set of fault trees represents various types of faults occurring in the vehicle and the logical relationships between the various types of faults in a multi-branch tree structure, and the push task is bound to the version number of the diagnostic package and the target vehicle to be pushed; receiving the diagnostic package version number reported by the target vehicle, and comparing the version number bound to the push task with the version number reported by the target vehicle; if the version number bound to the push task is inconsistent with the version number reported by the target vehicle, the diagnostic package is sent to the target vehicle based on the push task to update the local diagnostic package for vehicle fault judgment. Through this application, the problem that the vehicle fault analysis strategy in the prior art cannot be updated, resulting in the inability to cover more scenarios and a poor user experience is solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle fault handling, and in particular to a vehicle fault handling method, a cloud server, a server, and a storage medium. Background Art

[0002] Currently, smart cars are equipped with a variety of sensors and monitoring devices that can monitor various vehicle parameters and status in real time. When the monitoring equipment detects an anomaly or fault, it will perform fault diagnosis based on the locally installed diagnostic system and program. Once the system completes the fault diagnosis, it will display relevant warning information on the central control screen and instrument panel to alert the driver and take relevant measures. The diagnostic strategy of the on-board diagnostic system is usually designed and developed by the car manufacturer and is a software program stored in the on-board computer. Diagnostic strategy updates are usually performed as part of the car software upgrade and are upgraded together with the car software. However, in the existing technology, the vehicle-side fault analysis strategy cannot be updated. Once the vehicle leaves the factory, the on-board diagnostic system cannot be updated. The outdated strategy cannot cover more scenarios, resulting in a poor user experience. Summary of the Invention

[0003] The present application provides a vehicle fault processing method and a cloud server, server and storage medium to solve the problem in the prior art that the vehicle fault analysis strategy cannot be updated, resulting in the inability to cover more scenarios and a poor user experience.

[0004] In the first aspect, the present application provides a method for handling vehicle faults, which is applied to a cloud server, and the method includes: maintaining a diagnostic package composed of a fault tree set, and establishing a push task, wherein each fault tree in the fault tree set represents various types of faults occurring in the vehicle and the logical relationship between the various fault types in a multi-branch tree structure, and the push task is bound to the version number of the diagnostic package and the target vehicle to be pushed; receiving the diagnostic package version number reported by the target vehicle, and comparing the version number bound to the push task with the version number reported by the target vehicle; if the version number bound to the push task is inconsistent with the version number reported by the target vehicle, the diagnostic package is sent to the target vehicle based on the push task for updating the local diagnostic package to perform vehicle fault judgment.

[0005] In the second aspect, the present application provides a cloud server, comprising: a first processing module, used to maintain a diagnostic package consisting of a fault tree set, and establish a push task, wherein each fault tree in the fault tree set represents various types of faults occurring in the vehicle and the logical relationship between the various fault types in a multi-branch tree structure, and the push task is bound to the version number of the diagnostic package and the target vehicle to be pushed; a second processing module, used to receive the diagnostic package version number reported by the target vehicle, and compare the version number bound to the push task with the version number reported by the target vehicle; a third processing module, used to send the diagnostic package to the target vehicle based on the push task for updating the local diagnostic package to perform vehicle fault judgment when the version number bound to the push task is inconsistent with the version number reported by the target vehicle.

[0006] In a third aspect, the present application provides a server comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the processor is configured to execute the vehicle fault processing method described in the first aspect of the present application.

[0007] In a fourth aspect, the present application further provides a computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the vehicle fault handling method described in the first aspect of the present application.

[0008] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: In the embodiment of the present application, vehicle fault events can be maintained through a multi-branch tree structure, which can not only clearly obtain the logical relationship between faults, but also efficiently update the fault events according to the tree interface when they need to be updated. Based on this, when it is determined that the local diagnostic package version number of the target vehicle is inconsistent with the diagnostic package version number of the cloud server, the diagnostic package can be pushed to the target vehicle through the cloud server to update the fault event, so that the vehicle can adapt to more vehicle fault scenarios and can handle vehicle faults in a timely manner when they occur, thereby improving the safety of vehicle use and also improving the user's driving experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0011] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0012] Figure 1 A flowchart of a method for handling a vehicle failure provided in an embodiment of the present application;

[0013] Figure 2 A schematic diagram of a fault tree structure using a power battery failure as a fault tree according to an embodiment of the present application;

[0014] Figure 3 A schematic diagram of the structure of the full diagnostic package provided in an embodiment of the present application;

[0015] Figure 4 A flowchart of a vehicle fault diagnosis method based on a remote push strategy and a fault tree according to an embodiment of the present application;

[0016] Figure 5 A schematic diagram of the structure of the cloud server provided in an embodiment of the present application;

[0017] Figure 6 A schematic diagram of the structure of the server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0019] The disclosure below provides many different embodiments or examples for implementing different configurations of the present invention. To simplify the disclosure of the present invention, the components and configurations of specific examples are described below. Of course, these are merely examples and are not intended to limit the present invention. In addition, the present invention may repeat reference numerals and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or configurations discussed.

[0020] In order to solve the problem in the prior art that the vehicle fault analysis strategy cannot be updated, resulting in the inability to cover more scenarios and poor user experience, the present application provides a vehicle fault processing method, which is applied to a cloud server, such as Figure 1 As shown, the steps of the method include:

[0021] Step 101: Maintain a diagnostic package consisting of a fault tree set (FTSE) and establish a push task. Each fault tree in the FTSE represents various vehicle fault types and the logical relationships between them using a multi-branch tree structure. The push task is bound to the version number of the diagnostic package and the target vehicle to be pushed.

[0022] The multi-branch tree structure in the embodiment of the present application can be composed of a root node, one or more parent nodes, and one or more child nodes, wherein a root node has one or more parent nodes, and a parent node has one or more parent nodes or child nodes. In a specific example, taking the vehicle failure as an example of power battery depletion, there may be two reasons for the power battery depletion: a battery system failure and a charging system failure; if it is a charging system failure, it may be a charger failure or insufficient battery charging. In this regard, the charger failure can be further subdivided into low charger output and dirty charging interface, and insufficient battery charging can be further subdivided into too small charging current and insufficient charging time. It can be seen that the logical relationship between the fault types in the embodiment of the present application refers to the step-by-step subdivision process of the fault from large to small, as shown in the following example. Figure 2 As shown in the figure, power battery depletion is the root node, battery system failure and charging system failure are parent nodes, in addition, battery overheating, charger failure, and insufficient battery charging are also parent nodes; battery aging failure, excessive charging circuit resistance, low charger output, dirty charging interface, too low charging current, and insufficient charging time are child nodes.

[0023] Step 102: Receive the diagnostic package version number reported by the target vehicle and compare the version number bound to the push task with the version number reported by the target vehicle;

[0024] It can be seen that the vehicle has a preset diagnostic package locally, but the diagnostic package in the embodiment of the present application is updated in real time on the cloud server according to actual needs. If the current diagnostic package version number of the vehicle is inconsistent with the diagnostic package version number of the cloud server, it indicates that the vehicle's local diagnostic package needs to be updated to adapt to more scenario requirements.

[0025] Step 103 : If the version number bound to the push task is inconsistent with the version number reported by the target vehicle, the diagnostic package is sent to the target vehicle based on the push task to update the local diagnostic package for vehicle fault diagnosis.

[0026] From the above steps 101 to 103, it can be seen that in the embodiment of the present application, a multi-branch tree structure can be used to maintain vehicle fault events. Through this multi-branch tree structure, not only can the logical relationship between faults be clearly obtained, but also when the fault event needs to be updated, it can be efficiently updated according to the tree interface. Based on this, when it is determined that the local diagnostic package version number of the target vehicle is inconsistent with the diagnostic package version number of the cloud server, the diagnostic package can be pushed to the target vehicle through the cloud server to update the fault event, so that the vehicle can adapt to more vehicle fault scenarios and can handle vehicle faults in a timely manner when they occur, thereby improving the safety of vehicle use and also improving the user's driving experience.

[0027] In the embodiment of the present application, a vehicle fault tree is maintained using a multi-branch tree structure. That is, the relationship between the nodes in the fault tree in the embodiment of the present application indicates the logical relationship between the faults. Based on this, the method of maintaining the diagnostic package consisting of the fault tree set involved in step 102 in the embodiment of the present application can further include:

[0028] Step 11: Based on the logical relationship between the faults, the fault events corresponding to the vehicle are divided into top events, intermediate events, and bottom events. The top event represents the final result of the fault event, the intermediate event represents the event leading to the top event, and the bottom event represents the basic event of the fault event. The intermediate event can be decomposed into one or more intermediate events or one or more bottom events.

[0029] Step 12: construct a fault tree based on the logical relationship and the multi-branch tree structure, and construct a fault tree set based on the fault tree to obtain a diagnosis package, wherein the fault tree set includes multiple fault trees of the same type of fault.

[0030] In the embodiment of the present application, the top event is the final result or main event of the entire fault tree, which usually represents a fault or accident phenomenon. The intermediate event is the event that causes the top event to occur, which usually represents the failure or failure of a component or subsystem in the system. The intermediate event can be further decomposed into more intermediate events or bottom events. The bottom event is the most basic event of the fault tree, which cannot be further decomposed and is the cause of the intermediate event. Figure 2 As shown, power battery depletion is the top event, while battery system failure, charging system failure, battery overheating, charger failure, and insufficient battery charge are intermediate events. Battery aging, excessive charging circuit resistance, low charger output, dirty charging port, low charging current, and insufficient charging duration are bottom events. By dividing fault events and combining them with a multi-branch tree structure, the logical relationships between faults can be clearly identified. This also makes updating the fault tree quick and easy. For example, if an intermediate event is needed for the power battery depletion top event, only a parent node needs to be added.

[0031] In an optional implementation of the embodiment of the present application, the method of classifying the fault events corresponding to the vehicle into top events, intermediate events, and bottom events based on the logical relationship between the faults involved in step 11 above may further include:

[0032] Step 21, determining the type of the fault event according to the diagnostic domain, wherein different diagnostic domains represent different areas of the automotive system to which the fault belongs;

[0033] Step 22: Based on the logical relationship between faults, fault events corresponding to the same diagnosis domain are divided into top events, middle events, and bottom events.

[0034] In this regard, in a specific example, the diagnostic domains may include the power domain, chassis domain, body domain, cockpit domain, and autonomous driving domain. Each fault tree will define which domain it applies to. When a fault occurs in a diagnostic domain, the fault tree defined in that diagnostic domain will be used first, allowing for rapid fault location. In this specific example, the diagnostic domain classification shown in Table 1 is described as follows:

[0035]

[0036]

[0037] Table 1

[0038] After classifying the fault events into diagnostic domains, the fault events can be further divided, and then the fault data can be constructed in combination with the multi-tree structure. Therefore, the method of constructing a fault tree based on the logical relationship and the multi-tree structure involved in step 12 above, and constructing a fault tree set based on the fault tree to obtain a diagnostic package can further include:

[0039] Step 31: Based on the logical relationship, the top event, the middle event, and the bottom event in the fault event are set on the nodes of the multi-branch tree structure to obtain a fault tree corresponding to the fault event;

[0040] Step 32: Set a unique identifier and a usage scenario of the fault tree for each fault event, and set the fault trees corresponding to the same diagnostic domain as a fault tree set;

[0041] Step 33: construct a diagnosis package based on multiple fault tree sets corresponding to multiple different diagnosis domains.

[0042] It can be seen that in the embodiment of the present application, all fault trees belonging to the same diagnostic domain are grouped together and defined as a fault tree set. Each fault tree set has a unique number. Each time a fault tree set is sent to the vehicle side, all fault tree sets are packaged and compressed, and all are sent to the vehicle side as a full diagnostic package for use by the vehicle side. Each fault tree under the fault tree set also has a unique number and name, as shown in the following example. Figure 3 shown.

[0043] In addition, in the embodiments of this application, each fault tree requires a defined usage scenario, which specifies the circumstances under which the fault tree can be used. When the vehicle is identified as being in that scenario, the fault tree is enabled for fault diagnosis and analysis. In this specific example, usage scenarios include: when the vehicle is parked and powered off, when the vehicle is parked and powered on, while driving, in charging state, and in maintenance mode, as shown in Table 2.

[0044]

[0045] Table 2

[0046] It should be noted that the same fault tree can also be applied to multiple usage scenarios at the same time, because the same fault may occur in different usage scenarios, such as Figure 2 The use cases associated with power battery depletion in the example above can be the parking state and the driving state. Therefore, the fault tree can be used for fault analysis in these two states.

[0047] In the embodiment of the present application, the purpose of maintaining the fault tree and updating the vehicle diagnostic package is to enable the vehicle to adapt to more fault scenarios, that is, to provide prompts or repair suggestions in a timely manner after a fault occurs. Based on this, the method of determining the vehicle fault involved in the above step 103 may further include:

[0048] Step 41: receiving a fault code of a bottom event reported by a vehicle, wherein each bottom event corresponds to a fault code;

[0049] In a specific example, the fault code used to determine the occurrence of the bottom event is a specific combination of numbers and letters generated by the automotive electronic control unit (ECU) or the powertrain control module when a fault is detected in the vehicle system.

[0050] Step 42, detecting the number of fault code reports within the fault assessment period;

[0051] For example, if vehicle A generates and reports fault code D9021 to the cloud service, the system will monitor the vehicle for 5 minutes to detect whether the same fault code is reported again within 5 minutes. The 5 minutes here is the evaluation period. If vehicle A generates and reports fault code D9021 to the cloud service, the system will monitor the vehicle for 5 minutes to detect whether the same fault code is reported 10 times within 5 minutes. The 10 times here is the cumulative number of times.

[0052] Step 43, after the number of reports exceeds the preset threshold, based on the fault level corresponding to the bottom event, the fault and maintenance suggestions of the bottom event are prompted through one or more prompting methods, where the prompting methods include: vehicle-side display, terminal prompt, and cloud server prompt.

[0053] In this specific example, fault levels can be categorized as 1, 2, 3, and 4, with 1 being the highest level. Each fault code corresponds to a fault level. When a fault code is diagnosed, the corresponding fault level can be identified. Different levels correspond to different response measures. For example, a Level 1 fault represents the highest level of severity, requiring immediate notification to the vehicle owner and automatic notification to backend customer service and maintenance personnel for follow-up. The specific level classification is shown in Table 3.

[0054]

[0055]

[0056] Table 3

[0057] In addition, in specific examples, different reminder methods correspond to different processing measures. Based on this, the vehicle-side display in the embodiment of the present application refers to the direct display on the dashboard, central control screen and other terminals of the car after the fault is discovered; it is generally used when the vehicle is driving or parked and powered on to intuitively show the vehicle problem and prompt the user to perform relevant processing. Mobile phone prompts refer to the severity level of the fault, emergency situation, etc., which are divided into three types: customer service telephone prompts, mobile phone text message prompts, and mobile phone APP message prompts, and the prompt intensity gradually weakens. Cloud service background display refers to the fault message sent to the cloud service background for operation personnel to track and investigate; it mainly includes some faults with low current fault levels but potential upgrade risks, and also includes some faults that require long-term observation and analysis. The same fault can include multiple prompt methods at the same time, as shown in Table 4.

[0058]

[0059] Table 4

[0060] Combined with the above Figures 2 to 3, as well as Tables 1 to 4, take fault tree example 1 - the bottom event "charging circuit resistance is too large" under power battery depletion, the fault code is P0A1A, the evaluation cycle is 2 minutes, the cumulative number of times is 5, the fault level is level 2, and the fault prompt method is the vehicle-side instrument panel prompt and mobile phone text message prompt.

[0061] The usage scenario combined with the fault tree can be: when the car is driving or parked and powered on, if the vehicle-side system detects that the P0A1A fault code occurs 5 times in 2 minutes, it is judged that the bottom event occurs and the upper intermediate event of the bottom event "battery overheat" occurs; because the "battery overheat" domain "battery aging fault" is an "or" relationship, the upper intermediate event "battery system fault" occurs, which means that "battery system fault" occurs; similarly, if "power battery low power" occurs, the battery system fault will be prompted through the vehicle-side instrument panel; the mobile phone text message prompts the user that "the vehicle-side fault monitoring system has detected a battery system fault in your car. The maintenance suggestion is: please check whether the charging cable and interface are damaged, aged, loose, corroded or dirty, and whether the charger is working properly; if the problem cannot be solved, please contact the 4S shop to measure the charging circuit resistance and check the battery contact piece."

[0062] In the embodiment of the present application, the target vehicle may be one or more vehicles of the same model, or one or more vehicles specified by the cloud server. Therefore, the method of receiving the diagnostic package version number reported by the target vehicle involved in the above step 102 may further include: receiving the diagnostic package version number reported by one or more target vehicles of the same model; or, receiving the diagnostic package version number reported by one or more target vehicles specified by the cloud server.

[0063] In the embodiment of the present application, the method of sending the diagnostic package to the target vehicle based on the push task for updating the local diagnostic package involved in step 103 may further include:

[0064] Step 51: compress the push task into a corresponding compressed message and store it in the database for backup;

[0065] Step 52: When the push task is effective, the compressed message is pushed to one or more target vehicles of the same model through a preset communication protocol, or pushed to one or more target vehicles specified by the cloud server.

[0066] In this regard, in the embodiment of the present application, you can choose to manually upload or schedule the remote push task to set it to the effective state. Manual upload means that after creating the task, the operator manually clicks the upload button to set the task to effective. Scheduled upload means that when creating the task, a upload time is set, and the system automatically sets it to effective when the upload time is reached.

[0067] The following is an explanation of the present application in conjunction with the specific implementation of the embodiment of the present application. The specific implementation provides a vehicle fault diagnosis method based on remote push strategy and fault tree. The specific process execution process can be as follows: Figure 4 In this regard, the vehicle fault diagnosis method in the embodiment of the present application can be implemented as a whole through the following steps:

[0068] Step 401: The cloud backend maintains the fault tree.

[0069] Among them, the fault tree uses a multi-branch tree structure to represent the various combinations and logical relationships of possible system failures, and finds the root cause of the system failure by gradually decomposing the failure events.

[0070] Fault tree maintenance consists of two main parts: tree structure maintenance and bottom-level event maintenance. Maintaining the tree structure primarily involves identifying the various causes of top-level events, specifically listing the logical relationships between top-level events, intermediate events, and bottom-level events. Maintaining bottom-level events primarily involves defining their basic attributes, including fault code, evaluation period, cumulative counts, repair recommendations, fault severity, and fault prompts. These attributes are used to determine whether a related fault has occurred and to determine the next step.

[0071] like Figure 2 As shown, "power battery loss" is the top event, and the rectangles on the right are middle events, such as "battery system failure" and "battery overheating". The ellipses at the end are bottom events, such as "battery aging failure". "DTCP0563" is the fault code maintained by this bottom event. When the fault code P0563 appears in the vehicle message, it means that this bottom event may have occurred. It is also necessary to combine the evaluation cycle and the cumulative number of times to determine whether the "battery aging failure" has actually occurred. Figure 2 It can be seen that the fault tree "power battery low" contains one top event, five intermediate events, and six bottom events.

[0072] The maintenance of the fault tree structure needs to be carried out from the following aspects:

[0073] 1) Diagnostic domain,Fault tree analysis is widely used in various automotive system areas to systematically identify and solve faults.

[0074] In the embodiment of this application, several major automotive diagnostic domains are defined: power domain, chassis domain, body domain, cockpit domain, and self-driving domain, as shown in Table 2. Each fault tree will define which domain it applies to. When a fault occurs in a diagnostic domain, the fault tree defined in that diagnostic domain will be used first. Figure 2 Your fault tree example 1 - power battery depletion belongs to the power domain classification.

[0075] 2) Fault tree set. In the embodiment of the present application, all fault trees belonging to the same diagnostic domain are grouped together and defined as a fault tree set. Each fault tree set has a unique number. Each time a fault tree set is sent to the vehicle side, all fault tree sets are packaged and compressed, and all are sent to the vehicle side as a full diagnostic package for use by the vehicle side. Each fault tree under the fault tree set also has a unique number and name. As shown in Table 2, the fault tree example 1 - power battery depletion is numbered faultTree00001, and belongs to the power domain set numbered SetNo0001.

[0076] 3) Usage scenario: Each fault tree needs to define its usage scenario, which specifies the circumstances under which the fault tree can be used. When the vehicle is identified as being in this scenario, the fault tree is in a usable state and can be used for fault diagnosis and analysis.

[0077] In the present application, as shown in Table 3, the following five usage scenarios are used: when the vehicle is parked and powered off, when the vehicle is parked and powered on, while driving, in charging state, and in maintenance mode. The same fault tree can simultaneously include multiple usage scenarios. For example, the fault tree example 1 - Power battery low power associated with the usage scenarios of parked and powered on and while driving. This fault tree can be used for fault analysis in both states.

[0078] The maintenance of bottom events needs to be carried out from the following aspects:

[0079] 1) Fault code refers to the fault code that determines the occurrence of the underlying event, commonly known as the automobile fault code. It is a specific string of numbers and letters generated by the automobile electronic control unit (ECU) or powertrain control module when it detects a fault in the vehicle system.

[0080] 2) The evaluation cycle is the time it takes to monitor for the same fault code after a vehicle fault occurs and generates one. For example, if vehicle A generates and reports fault code D9021 to the cloud service, the system will monitor the vehicle for five minutes to detect any subsequent reports of the same fault code. This five-minute period is the evaluation cycle.

[0081] 3) Cumulative number: This refers to the number of times a specific fault code must be reported for the same vehicle within the evaluation period to trigger a custom alert. For example, if vehicle A generates and reports fault code D9021 to the cloud service, the system will observe the vehicle for 5 minutes to detect whether the same fault code is reported 10 times within 5 minutes. The 10 times here refers to the cumulative number of times.

[0082] 4) Maintenance recommendations refer to the corresponding measures that should be taken after the event occurs, such as restarting the power, adding refrigerant, replacing the air conditioning filter, etc.

[0083] 5) Fault Level. In the embodiment of the present application, a set of fault level classification methods are formulated, namely Level 1, Level 2, Level 3, and Level 4, with Level 1 being the highest level. Each fault code corresponds to a fault level. When the fault code is diagnosed, the corresponding fault level can be identified. Different levels correspond to different response measures. For example, the occurrence of a Level 1 fault represents the most serious level, requiring immediate notification to the vehicle owner and automatic notification to the backend customer service and operation and maintenance personnel for follow-up, as shown in Table 3.

[0084] 6) Fault prompt mode: Different prompt modes correspond to different handling measures, as shown in Table 4.

[0085] For example, in fault tree example 1, the bottom event "charging circuit resistance is too large" under power battery depletion has a fault code of P0A1A, an evaluation period of 2 minutes, a cumulative number of 5 times, a fault level of 2, and fault prompts in the form of vehicle dashboard prompts and mobile phone text message prompts.

[0086] Step 402: Create or update a full diagnostic package;

[0087] Step 403: The cloud backend creates a remote push task;

[0088] Step 404: whether an instruction for manual shelving is received, if not, proceed to step 405; if yes, proceed to step 407;

[0089] Step 405, waiting for the timing time;

[0090] Step 406, determine whether the shelf time has arrived, if yes, proceed to step 407, if not, continue to step 405;

[0091] Step 407, put the product on the shelf at a scheduled time and complete the shelf placement;

[0092] Step 408: The remote push task is completed.

[0093] Through the above steps 402 to 408, a remote push task is created in the cloud service background, the full diagnostic package and the target model (or target vehicle) are bound, and then the full diagnostic package is pushed to the vehicle through manual triggering, timed triggering, etc. After the vehicle is connected to the network, it receives the full diagnostic package and updates the fault tree in the full diagnostic package to the local computer as a fault analysis strategy on the vehicle side.

[0094] It should be noted that in the embodiment of this application, a full diagnostic package is added to avoid pushing empty data, and only one full diagnostic package can be added to each task. In addition, you can choose to manually put it on the shelf or to set the created remote push task to the effective state. Manual putting means that after creating the task, the operator manually clicks the put button to set the task to take effect; scheduled putting means setting a putting time when creating the task, and the system automatically sets it to take effect when the putting time is reached.

[0095] Step 409: The cloud backend sends a remote push task;

[0096] Step 410: The vehicle reports the local diagnostic package version;

[0097] Step 411: The cloud compares the vehicle version number with the cloud version number.

[0098] Step 412, determine whether the version number is different, if yes, proceed to step 413, if not, the process ends;

[0099] Step 413: Push the diagnostic package to the vehicle.

[0100] After the remote push task is created, proceeding from step 409 to step 413, the following process continues: the cloud backend generates a compressed message for each push task and stores it in a database for backup. Once the push task is triggered, the cloud pushes the compressed message to the vehicle via the MQTT protocol. After the vehicle is powered on and connected to the network, it receives the compressed message and reports the reception status. The vehicle decompresses the compressed message, reads the contents, and updates the local onboard diagnostic system, updating the full diagnostic package. When a fault occurs, the vehicle uses the latest diagnostic package for fault analysis.

[0101] As can be seen, in the embodiment of the present application, you can choose to push manually or you can choose to push regularly to push the rules to the specified vehicles. The specified vehicles can be all vehicles under a certain model, or one or more specified vehicles.

[0102] In a specific example, when the vehicle base is large, if many vehicles are powered on and connected to the Internet at the same time or in the same time period, the cloud server needs to push remote push tasks to these vehicles. There may be high concurrency and the risk of large-scale push failure. In an embodiment of the present application, after the cloud creates a remote push task, it will not actively send it in batches to all vehicles applicable to the task, but will adopt the following mechanism: after each vehicle is powered on and connected to the Internet, the vehicle side will actively report a login message, and the diagnostic package version number is used in the message to identify which version of the diagnostic package the vehicle is currently using; after the cloud receives the diagnostic package version number, it will compare it with the current latest remote push task version number. If there is a difference, it is determined that the vehicle needs to be pushed. If there is no difference, it is determined that the diagnostic package of the vehicle is the latest version and does not need to be pushed.

[0103] By determining the work advance in the above way, the pressure of batch push can be reduced and the efficiency of push can be improved.

[0104] Step 414: The vehicle receives and feeds back the result;

[0105] Step 415: The vehicle updates the full diagnostic package.

[0106] Step 416: Push the results of the cloud backend statistics task;

[0107] After the cloud backend receives the vehicle-side reception status feedback through the above steps 414 to 416, it will be counted in the database and reflected in the details of the corresponding push task, and the target vehicles will be classified according to push success and push failure. Then, the vehicle list can be viewed to check the failure cause, and after analysis, it can be decided to push again or perform other operations.

[0108] Furthermore, in the embodiment of the present application, two indicators need to be paid attention to when collecting statistics on push results:

[0109] 1) Arrival rate, which is the percentage of remote push tasks successfully sent to the vehicle side. Arrival rate = number of vehicles that successfully received remote push tasks / total number of vehicles that received remote push tasks.

[0110] When the remote push task is sent from the cloud server to the vehicle, the vehicle immediately replies with a response message. When the cloud receives the response message, it determines that the vehicle has received the remote push task and increases the number of vehicles that have successfully received the remote push task by one.

[0111] 2) Productivity, that is, the proportion of remote push tasks that are effective on the vehicle side, that is, productivity = number of vehicles for which remote push tasks have been effective on the vehicle side / number of vehicles that successfully received remote push tasks.

[0112] To avoid impacting vehicles in motion or undergoing diagnostics, a remote push task will not take effect immediately after it is received by the vehicle. It will only automatically update the remote push task when the vehicle is parked and has no diagnostic tasks. This will overwrite the vehicle's previous version and replace it with the new version as the currently active diagnostic policy. After the new diagnostic policy takes effect on the vehicle, the vehicle will include the current diagnostic policy version in the login message it sends the next time it is powered on and connected to the network. If the vehicle's diagnostic policy version received by the cloud matches the cloud service configuration, the remote push task is considered to have taken effect on the vehicle.

[0113] Corresponding to the above Figure 1 , the embodiment of the present application provides a cloud server, such as Figure 5 As shown, the cloud server includes:

[0114] The first processing module 502 is configured to maintain a diagnostic package consisting of a fault tree set (FTSE) and establish a push task. Each fault tree in the FTSE represents various vehicle fault types and the logical relationships between them using a multi-branch tree structure. The push task is bound to the version number of the diagnostic package and the target vehicle to be pushed.

[0115] The second processing module 504 is used to receive the diagnostic package version number reported by the target vehicle and compare the version number bound to the push task with the version number reported by the target vehicle;

[0116] The third processing module 506 is used to send the diagnostic package to the target vehicle based on the push task to update the local diagnostic package for vehicle fault diagnosis when the version number bound to the push task is inconsistent with the version number reported by the target vehicle.

[0117] In an optional implementation manner of an embodiment of the present application, the first processing module 502 in the embodiment of the present application may further include: a division unit, used to divide the fault events corresponding to the vehicle into top events, intermediate events and bottom events based on the logical relationship between the faults, wherein the top event represents the final result of the fault event, the intermediate event represents the event that causes the top event to occur, and the bottom event represents the basic event of the fault event; the intermediate event can be decomposed into one or more intermediate events or decomposed into one or more bottom events; the first processing unit, used to construct a fault tree based on the logical relationship and the multi-branch tree structure, and construct a fault tree set based on the fault tree to obtain a diagnostic package, wherein the fault tree set includes multiple fault trees of the same type of fault.

[0118] In an optional implementation manner of an embodiment of the present application, the division unit in the embodiment of the present application may further include: a determination subunit, used to determine the type of fault event according to the diagnostic domain, wherein different diagnostic domains represent different areas of the automotive system to which the fault belongs; and a division subunit, used to divide the fault events corresponding to the same diagnostic domain into top events, intermediate events and bottom events based on the logical relationship between the faults.

[0119] In an optional implementation manner of an embodiment of the present application, the first processing unit in the embodiment of the present application may further include: a setting subunit, used to set the top event, intermediate event and bottom event in the fault event on the nodes of the multi-branch tree structure based on a logical relationship, to obtain a fault tree corresponding to the fault event; a first processing subunit, used to set a unique identifier and a usage scenario of the fault tree for each fault event corresponding to the fault tree, and set the fault tree corresponding to the same diagnostic domain as a fault tree set; a construction subunit, used to construct a diagnostic package based on multiple fault tree sets corresponding to multiple different diagnostic domains.

[0120] In an optional implementation manner of an embodiment of the present application, the third processing module in the embodiment of the present application may further include: a first receiving unit, used to receive the fault code of the bottom event reported by the vehicle, wherein each bottom event corresponds to a fault code; a detection unit, used to detect the number of reports of the fault code within the fault assessment cycle; a prompt unit, used to prompt the fault and maintenance suggestions of the bottom event through one or more prompt methods based on the fault level corresponding to the bottom event after the number of reports exceeds a preset threshold, wherein the prompt methods include: vehicle-side display, terminal prompt, and cloud server prompt.

[0121] In an optional implementation manner of an embodiment of the present application, the second processing module in the embodiment of the present application may further include: a second receiving unit, used to receive the diagnostic package version number reported by one or more target vehicles of the same model; or, to receive the diagnostic package version number reported by one or more target vehicles specified by the cloud server.

[0122] In an optional implementation manner of an embodiment of the present application, the third processing module in the embodiment of the present application may further include: a backup unit, used to compress the push task into a corresponding compressed message and store it in a database for backup; a push unit, used to push the compressed message to one or more target vehicles of the same model through a preset communication protocol when the push task takes effect, or to one or more target vehicles specified by the cloud server.

[0123] like Figure 6As shown, the embodiment of the present application provides a server, including a processor 611, a communication interface 612, a memory 613 and a communication bus 614, wherein the processor 611, the communication interface 612, and the memory 613 communicate with each other through the communication bus 614.

[0124] Memory 613, for storing computer programs;

[0125] In one embodiment of the present application, the processor 611 is used to execute the program stored in the memory 613 to implement the vehicle fault processing method provided by any of the aforementioned method embodiments, and its role is similar and will not be repeated here.

[0126] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the vehicle fault processing method provided in any of the aforementioned method embodiments are implemented.

[0127] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0128] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiment.

[0129] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "comprise", "include", "contain" and "have" are inclusive and therefore specify the presence of stated features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring them to be performed in the specific order described or illustrated, unless the order of execution is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0130] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is intended to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for handling vehicle failure, characterized in that: Applied to a cloud server, the method includes: Maintaining a diagnostic package consisting of a fault tree set and establishing a push task, wherein each fault tree in the fault tree set represents various types of vehicle faults and the logical relationships between the various fault types using a multi-branch tree structure. The push task is bound to the version number of the diagnostic package and the target vehicle to be pushed; Receive the diagnostic package version number reported by the target vehicle, and compare the version number bound to the push task with the version number reported by the target vehicle; If the version number bound to the push task is inconsistent with the version number reported by the target vehicle, the diagnostic package is sent to the target vehicle based on the push task to update the local diagnostic package for vehicle fault diagnosis; Wherein, maintaining a diagnostic package consisting of a fault tree set includes: dividing the fault events corresponding to the vehicle into top events, intermediate events, and bottom events based on the logical relationship between the faults, wherein the top event represents the final result of the fault event, the intermediate event represents the event that causes the top event to occur, and the bottom event represents the basic event of the fault event; the intermediate event can be decomposed into one or more intermediate events or one or more bottom events; constructing the fault tree based on the logical relationship and the multi-branch tree structure, and constructing the fault tree set based on the fault tree to obtain the diagnostic package, wherein the fault tree set includes multiple fault trees of the same type of fault; Wherein, the fault tree is constructed based on the logical relationship and the multi-branch tree structure, and the fault tree set is constructed based on the fault tree to obtain the diagnostic package, including: based on the logical relationship, setting the top event, the intermediate event and the bottom event in the fault event on the nodes of the multi-branch tree structure to obtain the fault tree corresponding to the fault event; setting a unique identifier and a usage scenario of the fault tree for each fault event, and setting the fault tree corresponding to the same diagnostic domain as a fault tree set; wherein the usage scenario characterizes the scenario in which the corresponding fault tree is used for fault diagnosis and analysis, and the same fault tree is applicable to multiple usage scenarios; constructing the diagnostic package based on multiple fault tree sets corresponding to multiple different diagnostic domains.

2. The method according to claim 1, characterized in that Based on the logical relationship between faults, the fault events corresponding to the vehicle are divided into top events, intermediate events and bottom events, including: determining the type of the fault event according to a diagnostic domain, wherein different diagnostic domains represent different areas of the automotive system to which the fault belongs; Based on the logical relationship between faults, fault events corresponding to the same diagnosis domain are divided into top events, middle events and bottom events.

3. The method according to claim 1, characterized in that Vehicle fault diagnosis includes: Receiving a fault code of the bottom event reported by the vehicle, wherein each bottom event corresponds to a fault code; Detecting the number of reports of the fault code within a fault assessment period; After the number of reports exceeds a preset threshold, based on the fault level corresponding to the bottom event, the fault and maintenance suggestions of the bottom event are prompted through one or more prompting methods, wherein the prompting methods include: vehicle-side display, terminal prompt, and cloud server prompt.

4. The method according to claim 1, wherein Receiving the diagnostic package version number reported by the target vehicle, including: Receive the diagnostic package version numbers reported by one or more target vehicles of the same model; or receive the diagnostic package version numbers reported by one or more target vehicles specified by the cloud server.

5. The method according to claim 4, characterized in that Sending the diagnostic package to the target vehicle based on the push task for updating the local diagnostic package includes: Compressing the push task into a corresponding compressed message and storing it in a database for backup; When the push task takes effect, the compressed message is pushed to one or more target vehicles of the same model through a preset communication protocol, or is pushed to one or more target vehicles specified by the cloud server.

6. A cloud server, characterized in that: include: A first processing module is configured to maintain a diagnostic package consisting of a fault tree set (FTSE) and establish a push task, wherein each fault tree in the FTSE represents various types of vehicle faults and the logical relationships between the various fault types using a multi-branch tree structure. The push task is bound to the version number of the diagnostic package and the target vehicle to be pushed; A second processing module is configured to receive the diagnostic package version number reported by the target vehicle and compare the version number bound to the push task with the version number reported by the target vehicle; a third processing module, configured to, if the version number bound to the push task is inconsistent with the version number reported by the target vehicle, send the diagnostic package to the target vehicle based on the push task to update the local diagnostic package for vehicle fault diagnosis; The first processing module includes: a division unit for dividing the fault events corresponding to the vehicle into top events, intermediate events, and bottom events based on the logical relationship between the faults, wherein the top event represents the final result of the fault event, the intermediate event represents the event that leads to the occurrence of the top event, and the bottom event represents the basic event of the fault event; the intermediate event can be decomposed into one or more intermediate events or one or more bottom events; the first processing unit is used to construct a fault tree based on the logical relationship and the multi-branch tree structure, and to construct a fault tree set based on the fault tree to obtain a diagnostic package, wherein the fault tree set includes multiple fault trees of the same type of fault; The first processing unit includes: a setting subunit, which is used to set the top event, intermediate event and bottom event in the fault event on the nodes of the multi-branch tree structure based on the logical relationship to obtain the fault tree corresponding to the fault event; a first processing subunit, which is used to set a unique identifier and a usage scenario of the fault tree for each fault tree corresponding to the fault event, and set the fault trees corresponding to the same diagnostic domain as a fault tree set; wherein the usage scenario represents the scenario in which the corresponding fault tree performs fault diagnosis and analysis, and the same fault tree is applicable to multiple usage scenarios; a construction subunit, which is used to construct a diagnostic package based on multiple fault tree sets corresponding to multiple different diagnostic domains.

7. A server comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor coupled to the at least one bus; At least one memory connected to the at least one bus, wherein the processor is configured to execute the vehicle fault processing method according to any one of claims 1 to 5. 8 . A computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the vehicle fault processing method according to any one of claims 1 to 5.

Images