Vehicle abnormal event processing method and device and electronic equipment

Abstract

The invention provides a vehicle abnormal event processing method and device and electronic equipment, and the method comprises the steps: obtaining the state data of a vehicle, judging whether an abnormal event exists or not based on the state data, matching the abnormal event with a preset fault tree to obtain an abnormal path if the abnormal event exists, and determining an abnormal processing strategy based on the abnormal path, by means of the mode, fault detection does not need to be conducted through a local detector, the corresponding exception handling strategy is determined through the data reported by the vehicle, real-time data processing is supported, the real-time performance of exception discovery can be effectively improved, the tedious process of offline detection is avoided, the detection efficiency is improved, and the detection cost is reduced. When the abnormal event is the event related to the vehicle machine network communication, the abnormal event can be quickly identified and an abnormal processing strategy can be provided through the method.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, apparatus and electronic device for handling abnormal vehicle events. Background Technology

[0002] In vehicle-to-everything (V2X) communication systems, network anomalies can be caused by multiple factors. Detection methods primarily employ local diagnostic tools, log analysis, liveness detection, and fault code alerts. While these methods can detect network anomalies to some extent, they cannot identify problems promptly and effectively. They still rely on offline local testing after an anomaly occurs, resulting in poor real-time performance and a cumbersome testing process. Summary of the Invention

[0003] This application provides a method, apparatus, and electronic device for handling abnormal vehicle events, in order to solve the technical problems of poor real-time performance and cumbersome detection process in related technologies for detecting abnormal vehicle-to-everything (V2X) communication networks.

[0004] This application provides a method for handling abnormal vehicle events, the method comprising: acquiring vehicle status data; if an abnormal event is determined based on the status data, matching the abnormal event with a preset fault tree to obtain an abnormal path; and determining an abnormal handling strategy based on the abnormal path.

[0005] In one embodiment of this application, determining an abnormal event based on the status data includes: if the status data satisfies a preset abnormal event rule, triggering the generation of an abnormal event corresponding to the preset abnormal event rule to obtain the abnormal event of the vehicle, wherein a preset abnormal event rule is configured in advance for each bottom event of the preset fault tree, and the preset abnormal event rule includes at least one or more of the following: data source type, event target component, data duration, matching field, and trigger count, and the status data includes network fault data and / or network log data.

[0006] In one embodiment of this application, the method for creating the preset fault tree includes: obtaining a preset top event; determining the direct cause of the top event to obtain one or more intermediate events; repeatedly executing the step of determining the direct cause of the intermediate events until the obtained direct cause is a bottom event; if it is determined that the bottom event of all intermediate events is obtained, generating the preset fault tree based on all bottom events, intermediate events and the top event.

[0007] In one embodiment of this application, matching the abnormal event with a preset fault tree to obtain an abnormal path includes: matching the abnormal event with the bottom events of the preset fault tree, the preset fault tree including a top event, multiple intermediate events and multiple bottom events, the top event including a network fault; if the abnormal event matches a bottom event, the bottom event is taken as the target bottom event; sequentially obtaining the triggering conditions of the upper-level events of the current event in the preset fault tree, and determining the triggering state of the upper-level events according to the triggering conditions, and if the triggering state is triggered, the upper-level event is taken as the new current event, until the upper-level event is a top event or the triggering state changes to not triggered, wherein the initial current event is the target bottom event; generating the abnormal path based on the target bottom event and all upper-level events with the triggering state being triggered.

[0008] In one embodiment of this application, matching the abnormal event with a preset fault tree to obtain an abnormal path includes: if the number of abnormal events is at least two, matching each abnormal event with a base event of the preset fault tree, the preset fault tree including a top event, multiple intermediate events and multiple base events, the top event including a network fault; if the abnormal event matches a base event, the base event is taken as the target base event of the abnormal event; sequentially obtaining the triggering conditions of all current events in the preset fault tree for upper-level events, and determining the triggering state of the upper-level events according to the triggering conditions, and if the triggering state is triggered, taking the upper-level event as a new current event, until the upper-level event is a top event or the triggering state changes to not triggered, wherein the initial all current events are all the target base events; generating the abnormal path based on all the target base events and all upper-level events with the triggering state triggered.

