An intelligent fault diagnosis method and system based on task graph evidence closed loop

Abstract

The application discloses an intelligent fault diagnosis method and system based on a task graph evidence closed loop, receives a fault diagnosis request, equipment topology, a measurement point mapping, an interface list and historical fault samples of aviation equipment, generates a structured diagnosis target, constructs a task graph containing input and output interfaces, completion criteria and evidence source pointers, generates a candidate diagnosis chain based on an evidence gap graph, determines an executable chain through shadow playback, interface compatibility, data source reachability, evidence granularity consistency and evidence closed loop verification, encapsulates node results into a standardized diagnosis evidence package for next node input, posteriori confidence update and path switching, and finally generates a diagnosis program code and outputs a fault position, a fault category and an evidence chain.

Description

Technical Field

[0001] This invention relates to the field of intelligent fault diagnosis and industrial data processing technology, and in particular to an intelligent fault diagnosis method and system based on task graph evidence closed loop for industrial equipment, electromechanical systems and industrial production lines. Background Technology

[0002] Industrial equipment, electromechanical systems, and industrial production lines typically generate heterogeneous data from multiple sources during operation, including vibration, temperature, current, pressure, speed, alarm logs, and maintenance records. Existing fault diagnosis technologies usually employ fixed rule processes, single-model inference processes, knowledge graph reasoning processes, or manual experience-based troubleshooting processes. While these technologies can perform basic diagnoses in scenarios with simple equipment structures, fixed measurement points, stable interfaces, and few fault modes, they still suffer from problems in complex industrial environments, such as unclear task breakdown, ambiguous data coupling relationships, difficulty in dynamically adjusting diagnostic paths, and difficulty in reusing diagnostic results.

[0003] First, complex industrial equipment typically features multi-component coupling, multi-point data acquisition, multi-interface access, and the coexistence of multiple types of faults. The topology, measurement point mapping relationships, data source availability, and historical fault sample coverage may vary between different devices. Existing fixed diagnostic processes struggle to dynamically form a diagnostic task structure based on the fault object, observed variables, data source identifiers, and target output constraints. Furthermore, they struggle to clearly define the data input, data output, and completion criteria relationships between parent and child tasks, easily leading to situations where local diagnostic steps can be executed, but the overall diagnostic objective cannot be closed.

[0004] Secondly, while existing fault diagnosis methods may include multiple stages such as feature extraction, anomaly detection, root cause localization, and evidence presentation, these stages are typically communicated through temporary variables, local results, or model outputs. There is a lack of standardized evidence objects to coordinate and control node inputs, confidence updates, and path switching. When the data type, fault object granularity, or evidence fields output by upstream nodes fail to meet the input requirements of downstream nodes, the system often struggles to identify the source of the breakpoint in a timely manner, easily leading to invalid execution, repeated troubleshooting, or incorrect propagation.

[0005] Furthermore, existing multi-path diagnostic or knowledge graph diagnostic methods typically focus on fault knowledge representation and reasoning output, lacking unified verification of whether candidate diagnostic paths possess interface compatibility, data source accessibility, consistency of evidence granularity, and completeness of evidence closure loop. Unverified diagnostic paths may suffer from issues such as inaccessible data sources, mismatched node input and output fields, jumps in fault object granularity, or the inability of the end output to simultaneously cover fault location, fault category, and evidence completeness conditions, thus reducing the credibility of the diagnostic results.

[0006] Furthermore, when existing diagnostic systems fail to execute a certain path or lack sufficient evidence, they typically handle the situation by re-executing a fixed process, manually selecting an alternative path, or simply backtracking. These methods fail to determine which candidate diagnostic chains remain compatible with the current evidence based on the existing diagnostic evidence package, and lack mechanisms to suppress repeated switching and path oscillations. Therefore, the diagnostic process suffers from poor stability in scenarios involving interface fluctuations, missing data, conflicting evidence, or inconsistent granularity of faulty objects.

[0007] Finally, most existing fault diagnosis technologies remain at the level of outputting fault conclusions and diagnostic basis. Even if a diagnostic path can be formed, it is difficult to further convert the diagnostic path that has been verified by evidence loop into repeatable diagnostic program code. This makes it difficult to solidify diagnostic experience and is not conducive to rapid reuse in online monitoring, automatic inspection, edge deployment and unattended operation and maintenance scenarios.

[0008] Therefore, it is necessary to provide a new intelligent fault diagnosis method and system based on task graph evidence closed loop, which can establish a continuous data processing closed loop around structured diagnostic objectives, task graphs, candidate diagnostic chains, standardized diagnostic evidence packages, node posterior confidence, backtracking switching, and diagnostic program code generation, thereby improving the accuracy, stability, traceability, and automated deployment capabilities of fault diagnosis in complex industrial scenarios. Summary of the Invention

[0009] The purpose of this invention is to provide an intelligent fault diagnosis method and system based on task graph evidence closed loop, in order to solve the problems existing in the fault diagnosis technology, such as unclear division of diagnostic tasks, unclear input-output coupling relationship between parent and child tasks and diagnostic nodes, lack of executability and evidence closed loop verification before execution of candidate diagnostic paths, difficulty in supporting subsequent node input and path switching with diagnostic evidence at the same time, easy blindness or oscillation in backtracking switching, and difficulty in solidifying diagnostic paths into executable diagnostic program code.

[0010] This invention enables the unified conversion of fault diagnosis requests, equipment topology, measurement point mapping, interface lists, and historical fault samples into structured diagnostic targets. It explicitly establishes input interface definitions, output interface definitions, completion criteria, and task-side evidence source pointers between parent and child tasks in the task graph. Furthermore, it completes candidate diagnostic chains based on an evidence gap graph and filters executable chains through candidate chain shadow playback, interface compatibility, data source reachability, evidence granularity consistency, and evidence closed-loop verification. Simultaneously, it utilizes the same standardized diagnostic evidence package to drive the next node input, node posterior confidence update, and path switching determination, thus forming an executable, verifiable, traceable, and reusable closed loop in the fault diagnosis process.

[0011] In a first aspect, the present invention provides an intelligent fault diagnosis method based on task graph evidence closure, comprising:

[0012] The system receives fault diagnosis requests along with the device topology, measurement point mapping, interface list, and historical fault samples of the object to be diagnosed. It generates a structured diagnostic target containing the fault object, observed variables, data source identifiers, candidate diagnostic operators, target output constraints, and data source health. The target output constraints include fault location, fault category, and evidence completeness conditions. Using the target output constraints as the root task output boundary and the observed variables, data source identifiers, and data source health as sub-task input boundaries, a task graph is constructed, coupling parent and child tasks through input interface definitions, output interface definitions, completion criteria, and task-edge evidence source pointers. An evidence gap graph is then generated. Based on the task graph and the evidence gap graph, a candidate diagnostic chain is generated, and this chain is then subjected to candidate chain shadow playback and interface compatibility checks. The executable chain is determined by verifying data source reachability, evidence granularity consistency, and evidence loop closure. A path model for the executable chain is established, and diagnostic operator nodes are executed. The node results are encapsulated into standardized diagnostic evidence packages, which serve as the input for the next node, the posterior confidence update input, and the path switching judgment input. When the posterior confidence of a node is lower than the switching threshold and the standardized diagnostic evidence package does not meet the completion criteria of the corresponding parent task, the task graph is backtracked, and a backtracking cooling flag is used to switch to an input-output compatible candidate diagnostic chain. After the candidate diagnostic chain meets the target output constraints, the path confidence is determined, and the candidate diagnostic chain with the highest path confidence is converted into diagnostic program code, outputting diagnostic results including fault location, fault type, and evidence chain.

[0013] Secondly, the present invention provides an intelligent fault diagnosis system based on task graph evidence closed loop, comprising:

[0014] The module comprises an objective generation module, a task graph construction module, a diagnostic chain generation module, a path modeling module, an execution evaluation module, a backtracking and switching module, and a code generation module.

[0015] The target generation module is used to generate structured diagnostic targets based on fault diagnosis requests, equipment topology, measurement point mapping, interface list and historical fault samples. The structured diagnostic targets include fault objects, observation variables, data source identifiers, candidate diagnostic operators, target output constraints and data source health.

[0016] The task graph construction module is used to construct a task graph that couples parent and child tasks through input interface definition, output interface definition, completion criteria, and task edge evidence source pointers, with the target output constraint as the root task output boundary and the observed variables, data source identifiers, and data source health as the sub-task input boundaries, and generates an evidence gap graph.

[0017] The diagnostic chain generation module is used to generate candidate diagnostic chains based on the task graph and evidence gap graph, and to determine the executable chain through candidate chain shadow playback, interface compatibility, data source reachability, evidence granularity consistency and evidence closed loop verification.

[0018] The path modeling module is used to establish a path model that corresponds to the diagnostic operator node with the node state, diagnostic action, predicted reward and node prior confidence; the execution evaluation module is used to execute the diagnostic operator node, encapsulate the node result into a standardized diagnostic evidence package, and enable the same standardized diagnostic evidence package to drive the next node input, node posterior confidence update and path switching determination.

[0019] The backtracking switching module is used to switch to an input-output compatible candidate diagnostic chain when the posterior confidence of a node is lower than the switching threshold and the standardized diagnostic evidence package does not meet the completion criteria of the corresponding parent task, in conjunction with the backtracking cooling flag.

[0020] The code generation module is used to determine the path confidence and convert the candidate diagnostic chain with the highest path confidence into diagnostic program code, and output diagnostic results including fault location, fault category and evidence chain.

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

[0022] First, this invention maps fault diagnosis requests, equipment topology, measurement point mapping, interface list, and historical fault samples into a unified structured diagnostic target. The fault object, observation variables, data source identifier, candidate diagnostic operator set, target output constraints, and data source health are written into the structured diagnostic target. This enables the fault diagnosis task to form a unified data entry point from natural language requirements, multi-source equipment data, and historical samples, avoiding the lack of a unified boundary for subsequent task decomposition and path execution.

[0023] Second, this invention uses the target output constraint as the root task output boundary and the observed variables, data source identifiers, and data source health as the sub-task input boundaries. It constructs a task graph that couples the parent and sub-tasks through input interface definitions, output interface definitions, completion criteria, and task edge evidence source pointers. This makes the parent-child relationship in the task graph not only represent hierarchical relationships but also the relationship between input and output fields and the relationship between evidence sources, thereby improving the clarity and traceability of diagnostic task decomposition.

