A method and system for intelligent handling of vehicle anomalies based on causal attribution

Abstract

This invention discloses a vehicle anomaly intelligent handling method and system based on causal tracing, relating to the field of vehicle anomaly handling technology. The method includes: receiving and storing anomaly reports from various functional nodes of the vehicle in real time; performing source tracing analysis on all currently active error code sets based on a directed acyclic graph, and locating the root cause error code through reverse depth-first search; for each root cause error code, querying a multi-level decision strategy library in conjunction with the vehicle's current driving mode to determine the corresponding resolution action level; coordinating the execution of operations corresponding to the resolution action level, including issuing vehicle behavior commands to the control module, sending recovery commands to the lifecycle management service module, and sending takeover requests when conditions are met; and packaging and reporting the traced anomaly information. This invention achieves intelligent root cause localization, hierarchical decision-making, and closed-loop autonomous recovery of vehicle anomalies, significantly improving the safety and reliability of autonomous driving systems.

Description

Technical Field

[0001] This application relates to the field of vehicle anomaly handling technology, and in particular to a vehicle anomaly intelligent handling method and system based on causal tracing. Background Technology

[0002] With the widespread application of advanced autonomous driving systems, vehicles integrate a large number of complex sensors, controllers, and software modules. These modules may malfunction for various reasons during operation; a malfunction in a single module can trigger a chain reaction through the coupling relationships between systems, seriously threatening driving safety. Traditional vehicle malfunction handling methods have the following limitations:

[0003] Weak root cause diagnosis capability: The system can usually only report discrete abnormal phenomenon codes. When multiple abnormalities occur concurrently, it is difficult to automatically distinguish between the root cause and the derived phenomenon, making it difficult for maintenance personnel to locate the source of the fault. Rigid decision-making and response: The response strategy is mostly based on simple, pre-set rules, which trigger an emergency stop as soon as a specific error code is detected. This approach cannot make dynamic, graded decisions based on the severity of the fault or the vehicle's current driving mode, resulting in either overreaction or underreaction. The recovery process is fragmented and not autonomous: different recovery actions are handled by different subsystems or manually, lacking a coordination mechanism; this results in a cumbersome and time-consuming recovery process, and in emergency situations, it relies on manual intervention. Poor readability of maintenance information: The information reported to the cloud or displayed to the driver is mostly a chronological list of the original error codes, lacking causal analysis, which is not conducive to quickly understanding the whole picture of the fault and increases the difficulty of subsequent data analysis.

[0004] Therefore, there is an urgent need in this field for a vehicle anomaly intelligent processing method and system that can intelligently analyze abnormal causal relationships and execute coordinated, hierarchical, and integrated autonomous responses accordingly, so as to improve the safety and reliability of autonomous driving systems. Summary of the Invention

[0005] To address the technical problems of the prior art, this application provides a vehicle anomaly intelligent processing method and system based on causal tracing. This application provides a vehicle anomaly intelligent processing method based on causal attribution, including: Step S10: Receive and store anomaly reporting information from various functional nodes of the vehicle. Each anomaly reporting information includes an error code, error level, and time to survival. Step S20: Based on multiple pre-set directed acyclic graphs representing the causal relationships between error codes, perform source tracing analysis on all active error code sets in the current anomaly reporting information to locate the root cause error code. Step S30: For each root cause error code, in conjunction with the vehicle's current driving mode, query the multi-level decision strategy library to determine the corresponding resolution action level; Step S40: Coordinate the execution of operations corresponding to the action level and issue vehicle behavior control commands containing stop, slow braking or emergency braking instructions to the control module; after the vehicle enters a safe state, send a recovery command for the faulty module to the lifecycle management service module; when the conditions are met, send a takeover request to the host computer. Step S50: The traced abnormal information is packaged and reported with the root cause error code as the core and its downstream error code chain as the core.