[0009] In one embodiment of this application, the method further includes: if the upper-level event corresponding to the change of the triggering state to non-triggering is a top event, determining the path state of the abnormal path as a complete path, determining the root cause of the abnormal path based on the abnormal path, and then determining the exception handling strategy; and / or, if the upper-level event corresponding to the change of the triggering state to non-triggering is an intermediate event, determining the path state of the abnormal path as a partial path, and performing one or more of the following steps: generating fault tree update data and fault tree update prompts based on the partial path to prompt the update of the preset fault tree; determining the root cause of the abnormal path based on the partial path, and then determining the exception handling strategy; generating an after-sales prompt notification based on the exception handling strategy and sending it to the after-sales terminal; ignoring the partial path and ending the process.

[0010] In one embodiment of this application, determining an anomaly handling strategy based on the anomaly path includes: determining the root cause of the anomaly path based on the anomaly path; and determining the anomaly handling strategy based on the root cause of the anomaly path.

[0011] In one embodiment of this application, after determining the exception handling strategy based on the exception path, the method further includes: determining a user prompt notification and / or an after-sales prompt notification according to the exception handling strategy; sending the user prompt notification to the user terminal; and sending the after-sales prompt notification to the after-sales terminal.

[0012] This application embodiment also provides a vehicle abnormal event processing device, the vehicle abnormal event processing device comprising: an acquisition module, used to acquire vehicle status data; a matching module, used to match the abnormal event with a preset fault tree to obtain an abnormal path if an abnormal event is determined based on the status data; and a determination module, used to determine an abnormal handling strategy based on the abnormal path.

[0013] This application also provides an electronic device, including: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the steps of the method described in any of the above embodiments.

[0014] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0015] The beneficial effects of this application are as follows: The vehicle abnormal event handling method, device, and electronic device proposed in this application obtain vehicle status data, determine whether there is an abnormal event based on the status data, and if there is an abnormal event, match the abnormal event with a preset fault tree to obtain an abnormal path, and determine an abnormal handling strategy based on the abnormal path. In this way, it is not necessary to perform fault detection through a local detector, but to determine the corresponding abnormal handling strategy through the data reported by the vehicle. It supports real-time data processing, which can effectively improve the real-time performance of anomaly detection, avoid the cumbersome process of offline detection, and improve detection efficiency. When the abnormal event is related to vehicle network communication, this method can quickly identify the anomaly and provide an abnormal handling strategy. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] In the attached diagram: Figure 1 This is a schematic diagram illustrating an application scenario of a vehicle abnormal event handling method provided in an embodiment of this application; Figure 2 A schematic flowchart of a vehicle abnormal event handling method provided in an embodiment of this application; Figure 3 A schematic diagram of a preset fault tree provided in one embodiment of this application; Figure 4 A specific flowchart illustrating a vehicle abnormal event handling method provided in an embodiment of this application; Figure 5 A schematic diagram of a vehicle abnormal event handling device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0019] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0020] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0021] It should be noted that the collection and processing of data such as users' natural language commands in this application must strictly comply with the requirements of relevant national laws and regulations in actual application, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0022] In vehicle-to-everything (V2X) communication systems, network anomalies can be caused by multiple factors. Current technologies for detecting network anomalies primarily employ methods such as local diagnostic tools, log analysis, liveness detection, and fault code alarms. The inventors have found that while these technologies can detect network anomalies to some extent, they have significant shortcomings: first, they cannot detect problems promptly and effectively, relying on offline local detection after the anomaly occurs; second, they lack causal relationship modeling, making it difficult to accurately pinpoint the root cause; and third, they lack sensitivity to combined faults, failing to comprehensively analyze complex network anomaly factors. Therefore, the aforementioned methods are not yet effective in solving the problem of V2X network anomalies.

[0023] To address the aforementioned technical problems, this application provides a method for handling vehicle abnormal events. By acquiring vehicle status data, the method determines whether an abnormal event exists based on this data. If an abnormal event exists, it is matched with a preset fault tree to obtain an abnormal path. Based on this abnormal path, an abnormal handling strategy is determined. This method eliminates the need for local diagnostic tools; instead, it determines the corresponding abnormal handling strategy based on data reported by the vehicle. It supports real-time data processing, effectively improving the real-time performance of anomaly detection and avoiding the cumbersome offline testing process, thus improving detection efficiency. When the abnormal event is related to vehicle-to-everything (V2X) network communication, this method can quickly identify the anomaly and provide an abnormal handling strategy. Remote V2X network anomaly detection based on a fault tree improves timeliness, causal modeling, and combined fault analysis, thereby solving the aforementioned technical problems.