[0024] Third, after constructing the task graph, the present invention generates an evidence gap graph and completes the candidate diagnostic chain based on the evidence gap graph. It can automatically insert data acquisition nodes, feature construction nodes, object granularity refinement nodes or cross-validation nodes according to the difference between the fields required for the target output constraint and the fields that are currently satisfied, thereby reducing the breakage of the diagnostic chain caused by missing fields.

[0025] Fourth, this invention performs candidate chain shadow playback, interface compatibility, data source reachability, evidence granularity consistency, and evidence loop verification on candidate diagnostic chains. This can eliminate candidate diagnostic chains with input / output field mismatch, unreachable calling objects, non-convergence of fault object granularity, or failure of end output to meet the parent task completion criteria before actual execution, thereby reducing invalid path execution and improving diagnostic efficiency and execution stability.

[0026] Fifth, this invention establishes a path model for the executable chain that corresponds the diagnostic operator node with the node state, diagnostic action, predicted reward, and node prior confidence, so that the execution of nodes in the diagnostic chain has a quantifiable prior basis, and provides a unified data basis for subsequent node posterior confidence updates, path switching, and path confidence aggregation.

[0027] Sixth, this invention encapsulates the node results of diagnostic operator nodes into a standardized diagnostic evidence package, and makes the same standardized diagnostic evidence package serve as the input for the next node, the input for updating the node's posterior confidence, and the input for path switching. This makes node execution, confidence updates, and path switching no longer dependent on scattered data objects, but form a closed-loop control around the same evidence object, thereby enhancing the continuity and interpretability of the diagnostic process.

[0028] Seventh, when the posterior confidence of the current diagnostic operator node is lower than the switching threshold and the current standardized diagnostic evidence package does not meet the corresponding parent task completion criterion, the present invention backtracks along the task graph and switches to an input-output compatible candidate diagnostic chain in combination with the backtracking cooling mark. This can avoid blind backtracking, repeated execution and path oscillation in traditional fault diagnosis and improve the diagnostic stability in scenarios with interface fluctuations, insufficient evidence or missing data.

[0029] Eighth, after the candidate diagnostic chain outputs the fault location and fault category and meets the evidence completeness condition, the present invention determines the path confidence based on the node posterior confidence, execution success rate, evidence loop integrity and code shadow playback results, and converts the candidate diagnostic chain with the highest path confidence into diagnostic program code, so that the diagnostic path verified by evidence loop can be solidified into a repeatable automated diagnostic tool, which is conducive to reuse in online monitoring, automatic inspection, edge deployment and unattended operation and maintenance scenarios.

[0030] Ninth, the diagnostic results output by this invention include fault location, fault type, and evidence chain. It can not only provide the final fault conclusion, but also present the source of diagnostic evidence, the execution process of diagnostic nodes, and the basis for path selection, thereby improving the credibility of the diagnostic results and their engineering application value. Attached Figure Description

[0031] Figure 1 The flowchart illustrates the intelligent fault diagnosis method based on task graph evidence closure provided in this embodiment of the invention.

[0032] Figure 2 This is a block diagram of an intelligent fault diagnosis system based on task graph evidence closed loop provided in an embodiment of the present invention. Detailed Implementation

[0033] The present invention will be further described in detail below using an industrial equipment fault diagnosis scenario. This embodiment takes the aircraft engine accessory transmission system, airborne hydraulic pump station, landing gear retraction mechanism, aviation environmental control air circulator, airborne generator, fuel supply pump, and auxiliary power unit starting transmission unit as the objects to be diagnosed. The objects to be diagnosed include the aircraft engine accessory gearbox, main shaft bearing, accessory drive shaft, hydraulic pump slipper pair, servo valve, actuator cylinder seal, landing gear locking mechanism, air circulator rotor, cooling fan, generator winding, fuel pump bearing, and auxiliary power unit transmission gear. The equipment topology is used to represent the connection, transmission, and energy transfer relationships between various components; the measurement point mapping is used to represent the equipment components, sampling locations, sampling periods, and data fields corresponding to vibration sensors, temperature sensors, current sampling points, pressure sampling points, speed sampling points, and log collection points, respectively; the interface list is used to record the access methods for the time series database, historical fault database, maintenance log interface, model file library, field acquisition terminal, and Application Programming Interface (API); the historical fault samples are used to record the confirmed fault locations, fault categories, original monitoring data, characteristic results, maintenance records, manual confirmation conclusions, and corresponding diagnostic paths.

[0034] like Figure 1 As shown, the intelligent fault diagnosis method based on task graph evidence closed loop provided by the present invention includes the following steps.

[0035] S101. Generate structured diagnostic targets

[0036] The system first receives fault diagnosis requests along with the equipment topology, measurement point mappings, interface list, and historical fault samples of the object to be diagnosed. Fault diagnosis requests can be alarm work orders automatically reported by the monitoring system or diagnostic requirements entered by maintenance personnel. For example, a fault diagnosis request might be: "Increased vibration in the aircraft engine accessory transmission system, accompanied by abnormal temperature in the accessory gearbox bearing. Please determine the fault location and fault type." The target generation module performs semantic parsing on the fault diagnosis request and, combined with the equipment topology, measurement point mappings, interface list, and historical fault samples, generates structured diagnostic targets.

[0037] The structured diagnostic objective includes at least the fault object, observed variables, data source identifier, candidate diagnostic operator set, target output constraints, and data source health. The fault object defines the scope of components to be diagnosed, such as aircraft engine accessory gearboxes, main shaft bearings, accessory drive shafts, hydraulic pump slipper pairs, servo valves, actuator cylinder seals, landing gear locking mechanisms, air cycle rotors, generator windings, fuel pump bearings, and auxiliary power unit transmission gears. Observed variables define the available data types, such as vibration, temperature, current, pressure, speed, and maintenance log keywords. The data source identifier defines the data acquisition path, such as time-series databases, field acquisition terminals, maintenance log interfaces, historical fault databases, and model file libraries. The candidate diagnostic operator set defines the diagnostic actions that can be invoked, such as data acquisition operators, feature construction operators, anomaly detection operators, object granularity refinement operators, cross-validation operators, conflict evidence verification operators, causal invariance verification operators, and root cause location operators. Target output constraints include fault location, fault category, and evidence completeness conditions.

[0038] When generating structured diagnostic targets, the target generation module also calculates the data source health score for each data source based on the interface list and historical call records. The data source health score is determined according to the following formula: , in, Indicates the first The health status of each data source. Indicates the data source sequence number. Indicates the first Access reachability of each data source Indicates the first Data freshness of each data source Indicates the first Historical error rate of each data source Weights representing access reachability Weights representing the freshness of data The weights representing the historical error rate.

[0039] Specifically, access reachability is determined based on whether the current interface can be connected, whether a valid status code is returned, and whether the response time requirement is met; data freshness is determined based on the proximity between the latest data timestamp in the data source and the fault diagnosis request time; historical error rate is determined based on the failure rate, number of abnormal returns, and number of timeouts of the data source in historical calls. If a data source exists in the interface list but its health is lower than a preset health threshold, the target generation module does not directly delete the data source, but writes a low health flag in the structured diagnostic target, so that subsequent task graph construction and candidate diagnostic chain generation can prioritize other data sources, or configure a backup collection node for the data source.

[0040] In a further implementation, the target generation module also generates evidence lease parameters. These parameters define the consumable time range and transferable hierarchy of the standardized diagnostic evidence package generated from the data source during subsequent diagnostic processes. For vibration time-series data with high update frequencies, the evidence lease parameters are set to a shorter validity period; for relatively stable data such as equipment topology and measurement point mapping, the parameters are set to a longer validity period. Before any subsequent diagnostic operator node consumes the standardized diagnostic evidence package, it must verify whether the evidence lease is still valid; if the evidence lease expires, a data re-acquisition node or a backup data source switching node is triggered.

[0041] The data processing coupling relationship in this step is as follows: the fault diagnosis request provides the semantic entry point for diagnosis; the equipment topology provides the structural connection relationship between fault objects; the measurement point mapping provides the spatial correspondence between observed variables and fault objects; the interface list provides the data acquisition path for observed variables; historical fault samples provide the basis for selecting candidate diagnostic operators; the data source health provides the quantitative result of the availability of the data source; and the evidence lease parameters provide the time constraint for subsequent consumption of the evidence package. All of the above data converge into the same structured diagnostic objective and serve as the common input for task graph construction, candidate diagnostic chain generation, node prior confidence initialization, and evidence package validity verification.

[0042] When the target generation module uses a text semantic parsing model, the model employs historical fault diagnosis requests, historical alarm work orders, and manually labeled structured diagnostic targets as training samples. During training, historical fault diagnosis requests, alarm descriptions, device names, and maintenance record summaries are used as model inputs. Fault objects, observed variables, data source identifiers, candidate diagnostic operator sets, and target output constraints are used as supervision labels. Field recognition accuracy, field completeness rate, and structured diagnostic target restoration accuracy are used as training evaluation metrics. When the target generation module uses a data source health prediction model, this model is trained using historical interface call logs. These logs include interface response time, call success markers, data timestamps, exception return codes, timeout counts, and historical error counts. The training objective is to predict the availability of the data source in the current diagnostic task. When the target generation module uses an evidence lease prediction model, this model is trained using historical evidence package validity periods, diagnostic correctness when evidence packages are consumed downstream, data source update frequency, and evidence package expiration and misuse records. The training objective is to predict the effective consumption time range of evidence packages generated from different data sources.

[0043] This step transforms natural language diagnostic requirements, multi-source device data, interface status, historical fault knowledge, and evidence expiration constraints into structured data objects. This ensures that subsequent task decomposition, diagnostic chain generation, and path execution all have clear data boundaries. Furthermore, by using data source health and evidence leases, it proactively identifies risks of interface unreachability, outdated data, and misuse of expired evidence, reducing invalid calls and error propagation during subsequent diagnostic chain execution.

[0044] S102, Constructing the task graph, evidence gap graph, and conflict evidence subtask

[0045] After obtaining the structured diagnostic objectives, the task graph construction module uses the target output constraints as the root task output boundary and the observed variables, data source identifiers, and data source health as the sub-task input boundaries to construct a task graph that couples the parent and sub-tasks through input interface definitions, output interface definitions, completion criteria, and task edge evidence source pointers.

[0046] Specifically, the task graph construction module identifies "outputting the fault location, outputting the fault category, and satisfying the evidence completeness condition" as the root task. Subsequently, based on the fault object, observed variables, data source identifiers, and candidate diagnostic subsets, the task graph construction module decomposes the root task into a fault location subtask, a fault category identification subtask, and an evidence completeness verification subtask. The fault location subtask is further decomposed into a vibration data acquisition subtask, a temperature data reading subtask, an order feature construction subtask, and an abnormal component location subtask. The fault category identification subtask is further decomposed into a bearing spalling identification subtask, a tooth surface wear identification subtask, a misalignment identification subtask, an internal leakage identification subtask of the airborne hydraulic pump, an unbalanced air circulator rotor identification subtask, an abnormal fuel pump pressure identification subtask, and a seal leakage identification subtask.

