A fault positioning method and system for a modular autonomous driving system

Abstract

This invention discloses a fault location method and system for modular autonomous driving systems, belonging to the field of autonomous driving technology. The system includes: a scenario analysis module, used to parse the operational data of the autonomous driving system in a target scenario to obtain system-level anomalies, anomaly occurrence time intervals, and fault scenario contexts; a fault diagnosis module, used to determine the responsible module most relevant to the system-level anomaly within the autonomous driving system modules by combining the anomaly occurrence time intervals and fault scenario contexts; and a code fault location module, used to constrain candidate tasks, functions, or code regions within the responsible module based on the source code information of the responsible module and the fault scenario context to obtain the candidate execution range of the system-level anomaly; and to perform task analysis based on this candidate execution range to obtain the fault location result of the autonomous driving system. This invention can gradually transition system-level anomalies to the responsible module and further locate them to fine-grained code positions within the module.

Description

Technical Field

[0001] This invention belongs to the field of autonomous driving technology, specifically relating to a fault location method and system for modular autonomous driving systems. Background Technology

[0002] With the rapid iteration and deployment of autonomous driving technology, autonomous driving systems (ADS) are gradually evolving into complex cyber-physical systems with multi-module coupling, multi-task linkage, and highly dynamic scenarios. The system's functional logic, module interactions, and operating scenarios are becoming increasingly complex, leading to frequent functional failures and anomalies that directly impact the safety and stability of autonomous vehicles. Efficient and accurate fault diagnosis and root cause localization are core technological supports for the iterative optimization and safe, compliant deployment of autonomous driving systems.

[0003] Current research in the field of autonomous driving generally focuses on forward-looking technologies such as automated test case generation, intelligent construction of driving scenarios, and discovery and mining of system failure behaviors. A relatively complete technical system has been established for risk avoidance and failure identification before failures occur. However, research on post-failure debugging, fault tracing, and precise root cause localization is relatively weak, and the technical system has significant shortcomings. Especially for autonomous driving systems built on modular architectures, while existing mainstream technologies can identify abnormal modules and provide macroscopic explanations of accident causes in specific scenarios, they generally suffer from coarse-grained analysis. They cannot achieve the technological breakthrough of accurately mapping system-level and behavioral-level anomalies to specific code locations within modules, making it difficult to meet the core requirements of fine-grained engineering debugging.

[0004] From the perspective of current technological development, existing technologies related to fault diagnosis and code fault location in autonomous driving systems can be divided into three main categories: The first category is ADS module-level fault diagnosis technology, which mainly relies on system operation record data, manually set professional rules, causal reasoning, and counterfactual analysis to achieve coarse-grained fault investigation of autonomous driving systems; the second category is general software code fault diagnosis technology, which is based on general software technologies such as program static structure analysis, code semantic reasoning, and code repository navigation retrieval to achieve code-level fault location in conventional software; the third category is coarse-grained fault location technology, which combines program execution trajectory mining, temporal logic verification, and cyber-physical system (CPS) analysis methods to complete the preliminary fault location of complex systems. However, to date, a unified technical solution has not yet been formed that can directly transition from system-level anomalies in ADS to fine-grained code locations within modules.

[0005] Looking at it more closely, the existing technical solutions that are closest to the application scenario of this invention are mainly divided into two core technical directions: module-level fault diagnosis of autonomous driving systems and general code-level fault location. Both types of technical solutions have significant technical limitations and cannot meet the fine fault location requirements of modular autonomous driving systems.

[0006] On the one hand, existing ADS module-level fault diagnosis technologies mainly include three mainstream implementation schemes. First, the causal analysis scheme based on accident records extracts accident operation variables, identifies key operation frames and causal events, constructs a causal reasoning model, and relies on counterfactual deduction to determine whether event changes could avoid the accident, thereby locating the cause of the anomaly. However, this scheme is highly suitable for analyzing collision-related severe accidents, but has poor adaptability and limited coverage for non-collision system anomalies commonly found in autonomous driving systems, such as traffic rule violations, task execution failures, conservative decision-making logic, abnormal driving trajectories, and functional performance degradation. Second, the judgment scheme based on expert-preset rules relies on domain experts to set operational verification rules for each functional module, identifying modules that violate the rules as the root cause of the fault. This scheme has a simple implementation logic, but it cannot cope with complex scenarios commonly found in autonomous driving systems, such as anomaly propagation, downstream function compensation, cascading fault effects, and multi-module collaborative anomalies. It is difficult to distinguish between the original fault source and anomalies derived from fault propagation, resulting in low fault location accuracy. Third, the causal analysis scheme based on runtime replay involves pre-setting ideal output results for each module and repeatedly replaying the operation and replacing the ideal outputs to verify whether the system anomaly is eliminated after replacement, thereby determining the responsibility for the module failure. However, this scheme requires massive runtime replay, data replacement, and repeated verification operations, resulting in high computational load, long analysis time, and high engineering costs. It is difficult to adapt to the engineering scenarios of large-scale runtime data and complex module interactions in autonomous driving systems, and the debugging efficiency is extremely low. In summary, the analysis granularity of existing ADS module-level fault diagnosis technologies is limited to the module level, and can only output results such as abnormal modules, key fault events, and coarse-grained causal explanations. It cannot penetrate the module level to locate the specific tasks, functions, and lines of code within the module. Since a single module of an autonomous driving system typically contains massive amounts of code files and program logic, only locating module-level anomalies cannot support developers to quickly complete code repairs, resulting in extremely poor debugging practicality.

[0007] On the other hand, existing general-purpose code-level fault location technologies have formed four mainstream technical routes: fault location methods based on test spectrum, program mutation, machine learning, and large language models. Among them, the technical solutions based on test spectrum, program mutation, and traditional machine learning heavily rely on explicit test signals such as large-scale test cases, program pass / fail labels, code coverage data, and historical defect samples. These are difficult to apply in scenarios where test data for autonomous driving systems is insufficient and real defect samples are scarce. Fault location solutions based on large language models break through the dependence of traditional methods on explicit test signals. By modeling the code repository, relying on function definitions, call relationships, class dependencies, and program topology graphs to conduct multi-hop semantic retrieval and reasoning, and combining the matching degree between fault description and code semantics to rank candidate fault codes, the adaptability is stronger. However, this type of solution still relies on static code structure, inherent repository dependencies, and text semantic matching as the core analysis basis, and has not adapted to the specific fault characteristics and operating characteristics of autonomous driving systems. Faults in autonomous driving systems are mostly manifested as behavioral and logical anomalies such as trajectory deviation, decision-making errors, task failures, and rule violations, without obvious fault characteristics such as program crashes or unit test failures. Moreover, the system execution path changes dynamically in real time with driving scenarios, operating modes, and task links. Static code analysis cannot reconstruct the actual fault operation link and it is difficult to identify the semantic deviation between design expectations and actual program operation. As a result, general code fault location technology cannot accurately complete the fine-grained code fault location of modular autonomous driving systems.