[0024] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of a vehicle abnormal event handling method provided in an embodiment of this application. For example... Figure 1 As shown, vehicle 110 communicates with server 120. Vehicle 110 sends status data to server 120. Status data may include fault codes and / or log data. The fault codes may be network communication fault codes, and the log data may be network log data related to network faults. After receiving the status data, server 120 determines whether an abnormal event has occurred based on preset abnormal event rules. If an abnormal event has occurred, it obtains the abnormal path by matching the abnormal event with a preset fault tree, and then determines the abnormal handling strategy through the abnormal path.

[0025] It should be noted that the above scenario is only an example of an application scenario provided by the embodiments of this application. The method can also be applied to other scenarios according to the user's needs. The embodiments of this application do not limit the actual form of various devices, components, etc. included in the scenario. In the specific application of the solution, it can be set according to actual needs. Please see Figure 2 , Figure 2 This is a schematic flowchart illustrating a vehicle abnormal event handling method according to an embodiment of this application, as shown below. Figure 2 As shown, the method includes the following steps: Step S210: Obtain vehicle status data.

[0026] The status data includes, but is not limited to, one or more of fault data (such as fault codes) and log data. When this method is applied to network communication faults, the fault data can be network fault data related to the network communication fault, and the log data can be network log data related to the network communication fault.

[0027] Step S220: If an abnormal event is determined based on the status data, the abnormal event is matched with a preset fault tree to obtain an abnormal path.

[0028] In one embodiment, determining an abnormal event based on state data includes: if the state data satisfies a preset abnormal event rule, triggering the generation of an abnormal event corresponding to the preset abnormal event rule to obtain the abnormal event of the vehicle. In this embodiment, a preset abnormal event rule is configured in advance for each bottom event of a preset fault tree. The preset abnormal event rule includes at least one or more of the following: data source type, event target component, data duration, matching field, and trigger count (cumulative count). The state data includes network fault data and / or network log data.

[0029] The preset exception event rules can also include handling suggestions. When the event is triggered, the subsequent exception handling strategy can be generated by the handling suggestions configured in the preset exception event rules.

[0030] Multiple preset abnormal event rules can be pre-configured, and the corresponding preset abnormal event rules can be configured based on each bottom event of the preset fault tree.

[0031] A sample configuration of preset exception event rules can be found in Table 1.

[0032] Table 1

[0033] The above method enables remote identification of abnormal events based on vehicle-reported status data, offering greater real-time capability, eliminating the need for on-site testing with specialized instruments, and lowering the requirements for anomaly detection.

[0034] In one embodiment, the creation of a preset fault tree includes: obtaining a preset top event; determining the direct cause of the top event to obtain one or more intermediate events; repeatedly executing the step of determining the direct cause of the intermediate events until the obtained direct cause is the bottom event; if it is determined that the bottom events of all intermediate events are obtained, generating a preset fault tree based on all bottom events, intermediate events, and top events. By continuously searching for the direct cause of intermediate events until the root cause of each intermediate event is found (the cause for which no further direct cause can be found), this root cause is taken as the bottom event of this path. Based on the path mining based on this cause, the path of the fault tree is obtained.

[0035] Please see Figure 3 , Figure 3 A schematic diagram of a preset fault tree provided in an embodiment of this application is shown below. Figure 3 As shown, taking the vehicle infotainment system (V2S) network anomaly as an example, the top event is the V2S network anomaly failure. Based on this, the intermediate causes found are CDC (Central Detection and Control Center) issues and TBOX (Tabulation Toll Box) issues. The direct cause found based on the CDC issue is a communication failure between the CDC and TBOX. Then, based on the new intermediate event (communication failure between the CDC and TBOX), the direct causes found are TBOX authentication failure and the CDC wake-up service request network signal being inactive (failed). At this point, the root causes are TBOX authentication failure and the CDC wake-up service request network signal being inactive (failed), which means we have obtained two bottom events. For the TBOX issue, the direct causes found include: excessively high battery voltage, open circuit in the cellular antenna, cellular network issues, SIM card issues, eMMC memory issues, trust loop issues, and Ethernet network failures. These direct issues are used as new intermediate causes to further search for direct causes. For example, if an excessively high battery voltage cannot be found to have a direct cause, it is treated as a bottom event. Figure 3 The fault tree in the example is only one example, and those skilled in the art can create corresponding fault trees as needed based on the above logic.