[0047] Each task node is defined with input interface definition, output interface definition, and completion criteria. The input interface definition specifies the data fields, fault object granularity, data source identifier, time window, and evidence lease status that the task node needs to receive. The output interface definition specifies the data fields, intermediate diagnostic conclusions, evidence granularity, exception codes, and evidence lease update results that the task node should output. The completion criteria specify the requirements for field completeness, granularity consistency, evidence completeness, and evidence lease validity that the task node must meet to be considered complete. When the output interface definition of a subtask satisfies the input interface definition of its parent task, the task graph construction module attaches the subtask as a child node of the corresponding parent task and writes the task edge between the subtask and the parent task into the task graph.

[0048] The task edge evidence source pointer is used to record which subtask output field, data source, measurement point mapping relationship, and historical fault sample satisfy the input field of the parent task. For example, when the parent task requires "vibration envelope spectrum characteristics of aero-engine accessory gearbox bearing" as an input field, the task edge evidence source pointer records that this field originates from the vibration data acquisition subtask, aero-engine accessory gearbox bearing measurement points, a time-series database, and historical bearing spalling fault samples. Thus, the task edges in the task graph not only represent task hierarchy relationships but also field satisfaction relationships and evidence source relationships.

[0049] The task graph construction module also generates an evidence gap graph. This graph is generated based on the differences between the required output fields corresponding to the target output constraints and the fields already satisfied in the task graph. The required output fields include at least a fault location field, a fault category field, and an evidence completeness condition field; the satisfied fields originate from the output interface definitions of subtasks in the task graph. The evidence gap graph records the missing field name, corresponding fault object, optional data source, completable diagnostic operator, and missing priority, and establishes a mapping relationship between the missing fields and the completion criteria of the corresponding parent task. For example, if the root task requires a "fault category field," but the current task graph can only output "abnormal transmission chain of aero-engine accessories" and not "bearing inner ring spalling" or "tooth surface wear," then the evidence gap graph records that the fault category field is missing, the corresponding fault object is the transmission chain, the optional data source is vibration time series and maintenance logs, the completable diagnostic operators are the object granularity refinement operator and the cross-validation operator, and the missing priority is high.

[0050] In a further implementation, when task nodes from different data modalities output conflicting intermediate diagnostic conclusions for the same fault object or the same fault category, the task graph construction module generates a conflict evidence subtask. This conflict evidence subtask is used to prioritize, supplement, and verify the causal invariance of conflict evidence packages. For example, if vibration evidence points to "split of the inner ring of the bearing in the aircraft engine accessory gearbox," temperature evidence only points to "poor lubrication," and maintenance log evidence points to "poor alignment," and all three are associated with the same parent task in the same transmission chain, the task graph construction module writes the conflict field under that parent task into the conflict evidence subtask and configures a conflict evidence verification operator, a backup data acquisition operator, and a causal invariance verification operator for the conflict evidence subtask.

[0051] In a further implementation, the task graph construction module also generates an edge-level stability marker for each task edge. The edge-level stability marker is determined based on whether the output fields of the subtask remain consistent across different data sources, time windows, or operating conditions. The edge-level stability marker is written into the task edge evidence source pointer and used as input to the node prior confidence and path confidence in the subsequent path model. If a task edge frequently exhibits the situation of "upstream fields exist but cannot support downstream conclusions" in multiple historical fault samples, then this task edge is marked with a low stability marker, and cross-validation nodes or causal invariance verification nodes are preferentially inserted during the subsequent generation of candidate diagnostic chains.

[0052] In this step, the structured diagnostic objective provides the root task output boundary and subtask input boundary; the objective output constraint determines that the root task must output the fault location, fault category, and evidence completeness conditions; the observed variables and data source identifiers determine the data content and acquisition path that the subtask can obtain; the data source health affects the priority of the data source selected by the subtask; the evidence lease status limits the transferable range of evidence in the task graph; the input interface definition, output interface definition, and completion criteria determine whether a valid task edge can be formed between the parent task and the subtask; the task edge evidence source pointer records the evidence source formed by the task edge; the evidence gap graph, based on the current field coverage of the task graph, indicates in reverse the fields that need to be filled in the subsequent candidate diagnostic chain; the conflict evidence subtask transforms the conflict conclusions between different data modalities into an executable verification task.

[0053] When the task graph construction module adopts a task decomposition model, the model uses historical structured diagnostic targets and manually confirmed task graphs as training samples. During training, the fault object, observed variables, data source identifiers, candidate diagnostic operators, target output constraints, data source health, evidence lease parameters, and historical fault sample summaries are used as inputs. The root task, subtasks, input interface definitions, output interface definitions, completion criteria, task edge evidence source pointers, conflict evidence subtasks, and edge stability markers are used as supervision labels. The training evaluation metrics are task node identification accuracy, task edge connection accuracy, interface matching accuracy, completion criterion hit rate, evidence source pointer accuracy, and conflict evidence identification accuracy. After training, the task decomposition model outputs an initial task graph, which is then verified by a rule validator to ensure that the input and output fields between parent and child tasks satisfy the coupling relationship.

[0054] This step decomposes complex fault diagnosis objectives into an executable, connectable, verifiable task structure capable of handling conflicting evidence. This ensures that each diagnostic subtask has clearly defined data inputs, outputs, and completion conditions. Furthermore, by using evidence gap diagrams, conflicting evidence subtasks, and edge stability markers, it proactively identifies missing fields, evidence conflicts, and task edge instability, providing precise evidence for subsequent candidate diagnostic chain completion and path selection.

[0055] S103. Generate candidate diagnostic chains and perform candidate chain shadow playback and counterfactual shadow playback.

[0056] After generating the task graph and evidence gap graph, the diagnostic chain generation module retrieves template chains from the operator template library that simultaneously satisfy the subtask input interface definition and output interface definition for the leaf tasks or intermediate tasks in the task graph. The template chains in the operator template library are composed of multiple diagnostic operator nodes connected sequentially. These diagnostic operator nodes include data acquisition nodes, feature construction nodes, anomaly detection nodes, object granularity refinement nodes, cross-validation nodes, conflict evidence verification nodes, causal invariance verification nodes, and root cause localization nodes.

[0057] For each diagnostic operator node, the diagnostic chain generation module writes the node input field, node output field, calling object field, and node execution status field. The node input field is used to limit the data types, fault object identifiers, evidence granularity, time windows, and evidence lease status that the diagnostic operator node needs to consume; the node output field is used to limit the data types, feature results, intermediate diagnostic conclusions, exception codes, and evidence lease update results output by the diagnostic operator node; the calling object field is used to record the data source, interface, model file, or rule base called by the diagnostic operator node; and the node execution status field is used to record whether the diagnostic operator node was successfully executed and the reason for failure.

[0058] When the template chain contains unmet input fields, the diagnostic chain generation module inserts data acquisition nodes, feature construction nodes, object granularity refinement nodes, or cross-validation nodes based on the evidence gap diagram to form a complete chain. When there are conflicting evidence subtasks in the task graph, the diagnostic chain generation module inserts conflicting evidence verification nodes and causal invariance verification nodes under the corresponding parent task. When the evidence lease of an upstream evidence package is insufficient to support the execution of downstream nodes, the diagnostic chain generation module inserts evidence renewal nodes or re-acquisition nodes.

[0059] Subsequently, the diagnostic chain generation module merges the template chain and the completion chain at the node level to obtain the candidate diagnostic chain. During node-level merging, the diagnostic chain generation module matches the node input fields and node output fields according to the field name, field type, fault object identifier, evidence granularity, time window, and evidence lease status. It deletes duplicate data collection nodes, retains feature-constructed nodes that can meet the downstream input requirements, and sets cross-validation nodes or conflict evidence validation nodes at the convergence point of multiple evidence branches.

[0060] After generating the candidate diagnostic chain, the diagnostic chain generation module performs candidate chain shadow replay. This shadow replay pre-executes the candidate diagnostic chain using anonymized sample data and field placeholder data from historical fault samples without calling the actual production interface. During the shadow replay, the diagnostic chain generation module checks whether each diagnostic operator node's input fields have a source, whether its output fields can be consumed by downstream nodes, whether the calling object fields can be mapped to the interface list, whether the evidence lease status meets downstream consumption requirements, and whether the terminal output fields meet the completion criteria of the corresponding parent task. If the candidate chain shadow replay reveals missing input fields, unconsumable output fields, unmapped calling object fields to the interface list, invalid evidence leases, or terminal output fields that do not meet the completion criteria of the corresponding parent task, the diagnostic chain generation module corrects, downgrades, or removes the corresponding candidate diagnostic chain.

[0061] In a further embodiment, the diagnostic chain generation module also performs counterfactual shadow playback. Counterfactual shadow playback involves controlled perturbation of key evidence fields in the candidate diagnostic chain after the candidate chain shadow playback has passed, to determine whether the fault location and fault category output by the candidate diagnostic chain are overly sensitive to irrelevant fields. The key evidence fields include fault object identifier, time window, evidence granularity, feature results, intermediate diagnostic conclusions, data source health, and evidence lease status. If perturbing fields unrelated to the target fault causes a significant change in the fault location or fault category output by the candidate diagnostic chain, the diagnostic chain generation module marks the candidate diagnostic chain as a low-causal stable chain; if perturbing fields directly related to the target fault causes a change in the candidate diagnostic chain output that conforms to the device topology and measurement point mapping relationship, the candidate diagnostic chain is marked as a high-causal stable chain.

[0062] In this step, the subtask input interface definition in the task graph determines the data fields that the first node of the candidate diagnostic chain needs to receive, the subtask output interface definition determines the data fields that the last node of the candidate diagnostic chain must output, the evidence gap graph determines what kind of completion node needs to be inserted, the conflict evidence subtask determines whether to insert conflict evidence verification nodes and causal invariance verification nodes, the evidence lease status determines whether to insert evidence renewal nodes or re-acquisition nodes, the operator template library provides reusable combinations of diagnostic nodes, the candidate chain shadow playback tests whether the candidate diagnostic chain can form a continuous field flow, and the counterfactual shadow playback tests whether the candidate diagnostic chain has causal stability.