[0006] Furthermore, a source analysis was performed on all active error code sets, including: Starting with each active error code, perform a reverse depth-first search in a pre-defined directed acyclic graph representing the causal relationship between error codes to find all nodes with an in-degree of 0 as root error codes and establish a mapping relationship between the root error code and the downstream error codes it causes. And optimize the mapping relationship through path elimination: if a root cause error code If an error code is a downstream error code in one path, but the root cause of other error codes in another path, then... In the path of downstream error codes, Remove from the result chain of the mapping relationship; If the root cause of the currently active error code cannot be found in the directed acyclic graph, the source analysis will be performed again after a preset time window.

[0007] Furthermore, the vehicle driving modes include at least manual driving mode, remote driving mode, remote driving mode, and automatic driving mode; in the multi-level decision strategy library, for the same root cause error code, different resolution action levels are matched in different driving modes; the resolution action levels include a classification from information prompts, warnings, speed limits, pulling over, gentle braking, emergency braking to requesting manual or remote takeover.

[0008] Furthermore, in remote driving mode, when the root cause error code is due to an anomaly in the integrated navigation, vehicle agent, or control module, the collaborative execution steps, after issuing a stop command to the control module, wait for the driving mode to switch to autonomous driving or manual driving before sending a recovery command for the faulty module to the lifecycle management service module.

[0009] Furthermore, the packaged reporting has two mechanisms: trigger-based and periodic. When the error level reaches or exceeds the preset error threshold, reporting is triggered immediately; at the same time, periodic reporting is performed at fixed time intervals. The reported content is a structured report message, which is identified by a single root cause error code and filled with all downstream error codes corresponding to that root cause. The downstream error code chain does not contain detailed information about the root cause error code itself. Before preparing to report, if the set of all warning level error codes to be reported is exactly the same as the set of the last successfully reported, then the reporting of all warning level anomalies is suppressed.

[0010] This application also provides a vehicle anomaly intelligent processing system based on causal attribution, including: Anomaly monitoring module: Used to receive and store anomaly reports from various functional nodes of the vehicle. Each anomaly report includes an error code, error level, and time to survival. Causal tracing module: Used to perform tracing analysis on all active error code sets in the current anomaly reporting information based on multiple pre-set directed acyclic graphs representing the causal relationship between error codes, and to locate the root cause error code; Multi-level decision module: For each root cause error code, combined with the vehicle's current driving mode, it queries the multi-level decision strategy library to determine the corresponding resolution action level; Response Execution Module: Used to coordinate the execution and resolution of operations corresponding to the action level, issue vehicle behavior control commands containing stop, slow braking or emergency braking instructions to the control module; after the vehicle enters a safe state, send a recovery command for the faulty module to the lifecycle management service module; and send a takeover request to the host computer when the conditions are met. Information reporting module: This module is used to package and report traced abnormal information, with the root cause error code as the core and its downstream error code chain as the core.

[0011] It also includes a remote control interface module, which is used to receive module control commands from a remote agent, verify whether the current vehicle status allows the execution of the module control commands, and convert them into standard lifecycle management commands for forwarding when permitted.

[0012] The present invention discloses the following technical effects: This invention provides a vehicle anomaly intelligent processing method and system based on causal tracing. By introducing a directed acyclic graph to model the propagation relationship of vehicle faults, and using an inverse depth-first search algorithm, it realizes the transformation from vehicle anomaly processing to anomaly root cause management, thereby improving the accuracy of intelligent anomaly root cause diagnosis. This invention organically integrates multiple aspects such as anomaly monitoring, causal tracing, multi-level decision-making, vehicle control, and module lifecycle management into a collaborative closed loop. In vehicle anomaly handling, it can sequentially trigger and monitor a series of complex operations, and dynamically adjust the corresponding vehicle resolution action strategy according to the response results, realizing highly autonomous vehicle fault self-healing, reducing dependence on external interference, and improving the availability of the vehicle anomaly handling system. This invention defines a multi-level refined solution strategy, which integrates multiple dimensions such as error code, error level, real-time vehicle driving mode and system working mode for comprehensive decision-making; enabling the system to take the most appropriate solution action while ensuring the vehicle is in an absolutely safe state, optimizing the balance between vehicle safety and anomaly handling efficiency, and avoiding secondary problems caused by rigid response. Furthermore, the abnormal information reported by the system in this invention is a structured report based on causal source analysis and root cause error codes. The warning information filtering algorithm effectively avoids the redundant impact of non-critical abnormalities on communication bandwidth and cloud system, thereby improving the intelligence level of vehicle abnormal information processing. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a vehicle anomaly intelligent processing method based on causal tracing provided in Embodiment 1 of this application.