[0036] In one embodiment, matching an abnormal event with a preset fault tree to obtain an abnormal path includes: matching the abnormal event with the bottom events of the preset fault tree, the preset fault tree including a top event, multiple intermediate events and multiple bottom events, the top event including network faults; if the abnormal event matches a bottom event, the bottom event is taken as the target bottom event; sequentially obtaining the triggering conditions of the upper-level events of the current event in the preset fault tree, and determining the triggering state of the upper-level events according to the triggering conditions, and if the triggering state is triggered, the upper-level event is taken as the new current event, until the upper-level event is the top event or the triggering state changes to not triggered, wherein the initial current event is the target bottom event; generating an abnormal path based on the target bottom event and all upper-level events with the triggering state of triggered.

[0037] If there is only one abnormal event, such as a dialing failure, see [link to relevant documentation]. Figure 3 The system matches dialing failures with base events in a preset fault tree, identifying "dialing failure" as the target base event. The next level up from "dialing failure" is cellular network issues, which are then considered upper-level events. The trigger condition for this upper-level event is the occurrence of any one of the base events: "dialing failure," "network registration failure," "poor network signal strength failure," or "poor network signal quality failure." Figure 3 The "or" condition indicates that the triggering state is triggered. "Cellular network problem" is then taken as the new current event. The parent event of "Cellular network problem" is "TBOX problem," which also has an "or" triggering condition. Therefore, the triggering state remains triggered. "TBOX problem" is then taken as the new current event. The top event, "Vehicle infotainment network anomaly fault tree," is then found, completing the anomaly path search. The resulting anomaly path is: "Vehicle infotainment network anomaly fault tree" - "TBOX problem" - "Cellular network problem" - "Dialing failure."

[0038] In another embodiment, matching abnormal events with a preset fault tree to obtain an abnormal path includes: if the number of abnormal events is at least two, matching each abnormal event with a base event of the preset fault tree, the preset fault tree including a top event, multiple intermediate events and multiple base events, the top event including network faults; if an abnormal event matches a base event, the base event is taken as the target base event of the abnormal event; sequentially obtaining the triggering conditions of all current events in the preset fault tree, and determining the triggering state of the upper-level events according to the triggering conditions, and if the triggering state is triggered, the upper-level event is taken as the new current event, until the upper-level event is a top event or the triggering state changes to not triggered, wherein the initial all current events are all target base events; generating an abnormal path based on all target base events and all upper-level events with a triggering state.

