Vehicle fault processing method, cloud server, server and storage medium

Abstract

The invention relates to a vehicle fault processing method, a cloud server, a server and a storage medium, and the method comprises the steps: maintaining a diagnosis package composed of a fault tree set, and building a push task, each fault tree representation in the fault tree set represents various fault types of the vehicle and a logic relationship among the fault types by a multi-way tree structure, and the pushing task is bound with a version number of the diagnosis packet and a target vehicle to be pushed; receiving a diagnosis packet version number reported by the target vehicle, and comparing the version number bound with the push task with the version number reported by the target vehicle; and under the condition that the version number bound with the push task is inconsistent with the version number reported by the target vehicle, sending the diagnosis packet to the target vehicle based on the push task to update the local diagnosis packet so as to perform vehicle fault judgment. Through the method and the device, the problem that in the prior art, a vehicle fault analysis strategy cannot be updated, so that more scenes cannot be covered, and the user experience is relatively poor 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 and a cloud server, server and storage medium. Background Art

[0002] At present, smart cars are equipped with various sensors and monitoring devices that can monitor various parameters and status of the vehicle in real time. When the monitoring device detects an abnormality or fault, it will perform fault diagnosis according to the local diagnostic system and program. Once the system completes the fault diagnosis, it will display the relevant warning information on the central control screen and instrument panel to remind the driver to pay attention and take relevant measures. The diagnostic strategy of the on-board diagnostic system is usually designed and developed by the automobile manufacturer and is a software program stored in the on-board computer. The diagnostic strategy update is usually part of the car software upgrade and is upgraded together with the car software update. However, in the prior art, the vehicle-side fault analysis strategy cannot be updated. Once the vehicle diagnostic system leaves the factory, it cannot be updated. The old 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 resulting in a poor user experience.

[0004] In the first aspect, the present application provides a method for handling vehicle failures, 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; when the version number bound to the push task is inconsistent with the version number reported by the target vehicle, sending the diagnostic package 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 composed of a fault tree set, and establish a push task, wherein each fault tree in the fault tree set represents various fault types 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 make a 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 failure 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, through which not only the logical relationship between faults can be clearly obtained, but also efficient updates can be performed according to the tree interface when the fault event needs 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 be handled in time when a vehicle fault occurs, 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 drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0011] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and 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 with power battery failure as the structural diagram provided in an embodiment of the present application;

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

[0015] Figure 4 A flow chart of a vehicle fault diagnosis method based on a remote push strategy and a fault tree provided in an embodiment of the present application;

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

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

[0018] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0019] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings 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 resulting in 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, 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 fault types 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;

[0022] The multi-branch tree structure in the embodiment of the present application may 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 of the power battery being low, there may be two reasons for the low power of the power battery: 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 example below. Figure 2 As shown, 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 small charging current, and insufficient charging time are child nodes.

[0023] Step 102, 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;

[0024] It can be seen that a local diagnostic package is preset in the vehicle, 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 local diagnostic package version number of the vehicle is inconsistent with the diagnostic package version number of the cloud server, it indicates that the local diagnostic package of the vehicle needs to be updated to adapt to more scenario requirements.

[0025] Step 103 , when 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] It can be known from the above steps 101 to 103 that in the embodiment of the present application, the vehicle fault events can be maintained through a multi-branch tree structure, through which not only the logical relationship between faults can 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 be handled in time when a vehicle fault occurs, thereby improving the safety of vehicle use and also improving the user's driving experience.

[0027] In the embodiment of the present application, the fault tree of the vehicle is maintained by 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 composed of the fault tree set involved in step 102 in the embodiment of the present application may 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, wherein 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 decomposed into 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 indicates the fault 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 power failure is the top event, battery system failure, charging system failure, battery overheating, charger failure, and insufficient battery charging are intermediate events; battery aging failure, charging circuit resistance is too large, charger output is low, charging interface is dirty, charging current is too small, and charging time is insufficient are bottom events. By dividing the fault events and combining them with the display of the multi-branch tree structure, the logical relationship between each fault can be clearly obtained. If the fault tree needs to be updated, it is also convenient and quick. For example, if an intermediate event needs to be added to the top event of power battery power failure, only one parent node needs to be added.

[0031] In an optional implementation manner of the embodiment of the present application, the method of dividing 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 the above step 11 may further include:

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

[0033] Step 22: based on the logical relationship between faults, the 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 domain may include the power domain, chassis domain, body domain, cockpit domain, self-driving domain, etc. Each fault tree will define which domain it applies to. When a fault occurs in a diagnostic domain, the fault tree defined under the diagnostic domain will be used first, so that the fault can be located quickly. In the specific example, the diagnostic domain classification shown in Table 1 is introduced 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-branch tree structure. Therefore, for the above step 12 involving constructing a fault tree based on the logical relationship and the multi-branch tree structure, and constructing a fault tree set based on the fault tree, the method of obtaining 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, setting a unique identifier and a usage scenario of the fault tree for each fault tree corresponding to the fault event, and setting 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 figure. Figure 3 shown.