[0008] Based on the shortcomings of both core existing technologies, the current field of fault localization in modular autonomous driving systems faces five common technical bottlenecks, becoming the core obstacles to the industry's technological implementation. First, there is a disconnect in the technical chain. Existing ADS fault diagnosis focuses on the system and module levels, while general code localization focuses on the static code repository level. These two technologies are fragmented, lacking an effective connection and mapping mechanism from system-level anomalies to the code location within modules, making it impossible to achieve full-chain fault tracing. Second, there is insufficient dynamic adaptation capability. Existing technologies mostly rely on static code dependencies and fixed program structures for analysis, failing to adapt to the scenario-based and dynamic execution path characteristics of autonomous driving systems, making it difficult to reconstruct the actual operational chain at the time of the fault. Third, there is weak semantic fault recognition capability. Most faults in autonomous driving systems are semantic faults such as logical judgment errors, boundary condition errors, and task behavior deviations. Existing technologies have limited ability to identify semantic deviations between design expectations and program implementation behavior. Fourth, there is low utilization of multi-source information. Existing solutions cannot integrate multi-source engineering information such as driving operation scenarios, system design data, program structure characteristics, and code implementation logic for joint analysis, resulting in a single dimension of fault analysis. Fifth, the cost of engineering implementation is high. Existing mainstream solutions generally rely on massive replay verification, mutation execution, and large-scale static retrieval, resulting in high computational overhead and debugging costs, which cannot meet the engineering requirements of efficient iteration and rapid fault debugging for complex autonomous driving systems.

[0009] In summary, there is currently no integrated technical solution in the industry that can achieve end-to-end modular autonomous driving system-level anomaly perception, module fault tracing, and fine-grained code precise localization. Existing technologies are unable to balance the accuracy, comprehensiveness, efficiency, and scenario adaptability of fault localization, and cannot meet the fault debugging needs of large-scale and refined iteration of autonomous driving systems. Summary of the Invention

[0010] This invention proposes a fault location method and system for modular autonomous driving systems. When a modular autonomous driving system experiences traffic rule violations, task failures, collision risks, or other system-level anomalies, it can, based on operation records, scenario context, and source code information, gradually transition from system-level anomalies to the responsible module and further locate the fine-grained code position within the module.

[0011] To achieve the above objectives, the technical solution of the present invention includes the following:

[0012] A fault location method for a modular autonomous driving system, the method comprising: Analyze the operational data of the autonomous driving system in the target scenario to obtain system-level anomalies, anomaly occurrence time intervals, and fault scenario contexts; By combining the time interval of the anomaly occurrence with the context of the fault scenario, the responsible module most relevant to the system-level anomaly is identified in the autonomous driving system modules. The autonomous driving system modules include a perception module, a prediction module, a planning module, and a control module. The responsible module refers to the module whose inputs, outputs, or internal behaviors can more reasonably explain the cause of the system-level anomaly in the context of the fault scenario. Based on the source code information of the responsible module and the fault scenario context, constraints are applied to the candidate tasks, functions, or code regions within the responsible module to obtain the candidate execution range of system-level anomalies. Based on the candidate execution range, task analysis is performed to obtain the fault location results of the autonomous driving system.

[0013] Furthermore, by analyzing the operational data of the autonomous driving system in the target scenario, system-level anomalies, anomaly occurrence time intervals, and fault scenario contexts are obtained, including: Heterogeneous messages, module outputs, state variables, and trajectory information in the runtime data are converted into time-aligned structured execution records; wherein, the structured execution records include autonomous driving system module inputs and outputs at different times, vehicle state information, surrounding target state information, planned trajectory or control commands, and time stamps related to anomalies; The structured execution record is converted into a time-series record sequence; wherein the time-series record sequence includes speed, distance, collision risk, offset, stop state, and out-of-bounds state; Formal detection is performed on the time series signal to obtain system-level anomalies and the time intervals in which the anomalies occurred; The traffic scene at the time of the system-level anomaly is reconstructed based on vehicle trajectory, road topology, target object status and map information to obtain the fault scene context.

[0014] Furthermore, by combining the time interval of the anomaly occurrence with the context of the fault scenario, the responsible module most relevant to the system-level anomaly is identified within the autonomous driving system modules, including: Based on the system-level anomaly type and the dependencies between autonomous driving system modules, a set of candidate responsible modules is generated; One or more candidate fault hypotheses are generated around the set of candidate responsibility modules. The candidate fault hypotheses are used to describe the abnormal behavior that a candidate responsibility module may have in the target scenario, and how the abnormal behavior leads to or propagates into a system-level anomaly. Verify each candidate fault hypothesis; wherein the verification includes one or more of the following: input-output consistency analysis, upstream and downstream module behavior consistency analysis, and scene semantic consistency analysis: The responsible module is determined based on the explanatory power of the verification results for system-level anomalies. The factors constituting the explanatory power include: the degree of deviation between the output of the candidate responsible module and the expected function, the chronological relationship between the occurrence time of the candidate responsible module's anomaly and the system-level anomaly, the explanatory power of the candidate responsible module's anomaly for the propagation of downstream anomalies, the degree of correlation between the behavior of the candidate responsible module and the semantics of the target scene, and the support strength of temporal evidence and scene evidence.

[0015] Furthermore, based on the system-level anomaly type and the dependencies between autonomous driving system modules, a set of candidate responsible modules is generated, including: Based on the input-output relationships, publish-subscribe relationships, call relationships, or data dependencies between modules of the autonomous driving system, identify the modules related to system-level anomalies; Based on the correspondence between system-level anomaly types and the functional responsibilities of autonomous driving system modules, the modules related to system-level anomalies are screened to obtain a set of candidate responsible modules.

[0016] Furthermore, based on the verification results and the ability to explain system-level anomalies, the responsible module is determined, including: If a candidate responsibility module can fully explain the system-level anomaly in terms of time sequence, module dependency, and scenario semantics, then the candidate responsibility module is determined as the responsibility module; If a candidate responsibility module exhibits abnormal behavior, but the abnormality can be fully explained by the abnormality of the upstream module, then the candidate responsibility module is determined to be a module that propagates abnormal behavior or a module that performs compensatory behavior, and the upstream module is determined to be the responsibility module.

[0017] Furthermore, based on the source code information of the responsible module and the fault scenario context, constraints are applied to the candidate tasks, functions, or code regions within the responsible module to obtain the candidate execution range of system-level anomalies, including: Based on the source code information of the responsibility module, the execution entry point is identified. The execution entry point includes one or more of the following: message callback entry point, periodic execution entry point, scheduling entry point, or framework registration entry point. Based on the execution entry point, restore the function dependencies, class dependencies, control dependencies, and data dependencies, and construct a complete static call graph; By combining the context of the fault scenario, the static graph is dynamically filtered and pruned to remove branches, tasks and call chains that are not related to system-level anomalies, thus obtaining the candidate execution range of system-level anomalies.