[0039] If there are two abnormal events, such as dialing failure or TBOX authentication failure, please refer to [link / reference]. Figure 3 The system matches dialing failures with base events in a preset fault tree, identifying "dialing failure" as the target base event. The next level up from "dialing failure" is cellular network issues, which are then considered upper-level events. The trigger condition for this upper-level event is the occurrence of any one of the base events: "dialing failure," "network registration failure," "poor network signal strength failure," or "poor network signal quality failure." Figure 3The "OR" condition indicates that the triggering state is triggered. "Cellular network problem" is taken as the new current event. The parent event of "Cellular network problem" is then found to be "TBOX problem," whose triggering condition is also "OR." Therefore, the triggering state remains triggered. "TBOX problem" is taken as the new current event, and the top event "Vehicle network anomaly fault tree" is found. The anomaly path is then searched, resulting in: "Vehicle network anomaly fault tree" - "TBOX problem" - "Cellular network problem" - "Dialing failure." The "TBOX authentication failure" is matched with the bottom event "and TBOX authentication failure," and then "CDC and TBOX communication failure," "CDC problem," and "Vehicle network anomaly fault tree" are found sequentially, resulting in: "Vehicle network anomaly fault tree" - "CDC problem" - "CDC and TBOX communication failure" - "and TBOX authentication failure." For example, in the above example, the abnormal path could be: Sub-path 1: "Vehicle network abnormality fault tree" - "TBOX problem" - "Cellular network problem" - "Dialing failure"; Sub-path 2: "Vehicle network abnormality fault tree" - "CDC problem" - "Communication failure between CDC and TBOX" - "TBOX authentication failed". The abnormal path could also be: "Vehicle network abnormality fault tree" - (("TBOX problem" - "Cellular network problem" - "Dialing failure") & ("CDC problem" - "Communication failure between CDC and TBOX").

[0040] If there are two abnormal events, such as dialing failure or excessively high battery voltage, please refer to [link to relevant documentation]. Figure 3 The system matches dialing failures with base events in a preset fault tree, identifying "dialing failure" as the target base event. The next level up from "dialing failure" is cellular network issues, which are then considered upper-level events. The trigger condition for this upper-level event is the occurrence of any one of the base events: "dialing failure," "network registration failure," "poor network signal strength failure," or "poor network signal quality failure." Figure 3The "OR" condition indicates that the triggering state is triggered. "Cellular network problem" is taken as the new current event. The upper-level event of "Cellular network problem" is then found to be "TBOX problem," whose triggering condition is also "OR." Therefore, the triggering state remains triggered. "TBOX problem" is taken as the new current event, and the top event "Vehicle network anomaly fault tree" is found. This completes the search for the anomaly path, resulting in the path: "Vehicle network anomaly fault tree" - "TBOX problem" - "Cellular network problem" - "Dialing failure." "TBOX authentication failure" matches the bottom event "and TBOX authentication failure," then sequentially finds "CDC and TBOX communication failure," "CDC problem," and "Vehicle network anomaly fault tree." "Battery voltage too high" matches the bottom event "Battery voltage too high," thus finding "TBOX problem" and "Vehicle network anomaly fault tree." The anomaly path can be generated by creating all the found events in the fault tree according to the original hierarchy, or it can be generated separately for each anomaly event, resulting in multiple sub-paths. For example, in the above example, the abnormal path could be: Sub-path 1: "Vehicle network abnormality fault tree" - "TBOX problem" - "Cellular network problem" - "Dialing failure"; Sub-path 2: "Vehicle network abnormality fault tree" - "TBOX problem" - "Battery voltage too high". The abnormal path could also be "Vehicle network abnormality fault tree" - "TBOX problem" - (("Battery voltage too high") & ("Cellular network problem" - "Dialing failure")).

[0041] In one embodiment, the method further includes: if the upper-level event corresponding to the change from triggering to non-triggering is a top event, determining the path state of the abnormal path as a complete path, determining the root cause of the abnormal path based on the abnormal path, and then determining an exception handling strategy. If the abnormal path includes a top event, it indicates that a complete path has been obtained. In this case, it can be considered that this abnormal event may be a frequently occurring exception, and a corresponding exception handling strategy can be obtained based on the processing suggestions of the preset exception event rules of the lower-level event corresponding to this complete path.

[0042] In one embodiment, the method further includes: if the upper-level event corresponding to the change from triggering to non-triggering is an intermediate event, determining the path state of the abnormal path as a partial path, and performing one or more of the following steps: generating fault tree update data and fault tree update prompts based on the partial path to prompt for updating the preset fault tree; determining the root cause of the abnormal path based on the partial path, and then determining the abnormal handling strategy; generating an after-sales prompt notification based on the abnormal handling strategy and sending it to the after-sales terminal; ignoring the partial path and ending the process. If the abnormal path does not include the top event, it may be due to an incomplete fault tree setting or because the abnormal event may be a false alarm. Therefore, the abnormal event may not be reported to the user terminal, but only transmitted to after-sales service, so that after-sales service can conduct further testing as needed in conjunction with the abnormal event during vehicle maintenance or other situations. If the cause of the abnormal path is an incomplete fault tree, the abnormal path can be provided to the relevant personnel for corresponding maintenance of the fault tree. If the abnormal event is a false alarm, the abnormal event can be ignored.

[0043] Step S230: Determine the exception handling strategy based on the exception path.

[0044] In one embodiment, determining an anomaly handling strategy based on an anomaly path includes: determining the root cause of the anomaly path based on the anomaly path; and determining the anomaly handling strategy based on the root cause of the anomaly path. As provided in the above embodiments, after obtaining the anomaly path, the cause of the underlying event in the anomaly path is taken as the root cause of the anomaly path, and a corresponding anomaly handling strategy is obtained based on pre-configured handling suggestions. If the anomaly can be resolved by the user through methods such as restarting the vehicle's infotainment system, the anomaly handling strategy may include handling steps for the user. If the anomaly cannot be handled directly by the user and requires after-sales assistance, a reminder to the user to go to after-sales service can be generated, and an anomaly handling strategy for after-sales service outlets can be provided. For after-sales service, corresponding handling methods for the anomaly are also provided to facilitate after-sales execution.

[0045] In one embodiment, after determining the exception handling strategy based on the exception path, the method further includes: determining a user prompt notification and / or an after-sales prompt notification according to the exception handling strategy; sending the user prompt notification to the user terminal; and sending the after-sales prompt notification to the after-sales terminal. The exception handling strategy may have a corresponding notification template pre-configured. When the exception handling strategy is obtained, the corresponding notification template is matched and sent to the corresponding terminal.

[0046] The vehicle abnormal event handling method provided in the above embodiments obtains vehicle status data, determines whether an abnormal event exists based on the status data, and if an abnormal event exists, matches the abnormal event with a preset fault tree to obtain an abnormal path, and determines an abnormal handling strategy based on the abnormal path. In this way, it is not necessary to perform fault detection through a local diagnostic instrument, but to determine the corresponding abnormal handling strategy by the data reported by the vehicle. It supports real-time data processing, which can effectively improve the real-time performance of anomaly detection, avoid the cumbersome process of offline detection, and improve detection efficiency. When the abnormal event is related to vehicle network communication, this method can quickly identify the anomaly and provide an abnormal handling strategy.

[0047] Taking an abnormal event as an example of a vehicle-to-everything (V2X) network malfunction, and status data as one or more of the vehicle's DTCs and log data, a fault tree model for V2X network anomalies is established. By collecting data such as vehicle DTCs (fault codes) or log data, key detection points and triggering events are identified, enabling remote and rapid identification of abnormal fault paths and generation of solutions. Please refer to [link / reference]. Figure 4 , Figure 4 A specific flowchart illustrating a vehicle abnormal event handling method provided in an embodiment of this application is shown below. Figure 4 As shown, the method includes the following steps: Step 1: Create a fault tree detection model on the diagnostic platform.

[0048] As an example, the logic for creating a fault tree model is as follows: taking an event that the system does not want to happen (the top event) as the object of analysis, first find all the direct causes (intermediate events) that cause the top event, and then identify the direct causes of the above direct causes, until the most basic direct cause (bottom event).

[0049] Step 2: Configure key trigger event conditions.

[0050] Each ultimate direct cause, i.e., the underlying event, needs to match the triggering rule, such as: TBOX authentication failure (DTC=U315D00), etc.

[0051] Step 3: The vehicle reports faults and logs, including DTC (fault code) fault data and log data.

[0052] Fault data and log data are stored through a data platform.

[0053] Step 4: The diagnostic platform retrieves data from the data stored in the data platform.

[0054] Incorporate the DTCs (fault codes) or log data reported by the vehicle into the fault tree for fault diagnosis.

[0055] Step 5: Determine whether a single event, intermediate event, and top event have been triggered in sequence.

[0056] If a single event is triggered, it checks whether an intermediate event has been triggered. If an intermediate event is triggered, it then checks whether a top event has been triggered. If the top event is not triggered, a partial fault path is established; if the top event is triggered, a complete fault path is established. If no single event is triggered, it can be considered that there is no fault.

[0057] The diagnostic logic is the opposite of the model creation logic. When a bottom event is triggered, the fault path is automatically completed. That is, when a bottom event is triggered, the complete fault path from the bottom event to the intermediate event and then to the top event is automatically completed. If multiple bottom events are triggered, the fault is judged according to the logical relationship (AND or OR relationship) between the events. If an intermediate event is triggered, the path is completed to the intermediate event. If no intermediate event is triggered, the path is not completed. Similarly, it needs to be completed to the top event. If there are multiple intermediate events, the fault is judged according to the logical relationship (AND or OR relationship) between the intermediate events. If an upper-level event is triggered, the path is completed to the upper-level event. This continues until the entire fault path is completed, and finally the logical traversal of the entire fault tree is completed, thus completing the diagnosis.

[0058] Step 6: The diagnostic platform stores the diagnostic information and performs fault path analysis. Based on the fault tree path, it finds the minimum path to eliminate a single fault (i.e., find the root cause of the single fault; resolving the root cause solves the problem). If multiple faults exist, it needs to find the minimum path to eliminate each fault (i.e., the root cause of each fault). Based on these minimum paths, a fault handling plan (anomaly handling strategy) is generated and pushed to the after-sales business department (after-sales operation platform) by the business platform to implement the after-sales processing flow for the faulty vehicle. If necessary, a notification of a vehicle network anomaly can be generated and pushed to the user's app through the business platform.

[0059] The aforementioned fault tree-based remote vehicle network anomaly detection method improves timeliness, causal modeling, and combined fault analysis. Compared to traditional methods that require in-store inspection for vehicle network anomalies, this method, by establishing a fault tree-based detection model, enables rapid remote problem localization, significantly reducing the frequency and cost of in-store inspections. Utilizing the fault tree's fault path reasoning mechanism, it can automatically and accurately identify the root cause of problems without requiring manual consultation of repair manuals or reliance on localized data collection and analysis, thus effectively improving the speed and accuracy of problem localization. Upon identifying abnormal vehicle status data, it can immediately notify the owner and after-sales service personnel, facilitating rapid response and customer care, improving after-sales service efficiency and user experience. It provides a fault tree-based remote diagnostic mechanism: by establishing a vehicle network anomaly fault tree model and combining it with vehicle DTCs (fault codes) and log data, it enables remote fault path localization and root cause analysis without requiring in-store visits, avoiding manual intervention and improving the efficiency and accuracy of problem identification. This method does not rely on additional vehicle hardware configurations; it only utilizes periodically reported vehicle data or event data (such as DTC fault data and log data) for diagnostic analysis, thus ensuring detection capabilities without increasing vehicle hardware costs. Through automated data collection and fault tree analysis, it reduces the involvement of after-sales personnel in troubleshooting, significantly improves diagnostic efficiency, provides users with a more convenient remote service experience, and reduces labor and service costs.

[0060] In one embodiment, a vehicle anomaly event handling apparatus is provided, which is used to execute the vehicle anomaly event handling method provided in any of the above embodiments. Please refer to [link to previous document]. Figure 5 , Figure 5 A schematic diagram of a vehicle abnormal event handling device provided in an embodiment of this application is shown below. Figure 5 As shown, the vehicle abnormal event handling device 500 includes: an acquisition module 510 for acquiring vehicle status data; a matching module 520 for matching the abnormal event with a preset fault tree to obtain an abnormal path if an abnormal event is determined based on the status data; and a determination module 530 for determining an abnormal handling strategy based on the abnormal path.

[0061] Specific limitations regarding the vehicle abnormal event handling device can be found in the limitations of the vehicle abnormal event handling method described above, and will not be repeated here. Each module in the aforementioned vehicle abnormal event handling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the electronic device in hardware form or independently of it, or stored in the memory of the electronic device in software form, so that the processor can call and execute the corresponding operations of each module.

[0062] In this embodiment, the vehicle abnormal event handling device is essentially equipped with multiple modules to execute the vehicle abnormal event handling method in any of the above embodiments. The specific functions and technical effects can be referred to the above embodiments, and will not be repeated here.

[0063] See Figure 6 , Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown below. Figure 6 As shown, this embodiment of the invention also provides an electronic device 600, including a processor 601, a memory 602, and a communication bus 603; the communication bus 603 is used to connect the processor 601 and the memory 602; the processor 601 is used to execute a computer program stored in the memory 602 to implement the method described in any of the above embodiments.

[0064] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0065] This application also provides a non-volatile readable storage medium storing one or more modules (programs) that, when applied to a device, enable the device to execute the instructions included in the steps provided in this application.