[0063] When the diagnostic chain generation module employs a template retrieval model, this model is trained using paired data of historical task descriptions and successful diagnostic chains. During training, subtask descriptions, input interface definitions, output interface definitions, evidence gap maps, data source health, conflicting evidence subtasks, evidence lease status, and historical fault sample summaries are encoded as task vectors. Successfully executed template chains are encoded as template vectors. A contrastive learning approach is used to narrow the distance between matching task vectors and template vectors, and to widen the distance between mismatched task vectors and template vectors. Training evaluation metrics include template chain hit rate, coverage of the top candidate chains, candidate chain shadow replay pass rate, counterfactual shadow replay stability rate, and final execution success rate.

[0064] This step transforms the abstract subtasks in the task graph into candidate diagnostic chains sequentially connected by diagnostic operator nodes. This step fills in missing fields using an evidence gap graph, handles multi-source evidence conflicts through conflict evidence subtasks, prevents expired evidence from being misused downstream through evidence leases, and proactively identifies issues such as field breaks, interface mismatches, incomplete end-point outputs, and causal instability through candidate chain shadow playback and counterfactual shadow playback, thereby reducing the probability of failure and misdiagnosis in the actual execution phase.

[0065] S104. Perform candidate diagnostic chain verification and establish a path model.

[0066] After generating the candidate diagnostic chain, the diagnostic chain generation module performs interface compatibility verification, data source reachability verification, evidence granularity consistency verification, causal invariance verification, and evidence loop closure verification on the candidate diagnostic chain.

[0067] Interface compatibility verification checks whether the output fields of the preceding diagnostic operator node satisfy the input fields of the following diagnostic operator node. Verification includes checking for matching field names, consistent field types, corresponding fault object identifiers, aligned time windows, evidence granularity meeting downstream requirements, and valid evidence leases.

[0068] Data source reachability verification is used to check whether the data source, interface, model file, or rule base corresponding to the calling object field of each diagnostic operator node is accessible. During verification, the diagnostic chain generation module reads the data source health status in the structured diagnostic target. If a data source is unreachable or its health status is lower than a preset health threshold, the candidate diagnostic chain for that data source will be downgraded and sorted, or a backup data collection node will be called to complete the chain.

[0069] The evidence granularity consistency check is used to determine whether the fault object granularity output by each diagnostic operator node in the candidate diagnostic chain converges to the granularity required by the completion criteria of the corresponding parent task, according to the whole-machine level, subsystem level, component level, or measurement point level. When the fault object granularity output by the upstream diagnostic operator node cannot meet the input granularity requirements of the downstream diagnostic operator node, the object granularity refinement node is called to complete it; when the object granularity refinement node fails to complete, it is determined that the corresponding candidate diagnostic chain has not passed the evidence loop closure check.

[0070] The causal invariance check is used to determine whether the fault location and fault category output by the candidate diagnostic chain are primarily supported by evidence fields that have topological, measurement point, or historical sample associations with the fault object, rather than being driven by irrelevant fields, expired fields, or unstable data sources. Specifically, the causal invariance check node reads the counterfactual shadow playback results, edge-level stability markers, and conflict evidence subtask results. If the candidate diagnostic chain maintains consistent key evidence field dependencies for the same fault object under different operating conditions, different time windows, or different data source combinations, the causal invariance check is deemed to have passed. If the candidate diagnostic chain is highly sensitive to disturbances in irrelevant fields, or produces unreasonable conclusion jumps due to data source switching under the same fault object, the causal invariance check is deemed to have failed.

[0071] The evidence loop closure check verifies whether the output fields of the nodes at the end of the candidate diagnostic chain simultaneously cover the fault location, fault category, and evidence completeness conditions. If the candidate diagnostic chain can only output the fault location but not the fault category, or can only output intermediate diagnostic conclusions but does not meet the evidence completeness conditions, then the candidate diagnostic chain fails the evidence loop closure check. A candidate diagnostic chain is determined to be an executable chain only if it passes the candidate chain shadow playback, counterfactual shadow playback, interface compatibility check, data source reachability check, evidence granularity consistency check, causal invariance check, and evidence loop closure check.

[0072] For executable chains, the path modeling module establishes a path model. This path model maps diagnostic operator nodes to node states, diagnostic actions, predicted rewards, and prior confidence levels. Node states include currently obtained evidence summaries, unmet target output constraints, current fault object range, executed node sequence, available data source list, task-edge evidence source pointers, evidence gap graph state, conflict evidence subtask state, evidence lease state, and causal invariance verification state. Diagnostic actions represent the specific operations performed by the diagnostic operator node, such as reading vibration time series, extracting envelope spectrum features, calculating temperature rise trends, refining object granularity, performing conflict evidence verification, performing causal invariance verification, calling root cause localization models, or performing cross-validation. Predicted rewards represent the expected gains in fault location, fault category, evidence completeness conditions, and causal stability after performing the diagnostic action in the current node state. Prior confidence levels represent the degree of credibility to which the diagnostic operator node is considered capable of producing valid diagnostic evidence before execution.

[0073] Node prior confidence is determined based on the historical execution success rate of diagnostic operators, the degree of matching between diagnostic operators and faulty objects, the health of the data source corresponding to the called object's field, device topology consistency, measurement point mapping consistency, candidate chain shadow replay results, counterfactual shadow replay results, evidence lease status, and edge-level stability flag initialization. For example, if a diagnostic operator node has a high data source health, a high historical execution success rate, passes candidate chain shadow replay, has stable counterfactual shadow replay, and its diagnostic action matches the current faulty object, then that diagnostic operator node obtains a high node prior confidence; otherwise, the node prior confidence is low.

[0074] The data processing coupling relationships in this step are as follows: the candidate diagnostic chain provides the node order and node connection relationship; the candidate chain shadow replay results provide a reliable basis for pre-execution; the counterfactual shadow replay results provide a causal stability basis; interface compatibility verification ensures the continuity of adjacent node fields; data source reachability verification ensures the availability of the calling object; evidence granularity consistency verification ensures that the granularity of the faulty object converges step by step; causal invariance verification ensures that the output conclusion is not driven by irrelevant fields; and evidence loop closure verification ensures that the final output covers the target output constraint. The path model binds each diagnostic operator node in the verified executable chain with the node state, diagnostic action, predicted reward, and node prior confidence, so that subsequent execution, posterior update, and path switching have a unified data foundation.

[0075] When the path modeling module employs a predictive reward model, this model is trained using historical execution logs. These logs include node status, diagnostic actions, node execution results, intermediate diagnostic conclusions, the correctness of the final fault diagnosis, the completeness of the evidence chain, node execution time, data source health, task-side evidence source pointers, candidate chain shadow replay results, counterfactual shadow replay results, evidence lease status, and causal invariance verification results. During training, node status and diagnostic actions are used as inputs. The comprehensive reward, derived from the combination of final diagnosis correctness, evidence completeness, execution success rate, evidence granularity consistency, causal invariance, and execution time, serves as the supervision label. Regression error, node ranking consistency, and final path selection accuracy are used as training evaluation metrics.

[0076] This step selects truly executable chains from multiple candidate diagnostic chains that can form a closed loop of evidence and possess causal stability, and establishes a quantifiable execution basis for each diagnostic operator node. This reduces invalid paths from entering the actual execution stage and avoids diagnostic interruptions or incorrect diagnoses caused by unreachable data sources, incompatible interfaces, granular jumps in faulty objects, expired evidence, conflicting evidence, or causal instability.

[0077] S105. Execute the executable chain and generate a standardized diagnostic evidence package.

[0078] The execution evaluation module selects executable chains based on the prior confidence of each node and executes the diagnostic operator nodes sequentially. Each executed diagnostic operator node yields its corresponding result. The node result includes a summary of the original data, feature results, intermediate diagnostic conclusions, anomaly codes, node execution status, and evidence timestamps. The execution evaluation module then encapsulates the node results into a standardized diagnostic evidence package.

[0079] The standardized diagnostic evidence package is represented using JavaScript Object Notation (JSON) structure, and its fields include at least the evidence identifier, upstream evidence identifier, fault object identifier, data source identifier, time window, node identifier, diagnostic operator identifier, node input field, node output field, raw data summary, feature result, intermediate diagnostic conclusion, anomaly code, node execution status, evidence timestamp, task-side evidence source pointer, evidence package fingerprint, evidence freshness, evidence granularity, evidence lease status, conflict evidence marker, and causal stability marker.

[0080] Among them, the evidence identifier is used to uniquely identify the current standardized diagnostic evidence package; the upstream evidence identifier is used to record the upstream evidence packages inherited or consumed by the current standardized diagnostic evidence package; the fault object identifier is used to indicate the equipment component or system level corresponding to the evidence package; the data source identifier is used to indicate the data source of the evidence; the time window is used to indicate the data acquisition time range corresponding to the evidence; the node identifier and diagnostic operator identifier are used to indicate the diagnostic operator node and diagnostic action that generated the evidence package; the node input field and node output field are used to indicate the data fields consumed and output by the node; the original data summary is used to record the original data index or summary; the feature result is used to record the extracted diagnostic features; and the intermediate diagnostic conclusion is used to record the local output of the node. The system includes the following parameters: Exception code (to record node execution exceptions); Node execution status (to record whether the node executed successfully); Evidence timestamp (to record the evidence generation time); Task edge evidence source pointer (to record the source of the task graph evidence corresponding to the evidence package); Evidence freshness (to indicate the proximity between the data timestamp in the evidence package and the fault diagnosis request time); Evidence granularity (to indicate the device level to which the evidence package is located, such as the whole machine level, subsystem level, component level, or measurement point level); Evidence lease status (to indicate whether the evidence package can still be consumed downstream in the current diagnostic chain); Conflict evidence flag (to indicate whether the evidence package participates in a conflict evidence subtask); and Causal stability flag (to indicate the stability of the evidence package in causal invariance verification).

[0081] The fingerprint of the evidence package is generated according to the following formula: , in, Indicates the first A standardized diagnostic evidence package includes fingerprints. Indicates the serial number of the standardized diagnostic evidence package. Represents a hash function. Indicates the first Evidence identifiers for a standardized diagnostic evidence package, Indicates the first Upstream evidence identifiers for a standardized diagnostic evidence package Indicates the first A standardized diagnostic evidence package includes a fault object identifier. Indicates the first The data source identifier for a standardized diagnostic evidence package. Indicates the first A time window for a standardized diagnostic evidence package. Indicates the first The node output fields of a standardized diagnostic evidence package.