[0018] Furthermore, based on the candidate execution range, task analysis is performed to obtain the fault location results of the autonomous driving system, including: One or more tasks are extracted from the candidate execution scope as candidate tasks and organized into a candidate task sequence according to preset rules; wherein, the preset rules include sorting according to the execution order or call order within the module; sorting according to the data dependency relationship between candidate tasks; sorting according to the relevance between candidate tasks and the current system-level exception type, exception object and fault scenario context; or, filtering and sorting according to whether candidate tasks are enabled in the current configuration or running mode; Analyze each candidate task in the candidate task sequence to obtain the design and implementation intentions of the candidate task in the current fault scenario. Then, determine whether the candidate task causes the system-level anomaly by whether there is a deviation between the design and implementation intentions that is related to the system-level anomaly. If the candidate task causes a system-level anomaly, locate the suspected fault code within the candidate task. The suspected fault codes are sorted according to the set sorting criteria to obtain the fault location results. The set sorting criteria include the degree of correlation between the behavior of the suspected fault codes and the system-level anomalies, the degree of difference between the design intention and the implementation intention, the importance of the suspected fault codes in the current fault scenario, the strength of supporting evidence related to the suspected fault codes and the corresponding candidate tasks, and the level of explanatory power of the suspected fault codes for the system-level anomalies.

[0019] Furthermore, each candidate task in the candidate task sequence is analyzed individually to obtain the design and implementation intents of the candidate tasks under the current failure scenario, including: Based on the design documents, interface specifications, protocol specifications, and technical reports of the autonomous driving system, obtain the design intent of the candidate tasks under the current fault scenario; Extract the function implementations, decision branches, auxiliary function calls, constraint logic, and filtering logic related to the candidate task to construct the implementation intent of the candidate task.

[0020] A fault location system for a modular autonomous driving system, the system comprising: The scenario analysis module is used to parse the operating data of the autonomous driving system in the target scenario to obtain system-level anomalies, anomaly occurrence time intervals, and fault scenario contexts. The fault diagnosis module is used to determine the responsible module most relevant to the system-level anomaly within the autonomous driving system module by combining the time interval of the anomaly occurrence with the context of the fault scenario. The autonomous driving system module includes a perception module, a prediction module, a planning module, and a control module. The responsible module refers to the module whose inputs, outputs, or internal behaviors can more reasonably explain the cause of the system-level anomaly in the context of the fault scenario. The code fault location module is used to constrain candidate tasks, functions, or code regions within the responsible module based on the source code information and fault scenario context of the responsible module, thereby obtaining the candidate execution range of system-level anomalies; based on the candidate execution range, task analysis is performed to obtain the fault location result of the autonomous driving system.

[0021] A computer device includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the fault location method for a modular autonomous driving system as described above.

[0022] Compared with the prior art, the present invention has at least the following beneficial effects.

[0023] This invention proposes a phased fault localization technique for modular autonomous driving systems, dividing the fault localization process into two stages: locating system-level anomalies to the responsible module and locating the responsible module to fine-grained code locations. These two stages are not simply a combination of existing independent techniques, but rather the responsible module, anomaly type, anomaly range, scene context, and supporting evidence output from the previous stage serve as input constraints for the subsequent stage. These constraints are used to limit the scope of code analysis, filter candidate tasks, and guide the sorting of suspected code locations.

[0024] Unlike existing technologies that separate module-level diagnosis from code-level localization, this invention first identifies the responsible module with higher interpretability for system-level anomalies. Then, within this responsible module, candidate execution range constraints and fine-grained code analysis are performed in conjunction with the current fault scenario. This establishes a continuous localization link from system-level anomalies to the code location within the module, enabling system behavior anomalies in the autonomous driving system to be gradually mapped to specific code regions.

[0025] This invention does not determine the source of responsibility solely based on whether a single module's output is abnormal. Instead, it analyzes candidate responsible modules by combining runtime records, the interval in which the anomaly occurred, and the context of the scenario, thereby identifying the responsible module most relevant to the system-level anomaly. This technical approach provides a more accurate analytical boundary for subsequent code-level localization, avoiding the problem of directly mapping system anomalies to a large static code repository, which would result in an excessively large search space.

[0026] To address the dynamic changes in execution paths of autonomous driving systems based on scenarios, modes, and task chains, and the fact that faults typically manifest as semantic logical errors such as flawed logical judgments, incorrect condition boundaries, fault filtering, or deviations in task behavior, this invention, within the responsibility module, does not directly perform a large-scale search based on global static dependencies. Instead, it constrains the relevant execution chains in conjunction with the current fault scenario and comprehensively utilizes program structure, source code, and other fault-related engineering information to analyze candidate code behavior. This narrows down the range of code unrelated to the fault and improves the ability to identify fine-grained code fault locations. Compared to existing solutions that rely solely on static structure expansion, rule-based judgment, or single code semantic matching, this technique reduces candidate noise and improves the specificity, accuracy, and engineering applicability of code-level fault localization. Attached Figure Description

[0027] Figure 1 Block diagram of a fault location system for modular autonomous driving systems.

[0028] Figure 2 A flowchart of a fault location method for modular autonomous driving systems.

[0029] Figure 3 A flowchart for code-level fault location.

[0030] Figure 4 Comparison chart of positioning accuracy for end-to-end fault location tasks.

[0031] Figure 5 Comparison chart of module-level fault diagnosis accuracy under different anomaly types. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, and to make the objectives, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0033] In one embodiment, the present invention operates within a software debugging and analysis environment for an autonomous driving system, such as... Figure 1 As shown, the environment includes: 1. An autonomous driving system operating object, used to generate operating records to be analyzed, wherein the autonomous driving system has a modular architecture and includes one or more of a perception module, a prediction module, a planning module, and a control module.

[0034] 2. The operation record acquisition module is used to acquire message records, status records, and module outputs of the autonomous driving system during simulation testing, playback testing, or operation verification.

[0035] 3. Scene analysis module, used to perform time-series parsing of runtime records, identification of abnormal intervals, and scene reconstruction.

[0036] 4. Module-level fault diagnosis module, used to determine the responsible module most relevant to the system anomaly based on abnormal phenomena, operation records, and scenario context.

[0037] 5. A code-level fault location module, used within the responsible module to perform fine-grained code location based on the program structure and the current scenario.

[0038] 6. Results output module, used to output the sorting results of responsibility modules, candidate tasks, candidate functions or candidate code regions.

[0039] In one embodiment, the present invention can be deployed on a single server, development workstation, or cloud analysis node. The analysis node includes at least a processor, memory, and program instructions; when executed by the processor, the program instructions are used to implement the method steps of the present invention. In another embodiment, the autonomous driving system and the analysis node are independent of each other; the analysis node completes fault location by reading offline log files, playback result files, or code repository content.

[0040] like Figure 2 As shown, the present invention provides a fault location method for modular autonomous driving systems, which includes at least the following steps.

[0041] Step S1. Obtain the operating data of the autonomous driving system to be analyzed.

[0042] Acquire the autonomous driving system's operation records, message records, status information, and corresponding source code information in the target scenario.

[0043] In some embodiments, scenario configuration files, simulation inputs, task configuration files, module registration information, or other engineering information related to the execution chain may also be obtained.

[0044] Step S2. Identify system-level anomalies and their associated contexts.

[0045] The operational data is analyzed to identify traffic rule violations, task failures, collision risks, or other system-level anomalies, and the relevant time intervals and scenario contexts in which the anomalies occurred are determined.