[0014] Figure 2 This is a schematic diagram of the structure of a vehicle anomaly intelligent processing system based on causal tracing provided in Embodiment 3 of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description of this application will be provided in conjunction with the accompanying drawings. The described embodiments should not be considered as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] Example 1: The present invention is deployed as an exception processing node (ExceptionProcessNode) on the autonomous driving domain controller of the vehicle and runs under the ROS 2 (Robot Operating System 2) framework; When the exception handling node starts, the system loads all the static knowledge base and policy rules required for operation from the pre-configured configuration file (JSON format) to complete the initialization, including: Loading the causal knowledge base: The causal knowledge base consists of predefined directed acyclic graphs (DAGs). The system loads multiple predefined DAGs, each depicting a fault propagation chain in a specific subsystem or scenario. Each DAG consists of nodes (error codes) and directed edges (causal relationships), configured as a JSON list, such as PERCEPTION_DAG_TYPE_1. The parent-child (causal) relationships between nodes are explicitly declared using the "node" and "roots" keys. A node can be the root (cause) of one or more other nodes. The system parses the configuration and constructs a std::unordered_map. <ErrorCode, std::vector <errorcode>Data structures such as > are used to form a directed acyclic graph that can be traversed quickly, and a mapping table between error codes and their respective DAG indices is established for subsequent fast retrieval.

[0017] Loading a multi-level decision strategy library: The system loads strategy configurations stored in key-value pairs or tables. The SolveAction strategy defines the vehicle-level safety response actions that should be triggered under different conditions. The SolveAction uses a 10-level enumeration defined by the SolveAction interface protocol in Table 1. Table 1. Ten-level enumeration of the SolveAction interface protocol's solution action strategies.

[0018] In addition, the policy library also includes lifecycle action policies, which define recovery operation codes (LifecycleAction) for specific software modules. The coding rules are shown in Table 2: Table 2 Coding rules for lifecycle actions

[0019] The matching conditions for the above strategy include at least the root cause error code, error level, current vehicle driving mode, and system operating mode. The driving mode is obtained from the vehicle chassis information and includes manual driving mode (MANUAL), remote driving mode (TELECONTROL), remote driving mode (REMOTE), and automatic driving mode (AUTODRIVE). The system operating mode includes release mode (RELEASE), debug mode (DEBUG), and repair mode (REPAIR).

[0020] Operating mode settings and interface initialization: When the system starts, the operating mode is configured to be one of release mode, debug mode, and maintenance mode. Each mode executes different functions in the exception handling process. Release mode: Performs source tracing, decision-making, recovery, takeover, and reporting functions; Debug mode: Performs tracing, decision-making, and reporting functions, but prohibits the execution of recovery operations in actual lifecycle actions, for safe debugging; Maintenance mode: Only performs source tracing and reporting functions to assist in vehicle fault location; In addition, initialize the publish and subscribe communication interfaces for all ROS 2 topics, define and compile the message interfaces using IDL files, and the core communication interfaces include: Subscription interfaces: / exception / report_error_msg (used to receive exception reports from various functional nodes of the vehicle), / vehicle_status (used to obtain the current driving mode of the vehicle); Release interfaces: / exception / solve_action (used to send exception information to the planning module), / exception / control_solve_action (used to send exception information to the control module), / exception / lifecycle_action (used to send exception information to the lifecycle management service module), / exception / take_over_request (used to request takeover), / exception / change_action (used for function degradation).

[0021] After system initialization, based on the above configuration process, this application embodiment provides a complete flow for executing the intelligent vehicle anomaly handling method based on causal tracing proposed in this invention, such as... Figure 1 As shown, it includes: Step S10: Receive and store anomaly reports from various functional nodes of the vehicle. Each anomaly report includes an error code, error level, and time to survival.