[0082] Evidence package fingerprints are used to identify evidence packages that are reused, mistransmitted across tasks, or have their fields tampered with. When a downstream diagnostic operator node receives a standardized diagnostic evidence package, the evaluation module first verifies whether the evidence package fingerprint matches the evidence identifier, upstream evidence identifier, fault object identifier, data source identifier, time window, and node output fields, and verifies whether the evidence lease status is valid. If the evidence package fingerprint does not match or the evidence lease status is invalid, the standardized diagnostic evidence package is rejected as input to the downstream node, and the corresponding exception code is written to the current path model.

[0083] When the current diagnostic operator node needs to consume the output of multiple upstream diagnostic operator nodes, the execution evaluation module aligns multiple standardized diagnostic evidence packages based on time windows, fault object identifiers, evidence granularity, evidence lease status, and node input fields to form an aggregated evidence package. For example, if an abnormal frequency band location node simultaneously receives standardized diagnostic evidence packages from both a vibration data acquisition node and a speed reading node, the execution evaluation module first aligns them according to time windows, then according to fault object identifiers, then checks whether the two are at the same device level according to evidence granularity, then verifies whether the evidence lease status is valid, and finally writes the vibration characteristics and speed information into the same aggregated evidence package according to the node input fields.

[0084] In a further implementation, when multiple standardized diagnostic evidence packages output conflicting intermediate diagnostic conclusions for the same faulty object, the evaluation module does not directly discard any evidence package. Instead, it writes the evidence identifier, upstream evidence identifier, data source health, evidence freshness, evidence granularity, evidence lease status, and task-side evidence source pointer of each evidence package into a conflict evidence set, and inputs the conflict evidence set into a conflict evidence subtask. The conflict evidence subtask outputs conflict priority, supplementary collection suggestions, and causal invariance verification results, which are then used as inputs for subsequent node posterior confidence updates and path switching determinations.

[0085] In this step, the node state in the path model determines the evidence fields that the current diagnostic operator node needs to read, the diagnostic action determines how to process these fields, and the node execution result is encapsulated into a standardized diagnostic evidence package. The same standardized diagnostic evidence package serves as the input for the next node, the input for updating the node's posterior confidence, and the input for path switching determination. The evidence package fingerprint ensures the consistency of evidence transmission, the freshness of evidence affects subsequent confidence updates, the granularity of evidence constrains the fault location hierarchy, the lease status of evidence constrains the timeliness of evidence consumption, the conflict evidence marker triggers the conflict evidence subtask, the causal stability marker affects the path confidence, and the task edge evidence source pointer ensures the traceability of the evidence source.

[0086] This step unifies node results from different sources, formats, and semantic levels into standardized evidence objects. This allows subsequent diagnostic operators to continue execution simply by reading standardized fields, without needing to concern themselves with the internal algorithms of upstream nodes. Furthermore, it reduces diagnostic biases caused by evidence mistransmission, misuse of old data, inconsistent granularity of faulty objects, evidence conflicts, and causal instability through evidence package fingerprints, evidence freshness, evidence granularity, evidence lease status, conflict evidence markers, and causal stability markers.

[0087] S106. Update the node's posterior confidence and perform a backtracking switch.

[0088] Each time the evaluation module generates a new standardized diagnostic evidence package, it determines the actual benefit of the current diagnostic operator node based on this package. The actual benefit is determined by the node's execution status, the degree to which the input fields of the next node are satisfied, the convergence degree of the fault object range, device topology consistency, measurement point mapping consistency, the degree to which the evidence completeness conditions are met, the consistency of the evidence package fingerprint, the freshness of the evidence, the lease status of the evidence, the result of conflict evidence handling, the causal stability marker, and the node's execution time.

[0089] Specifically, if the current diagnostic sub-node executes successfully, and its standardized diagnostic evidence package can satisfy the input fields of the next node, can converge the scope of the fault object from the whole machine level to the subsystem level or from the subsystem level to the component level, can be consistent with the equipment topology and measurement point mapping, has consistent evidence package fingerprints, valid evidence leases, and conflicting evidence has been verified or resolved, and can improve the coverage of fault location, fault category, and evidence completeness conditions, then the actual benefit is high. If the current diagnostic sub-node fails to execute, the evidence package fingerprints are inconsistent, the evidence leases are invalid, the evidence is too old, the node output fields cannot be consumed downstream, conflicting evidence is unresolved, the causal stability marker is low, or the execution time exceeds the allowable range, then the actual benefit is low.

[0090] The posterior confidence of a node is updated according to the following formula: , in, Indicates the first The first in the candidate diagnostic chain The observed likelihood of each diagnostic operator node Indicates the candidate diagnostic chain number. Indicates the node number of the diagnostic operator. Indicates the first The first in the candidate diagnostic chain The actual benefit determined by each diagnostic operator node based on a standardized diagnostic evidence package. Indicates the first The first in the candidate diagnostic chain The predicted reward of each diagnostic operator node in the path model. Indicates the first The first in the candidate diagnostic chain The posterior confidence of each diagnostic operator node. Indicates the first The first in the candidate diagnostic chain The prior confidence of each diagnostic operator node. This represents a positive constant used to avoid a denominator of zero.

[0091] The evaluation module writes back the updated node posterior confidence to the current candidate diagnostic chain and the corresponding task branch. After the node posterior confidence is written back, the execution order of subsequent nodes in the current candidate diagnostic chain, the path switching candidate set, and the final path confidence can all be updated based on this posterior result.

[0092] When the posterior confidence of the current diagnostic operator node is lower than the switching threshold, and the current standardized diagnostic evidence package does not meet the completion criteria of the corresponding parent task, the backtracking switching module backtracks along the task graph to a parent task with unexecuted sibling nodes, and filters candidate diagnostic chains under that parent task that are compatible with the input and output of the current standardized diagnostic evidence package. Input and output compatibility means that the fault object identifier, time window, evidence granularity, node output fields, evidence lease status, conflict evidence markers, and evidence sources in the current standardized diagnostic evidence package can satisfy the node input fields of the head node of the candidate diagnostic chain to be switched.

[0093] The backtracking switching module writes a backtracking cooling mark for each path switch. The backtracking cooling mark includes the candidate diagnostic chain identifier, the switching reason, the evidence package fingerprint, the anomaly code, and the cooling period. When the same candidate diagnostic chain is repeatedly switched away within the cooling period due to the same evidence gap, the same anomaly code, the same evidence lease expiration reason, or the same unresolved conflicting evidence reason, the backtracking switching module increases the backtracking cooling penalty value of that candidate diagnostic chain to prevent the system from repeatedly oscillating between the same candidate diagnostic chains.

[0094] The backtracking handover module determines the handover score according to the following formula: , in, Indicates the first Switching scores for the available candidate diagnostic chains. Indicates the sequence number of the candidate diagnostic chain that can be switched. Indicates the first The average posterior confidence of evaluated diagnostic operator nodes in a switchable candidate diagnostic chain. Indicates the first The degree of input-output compatibility between the available candidate diagnostic chains and the current standardized diagnostic evidence package. Indicates the first The degree of matching between the available candidate diagnostic chains and the remaining target output constraints. Indicates the first The backtracking cooldown penalty value for each switchable candidate diagnostic chain. Indicates the first The causal stable gain of a switchable candidate diagnostic chain, The weights represent the average posterior confidence scores at each node. Weights representing the degree of input-output compatibility. The weights representing the remaining target output constraint matching degrees The weights representing the backtracking cooldown penalty values. The weights represent the causal stability gain.

[0095] When a path switch is required, the backtracking switching module selects the candidate diagnostic chain with the highest switching score as the new executable chain to continue execution. For example, if the current path can determine that the faulty object is located in the bearing of the aircraft engine accessory gearbox, but cannot reliably distinguish between inner ring spalling and outer ring wear, the backtracking switching module will prioritize selecting the candidate diagnostic chain corresponding to the sibling node under the same parent task that is compatible with the current standardized diagnostic evidence package input and output, has resolved conflicting evidence, and has a high causal stability gain, instead of switching to the candidate diagnostic chain related to the internal leakage of the airborne hydraulic pump or the imbalance of the air cycle machine rotor.

[0096] In this step, the standardized diagnostic evidence package provides the fields required for calculating the actual benefit. The actual benefit and the predicted reward in the path model form the observational likelihood. The observational likelihood is fused with the prior confidence of the node to obtain the posterior confidence of the node. The posterior confidence of the node is written back to the candidate diagnostic chain and the task branch. The written-back posterior confidence of the node then participates in the path switching score and the final path confidence calculation. The backtracking cooling mark feeds back the historical switching status to the current switching score. The causal stability gain makes the path switching prioritize candidate diagnostic chains that are not sensitive to disturbances of irrelevant fields and can stably support the remaining target output constraints.

[0097] When the performance evaluation module adopts the actual benefit evaluation model, the model is trained using historical standardized diagnostic evidence packages and manually confirmed node contribution values. During training, the following parameters are used as inputs: node execution status, the degree to which the next node's input fields are satisfied, the convergence degree of the fault object range, equipment topology consistency, measurement point mapping consistency, the degree to which evidence completeness conditions are met, evidence package fingerprint consistency, evidence freshness, evidence lease status, conflict evidence processing results, causal stability markers, and node execution time. The manually confirmed actual node contribution values ​​are used as supervision labels. The evaluation metrics are benefit prediction error, node ranking consistency, and low-confidence node identification accuracy.

[0098] This step utilizes the same standardized diagnostic evidence package to drive confidence updates and path backtracking switching. This avoids the blind re-execution of the entire path due to partial failures in traditional diagnostic processes. Furthermore, it reduces repeated switching between candidate diagnostic chains by backtracking cooling flags, evidence lease status, conflict evidence handling results, and causal stability gains, thereby improving the stability and efficiency of the diagnostic process.

[0099] S107. Determine path confidence, generate diagnostic program code, and perform code backfilling and repair.

[0100] Once a candidate diagnostic chain outputs the fault location and fault category and meets the evidence completeness condition, the code generation module determines the path confidence based on the node posterior confidence, execution success rate, evidence loop completeness, code shadow playback results, causal stability results, and evidence lease passage status. The path confidence is used to evaluate the credibility, evidence completeness, execution stability, causal stability, and code reusability of the entire candidate diagnostic chain in actual execution.

[0101] Path confidence is determined according to the following formula: , in, Indicates the first Path confidence of candidate diagnostic chains, Indicates the candidate diagnostic chain number. Indicates the first The average posterior confidence of all diagnostic operator nodes in a candidate diagnostic chain. Indicates the first The execution success rate of all diagnostic operator nodes in the candidate diagnostic chain. Indicates the first The completeness of the evidence loop for each candidate diagnostic chain regarding fault location, fault type, and evidence completeness conditions. Indicates the first The pass rate of code shadow replay after converting candidate diagnostic chains into diagnostic program code. Indicates the first The degree of causal invariance of the candidate diagnostic chain. Indicates the first The extent to which the evidence lease passes for the standardized diagnostic evidence package in the candidate diagnostic chain. The weights represent the average posterior confidence scores at each node. The weights representing the success rate of execution. The weight representing the completeness of the evidence loop. The weights representing the pass rate of code shadow playback. The weight representing the degree of causal invariance. The weighting indicates the degree to which the evidence lease is valid.