[0046] In one embodiment, the identification process is as follows:

[0047] Step S21: Run record parsing.

[0048] First, the original operation records of the autonomous driving system are parsed, and heterogeneous messages, module outputs, state variables and trajectory information are converted into time-aligned structured execution records.

[0049] The structured execution log may include at least one or more of the following information: module inputs and outputs at different times, vehicle status information, surrounding target status information, planned trajectory or control commands, and timestamps related to anomalies. In one embodiment, the parsing results form a queryable time-series record sequence, providing a basis for subsequent anomaly identification and responsibility attribution.

[0050] Step S22: Abnormal interval identification.

[0051] The time-series signals in the structured execution records are analyzed to identify anomalous intervals corresponding to system-level anomalies. These time-series signals may include speed, distance, collision risk, offset, stopped state, out-of-bounds state, and other behavioral indicators. In one embodiment, Signal Temporal Logic (STL) rules can be used to formally inspect the time-series signals, thereby identifying violation intervals corresponding to system anomalies and distinguishing between normal behavior, critical behavior, and obvious violation behavior.

[0052] Step S23: Scene context construction.

[0053] After identifying the abnormal interval, a context is constructed for the scene corresponding to the abnormal interval. In one embodiment, the traffic scene at the time of the anomaly can be reconstructed based on vehicle trajectory, road topology, target object state, and map information, thereby obtaining the spatial relationships and dynamic interaction relationships related to the anomaly.

[0054] The scenario context can represent at least one or more of the following: the positional relationship between the vehicle and surrounding targets; the topological relationship between the vehicle and lanes, road boundaries or intersections; and the behavioral change trend before and after the anomaly occurs.

[0055] In a preferred embodiment, the scenario context can also be comprehensively characterized by combining the time series analysis results within the abnormal interval to form a scenario semantic description corresponding to the system-level abnormality, which can be used for subsequent analysis by the responsible module.

[0056] Step S3. Perform module-level fault diagnosis.

[0057] Based on the system-level anomaly, the runtime log, and the scenario context, the responsible module most closely related to the anomaly is determined, resulting in a module-level fault diagnosis result. The module-level fault diagnosis result may include one or more of the following: suspected responsible module, anomaly type, and supporting evidence.

[0058] Specifically, after obtaining the structured execution records and scenario context, responsibility analysis is performed on candidate modules to determine the responsible module most relevant to the system-level anomaly. Unlike simply identifying the module that first exhibits the anomaly, the responsible module in this embodiment refers to a module whose inputs, outputs, or internal behavior can more reasonably explain the cause of the system-level anomaly within the current scenario context. This responsible module can be a module that directly generates the anomalous output, or an upstream module that causes propagating anomalies or compensatory behaviors in downstream modules.

[0059] In one embodiment, a set of candidate responsible modules is first generated based on the system-level anomaly type, the time interval of the anomaly occurrence, and the dependencies between modules of the autonomous driving system. Specifically, modules related to the current anomaly can be identified based on the input-output relationships, publish-subscribe relationships, call relationships, or data dependencies between modules; and the candidate responsible module set is obtained by combining the correspondence between the anomaly type and the functional responsibilities of each module. For example, when the anomaly involves obstacle collision risk, one or more of the perception module, prediction module, planning module, and control module can be used as candidate modules; when the anomaly involves traffic rule violations or task execution failure, the planning module, control module, and upstream modules related to the task can be analyzed first. Among them, the perception module is responsible for identifying the surrounding environment from sensor data and outputting structured information for downstream use; the prediction module is responsible for predicting the future movement trends of other traffic participants based on the structured information output by the perception module; the planning module is responsible for generating the running trajectory based on the structured information and the future movement trends of other traffic participants; and the control module is responsible for calculating the physical commands of the steering wheel, accelerator, and brake based on the running trajectory to drive the vehicle to follow the path.

[0060] Subsequently, one or more candidate fault hypotheses are generated around the set of candidate responsible modules. These candidate fault hypotheses describe the abnormal behavior that a particular candidate module may exhibit in the current scenario, and how this abnormal behavior leads to or propagates into a system-level anomaly. In one embodiment, candidate fault hypotheses can be generated based on the input, output, and scenario context of the candidate module. If the input information and scenario context of a candidate module support its normal output, but the actual output is inconsistent with the expected function, a candidate fault hypothesis indicating a source fault in that candidate module can be generated. If the abnormal output of a candidate module can be explained by an upstream input anomaly, a candidate fault hypothesis indicating that the candidate module belongs to a propagation anomaly or a compensatory behavior can be generated, and the analysis of its upstream modules continues.

[0061] After generating candidate fault hypotheses, each candidate fault hypothesis is verified. The verification includes one or more of the following analyses: input-output consistency analysis, upstream and downstream module behavior consistency analysis, and scenario semantic consistency analysis. Specifically, input-output consistency analysis is used to determine whether a candidate module produced abnormal output under reasonable input conditions; upstream and downstream module behavior consistency analysis is used to determine whether the output of the candidate module can explain the abnormal behavior of the downstream module; and scenario semantic consistency analysis is used to determine whether the behavior of the candidate module conforms to the current traffic scenario, task objectives, safety constraints, or traffic rule constraints.

[0062] In a preferred embodiment, the responsible module is determined based on the explanatory power of the candidate fault hypothesis to explain the system-level anomaly. The explanatory power can be determined by a combination of one or more of the following factors: the degree of deviation between the candidate module's output and the expected function; the chronological relationship between the candidate module's anomaly occurrence time and the system-level anomaly; the explanatory power of the candidate module's anomaly on the propagation of downstream anomalies; the correlation between the candidate module's behavior and the semantics of the current scenario; and the strength of support from corresponding temporal and scenario evidence. If a candidate module can more completely explain the system-level anomaly in terms of temporal sequence, module dependencies, and scenario semantics, it is determined as the responsible module; if a candidate module exhibits anomalies, but its anomalies can be fully explained by upstream module anomalies, it is determined as a propagation anomaly module or a compensatory behavior module, rather than a responsible module.

[0063] In one optional embodiment, the determination result of the responsibility module is represented as a structured diagnostic result, which includes at least: suspected responsibility module, anomaly category, candidate fault hypothesis, anomaly propagation relationship, temporal evidence, and scenario evidence.

[0064] In this way, the present invention can identify the responsible module with higher interpretability for the system-level anomaly from multiple candidate modules after the system-level anomaly occurs, instead of simply outputting the module that first exhibits the anomaly. This distinguishes between source faults, propagation anomalies, and compensatory behaviors, and provides a more accurate analysis boundary for locating code-level faults within subsequent modules.

[0065] Step S4. Within the responsibility module, determine the candidate execution scope related to the current failure scenario. Based on the responsible module, the source code information, and the fault scenario context, constraints are applied to the candidate tasks, functions, or code regions within the responsible module to obtain a candidate execution range more relevant to the current exception.

[0066] In one embodiment, after obtaining the responsible module, the candidate execution scope related to the current fault scenario is first determined within the responsible module. Unlike directly searching the entire code repository based on global static dependencies, this invention preferably combines the responsible module, the exception interval, and the scenario context to constrain and prune code regions unrelated to the current system-level exception, thereby narrowing the scope of subsequent analysis.