[0022] In this embodiment, this step continuously subscribes to topics from the / exception / report_error_msg communication interface, listens for messages from the exception reporting interface ReportErrorMsg, and parses fields such as error_code, error_level, lifespan_time, and solve_action whenever a message is received. The message instance is then stored in a global std::unordered_map.<ErrorCode, ErrorMsg> The `all_error_msgs_map` data structure is used to record details and add the `error_code` to the active error code set `std::set`. <errorcode>error_code_set; If the current error level exceeds the preset threshold or the solve_action field indicates that immediate processing is required, such as an emergency stop request autonomously determined and reported by the vehicle planning module, the normal exception handling cycle is immediately interrupted, the emergency handling thread is triggered, and the process jumps directly to steps S30 and S40 to ensure timely response.

[0023] Step S20: Based on multiple pre-set directed acyclic graphs representing the causal relationships between error codes, perform source tracing analysis on all active error code sets in the current anomaly reporting information to locate the root cause error code.

[0024] In this embodiment, at the beginning of each tracing cycle, this step iterates through the error_msgs_map, which is the mapping table between error codes and their corresponding DAG indexes in the causal knowledge base, and calculates the lifespan of each abnormal reporting information (current time minus message timestamp). If the lifespan is greater than its lifespan_time, the error code corresponding to the abnormal reporting information is removed from the active error code set and the status is marked as IGNORED. Next, for each remaining error code in the active error code set, perform the following operations: Iterate through the active error codes set error_code_set: ErrorCode1, ErrorCode2, ...; Find the corresponding DAG graph through the mapping table error_msgs_map; Perform a depth-first search to trace the source, starting with the current error code as the initial node (startNode), and recursively and backwards search for all parent nodes (i.e. direct causes) pointing to the current node in the corresponding DAG graph. Recursively search for the parent node of each parent node until a node with an in-degree of 0 (i.e., no parent node) is found. This node is then marked as a root cause error. Record the complete path from the root cause error code to the original startNode; After traversing all active error codes, a set containing all possible paths is obtained. Critical path culling is then performed to optimize the output: if an error code A is the result of error code B in path X, but the cause of error code C in path Y, then when reporting path X, A is removed from the result chain of B, generating a clean root_cause_map. <ErrorCode, std::vector <errorcode>The structure is used to obtain the root cause error code and its corresponding root cause mapping table root_cause_map.

[0025] For error codes that are not defined in the DAG or for which no upstream root cause has been found (and are not in an emergency), start a separate waiting thread with a short timeout of 500ms, expecting the potential root cause to be reported within this time, and then re-trigger the source tracing process to improve the diagnostic success rate.

[0026] Step S30: For each root cause error code, in conjunction with the vehicle's current driving mode, query the multi-level decision strategy library to determine the corresponding resolution action level; In this embodiment, this step receives the root_cause_map output by step S20, and makes an independent decision for each key in the map (i.e., each identified root cause error code). The decision-making steps include: Query the multi-level decision strategy library based on the root cause error code, the error level corresponding to the error code (error_level), the vehicle's current driving mode, and the system's current operating mode; Output the triplet decision result for the root cause error code: the level value of the primary SolveAction (corresponding to the second column of Table 1), the code of the auxiliary LifecycleAction, and the reporting flag. The reporting flag is used to determine whether immediate triggering reporting is required, and the code of the auxiliary LifecycleAction can also be empty.

[0027] Step S40: Coordinate the execution of operations corresponding to the action level and issue vehicle behavior control commands containing stop, slow braking or emergency braking instructions to the control module; after the vehicle enters a safe state, send a recovery command for the faulty module to the lifecycle management service module; when the conditions are met, send a takeover request to the host computer. In this embodiment, the decision-making process involved in this step includes: The exception handling node (ExceptionProcessNode) publishes a SolveAction message to the planning module of the vehicle system through the topic / exception / solve_action, informing it of the resolution action level of the decision output in step S30. The planning module immediately replies with a SolveActionResponse message to confirm receipt. If SolveAction directly controls the vehicle's current driving mode, the system will simultaneously issue the same command to the vehicle's control module via the / exception / control_solve_action topic; When a parking command is issued to the control module, a safety monitoring process is executed, including: After the first parking command is issued, wait for a preset first time period T1 to check whether a successful response message from the control module has been received. The response indication in the message includes no response (SOLVE_EXECUTING) and successful response (SOLVE_SUCCESS). If there is no response, the parking command will be issued again; after the cumulative waiting time since the first parking command is issued exceeds the preset second duration T2, the system will check again to see if any successful response message has been received. If no successful response is received, the control module is deemed to be seriously faulty and unable to guarantee parking safety. At this point, the system will no longer wait and will forcibly escalate the entire exception resolution action to TAKE_OVER_MANUAL (requesting manual takeover) and immediately trigger the takeover process.