[0102] The code generation module maps the candidate diagnostic chain with the highest path confidence to diagnostic program code according to the node order of the diagnostic operator nodes. Specifically, data acquisition nodes are mapped to interface call statements, feature construction nodes are mapped to data processing statements, anomaly detection nodes are mapped to conditional judgment statements, object granularity refinement nodes are mapped to field completion statements, cross-validation nodes are mapped to validation statements, conflict evidence validation nodes are mapped to conflict resolution statements, causal invariance verification nodes are mapped to stability verification statements, evidence renewal nodes are mapped to evidence validity verification statements, root cause localization nodes are mapped to model inference statements, and result output nodes are mapped to output statements for fault location, fault category, and evidence chain. The diagnostic program code can be in Python (scripting language), Shell (command interpreter script), or a combination of both.

[0103] Before outputting the diagnostic program code, the code generation module performs field connectivity checks on the diagnostic program code. Field connectivity checks verify whether each input field originates from an upstream standardized diagnostic evidence package or API call result, whether each intermediate field is consumed by at least one downstream statement, and whether each output field covers the fault location, fault category, and evidence chain. It also checks whether the evidence lease status field, conflict evidence marker field, and causal stability marker field are consumed by the corresponding code statements. If an input field has no upstream source, an intermediate field is not consumed by a downstream statement, the output field does not cover the fault location, fault category, and evidence chain, or the evidence lease status field, conflict evidence marker field, and causal stability marker field are not consumed by the corresponding code statements, the code generation module selects the candidate diagnostic chain with the second-highest path confidence to regenerate the diagnostic program code.

[0104] The code generation module also performs code shadow playback. Code shadow playback runs the generated diagnostic code on desensitized historical samples or simulated evidence packages without accessing actual production equipment. This verifies whether the diagnostic code can complete field reading, feature processing, condition judgment, object granularity refinement, cross-validation, conflict evidence resolution, causal invariance verification, evidence lease verification, model inference, and result output. The code shadow playback result is written into the code shadow playback pass rate in the path confidence. If the code shadow playback fails, the code generation module lowers the path confidence corresponding to the candidate diagnostic chain and selects a new candidate diagnostic chain to regenerate the diagnostic code.

[0105] In a further implementation, the code generation module also performs code backfeeding and repair. This code backfeeding and repair refers to the process where, when field connectivity checks or code shadow playback detect issues in the diagnostic program code such as missing fields, mismatched interfaces, unverified evidence leases, unconsumed conflicting evidence, or unconsumed causal stability markers, the code is not directly discarded. Instead, the problematic fields, corresponding diagnostic operator nodes, corresponding standardized diagnostic evidence packages, and the locations of failed statements are backfeeded to the candidate diagnostic chain, triggering partial repair of the candidate diagnostic chain. Partial repair includes inserting field completion statements, replacing interface call statements, adding evidence lease verification statements, adding conflicting evidence resolution statements, or adding causal invariance verification statements. The repaired candidate diagnostic chain undergoes field connectivity checks and code shadow playback again, and only after passing these checks is the diagnostic program code output.

[0106] After generating the diagnostic procedure code, the system uses this code to output the fault location, fault type, and evidence chain. The evidence chain includes the evidence identifier of each standardized diagnostic evidence package, upstream evidence identifier, task-side evidence source pointer, node execution status, evidence package fingerprint, intermediate diagnostic conclusions, evidence lease status, conflict evidence markers, and causal stability markers, enabling operations and maintenance personnel to trace the data sources, diagnostic nodes, path selection criteria, and conflict evidence handling processes upon which the fault conclusions depend.

[0107] In this step, the candidate diagnostic chain provides the node order, node input fields, node output fields, and calling object fields; the standardized diagnostic evidence package provides the source of code fields and the basis for the output of the evidence chain; the path confidence is jointly determined by the node posterior confidence, execution success rate, evidence loop integrity, code shadow playback pass rate, causal invariance pass rate, and evidence lease pass rate; the path confidence determines the candidate diagnostic chain on which the diagnostic program code is generated; the results of field connectivity verification, code shadow playback, and code re-injection repair are further fed back to the candidate diagnostic chain, so that the diagnostic program code generation and evidence loop verification form a closed loop.

[0108] When the code generation module employs a code generation model, the model is trained using paired samples of "candidate diagnostic chain - manually confirmed diagnostic procedure code". During training, the node order, node input fields, node output fields, calling object fields, standardized diagnostic evidence package fields, task-side evidence source pointers, evidence lease status, conflict evidence markers, causal stability markers, and target output fields in the candidate diagnostic chain are used as inputs. Manually confirmed executable diagnostic procedure code is used as a supervision label. The training evaluation metrics include syntax accuracy, interface call accuracy, field connectivity verification pass rate, code shadow playback pass rate, evidence lease verification coverage, conflict evidence consumption coverage, causal stability marker consumption coverage, and output field completeness. When the code generation module uses a template mapping method, each diagnostic operator node in the operator template library is pre-configured with a corresponding code fragment template. The code generation module then assembles these templates according to the node order and field mapping relationships of the candidate diagnostic chain to form complete diagnostic procedure code.

[0109] This step solidifies the diagnostic path—completing evidence loop verification, conflict evidence handling, and causal invariance verification—into reproducible diagnostic program code. This transforms a one-time fault diagnosis process into a deployable and reusable automated diagnostic tool. Furthermore, through field connectivity verification, code shadow playback, and code re-injection repair, it reduces the risk of execution failures during actual deployment due to missing fields, interface mismatches, expired evidence, unhandled conflict evidence, or insufficient causal stability.

[0110] like Figure 2 As shown, this embodiment also provides an intelligent fault diagnosis system based on task graph evidence closed loop. The system includes a target generation module for sequential data connection, a task graph construction module, a diagnostic chain generation module, a path modeling module, an execution evaluation module, a backtracking switching module, and a code generation module.

[0111] The target generation module receives fault diagnosis requests, equipment topology, measurement point mapping, interface list and historical fault samples, and generates a structured diagnostic target containing fault objects, observation variables, data source identifiers, candidate diagnostic operators, target output constraints, data source health and evidence lease parameters. The target output constraints include fault location, fault category and evidence completeness conditions, and the structured diagnostic target is output to the task graph construction module.

[0112] The task graph construction module uses the target output constraint as the root task output boundary and the observed variables, data source identifiers, and data source health as the sub-task input boundaries. It constructs a task graph that couples the parent and sub-tasks through input interface definitions, output interface definitions, completion criteria, and task edge evidence source pointers. It also generates an evidence gap graph based on the differences between the required output fields corresponding to the target output constraint and the fields already satisfied in the task graph. When different data modalities output conflicting intermediate diagnostic conclusions for the same fault object or the same fault category, the task graph construction module generates conflict evidence sub-tasks and outputs the task graph, evidence gap graph, and conflict evidence sub-tasks to the diagnostic chain generation module.

[0113] The diagnostic chain generation module generates candidate diagnostic chains based on the task graph, evidence gap graph, and conflict evidence subtasks. It then performs candidate chain shadow playback, counterfactual shadow playback, interface compatibility verification, data source reachability verification, evidence granularity consistency verification, causal invariance verification, and evidence loop closure verification on the candidate diagnostic chains. The candidate diagnostic chains that pass the verification are determined as executable chains, and the executable chains are output to the path modeling module.

[0114] The path modeling module establishes a path model for the executable chain that corresponds to the diagnostic operator nodes with their node states, diagnostic actions, predicted rewards, and prior confidence levels. This path model is then output to the execution evaluation module. The execution evaluation module executes the diagnostic operator nodes according to their prior confidence levels, encapsulating the node results into a standardized diagnostic evidence package containing evidence package fingerprints, evidence freshness, evidence granularity, evidence lease status, conflict evidence markers, and causal stability markers. This standardized diagnostic evidence package is then used as input for the next node, for updating the node's posterior confidence level, and for determining path switching.

[0115] When the posterior confidence of the current diagnostic operator node is lower than the switching threshold and the current standardized diagnostic evidence package does not meet the completion criteria of the corresponding parent task, the backtracking switching module backtracks along the task graph to the parent task with an unexecuted sibling node, and switches to the input-output compatible candidate diagnostic chain to continue execution by combining the backtracking cooling mark, input-output compatibility, remaining target output constraint matching degree and causal stability gain.

[0116] After the candidate diagnostic chain outputs the fault location and fault category and meets the evidence completeness condition, the code generation module determines the path confidence based on the node posterior confidence, execution success rate, evidence loop integrity, code shadow playback result, causal invariance pass degree, and evidence lease pass degree. The candidate diagnostic chain with the highest path confidence is converted into diagnostic program code, and code backfilling repair is performed when field connectivity verification or code shadow playback fails. Finally, the fault location, fault category, and evidence chain are output.

[0117] In terms of hardware implementation, the target generation module, task graph construction module, diagnostic chain generation module, path modeling module, execution evaluation module, backtracking switching module, and code generation module can be implemented by one or more processors, memory, and communication interfaces, or deployed in industrial servers, edge computing terminals, or cloud diagnostic platforms. The modules communicate with each other through structured diagnostic targets, task graphs, evidence gap graphs, conflict evidence subtasks, candidate diagnostic chains, executable chains, path models, standardized diagnostic evidence packages, node posterior confidence, backtracking cooling markers, path confidence, and diagnostic program code. This creates a closed-loop data processing chain from fault diagnosis request input to diagnostic program code output.

[0118] Comparative experiment

[0119] This invention selects aero-engine accessory transmission systems, airborne hydraulic pump stations, landing gear retraction and extension mechanisms, aero-environmental control air circulators, airborne generators, fuel supply pumps, and auxiliary power unit starting transmission units as test objects for aerospace industrial equipment, and constructs an experimental dataset containing 2,400 fault samples. Among them, 1,900 samples are used for model training, operator template configuration, and parameter setting, and 500 samples are used for independent testing.