[0067] In a preferred embodiment, when determining the candidate execution range of a system-level exception, the execution entry point is first identified based on the source code information of the responsible module, and the function dependency, class dependency, control dependency and data dependency relationships are restored accordingly to construct a complete static call graph. Then, the static graph is dynamically filtered and pruned in combination with the fault scenario context to remove branches, tasks and call chains that are not related to the current fault, thereby retaining candidate tasks, functions or code regions that are more relevant to the system and the exception.

[0068] In a preferred embodiment, the execution entry point may include one or more of the following: a message callback entry point, a periodic execution entry point, a scheduling entry point, or a framework registration entry point. In another preferred embodiment, the candidate execution scope within the responsibility module may be represented as an ordered task chain or task set related to the current fault scenario, for subsequent step-by-step analysis. This ordered task chain is used to approximately reflect the actual execution process of the responsibility module under the current fault scenario, thereby reducing irrelevant candidate noise caused by static search.

[0069] Step S5. Perform fine-grained fault localization on the code within the candidate execution range.

[0070] Further analysis is performed on candidate tasks or functions to identify the fine-grained code locations most relevant to the current exception, and the ranking results are output. These ranking results can be task-level, function-level, class-level, or code fragment-level.

[0071] Step S51: Generate candidate task sequence.

[0072] After determining the execution scope, one or more tasks are extracted from the candidate execution scope as candidate tasks, and organized into a candidate task sequence according to preset rules. Here, a task refers to a program unit in the responsibility module that undertakes relatively independent responsibilities, which may correspond to a class, a function entry point, a functional sub-procedure, or several tightly coupled code entities.

[0073] In one embodiment, candidate tasks can be generated based on one or more of the following information: program structure dependencies, internal module execution order, configuration or registration relationships, and context constraints in the current scenario. Specifically, functions, classes, and code entities within the candidate execution scope can be obtained first based on the execution entry point of the responsible module, following the call relationship, control dependency, or data dependency; then, based on the functional responsibilities, input and output data, call relationships, and relevance to the current exception of the code entities, code entities that undertake the same sub-function or closely collaborate to complete the same functional goal are aggregated into candidate tasks.

[0074] In one embodiment, if a function, class, or code snippet has relatively independent inputs, outputs, and functional objectives, it can be considered as a candidate task; if multiple functions or code snippets jointly accomplish the same functional objective, they can be merged into a single candidate task. For example, in the planning module, candidate tasks may include functional sub-processes such as reference line processing, obstacle screening, traffic rule constraint checking, lane change feasibility assessment, trajectory generation, trajectory cost calculation, or speed planning.

[0075] After obtaining the candidate task set, the candidate tasks are organized into a candidate task sequence according to preset rules. The preset rules are used to determine the analysis order of the candidate tasks and may include one or more of the following rules: sorting according to the execution order or call order within the module; sorting according to the data dependencies between candidate tasks; sorting according to the relevance between candidate tasks and the current system-level exception type, exception object, and scenario context; and filtering or sorting according to whether candidate tasks are enabled in the current configuration or running mode.

[0076] In a preferred embodiment, candidate tasks are organized according to their relevance to the current system-level anomaly or their order in the execution chain, so that subsequent analysis prioritizes tasks that may cause the anomaly. If a candidate task directly processes key input data, key scenario objects, or key decision conditions related to the anomaly, its priority in the candidate task sequence is increased; if a candidate task lacks a scenario semantic association with the current anomaly, or is not enabled in the current configuration or operating mode, its priority is reduced or it is removed from the candidate task set.

[0077] In this way, the present invention can extract candidate tasks related to the current system-level anomaly from the candidate execution scope based on program structure, execution order, configuration registration information and current scenario context, and organize them into a candidate task sequence, thereby avoiding indiscriminate analysis of all code within the responsible module and improving the efficiency of subsequent candidate task intent analysis and fine-grained code location.

[0078] Step S52: Candidate task intent analysis.

[0079] After obtaining the candidate task sequence, each candidate task is analyzed individually to determine whether it may cause the current system-level anomaly. In this invention, the candidate task analysis not only considers the source code itself, but also combines design information, interface specifications, functional constraints, or other engineering data related to the candidate task to compare and analyze the design intent and implementation intent of the candidate task under the current failure scenario.

[0080] The design intent characterizes the functional goals, applicable conditions, constraints, or dependencies expected to be achieved by the candidate task at the system design level; the implementation intent characterizes the conditional judgments, behavioral logic, filtering rules, constraint relationships, or dependency assumptions actually manifested in the candidate task's source code. By comparing the consistency between the design intent and the implementation intent, it is possible to identify whether the candidate task has semantic logical errors such as improper logical judgments, incorrect condition boundaries, incorrect filtering, missing constraints, or deviations in task behavior.

[0081] In one embodiment, candidate task intent analysis may include the following: 1) Extract design-side information related to the candidate task to construct the design intent of the candidate task; 2) Extract source code behavior information related to the candidate task to construct the implementation intent of the candidate task; 3) Compare the differences between the design intent and the implementation intent; 4) Determine whether the current candidate task can explain the system-level anomaly based on the differences.

[0082] In one embodiment, the design-side information may come from design documents, interface specifications, protocol specifications, technical reports, or other design-side materials; the source code behavior information may come from the function implementation, decision branches, auxiliary function calls, constraint logic, or filtering logic corresponding to the candidate task. In a preferred embodiment, the design intent and the implementation intent can be represented using a unified intent pattern to enable a structured analysis that allows for a comparison between the expected and actual behaviors of candidate tasks.

[0083] In a further embodiment, the unified intent pattern may include one or more of the following: the functional goal that the task is intended to achieve; the conditions under which the task is triggered or applicable; the constraints that the task should meet when it is executed; and the environmental or input prerequisites that the task depends on.

[0084] In an optional embodiment, if there is a significant deviation between the design intent and implementation intent of the current candidate task that is related to a system-level anomaly, the candidate task is identified as a highly relevant candidate task and proceeds to the subsequent fine-grained code location determination step; if the current candidate task is insufficient to explain the system-level anomaly, the next candidate task in the candidate task sequence is analyzed.

[0085] Step S53: Semantic expansion of candidate code and fine-grained location determination.

[0086] After identifying candidate tasks more relevant to system-level anomalies, further investigation is conducted to pinpoint the location of suspected fault codes within those candidate tasks. For example... Figure 3 As shown, since the actual behavioral semantics of the candidate task are often not limited to a single function body, in one embodiment, it is also necessary to further expand the relevant code logic around the candidate task in order to recover the key functions, judgment branches, auxiliary calls or constraint logic related to the candidate task.

[0087] In a preferred embodiment, a semantic tree is gradually formed around the candidate task. The semantic tree may consist of selected code entities from the call relationships related to the responsible modules, but is not limited to the traditional call graph structure. The semantic tree is not a pre-built global program graph, but an intermediate representation gradually formed during the semantic expansion of the candidate task-related code, used to characterize the implementation-side behavioral semantics of the current candidate task under the current fault scenario.