[0028] After the vehicle control command has been issued and the system determines that the vehicle has entered a controllable and safe state (such as starting to decelerate), the execution module resumes and sends a LifecycleAction message to the lifecycle management service module via the / exception / lifecycle_action topic, waiting for and listening for the / exception / lifecycle_action / response response: During the recovery process, if a duplicate recovery request for the same module is received, it will be suppressed and will not be sent again. If the cumulative number of times the same LifecycleAction is sent exceeds the preset threshold and still fails, the autonomous recovery will be deemed invalid and the takeover process will be triggered. When the lifecycle management service module returns a success message and monitors that all recovered nodes have re-entered an active state, the recovery is considered successful.

[0029] When the resolution action output by step S30 is directly takeover (TAKE_OVER), or when the above recovery process fails, this is used as the trigger condition for the takeover process. All takeover requests are collected. According to the principle that manual takeover has a higher priority than remote takeover, a takeover request is sent after the vehicle has come to a complete stop. The takeover request is sent by publishing an ExceptionTakeOverRequest message through the / exception / take_over_request topic. A request timeout period is set. If a successful takeover confirmation is not received after the timeout, the request is resent until the exception disappears. Once the takeover process is initiated (i.e., a takeover request has been sent), the system suspends the issuance of new SolveActions to the planning and control module and completely transfers control of the vehicle.

[0030] Step S50: Pack and report the traced abnormal information, with the root cause error code as the core and its downstream error code chain attached.

[0031] In this embodiment, the reporting has two mechanisms: trigger-based and periodic. When the error level (error_level) reaches or exceeds the preset error threshold (ERROR), or when the decision output indicates that the resolution action needs to be reported immediately, the packaged reporting process is immediately triggered; and a minimum interval limit is imposed on the reporting of the same error code to avoid screen flooding; at the same time, periodic routine reporting is performed at fixed time intervals to report all currently unresolved vehicle abnormal statuses.

[0032] The reported content is a structured alert message. The detailed steps for constructing the reported content include: Iterate through the root_cause_map, and for each root cause error code, create a ReportErrorMsg structure. The error_code field of this structure is filled with the root cause error code, and the traces field is filled with a list of all downstream child cause error codes corresponding to that root cause (i.e., a std::vector). <errorcode>(but does not include detailed information about the root cause error code itself, to avoid information redundancy; fill in the solve_action obtained from the decision result, and the solve_status obtained from the response message of the planning and control module.)

[0033] Filter warning messages before submitting them: WARNING level exceptions are not involved in the tracing process of step S20. Before reporting, all WARNING error codes to be reported this time and error codes not in any DAG are combined into a temporary set. This set is compared with the set of the same type of error that was successfully reported last time. If the two sets are completely consistent, the reporting of the entire set is suppressed this time.

[0034] When a root cause error code is detected to have disappeared from its data source (lifespan_time expired), and all its associated child cause error codes have also been cleared from the active set, the exception chain is considered to have been recovered. If no takeover request was previously issued, the instruction solve_action = SOLVE_ACTION_INFO(0) is sent to the planning module to notify it that normal driving can be resumed; By issuing a ChangeAction message, the vehicle's Automation Level and Automation Feature set are restored to normal, completing the closed loop of the entire abnormal autonomous recovery.