[0066] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0067] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0068] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0069] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0070] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0071] It should be understood that the terms "first," "second," etc., used in this application are used to distinguish similar objects and do not necessarily indicate a specific order or sequence. The technical features to which these terms are used can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0072] It should be understood that although the flowcharts provided in the embodiments of this application indicate the various steps with arrows, the order indicated by the arrows does not necessarily limit the implementation order of these steps. Those skilled in the art can perform these steps in other orders according to different implementation scenarios and requirements.

[0073] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for handling abnormal vehicle events, characterized in that, The method includes: Obtain vehicle status data; If an abnormal event is determined based on the state data, the abnormal event is matched with a preset fault tree to obtain an abnormal path; An exception handling strategy is determined based on the aforementioned exception path.

2. The vehicle abnormal event handling method as described in claim 1, characterized in that, Based on the aforementioned state data, abnormal events are identified, including: If the status data satisfies a preset abnormal event rule, an abnormal event corresponding to the preset abnormal event rule is triggered to obtain the abnormal event of the vehicle. In this case, a preset abnormal event rule is configured in advance for each bottom event of the preset fault tree. The preset abnormal event rule includes at least one or more of the following: data source type, event target component, data duration, matching field, and trigger count. The status data includes network fault data and / or network log data.

3. The vehicle abnormal event handling method as described in claim 1, characterized in that, The methods for creating the preset fault tree include: Get the preset top event; Determine the direct cause of the top event to obtain one or more intermediate events; Repeat the steps to determine the direct cause of the intermediate event until the direct cause is the base event; If the bottom events of all intermediate events are determined, the preset fault tree is generated based on all the bottom events, intermediate events, and the top event.