[0088] In this semantic tree, nodes can represent functions, methods, decision logic, filtering logic, constraint logic, or other code entities related to the behavior of candidate tasks. Edges in the semantic tree represent semantic dependencies between nodes, which can include one or more of control dependencies, data dependencies, call dependencies, or decision delegation relationships. Unlike ordinary call graphs oriented towards the global code repository, this semantic tree does not require an exhaustive expansion of all reachable code, but rather prioritizes retaining code logic that has a substantial impact on the representation of candidate task behavior.

[0089] Specifically, fine-grained code location determination may include one or more of the following processes: extracting the set of key functions within candidate tasks; identifying key decision branches or key filtering logic related to the current anomaly; identifying threshold conditions, selection conditions, or security constraints that are more sensitive to the current anomaly; continuing to expand code semantics along relevant auxiliary functions or dependent logic; and sorting candidate functions, candidate code fragments, or candidate logic units.

[0090] In one embodiment, when expanding the code related to candidate tasks, the dependent logic that has a substantial impact on the behavior of the candidate tasks can be expanded first, while the infrastructure code, general encapsulation code, or irrelevant auxiliary logic that is weakly related to the current system-level anomaly can be folded or skipped in order to control the complexity of the analysis and reduce irrelevant interference.

[0091] In a preferred embodiment, the expansion result is retained and incorporated into the semantic tree only if continuing to expand a certain dependency logic can change or supplement the implementation-side intent of the current candidate task; if continuing to expand cannot substantially update the implementation-side intent of the current candidate task, further expansion of the dependency logic is stopped.

[0092] In one embodiment, if a candidate function, decision branch, filtering logic, or constraint directly affects the output of a candidate task, or processes key input data, key scenario objects, or key decision conditions related to the current anomaly, or if there is an inconsistency between its implementation intent and design intent related to the current anomaly, then it can be considered a suspected fault code location. Furthermore, candidate functions, candidate code fragments, or candidate logic units can be ranked according to their degree of correlation with the current anomaly, their impact on the candidate task output, and the strength of the corresponding evidence.

[0093] By using the above method, a semantic tree representation related to the anomaly surrounding the current candidate task can be obtained, and the location of suspected faulty code can be determined at a more granular level. In other words, this invention does not first construct the complete semantic tree and then determine the code location, but rather gradually forms the semantic tree during the semantic expansion of the candidate task-related code, and determines the location of suspected faulty code based on the key functions, decision branches, filtering logic, and constraints retained in the semantic tree.

[0094] Step S54: Sort the locations of suspected fault codes.

[0095] After completing the semantic expansion of the candidate code, the candidate functions, candidate decision branches, candidate code fragments or candidate logic units within the candidate task are sorted to determine the location of the suspected fault code that is more likely to cause the current system-level anomaly.

[0096] In one embodiment, the ranking criteria may include one or more of the following: the degree of correlation between the candidate code behavior and the current system-level anomaly, the degree of difference between the design intent and the implementation intent, the importance of the candidate code in the current failure scenario, the strength of supporting evidence related to the current candidate task, and the degree of explanatory power of the candidate code for the current anomaly.

[0097] In a preferred embodiment, a corresponding fault correlation score can be calculated for each candidate function or candidate code fragment, and the functions can be sorted according to the correlation scores. The correlation score can take the following form: in, This represents a candidate function or candidate code snippet. This indicates the degree of correlation between the candidate code and the current system-level exception. This indicates the degree of difference between the design intent and the implementation intent. This indicates the importance of the candidate code in the current failure scenario. Indicates support for the strength of the evidence. For the corresponding weights.

[0098] In one embodiment, task-level relevance results can be generated first, and then the corresponding results can be assigned to candidate functions or candidate code snippets within the candidate task to generate function-level or code snippet-level ranking results.

[0099] Step S6. Output the fault location results.

[0100] Outputs the responsible module and the location of suspected fault codes within the module to support developers in debugging, fixing, and verifying.

[0101] In the above steps, steps S1 to S3 constitute the process of locating system-level exceptions to the responsible module, and steps S4 to S6 constitute the process of locating the responsible module to the fine-grained code location within the module.

[0102] In summary, this invention divides the fault localization process into two stages: module-level fault diagnosis and code-level fault localization, thereby establishing a continuous localization link from system-level anomalies to the responsible module, and then to the fine-grained code location within the module. Compared to the existing technologies that treat module-level diagnosis and code-level localization as separate processes, this invention can progressively narrow down and map system behavior anomalies to specific code regions, solving the problem that existing autonomous driving fault analysis technologies often remain at the system or module level and are difficult to further transition to the code location within the module.

[0103] This invention does not determine the source of responsibility solely based on whether a particular module initially exhibits an anomaly or violates a single rule. Instead, it combines operational records, anomaly intervals, and scenario context to analyze and verify candidate responsible modules, thereby identifying the responsible module most relevant to the system-level anomaly. This technique improves the accuracy of responsible module identification and reduces the likelihood of misclassifying propagating anomalies, compensatory behaviors, or downstream anomalies as root cause modules. Compared to existing solutions that rely solely on rule verification, accident replay, or simple causal triggering, this invention provides a more accurate and effective analytical boundary for subsequent code-level fault localization in autonomous driving systems, thereby reducing the subsequent code search space.

[0104] This invention, within the responsible module, does not directly perform a large-scale search of the entire code repository based on global static dependencies. Instead, it combines the current fault scenario to constrain and prune the execution entry points, task chains, and candidate code regions within the responsible module that are more relevant to the anomaly, thereby determining the candidate execution range and generating candidate task sequences. The candidate execution range reflects the execution process that is more likely to be actually relevant to the responsible module under the current anomaly scenario, providing a more accurate analytical boundary for subsequent fine-grained code fault localization. Therefore, this invention can effectively reduce irrelevant code candidates introduced by static call expansion, reduce search noise in industrial-grade autonomous driving code repositories, and allow subsequent analysis to focus more on the truly relevant execution chains under the current fault scenario, thereby improving the targeting and efficiency of code-level fault localization. Compared with existing fault localization schemes that mainly rely on static program structure, global repository navigation, or large-scale code expansion, this invention better reflects the dynamic execution characteristics of autonomous driving systems under specific scenarios, modes, and task conditions, and is therefore more suitable for fine-grained code fault localization in modular autonomous driving systems. Furthermore, by first constraining the candidate execution scope and then performing subsequent analysis on the candidate tasks, this invention can also reduce the complexity of subsequent intent analysis and fine-grained code location, and improve the overall engineering applicability of the method.