[0120] The fault samples cover fault locations in aircraft engine accessory gearboxes, main shaft bearings, accessory drive shafts, hydraulic pump slipper pairs, servo valves, actuator cylinder seals, landing gear locking mechanisms, air circulator rotors, cooling fans, generator windings, fuel pump bearings, and auxiliary power unit transmission gears. Fault categories cover bearing inner ring peeling, bearing outer ring wear, tooth surface pitting, tooth surface scuffing, drive shaft misalignment, hydraulic pump internal leakage, servo valve sticking, actuator cylinder seal leakage, locking mechanism misalignment, air circulator rotor imbalance, fan blade wear, generator winding overheating, abnormal fuel pump pressure supply, and abnormal starting transmission shock.

[0121] To verify the adaptability of this invention under complex operating conditions in aviation equipment, 150 interface fluctuation samples, 110 expired data source samples, 120 conflicting multi-source evidence samples, 90 samples with inconsistent fault object granularity, and 80 samples with missing diagnostic program code fields were included in the 500 independent test samples. Some samples exhibited multiple anomalies simultaneously. The interface fluctuation samples included time-series database response delays, unstable airborne maintenance log interfaces, and short-term inaccessibility of the model file library; the expired data source samples included vibration data time window offsets, hydraulic pressure data not being updated in a timely manner, and inconsistent temperature data sampling periods; the conflicting multi-source evidence samples included situations where vibration evidence pointed to bearing failure while temperature evidence pointed to lubrication abnormalities, and hydraulic pressure evidence pointed to pump internal leakage while actuator cylinder displacement evidence pointed to seal leakage, etc.

[0122] The comparison scheme is set as follows.

[0123] In contrast, Option 1 is a fixed threshold rule-based diagnostic scheme that only uses preset thresholds, a fixed diagnostic order, and manually configured rules. It does not construct a task graph, generate candidate diagnostic chains, or perform evidence loop verification.

[0124] The second scheme is an aviation equipment knowledge graph diagnostic scheme, which performs fault reasoning based on the relationships between aviation equipment components, fault mode relationships and maintenance records, but does not generate evidence gap graphs, and does not perform candidate chain shadow playback and counterfactual shadow playback.

[0125] In contrast, Scheme 3 is a multi-model, multi-path diagnostic scheme that can generate multiple candidate diagnostic paths based on different data modalities. However, it does not use the same standardized diagnostic evidence package to simultaneously drive the next node input, node posterior confidence update, and path switching determination, nor does it set a backtracking cooling flag.

[0126] Compared to Scheme 4, which is a closed-loop scheme based on a task graph evidence, Scheme 4 constructs a task graph, candidate diagnostic chains, and standardized diagnostic evidence packages, but does not introduce evidence leases, conflicting evidence subtasks, causal invariance verification, counterfactual shadow playback, or code re-injection and repair.

[0127] The present invention adopts the complete solution described in this embodiment, which simultaneously employs structured diagnostic objectives, task graphs, evidence gap graphs, candidate chain shadow replay, counterfactual shadow replay, standardized diagnostic evidence packages, evidence leases, conflicting evidence subtasks, causal invariance verification, node posterior confidence updates, backtracking cooling markers, path confidence, code shadow replay, and code re-injection repair.

[0128] The overall experimental results of each scheme on the independent test set of aviation industrial equipment are shown in the table below.

[0129] Comparison Option 1 83.6% 80.9% 56.8% 41.5% 14.2% 3.8 14.6 seconds 68.7% Comparison Option 2 88.4% 85.7% 66.9% 54.6% 10.5% 2.9 12.5 seconds 75.8% Comparison Option 3 91.7% 89.5% 79.6% 63.8% 7.9% 2.1 10.7 seconds 85.1% Comparison Option 4 94.8% 93.1% 90.7% 77.5% 4.4% 1.3 9.1 seconds 92.4% Invention Solution 97.1% 95.9% 97.8% 91.9% 1.5% 0.6 7.6 seconds 96.8%

[0130] The results show that the present invention's solution outperforms the comparative solutions in scenarios involving aviation equipment such as aero-engine accessory transmission systems, airborne hydraulic pump stations, landing gear retraction mechanisms, aviation environmental control air circulators, airborne generators, and fuel supply pumps. These improvements include higher accuracy in fault location, fault category, completeness of evidence loop closure, correct resolution of conflicting evidence, and first-time code execution rate. Furthermore, the present invention significantly reduces the evidence misuse rate, average number of invalid branch visits, and average diagnosis time per case. These results demonstrate that the present invention can improve the accuracy, stability, and automated deployment capabilities of fault diagnosis in scenarios involving multi-component coupling, multi-measurement point acquisition, multi-interface access, significant changes in operating conditions, and numerous conflicting evidence in aviation equipment.

[0131] To further verify the role of the newly added key technical features, an ablation experiment was conducted on the scheme of this invention. The ablation experiment maintained the same training set, test set, and evaluation metrics, removing only the corresponding technical features while keeping the rest of the processing unchanged. The experimental results are shown in the table below.

[0132] Remove evidence lease 95.7% 94.3% 95.2% 88.7% 5.3% 95.0% Removing conflicting evidence subtask 95.3% 93.8% 95.9% 72.8% 4.1% 95.2% Remove causality invariance check 95.0% 93.5% 95.6% 85.6% 3.9% 94.9% Remove counterfactual shadow playback 95.5% 94.0% 96.1% 86.2% 3.6% 95.3% Remove backcooling marker 95.8% 94.5% 96.4% 87.9% 3.1% 95.8% Remove code re-feedback and fix 96.6% 95.4% 97.0% 90.6% 1.9% 92.3% Invention Solution 97.1% 95.9% 97.8% 91.9% 1.5% 96.8%

[0133] Ablation experiments show that evidence leases can effectively reduce the probability of downstream nodes misusing expired vibration data, delayed hydraulic pressure data, and hysteretic temperature data; conflict evidence subtasks can significantly improve the correct resolution rate when there are conflicts between vibration, pressure, temperature, displacement, and maintenance logs; causal invariance verification and counterfactual shadow playback can reduce the diagnostic chain's over-reliance on irrelevant operating condition fields, unstable interface fields, or accidental noise features; backtracking cooling markers can reduce invalid execution caused by repeated switching of paths between multiple candidate diagnostic chains; code backfeed repair can perform local repairs on candidate diagnostic chains when field connectivity verification or code shadow playback fails, thereby improving the first-run executability rate of diagnostic program code.

[0134] Furthermore, to verify the robustness of the present invention under typical abnormal scenarios of aviation equipment, the test set was grouped and statistically analyzed according to interface fluctuations, expired data sources, conflicting evidence from multiple sources, inconsistent granularity of fault objects, and switching of operating conditions. The results are shown in the table below.

[0135] Interface fluctuation scenarios 91.2% 95.1% 88.9% 96.4% Data source expiration scenario 89.7% 95.8% 87.6% 97.1% Multi-source evidence conflict scenario 87.9% 94.9% 87.2% 96.2% Inconsistent granularity of fault objects 91.8% 96.3% 89.8% 97.9% Working condition switching scenario 90.6% 95.5% 88.5% 96.8%

[0136] The grouping results above show that, in scenarios involving interface fluctuations, expired data sources, conflicting multi-source evidence, inconsistent granularity of fault objects, and switching operating conditions, the solution of this invention exhibits higher fault category accuracy and evidence loop integrity rate. This is because: data source health and evidence leases can identify issues such as unreachable data sources, outdated data, and expired evidence; the conflicting evidence subtask can transform conflicts between multi-source evidence into executable verification tasks; evidence granularity consistency verification and object granularity refinement nodes can avoid jumping directly from system-level anomalies to component-level fault conclusions; and causal invariance verification and counterfactual shadow playback can suppress interference from irrelevant operating condition fields or accidental fluctuation fields on fault conclusions.

[0137] To verify the effectiveness of the diagnostic program code generation, we further analyzed the field connectivity during the code generation phase and the pre-deployment verification for each solution. The results are shown in the table below.

[0138] Comparison Option 1 70.8% 68.7% — 66.5% Comparison Option 2 78.9% 75.8% — 73.6% Comparison Option 3 87.5% 85.1% — 82.9% Comparison Option 4 93.2% 92.4% — 90.6% Invention Solution 97.4% 96.8% 87.9% 96.1%

[0139] The above results show that the present invention, by mapping the data acquisition nodes, feature construction nodes, anomaly detection nodes, object granularity refinement nodes, cross-validation nodes, conflict evidence verification nodes, causal invariance verification nodes, evidence renewal nodes, and root cause localization nodes in the candidate diagnostic chain to corresponding statements in the diagnostic program code, and performing field connectivity verification, code shadow playback, and code re-injection repair before outputting the diagnostic program code, can significantly improve the field integrity, shadow playback pass rate, and final deployability rate of the generated code.

[0140] In summary, both comparative and ablation experiments demonstrate that this invention does not merely improve diagnostic effectiveness by adding diagnostic steps. Instead, it achieves this through continuous data coupling between structured diagnostic objectives, task graphs, evidence gap graphs, candidate diagnostic chains, standardized diagnostic evidence packages, evidence leases, conflicting evidence subtasks, causal invariance verification, node posterior confidence, backtracking cooling markers, path confidence, code shadow playback, and code re-injection repair. This creates a complete closed loop in the fault diagnosis process for aerospace industrial equipment, encompassing diagnostic request input, diagnostic path generation, evidence closed-loop verification, and path switching to diagnostic program code output. Therefore, this invention can improve fault diagnosis accuracy, evidence chain integrity, path execution stability, and diagnostic program code deployability in complex aerospace equipment scenarios such as aero-engine accessory transmissions, airborne hydraulics, landing gear retraction and extension, aerospace environmental control, and aerospace power and fuel supply.

Claims

1. An intelligent fault diagnosis method based on task graph evidence closed loop, characterized in that, include: The system receives fault diagnosis requests and the device topology, measurement point mapping, interface list, and historical fault samples of the object to be diagnosed. It generates a structured diagnostic target containing the fault object, observed variables, data source identifier, candidate diagnostic operators, target output constraints, and data source health. The target output constraints include fault location, fault category, and evidence completeness conditions. Using the target output constraints as the root task output boundary and the observed variables, data source identifier, and data source health as sub-task input boundaries, a task graph is constructed, coupling parent and child tasks through input interface definitions, output interface definitions, completion criteria, and task-edge evidence source pointers. An evidence gap graph is generated. Based on the task graph and the evidence gap graph, a candidate diagnostic chain is generated, and an executable chain is determined through candidate chain shadow playback, interface compatibility, data source reachability, evidence granularity consistency, and evidence loop closure verification. A path model for the executable chain is established, and diagnostic operator nodes are executed. The node results are encapsulated into a standardized diagnostic evidence package, which serves as the input for the next node, the posterior confidence update input for the node, and the path switching judgment input. When the posterior confidence of a node is lower than the switching threshold and the standardized diagnostic evidence package does not meet the completion criteria of the corresponding parent task, backtrack along the task graph and switch to an input-output compatible candidate diagnostic chain in combination with the backtracking cooling mark; after the candidate diagnostic chain meets the target output constraint, determine the path confidence and convert the candidate diagnostic chain with the highest path confidence into diagnostic program code, and output the diagnostic results including fault location, fault category and evidence chain.

2. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 1, characterized in that, The data source health score is used to quantify the availability of the data source corresponding to the data source identifier, and is determined according to the following formula: in, Indicates the first The health status of each data source. Indicates the data source sequence number. Indicates the first Access reachability of each data source Indicates the first Data freshness of each data source Indicates the first Historical error rate of each data source Weights representing access reachability Weights representing the freshness of data The weights represent the historical error rate; the health of the data source is written into the structured diagnostic target and serves as a common input for the task graph construction, the candidate diagnostic chain generation, and the node prior confidence initialization.

3. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 2, characterized in that, The construction of the task graph and the generation of the evidence gap graph include: determining the target output constraint as the output boundary of the root task; determining the input boundary of the subtask based on the observed variable, the data source identifier, and the health of the data source; writing input interface definition, output interface definition, and completion criteria for each task node; when the output interface definition of a subtask satisfies the input interface definition of the parent task, connecting the subtask to the corresponding parent task through a task edge, and recording the subtask output field, data source identifier, measurement point mapping relationship, and historical fault sample basis in the task edge evidence source pointer; generating the evidence gap graph based on the difference between the required output field corresponding to the target output constraint and the fields already satisfied in the task graph, wherein the evidence gap graph records the missing field name, corresponding fault object, optional data source, complete diagnostic operator, and missing priority.

4. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 3, characterized in that, The step of generating candidate diagnostic chains based on the task graph and the evidence gap graph includes: retrieving template chains from the operator template library that simultaneously satisfy the subtask input interface definition and output interface definition; when the template chain has unsatisfied input fields, inserting data acquisition nodes, feature construction nodes, object granularity refinement nodes, or cross-validation nodes according to the evidence gap graph to form a completion chain; merging the template chain and the completion chain at the node level to obtain candidate diagnostic chains; performing candidate chain shadow playback on the candidate diagnostic chains using de-identified historical fault samples and field placeholder data without calling real production interfaces; when the candidate chain shadow playback shows missing node input fields, node output fields that cannot be consumed by downstream nodes, calling object fields that cannot be mapped to the interface list, or end output fields that do not meet the completion criteria of the corresponding parent task, correcting, downgrading, or eliminating the corresponding candidate diagnostic chains.

5. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 4, characterized in that, The interface compatibility is used to verify whether the node output fields and node input fields between adjacent diagnostic operator nodes match; the data source reachability is used to verify whether the data source, interface, model file, or rule base corresponding to the calling object field of the diagnostic operator node is accessible; the evidence granularity consistency is used to determine whether the fault object granularity output by each diagnostic operator node in the candidate diagnostic chain converges to the granularity required by the completion criteria of the corresponding parent task according to the whole machine level, subsystem level, component level, or measurement point level; when the fault object granularity output by the upstream diagnostic operator node cannot meet the input granularity requirements of the downstream diagnostic operator node, the object granularity refinement node is called to complete it; when the object granularity refinement node fails to complete, or the output field at the end of the candidate diagnostic chain does not simultaneously cover the fault location, fault category, and evidence completeness conditions, it is determined that the corresponding candidate diagnostic chain has not passed the evidence closed-loop verification.

6. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 5, characterized in that, The standardized diagnostic evidence package includes evidence identifier, upstream evidence identifier, fault object identifier, data source identifier, time window, node identifier, diagnostic operator identifier, node input field, node output field, raw data summary, feature results, intermediate diagnostic conclusions, anomaly code, node execution status, evidence timestamp, task-side evidence source pointer, evidence package fingerprint, evidence freshness, evidence granularity, evidence lease status, conflict evidence marker, and causal stability marker. The evidence package fingerprint is generated according to the following formula: in, Indicates the first A standardized diagnostic evidence package includes fingerprints. Indicates the serial number of the standardized diagnostic evidence package. Represents a hash function. Indicates the first Evidence identifiers for a standardized diagnostic evidence package, Indicates the first Upstream evidence identifiers for a standardized diagnostic evidence package Indicates the first A standardized diagnostic evidence package includes a fault object identifier. Indicates the first The data source identifier for a standardized diagnostic evidence package. Indicates the first A time window for a standardized diagnostic evidence package. Indicates the first The node output fields of a standardized diagnostic evidence package; the evidence package fingerprint is used to identify evidence package reuse, cross-task mistransmission, or field tampering.

7. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 6, characterized in that, The path model maps diagnostic operator nodes to node states, diagnostic actions, predicted rewards, and prior confidence levels. The posterior confidence levels of nodes are updated according to the following formula: in, Indicates the first The first in the candidate diagnostic chain The observed likelihood of each diagnostic operator node Indicates the candidate diagnostic chain number. Indicates the node number of the diagnostic operator. Indicates the first The first in the candidate diagnostic chain The actual benefit determined by each diagnostic operator node based on the standardized diagnostic evidence package. Indicates the first The first in the candidate diagnostic chain The predicted reward of each diagnostic operator node in the path model. Indicates the first The first in the candidate diagnostic chain The posterior confidence of each diagnostic operator node. Indicates the first The first in the candidate diagnostic chain The prior confidence of each diagnostic operator node. This represents a positive constant used to avoid a denominator of zero; the actual benefit is determined by the node execution status, the degree of satisfaction of the input field of the next node, the degree of convergence of the fault object range, the consistency of the device topology, the consistency of the measurement point mapping, the degree of satisfaction of the evidence completeness conditions, the consistency of the evidence package fingerprint, the freshness of the evidence, the lease status of the evidence, the result of conflict evidence processing, the causal stability marker, and the node execution time.

8. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 7, characterized in that, The backtracking cooling flag includes the candidate diagnostic chain identifier, switching reason, evidence package fingerprint, anomaly code, and cooling period; the switching to an input / output compatible candidate diagnostic chain based on the backtracking cooling flag includes determining the switching score according to the following formula: in, Indicates the first Switching scores for the available candidate diagnostic chains. Indicates the sequence number of the candidate diagnostic chain that can be switched. Indicates the first The average posterior confidence of evaluated diagnostic operator nodes in a switchable candidate diagnostic chain. Indicates the first The degree of input-output compatibility between the available candidate diagnostic chains and the current standardized diagnostic evidence package. Indicates the first The degree of matching between the available candidate diagnostic chains and the remaining target output constraints. Indicates the first The backtracking cooldown penalty value for each switchable candidate diagnostic chain. Indicates the first The causal stable gain of a switchable candidate diagnostic chain, The weights represent the average posterior confidence scores at each node. Weights representing the degree of input-output compatibility. The weights representing the remaining target output constraint matching degrees The weights representing the backtracking cooldown penalty values. The weights represent the causal stability gain; when the same candidate diagnostic chain is repeatedly switched out during the cooling period due to the same evidence gap or the same anomaly code, the backtracking cooling penalty value is increased, and the candidate diagnostic chain with the highest switching score is selected to continue execution.

9. The intelligent fault diagnosis method based on task graph evidence closed loop according to claim 8, characterized in that, The process of determining the path confidence and converting the candidate diagnostic chain with the highest path confidence into diagnostic program code includes determining the path confidence according to the following formula: in, Indicates the first Path confidence of candidate diagnostic chains, Indicates the candidate diagnostic chain number. Indicates the first The average posterior confidence of all diagnostic operator nodes in a candidate diagnostic chain. Indicates the first The execution success rate of all diagnostic operator nodes in the candidate diagnostic chain. Indicates the first The completeness of the evidence loop for each candidate diagnostic chain regarding fault location, fault type, and evidence completeness conditions. Indicates the first The pass rate of code shadow replay after converting candidate diagnostic chains into diagnostic program code. Indicates the first The degree of causal invariance of the candidate diagnostic chain. Indicates the first The extent to which the evidence lease passes for the standardized diagnostic evidence package in the candidate diagnostic chain. The weights represent the average posterior confidence scores at each node. The weights representing the success rate of execution. The weight representing the completeness of the evidence loop. The weights representing the pass rate of code shadow playback. The weight representing the degree of causal invariance. The weights represent the degree of acceptance of the evidence lease; the data acquisition nodes, feature construction nodes, anomaly detection nodes, object granularity refinement nodes, cross-validation nodes, and root cause localization nodes in the candidate diagnostic chain with the highest path confidence are mapped to interface call statements, data processing statements, condition judgment statements, field completion statements, verification statements, and model inference statements, respectively, and field connectivity verification and code shadow playback are performed before the output diagnostic program code.

10. An intelligent fault diagnosis system based on task graph evidence closed-loop, characterized in that, It includes a target generation module, a task graph construction module, a diagnostic chain generation module, a path modeling module, an execution evaluation module, a backtracking and switching module, and a code generation module. The target generation module is used to generate structured diagnostic targets based on fault diagnosis requests, equipment topology, measurement point mapping, interface list and historical fault samples. The structured diagnostic targets include fault objects, observation variables, data source identifiers, candidate diagnostic operators, target output constraints and data source health. The task graph construction module is used to construct a task graph that couples parent and child tasks through input interface definition, output interface definition, completion criteria, and task edge evidence source pointers, with the target output constraint as the root task output boundary and the observed variables, data source identifiers, and data source health as the sub-task input boundaries, and generates an evidence gap graph. The diagnostic chain generation module is used to generate candidate diagnostic chains based on the task graph and evidence gap graph, and to determine the executable chain through candidate chain shadow playback, interface compatibility, data source reachability, evidence granularity consistency and evidence closed loop verification. The path modeling module is used to establish a path model that corresponds to the diagnostic operator node with the node state, diagnostic action, predicted reward and node prior confidence; the execution evaluation module is used to execute the diagnostic operator node, encapsulate the node result into a standardized diagnostic evidence package, and enable the same standardized diagnostic evidence package to drive the next node input, node posterior confidence update and path switching determination. The backtracking switching module is used to switch to an input-output compatible candidate diagnostic chain when the posterior confidence of a node is lower than the switching threshold and the standardized diagnostic evidence package does not meet the completion criteria of the corresponding parent task, in conjunction with the backtracking cooling flag. The code generation module is used to determine the path confidence and convert the candidate diagnostic chain with the highest path confidence into diagnostic program code, and output diagnostic results including fault location, fault category and evidence chain.

Images