[0035] Example 2: This embodiment of the invention provides an intelligent vehicle anomaly handling method based on causal tracing applied to a scenario of a perception subsystem link anomaly, i.e., radar failure, including: In autonomous driving mode, the following error codes are received: {100101 (radar drive anomaly), 400101 (point cloud preprocessing anomaly), 402101 (target detection anomaly), 600201 (planning anomaly)}. Traverse the error_msgs_map, a mapping table between error codes and their corresponding DAG indices, in the causal knowledge base. Find the corresponding PERCEPTION_DAG_TYPE_1 graph. After performing a reverse depth optimization search in this graph, obtain the root cause error code and its corresponding root cause mapping table root_cause_map: {100101: [400101, 402101, 600201]}. Locate the root cause error code 100101 from this table. Querying the multi-level decision strategy library, the root cause error code 100101 in the AUTODRIVE mode is SolveAction: BRAKE_RECOVER(6), LifecycleAction: 1001; Based on the decision result, a BRAKE_RECOVER command is issued to the control module, and its response is monitored. After the vehicle brakes suddenly and decelerates, a restart radar drive command (1001) is sent to the lifecycle management service module. The restart result is monitored: if successful, the abnormal message reporting process is initiated; if the restart fails more than 3 times, the process is upgraded to manual takeover (TAKE_OVER_MANUAL). When the radar restarts successfully, a ReportErrorMsg is reported in a triggered manner, with error_code=100101, traces=[400101, 402101, 600201], and solve_action=6. At this time, all relevant error codes are cleared, a recovery command is sent to the planning module, and the vehicle continues to drive autonomously.

[0036] Example 3: The vehicle anomaly intelligent processing system based on causal tracing provided in this embodiment of the invention can execute the vehicle anomaly intelligent processing method based on causal tracing provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method, such as... Figure 2 As shown, it has the following modules: Anomaly monitoring module: Used to receive and store anomaly reports from various functional nodes of the vehicle. Each anomaly report includes an error code, error level, and time to survival. Causal tracing module: Used to perform tracing analysis on all active error code sets in the current anomaly reporting information based on multiple pre-set directed acyclic graphs representing the causal relationship between error codes, and to locate the root cause error code; Multi-level decision module: For each root cause error code, combined with the vehicle's current driving mode, it queries the multi-level decision strategy library to determine the corresponding resolution action level; Response Execution Module: Used to coordinate the execution and resolution of operations corresponding to the action level, issue vehicle behavior control commands containing stop, slow braking or emergency braking instructions to the control module; after the vehicle enters a safe state, send a recovery command for the faulty module to the lifecycle management service module; and send a takeover request to the host computer when the conditions are met. Information reporting module: This module is used to package and report traced abnormal information, with the root cause error code as the core and its downstream error code chain as the core.

[0037] It also includes a remote control interface module, which is used to receive module control commands from a remote agent, verify whether the current vehicle status allows the execution of the module control commands, and convert them into standard lifecycle management commands for forwarding when permitted.

[0038] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0039] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than in the embodiments and still achieve the desired results.< / errorcode> < / errorcode> < / errorcode> < / errorcode>

Claims

1. A vehicle anomaly intelligent processing method based on causal attribution, characterized in that, The method includes: Step S10: Receive and store anomaly reporting information from various functional nodes of the vehicle. Each anomaly reporting information includes an error code, error level, and time to survival. Step S20: Based on multiple pre-defined directed acyclic graphs representing the causal relationships between error codes, perform source tracing analysis on the set of all active error codes in the current anomaly reporting information to locate the root cause error code: Starting with each active error code, perform a reverse depth-first search in a pre-defined directed acyclic graph representing the causal relationship between error codes to find all nodes with an in-degree of 0 as root error codes and establish a mapping relationship between the root error code and the downstream error codes it causes. And optimize the mapping relationship through path elimination: if a root cause error code If an error code is a downstream error code in one path, but the root cause of other error codes in another path, then... In the path of downstream error codes, Remove from the result chain of the mapping relationship; If the root cause of the currently active error code cannot be found in the directed acyclic graph, the source analysis will be performed again after a preset time window. Step S30: For each root cause error code, in conjunction with the vehicle's current driving mode, query the multi-level decision strategy library to determine the corresponding resolution action level; Step S40: Coordinate the execution of operations corresponding to the action level and issue vehicle behavior control commands containing stop, slow braking or emergency braking instructions to the control module; after the vehicle enters a safe state, send a recovery command for the faulty module to the lifecycle management service module; when the conditions are met, send a takeover request to the host computer. Step S50: The traced abnormal information is packaged and reported with the root cause error code as the core and its downstream error code chain as the core.