[0043] In addition, in the embodiment of the present application, 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 to be in this scenario, the fault tree is available and can be used for fault diagnosis and analysis. In this regard, in the specific example, the usage scenarios can be: when the vehicle is parked and powered off, when the vehicle is parked and powered on, during 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 scenarios associated with the power battery power failure in the example can be the parking power-on state and the driving process. Therefore, the fault tree can be used for fault analysis in these two states.

[0047] In the embodiment of the present application, the fault tree is maintained and the diagnostic package of the vehicle is updated so that the vehicle can adapt to more fault scenarios, that is, prompts or maintenance suggestions can be given in time after a fault occurs. Based on this, the method of determining the vehicle fault involved in the above step 103 can further include:

[0048] Step 41, receiving the fault code of the bottom event reported by the 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 cycle;

[0051] For example, if a vehicle A generates and reports a 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 within 5 minutes. The 5 minutes here is the evaluation period. If a vehicle A generates and reports a 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 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 the specific example, the fault level can be divided into 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, a level 1 fault represents the highest level of severity, requiring immediate notification to the owner, and automatically notifying the backend customer service and operation 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 found; it is generally used in the driving of the vehicle, the parking and the power-on situation, intuitively showing the vehicle problem, and prompting 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 tracking and troubleshooting by operators; 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 times, the fault level is level 2, and the fault prompt method is the vehicle-side instrument panel prompt and the 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 total within 2 minutes, it is judged that the bottom event occurs and the upper intermediate event "battery overheat" of the bottom event occurs; because the "battery overheat" domain "battery aging fault" is an "or" relationship, the upper intermediate event "battery system failure" occurs, which means that the "battery system failure" occurs; similarly, if the "power battery is low" occurs, the battery system failure is prompted through the vehicle-side instrument panel; the mobile phone text message prompts the user that "the vehicle-side fault monitoring system detects that your car has a battery system failure. 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 the above step 103 may further include:

[0064] Step 51, compressing the push task into a corresponding compressed message and storing it in a database for backup;

[0065] Step 52, 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.

[0066] In this regard, in the embodiment of the present application, you can choose to manually put it on the shelf or to choose the timed putting it on the shelf to set the created remote push task to the effective state. Manual putting on the shelf means that after creating the task, the operator manually clicks the put on shelf button to set the task to take effect; timed putting on the shelf means setting a putting on shelf time when creating the task, and the system automatically sets it to take effect when the putting on shelf time is reached.

[0067] The present application is explained below in conjunction with the specific implementation of the embodiment of the present application. The specific implementation provides a vehicle fault diagnosis method based on a remote push strategy and a 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 out the root cause of the system failure by gradually decomposing the fault events.

[0070] Fault tree maintenance is mainly divided into two parts, one is the maintenance of the tree structure, and the other is the maintenance of the bottom events. Maintaining the tree structure is mainly to indicate the various causes of the top event, that is, to list the various logical relationships between the top event and the intermediate event and the bottom event. Maintaining the bottom event is mainly to define the basic attributes of the bottom event, including fault code, evaluation cycle, cumulative number of times, maintenance suggestions, fault level, fault prompt method, etc. These basic attributes are used to match whether a related fault has occurred and to provide the next step prompt.

[0071] like Figure 2 As shown in the figure, "power battery low" is the top event, and the rectangles on the right are middle events, such as "battery system failure", "battery overheating", etc.; the ovals at the end are bottom events, such as "battery aging failure", and "DTCP0563" is the fault code maintained by the bottom event; when the fault code P0563 appears in the vehicle message, it means that the 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 really occurred. Figure 2 It can be seen that the fault tree "power battery low power" contains one top event, five middle 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 the present 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 the 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-the power battery is low in power and is numbered faultTree00001, which 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 to be in this scenario, the fault tree is available for fault diagnosis and analysis.

[0077] In the embodiment of the present application, as shown in Table 3, there are five usage scenarios: when the vehicle is parked and powered off, when the vehicle is parked and powered on, during driving, in charging state, and in maintenance mode. Among them, the same fault tree can include multiple usage scenarios at the same time. For example, the usage scenarios associated with fault tree example 1-power battery power failure are the parking power-on state and the driving state. In these two states, the fault tree can be used for fault analysis.

[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, usually called the automobile fault code. It is a string of specific numbers and letters generated by the automobile electronic control unit (ECU) or powertrain control module when a fault is detected in the vehicle system.

[0080] 2) Evaluation cycle refers to the time to monitor the same fault code of the vehicle after the vehicle fails and generates a fault code. For example, if a 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 within 5 minutes. The 5 minutes here is the evaluation cycle.