4. The vehicle abnormal event handling method as described in any one of claims 1-3, characterized in that, The abnormal events are matched with a preset fault tree to obtain the abnormal paths, including: The abnormal event is matched with the bottom event of a preset fault tree, which includes a top event, multiple intermediate events and multiple bottom events, and the top event includes network faults; If the abnormal event matches a bottom event, the bottom event is taken as the target bottom event; The triggering conditions of the upper-level events of the current event in the preset fault tree are obtained layer by layer, and the triggering state of the upper-level events is determined according to the triggering conditions. If the triggering state is triggered, the upper-level event is taken as the new current event until the upper-level event is the top event or the triggering state is changed to not triggered. The initial current event is the target bottom event. The abnormal path is generated for the triggered upper-level event based on the target bottom event and all trigger states.

5. The vehicle abnormal event handling method as described in any one of claims 1-3, characterized in that, The abnormal events are matched with a preset fault tree to obtain the abnormal paths, including: If the number of abnormal events is at least two, each abnormal event is matched with the bottom event of a preset fault tree. The preset fault tree includes a top event, multiple intermediate events and multiple bottom events. The top event includes network faults. If the abnormal event matches a base event, the base event is taken as the target base event of the abnormal event; The triggering conditions of all current events in the preset fault tree are obtained layer by layer, and the triggering state of the upper-level events is determined according to the triggering conditions. If the triggering state is triggered, the upper-level event is taken as the new current event until the upper-level event is the top event or the triggering state is changed to not triggered. The initial all current events are all the target bottom events. The abnormal path is generated for the triggered upper-level event based on all the target bottom events and all the triggering states.