[0105] In the code-level fault localization stage, this invention not only analyzes the source code structure and code behavior corresponding to candidate tasks, but also constructs design-side intent and implementation-side intent by combining design information, interface specifications, functional constraints, or other engineering data related to the candidate tasks. The differences between these two intents are then compared to identify whether the candidate task contains semantic logical errors related to the current system-level anomaly. Specifically, the design-side intent characterizes the functional goals, applicable conditions, constraints, or dependencies expected to be achieved by the candidate task at the system design level; the implementation-side intent characterizes the conditional judgments, behavioral logic, filtering rules, constraint relationships, or dependency assumptions actually manifested in the candidate task's source code. Therefore, this invention no longer relies solely on static structural correlation, surface semantic matching, or test spectrum information to determine whether candidate code is related to anomalies. Instead, it further compares the differences between "how it should work in design" and "how the code actually works," thereby more effectively identifying common semantic logical errors in autonomous driving systems, such as inappropriate logical judgments, conditional boundary errors, error filtering, missing constraints, and task behavior deviations. Compared with existing general code fault location methods, this invention is more applicable to complex software fault scenarios in autonomous driving systems where "system behavior is obviously abnormal but the program itself does not crash," and can improve the accuracy, interpretability, and engineering practicality of fine-grained code fault location. Furthermore, since the design intent and implementation intent are compared in a unified manner, this invention can also provide a clearer analytical basis for subsequent candidate function ranking and identification of suspected fault code regions.

[0106] After identifying candidate tasks more relevant to the current system-level anomaly, this invention does not merely stop at a shallow analysis of the candidate task's entry function. Instead, it constructs a semantic tree around the candidate task, selectively expanding key functions, decision branches, filtering logic, constraint logic, and related auxiliary calls. The semantic tree uses the candidate task as the root node. Nodes represent functions, methods, decision logic, filtering logic, constraint logic, or other code entities related to the candidate task's behavior. Edges represent semantic dependencies between nodes, which may include one or more of control dependencies, data dependencies, call dependencies, or decision delegation relationships. Unlike a typical fully expanded call graph, this invention prioritizes retaining key code logic that substantially impacts the interpretation of the current anomaly, while collapsing or skipping irrelevant infrastructure code, general encapsulation code, or weakly relevant auxiliary logic. Therefore, this invention can gradually recover the key implementation semantics related to the candidate task while controlling the complexity of the analysis. This allows implementation-side intent extraction to move beyond a single function body and cover key decision branches, filtering conditions, and constraint relationships that are explanatory to the current system-level anomaly. Compared to existing solutions that only perform shallow function analysis, ordinary static call expansion, or large-scale full expansion search, this invention can retain the core code logic related to the fault with lower noise, thereby improving the accuracy, interpretability, and engineering usability of fine-grained code fault localization. Furthermore, since the semantic tree expansion is performed around the current candidate task and the current fault scenario, this invention can also more effectively support the subsequent candidate function sorting and the identification of suspected faulty code regions, making the localization results more focused on the key code locations that are truly related to the anomaly.

[0107] The performance of the present invention will be verified through experiments below.

[0108] Experiment 1: In an end-to-end fault localization task, the localization performance was evaluated using top-1 accuracy at the class level, top-5 accuracy at the class level, and top-10 accuracy at the function level. Specifically, top-1 accuracy at the class level indicates whether the top-ranked candidate class output by this invention contains the actual fault class in each fault case; top-5 accuracy at the class level indicates whether the top 5 candidate classes contain the actual fault class; and top-10 accuracy at the function level indicates whether the top 10 candidate functions contain the actual fault function. For example... Figure 4 As shown, on the injected defect dataset, the accuracy rates of the present invention at the class level (top 1), class level (top 5), and function level (top 10) reached 42.9%, 66.7%, and 81.0%, respectively; on the real defect dataset, the above three indicators reached 44.4%, 77.8%, and 77.8%, respectively. These results demonstrate that the present invention can not only identify the responsible module but also further locate the finer-grained class-level or function-level code location within the module, forming a complete fault location chain from system-level anomalies to fine-grained code locations.

[0109] Experiment 2: In module-level fault diagnosis tasks, such as Figure 5 As shown in Table 1, the present invention injects defect datasets The diagnostic accuracy for collision-related anomalies, traffic rule violation anomalies, and task failure anomalies reached 93.5%, 93.3%, and 88.2%, respectively. In comparison, the representative rule-based Oracle-based solution (hereinafter referred to as Oracle) achieved accuracies of 29.0%, 26.7%, and 23.5%, respectively. This was demonstrated in a real-world defect dataset. The present invention achieves diagnostic accuracy rates of 66.7%, 100%, and 100% for collision-related anomalies, traffic rule violation anomalies, and task failure anomalies, respectively, while Oracle's corresponding accuracy rates are 33.3%, 50.0%, and 66.7%. Table 1 The above results demonstrate that the present invention achieves higher module-level diagnostic accuracy across a wider range of autonomous driving anomaly types, outperforming existing solutions that rely solely on rule verification. While the representative ACAV solution based on accident record causal analysis exhibits high accuracy in some collision scenarios, it is not applicable to traffic rule violations and task failures. Therefore, considering both applicability and overall effectiveness, the present invention demonstrates greater versatility in analyzing multiple anomalies within modular autonomous driving systems.

[0110] Experiment 3: In the code-level fault localization task, the top K accuracy at the class level and the top K accuracy at the function level are used to evaluate the localization performance. The top K accuracy at the class level indicates whether the true faulty class appears in the top K candidate classes of the method output, and the top K accuracy at the function level indicates whether the true faulty function appears in the top K candidate functions of the method output. Table 2 As shown in Table 2, in the injection defect dataset The accuracy rates of the top 1, top 3, and top 5 at the class level of this invention are 46.0%, 65.1%, and 74.6%, respectively, and the accuracy rates of the top 3, top 5, and top 10 at the function level are 42.9%, 61.9%, and 90.5%, respectively. In comparison, the representative general code fault location method AutoFL... The accuracy rate for the top 5 at the class level was only 23.8%, and the accuracy rate for the top 10 at the function level was 39.7%. For LocAgent, the accuracy rate for the top 5 at the class level was 17.5%, and the accuracy rate for the top 10 at the function level was 15.9%.

[0111] In real defect datasets The accuracy rates of the top 1, top 3, and top 5 at the class level of this invention are 55.6%, 88.9%, and 88.9%, respectively, while the accuracy rates of the top 3, top 5, and top 10 at the function level are 33.3%, 66.7%, and 88.9%, respectively. In comparison, AutoFL's accuracy rate for the top 5 at the class level is 33.3%, and its accuracy rate for the top 10 at the function level is 22.2%, while LocAgent's accuracy rate for the top 5 at the class level is 44.4%, and its accuracy rate for the top 10 at the function level is 44.4%. These results demonstrate that this invention achieves superior localization performance at both the class and function levels, and is particularly effective in supporting fine-grained code fault localization in modular autonomous driving systems.

[0112] Although the present invention has been described through the above preferred embodiments, those skilled in the art will understand that various modifications in form and detail can be made therein without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention should be defined by the appended claims.

Claims