2. The intelligent vehicle anomaly handling method based on causal attribution as described in claim 1, characterized in that, In step S30, the driving modes include at least manual driving mode, remote driving mode, remote driving mode and automatic driving mode; In the multi-level decision strategy library, different levels of resolution actions are matched for the same root cause error code in different driving modes. The resolution action levels include a range from information prompts, warnings, speed limits, pulling over, gentle braking, emergency braking to requesting manual or remote intervention.

3. The intelligent vehicle anomaly handling method based on causal attribution as described in claim 2, characterized in that, In remote driving mode, when the root cause error code is related to an anomaly in the integrated navigation, vehicle agent, or control module, the collaborative execution steps, after issuing a stop command to the control module, wait for the driving mode to switch to autonomous or manual driving mode before sending a recovery command for the faulty module to the lifecycle management service module.

4. The intelligent vehicle anomaly handling method based on causal attribution as described in claim 3, characterized in that, When issuing a parking command to the control module, a safety monitoring process is executed, including: After the first parking instruction is issued, wait for a preset first time. If there is no response, repeat the parking instruction. If there is still no response after the cumulative waiting time exceeds the preset second time since the first parking instruction was issued, the subsequent handling action will be escalated to request manual intervention. The manual takeover has a higher priority than the remote takeover, and only the highest priority manual takeover request is sent after the vehicle has come to a complete stop.

5. The intelligent vehicle anomaly handling method based on causal attribution as described in claim 3, characterized in that, When sending a recovery command for a faulty module to the lifecycle management service module, if the same recovery command for the same module is received during the recovery process, subsequent duplicate commands will be suppressed; if the cumulative number of times the same recovery command is sent exceeds a preset threshold and the response still fails, a takeover process will be triggered.

6. The intelligent vehicle anomaly handling method based on causal attribution as described in claim 1, characterized in that, In step S50, when the package is reported, a report is immediately triggered when the error level reaches or exceeds a preset error threshold; at the same time, periodic reporting is performed at fixed time intervals. The reported content is a structured warning message, which is identified by a single root cause error code and filled with all downstream error codes corresponding to that root cause. The downstream error code chain does not contain detailed information about the root cause error code itself. Furthermore, the warning message is filtered before it is prepared for reporting. If the set of all warning level error codes to be reported is exactly the same as the set of the last successfully reported message, then the reporting of all warning messages in this report is suppressed.

7. A vehicle anomaly intelligent processing system based on causal attribution, characterized in that, The system is used to implement the intelligent vehicle anomaly processing method based on causal attribution as described in any one of claims 1-6, and the system comprises: Anomaly monitoring module: Used to receive and store anomaly reports from various functional nodes of the vehicle. Each anomaly report includes an error code, error level, and time to survival. Causal tracing module: Used to perform tracing analysis on all active error code sets in the current anomaly reporting information based on multiple pre-set directed acyclic graphs representing the causal relationship between error codes, and to locate the root cause error code; Multi-level decision module: For each root cause error code, combined with the vehicle's current driving mode, it queries the multi-level decision strategy library to determine the corresponding resolution action level; Response Execution Module: Used to coordinate the execution and resolution of operations corresponding to the action level, issue vehicle behavior control commands containing stop, slow braking or emergency braking instructions to the control module; after the vehicle enters a safe state, send a recovery command for the faulty module to the lifecycle management service module; and send a takeover request to the host computer when the conditions are met. Information reporting module: This module is used to package and report traced abnormal information, with the root cause error code as the core and its downstream error code chain as the core.

8. The intelligent vehicle anomaly processing system based on causal attribution as described in claim 7, characterized in that, It also includes a remote control interface module, which is used to receive module control commands from a remote agent, verify whether the current vehicle status allows the execution of the module control commands, and convert them into standard lifecycle management commands for forwarding when permitted.

Images