6. The vehicle abnormal event handling method as described in claim 5, characterized in that, The method further includes: If the triggering state changes to the top event corresponding to the non-triggering state, the path state of the abnormal path is determined to be a complete path. Based on the abnormal path, the root cause of the abnormal path is determined, and then the abnormal handling strategy is determined. And / or, If the upper-level event corresponding to the change from triggering to non-triggering is an intermediate event, the path status of the abnormal path is determined to be a partial path, and one or more of the following steps are executed: generating fault tree update data and fault tree update prompts based on the partial path to prompt the preset fault tree to be updated; determining the root cause of the abnormal path based on the partial path, and then determining the abnormal handling strategy; generating an after-sales prompt notification based on the abnormal handling strategy and sending it to the after-sales terminal; ignoring the partial path and ending the process.

7. The vehicle abnormal event handling method as described in any one of claims 1-3, characterized in that, Determining an anomaly handling strategy based on the aforementioned anomaly path includes: Identify the root cause of the abnormal path based on the abnormal path; The anomaly handling strategy is determined based on the root cause of the abnormal path.

8. The vehicle abnormal event handling method as described in any one of claims 1-3, characterized in that, After determining the exception handling strategy based on the exception path, the method further includes: The user notification and / or after-sales notification shall be determined according to the aforementioned anomaly handling strategy; Send the user notification to the user's terminal; Send the after-sales notification to the after-sales terminal.

9. A vehicle abnormal event handling device, characterized in that, The device includes: The acquisition module is used to acquire vehicle status data; The matching module is used to match the abnormal event with a preset fault tree to obtain an abnormal path if an abnormal event is determined based on the status data. The determination module is used to determine the exception handling strategy based on the exception path.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

Images