1. A fault location method for modular autonomous driving systems, characterized in that, The method includes: Analyze the operational data of the autonomous driving system in the target scenario to obtain system-level anomalies, anomaly occurrence time intervals, and fault scenario contexts; By combining the time interval of the anomaly occurrence with the context of the fault scenario, the responsible module most relevant to the system-level anomaly is identified in the autonomous driving system modules. The autonomous driving system modules include a perception module, a prediction module, a planning module, and a control module. The responsible module refers to the module whose inputs, outputs, or internal behaviors can more reasonably explain the cause of the system-level anomaly in the context of the fault scenario. Based on the source code information of the responsible module and the fault scenario context, constraints are applied to the candidate tasks, functions, or code regions within the responsible module to obtain the candidate execution range of system-level anomalies. Based on the candidate execution range, task analysis is performed to obtain the fault location results of the autonomous driving system.

2. The method according to claim 1, characterized in that, Analyze the operational data of the autonomous driving system in the target scenario to obtain system-level anomalies, the time interval of anomaly occurrence, and the context of the fault scenario, including: Heterogeneous messages, module outputs, state variables, and trajectory information in the runtime data are converted into time-aligned structured execution records; wherein, the structured execution records include autonomous driving system module inputs and outputs at different times, vehicle state information, surrounding target state information, planned trajectory or control commands, and time stamps related to anomalies; The structured execution record is converted into a time-series record sequence; wherein the time-series record sequence includes speed, distance, collision risk, offset, stop state, and out-of-bounds state; Formal detection is performed on the time series signal to obtain system-level anomalies and the time intervals in which the anomalies occurred; The traffic scene at the time of the system-level anomaly is reconstructed based on vehicle trajectory, road topology, target object status and map information to obtain the fault scene context.

3. The method according to claim 1, characterized in that, By combining the time interval of the anomaly occurrence with the context of the fault scenario, the responsible module most relevant to the system-level anomaly is identified within the autonomous driving system modules, including: Based on the system-level anomaly type and the dependencies between autonomous driving system modules, a set of candidate responsible modules is generated; One or more candidate fault hypotheses are generated around the set of candidate responsibility modules. The candidate fault hypotheses are used to describe the abnormal behavior that a candidate responsibility module may have in the target scenario, and how the abnormal behavior leads to or propagates into a system-level anomaly. Verify each candidate fault hypothesis; wherein the verification includes one or more of the following: input-output consistency analysis, upstream and downstream module behavior consistency analysis, and scene semantic consistency analysis: The responsible module is determined based on the explanatory power of the verification results for system-level anomalies. The factors constituting the explanatory power include: the degree of deviation between the output of the candidate responsible module and the expected function, the chronological relationship between the occurrence time of the candidate responsible module's anomaly and the system-level anomaly, the explanatory power of the candidate responsible module's anomaly for the propagation of downstream anomalies, the degree of correlation between the behavior of the candidate responsible module and the semantics of the target scene, and the support strength of temporal evidence and scene evidence.

4. The method according to claim 3, characterized in that, Based on the system-level anomaly type and the dependencies between autonomous driving system modules, a set of candidate responsible modules is generated, including: Based on the input-output relationships, publish-subscribe relationships, call relationships, or data dependencies between modules of the autonomous driving system, identify the modules related to system-level anomalies; Based on the correspondence between system-level anomaly types and the functional responsibilities of autonomous driving system modules, the modules related to system-level anomalies are screened to obtain a set of candidate responsible modules.

5. The method according to claim 3, characterized in that, The responsible module is determined based on the ability to explain system-level anomalies according to the verification results, including: If a candidate responsibility module can fully explain the system-level anomaly in terms of time sequence, module dependency, and scenario semantics, then the candidate responsibility module is determined as the responsibility module; If a candidate responsibility module exhibits abnormal behavior, but the abnormality can be fully explained by the abnormality of the upstream module, then the candidate responsibility module is determined to be a module that propagates abnormal behavior or a module that performs compensatory behavior, and the upstream module is determined to be the responsibility module.

6. The method according to claim 1, characterized in that, Based on the source code information of the responsible module and the fault scenario context, constraints are applied to the candidate tasks, functions, or code regions within the responsible module to obtain the candidate execution range of system-level anomalies, including: Based on the source code information of the responsibility module, the execution entry point is identified. The execution entry point includes one or more of the following: message callback entry point, periodic execution entry point, scheduling entry point, or framework registration entry point. Based on the execution entry point, restore the function dependencies, class dependencies, control dependencies, and data dependencies, and construct a complete static call graph; By combining the context of the fault scenario, the static graph is dynamically filtered and pruned to remove branches, tasks and call chains that are not related to system-level anomalies, thus obtaining the candidate execution range of system-level anomalies.

7. The method according to claim 1, characterized in that, Based on the candidate execution range, task analysis is performed to obtain the fault location results of the autonomous driving system, including: One or more tasks are extracted from the candidate execution scope as candidate tasks and organized into a candidate task sequence according to preset rules; wherein, the preset rules include sorting according to the execution order or call order within the module; sorting according to the data dependency relationship between candidate tasks; sorting according to the relevance between candidate tasks and the current system-level exception type, exception object and fault scenario context; or, filtering and sorting according to whether candidate tasks are enabled in the current configuration or running mode; Analyze each candidate task in the candidate task sequence to obtain the design and implementation intentions of the candidate task in the current fault scenario. Then, determine whether the candidate task causes the system-level anomaly by whether there is a deviation between the design and implementation intentions that is related to the system-level anomaly. If the candidate task causes a system-level anomaly, locate the suspected fault code within the candidate task. The suspected fault codes are sorted according to the set sorting criteria to obtain the fault location results. The set sorting criteria include the degree of correlation between the behavior of the suspected fault codes and the system-level anomalies, the degree of difference between the design intention and the implementation intention, the importance of the suspected fault codes in the current fault scenario, the strength of supporting evidence related to the suspected fault codes and the corresponding candidate tasks, and the level of explanatory power of the suspected fault codes for the system-level anomalies.

8. The method according to claim 7, characterized in that, Each candidate task in the candidate task sequence is analyzed individually to obtain the design and implementation intents of the candidate tasks under the current failure scenario, including: Based on the design documents, interface specifications, protocol specifications, and technical reports of the autonomous driving system, obtain the design intent of the candidate tasks under the current fault scenario; Extract the function implementations, decision branches, auxiliary function calls, constraint logic, and filtering logic related to the candidate task to construct the implementation intent of the candidate task.

9. A fault location system for a modular autonomous driving system, characterized in that, The system includes: The scenario analysis module is used to parse the operating data of the autonomous driving system in the target scenario to obtain system-level anomalies, anomaly occurrence time intervals, and fault scenario contexts. The fault diagnosis module is used to determine the responsible module most relevant to the system-level anomaly within the autonomous driving system module by combining the time interval of the anomaly occurrence with the context of the fault scenario. The autonomous driving system module includes a perception module, a prediction module, a planning module, and a control module. The responsible module refers to the module whose inputs, outputs, or internal behaviors can more reasonably explain the cause of the system-level anomaly in the context of the fault scenario. The code fault location module is used to constrain candidate tasks, functions, or code regions within the responsible module based on the source code information and fault scenario context of the responsible module, thereby obtaining the candidate execution range of system-level anomalies; based on the candidate execution range, task analysis is performed to obtain the fault location result of the autonomous driving system.

10. A computer device, characterized in that, The computer device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the fault location method for a modular autonomous driving system as described in any one of claims 1-8.

Images