[0081] 3) Cumulative number refers to the number of times the specified fault code of the same vehicle must be reported cumulatively within the evaluation period to trigger a custom alarm. For example, if a 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 suggestions refer to what corresponding measures 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, where level 1 is 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 highest level of severity, and the car owner must be notified immediately, and the backend customer service and operation and maintenance personnel must be automatically notified 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, 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 times, the fault level is level 2, and the fault prompt method is the vehicle-side instrument panel prompt and the mobile phone text message prompt.

[0086] Step 402, creating or updating 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, execute step 405, if yes, execute 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, timed shelf placement, and completed 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 power network, it receives the full diagnostic package and updates the fault tree in the full diagnostic package to the local as a fault analysis strategy on the vehicle side.

[0094] It should be noted that the full diagnostic package added in the embodiment of the present application is to avoid pushing empty data, and each task can only add one full diagnostic package. In addition, you can choose to manually put it on the shelf or to choose the timed putting it on the shelf to set the created remote push task to the effective state. Manual putting on the shelf means that after creating the task, the operator manually clicks the put on shelf button to set the task to take effect; timed putting on the shelf means setting a putting on shelf time when creating the task, and the system automatically sets it to take effect after the putting on shelf 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-side version number with the cloud-side 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 end;

[0100] After the remote push task is created through 409 to step 413, the following process is continued: the cloud backend generates a compressed message for each push task, stores it in the database, and backs it up. After the push task is triggered, the cloud pushes the compressed message to the vehicle through the MQTT protocol. After the vehicle is powered on and connected to the network, it receives the compressed message and feedbacks the receiving status. The vehicle decompresses the compressed message, reads the content, updates it to the local on-board diagnostic system, and updates the full diagnostic package. When a fault occurs, the vehicle uses the latest diagnostic package for fault analysis.

[0101] It can be seen that in the embodiment of the present application, manual push or timed push can be selected 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 the 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 the 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 adopts the following mechanism: After each vehicle is powered on and connected to the Internet, the vehicle side actively reports a login message, and the diagnostic package version number is used in the message to identify which version of the diagnostic package is currently used by the vehicle; after the cloud receives the diagnostic package version number, it is compared 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 end updates the full diagnostic package;

[0106] Step 416, the cloud backend statistics task push results;

[0107] Through the above steps 414 to 416, after the cloud backend receives the reception status feedback from the vehicle, 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 cause of the failure, 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 counting the push results:

[0109] 1) Arrival rate, that is, the proportion of remote push tasks that are successfully sent to the vehicle side, that is, arrival rate = number of vehicles that successfully receive remote push tasks / total number of vehicles pushed by 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 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 has been effective on the vehicle side / number of vehicles that have successfully received remote push tasks.

[0112] To avoid affecting vehicles that are driving or performing diagnostics, the remote push task will not take effect immediately after the vehicle receives it. It will automatically update the remote push task when it is parked and there is no diagnostic task, overwriting the previous version on the vehicle and using the new version as the currently effective diagnostic strategy. After the new diagnostic strategy takes effect on the vehicle, the current diagnostic strategy version will be sent in the login message sent after the next power-on and networking; when the diagnostic strategy version received by the cloud is the same as the cloud service configuration, it is determined that the remote push task has taken effect on the vehicle.

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

[0114] The first processing module 502 is used to maintain a diagnostic package composed of a fault tree set and establish a push task, wherein each fault tree in the fault tree set represents various fault types 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;

[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 the 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, which is used to set the top event, the middle event and the bottom event in the fault event on the nodes of the multi-branch tree structure based on the logical relationship, and obtain a 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 tree corresponding to the same diagnostic domain as a fault tree set; a construction subunit, which is 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 the 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 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 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, an 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, used 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 failure processing method provided in any of the aforementioned method embodiments are implemented.

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

[0128] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for 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 some parts of the embodiments.

[0129] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments 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 "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence 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 interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0130] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be 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 will not be limited to the embodiments shown herein, but rather to 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 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; When 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.

2. The method according to claim 1, characterized in that Maintain a diagnostic package consisting of a collection of fault trees, including: 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, wherein the top event represents the final result of the fault event, the intermediate event represents the event that causes 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 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 diagnosis package, wherein the fault tree set includes multiple fault trees of the same type of fault.

3. The method according to claim 2, 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: Determine the type of the fault event according to the diagnosis domain, wherein different diagnosis domains represent different automotive system fields 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.

4. The method according to claim 2, characterized in that: 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, and the diagnosis package is obtained, including: Based on the logical relationship, the top event, the intermediate 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; Setting a unique identifier and a usage scenario of the fault tree for each fault tree corresponding to a fault event, and setting the fault trees corresponding to the same diagnostic domain as a fault tree set; The diagnostic package is constructed based on a plurality of fault tree sets corresponding to a plurality of different diagnostic domains.

5. The method according to claim 2, 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 cycle; 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.

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

7. The method according to claim 6, 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.

8. A cloud server, characterized in that: include: A first processing module is 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 fault types 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 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; The third processing module 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 judgment when the version number bound to the push task is inconsistent with the version number reported by the target vehicle.

9. 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 7.

10. 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 7.

Images