Two-way data interaction method and system based on upper computer and test platform

Abstract

The invention provides a data bidirectional interaction method and system based on an upper computer and a test platform, and relates to the technical field of industrial automation, and the method comprises the steps: obtaining the capability description information of the test platform through the upper computer to construct a protocol adaptation rule, transmitting a test instruction with an identifier, receiving test data with a traceability sequence and state feedback, and transmitting the test data to the upper computer; the instruction sending frequency is dynamically adjusted according to state feedback, the dependency graph is constructed based on the traceability sequence, the weight is distributed, and the root cause node is determined through weight propagation and sub-graph matching, so that rapid positioning and optimization adjustment of test abnormity are realized, and the test efficiency and accuracy are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of industrial automation, and in particular to a host computer and test platform data bidirectional interaction method and system. BACKGROUND

[0002] With the rapid development of industrial automation and intelligent manufacturing, data interaction between the host computer and the test platform plays a crucial role in modern test systems. The prior art lacks real-time perception and dynamic adaptation capability of the test platform state, and cannot automatically adjust the sending frequency of test instructions according to the load state of the test platform, which easily causes the test platform to be overloaded or resources to be wasted, affecting the test efficiency and accuracy; the data interaction method fails to effectively build the dependency relationship between test data, lacks systematic management of the traceability sequence of test data, and thus it is difficult to identify the internal relationship between test data when facing complex test scenarios, affecting the traceability analysis capability of abnormal data. SUMMARY

[0003] The embodiment of the present application provides a host computer and test platform data bidirectional interaction method and system, which can solve the problems in the prior art.

[0004] In a first aspect, the embodiment of the present application provides a host computer and test platform data bidirectional interaction method, which comprises: The host computer acquires the capability description information of the test platform and constructs protocol adaptation rules, generates a test instruction sequence and assigns an instruction identifier to each test instruction, and then sends the test instruction sequence to the test platform; Receiving test data returned by the test platform, the test data carrying a traceability sequence and a state feedback, adjusting the sending frequency of subsequent test instructions when the state feedback meets the load determination condition, determining an execution scheme according to the feasibility feedback returned by the test platform and sending the execution scheme to the test platform; Based on the traceability sequence, a dependency directed acyclic graph is constructed, an influence weight is assigned to a dependency edge, weight propagation update is performed along the dependency edge according to the test data deviation, and when abnormal test data is detected, a dependency path that meets the priority traceability condition is filtered to extract a set of predecessor nodes; The set of predecessor nodes of multiple abnormal test data is subjected to subgraph matching to identify a common predecessor subgraph, a root cause node is determined according to the cumulative weight of the nodes in the common predecessor subgraph on the dependency path, and the execution strategy is optimized and adjusted to generate an adjustment strategy which is sent to the test platform.

[0005] The step of the host computer acquiring the capability description information of the test platform and constructing protocol adaptation rules, generating a test instruction sequence and assigning an instruction identifier to each test instruction, and then sending the test instruction sequence to the test platform comprises: Receiving capability description information returned by the test platform, the capability description information including supported instruction set types, data interface formats and resource constraint parameters, and marking a version number for the capability description information; Determining instruction categories requiring protocol conversion according to the instruction set types, extracting difference features of source instruction formats and target instruction formats for each instruction category, and constructing a field mapping relationship table in combination with the data interface formats; determining test platform load determination conditions according to the resource constraint parameters; integrating the field mapping relationship table and the load determination conditions to form a protocol adaptation rule and associating the version number; Periodically acquiring current capability description information and performing difference comparison with stored versions, reconstructing a field mapping relationship table and updating load determination conditions for changed parts when changes are detected, generating a new version protocol adaptation rule and establishing a mapping relationship between the new and old versions; Generating a test instruction sequence according to the new version protocol adaptation rule, and embedding the version number in an instruction identifier of each test instruction, so that the test instruction carries version information of the protocol adaptation rule used by the test instruction and is sent to the test platform.

[0006] Receiving test data returned by the test platform, the test data carrying a trace sequence and a state feedback, adjusting a sending frequency of subsequent test instructions when the state feedback satisfies the load determination condition, and the steps of determining an execution scheme according to the feasibility feedback returned by the test platform and sending the execution scheme to the test platform comprising: Parsing the trace sequence and the state feedback from the received test data, the state feedback including a resource occupation state and an instruction processing response time; Comparing the resource occupation state with a resource occupation threshold in the protocol adaptation rule, and comparing the instruction processing response time with a response delay threshold, and determining that the load determination condition is satisfied when any threshold is exceeded; When the load determination condition is satisfied, calculating an adjustment coefficient according to the resource occupation state and the instruction processing response time, reducing the sending frequency of subsequent test instructions according to the adjustment coefficient and generating an execution strategy; sending the execution strategy to the test platform and receiving a feasibility feedback, the feasibility feedback including a determination result of whether the execution strategy is acceptable, taking the execution strategy as an execution scheme when it is acceptable, and regenerating an execution strategy according to suggested parameters in the feasibility feedback as an execution scheme sent to the test platform when it is not acceptable; and maintaining the current test instruction sending frequency when the load determination condition is not satisfied.

[0007] Constructing a dependency directed acyclic graph based on the trace sequence, assigning influence weights to dependency edges, and updating weights along dependency edges according to test data deviations, and the steps of filtering a dependency path satisfying a priority tracing condition to extract a set of predecessor nodes when abnormal test data is detected comprising: extracting trigger instructions, intermediate processing links and identifier of influence state from the traceability sequence as nodes, establishing directed edges according to the order and influence relationship between identifiers to form a directed acyclic graph of dependency relationship; allocating an initial influence weight according to the source node type and target node type connected by each directed edge, and creating a weight evolution sequence for each directed edge; calculating test data deviation by comparing test data with expected value, locating corresponding target node from the directed acyclic graph of dependency relationship, and updating influence weight from the target node along the reverse direction of the dependency edge and appending to the weight evolution sequence; calculating weight fluctuation characteristics of the dependency edge based on the weight evolution sequence, and marking as strong causal dependency edge when the weight fluctuation characteristics meet the stability condition, otherwise marking as weak correlation dependency edge; extracting abnormal nodes from the directed acyclic graph of dependency relationship when detecting abnormal test data, traversing the predecessor path along the strong causal dependency edge from the abnormal node, screening the dependency path combined with the updated influence weight of the dependency edge, and extracting the predecessor nodes on the dependency path to form a set of predecessor nodes.

[0008] The step of updating the influence weight from the target node along the dependency edge and appending to the weight evolution sequence comprises: determining the initial propagation intensity according to the magnitude of the test data deviation, obtaining all incoming edges and corresponding predecessor nodes from the target node; for each incoming edge, extracting the combination mode of the source node type and the target node type connected by the edge, and querying the corresponding weight attenuation factor from the preset attenuation factor table; multiplying the initial propagation intensity by the current influence weight of the incoming edge and then by the weight attenuation factor to obtain the propagation intensity of the predecessor node, and updating the influence weight of the incoming edge according to the difference between the propagation intensity and the current influence weight; when a predecessor node has multiple outgoing edges pointing to different successor nodes, collecting the propagation intensities received by all outgoing edges, calculating the total propagation intensity of the predecessor node using a weighted fusion mechanism, and the weighted fusion mechanism allocates fusion weights according to the abnormal degree of each successor node; judging whether the total propagation intensity of the predecessor node is greater than the propagation termination threshold, if greater, continue to propagate from the predecessor node to the more predecessor nodes, if less, terminate the propagation of this branch; recording the weight update value and update time of each dependency edge during the propagation process, and appending to the weight evolution sequence of the dependency edge.

[0009] performing subgraph matching on the set of predecessor nodes of multiple abnormal test data to identify common predecessor subgraphs, determining root cause nodes according to the cumulative weight of nodes in the common predecessor subgraphs on the dependency path, and optimizing and adjusting the execution strategy to generate an adjusted strategy and sending it to the test platform. extracting a subgraph structure of a plurality of sets of predecessor nodes corresponding to the plurality of pieces of abnormal test data from the dependency directed acyclic graph, performing subgraph isomorphism matching on the subgraph structure to identify a common predecessor subgraph; obtaining a cumulative weight of each node in the common predecessor subgraph by accumulating updated influence weights of each dependency edge along a dependency path from the abnormal node, and determining a set of candidate root cause nodes by sorting the cumulative weights; extracting topological features of the common predecessor subgraph and node features of the candidate root cause nodes, querying a matching historical root cause pattern in a root cause knowledge graph based on the topological features and the node features, extracting an adjustment method and parameters of the historical root cause pattern as an adjustment template when a match is found, and generating an adapted adjustment strategy in combination with a current execution strategy; when no match is found, adjusting an already generated execution strategy according to the candidate root cause nodes to generate a new adjustment strategy and updating the root cause knowledge graph; and sending the adjustment strategy to a test platform.

[0010] The step of generating an adjustment strategy in the root cause knowledge graph based on the topological features and the node features and updating the root cause knowledge graph includes: querying a historical root cause pattern in the root cause knowledge graph that matches the topological features and the node features; when a matching historical root cause pattern is found, extracting a historical adjustment strategy with the highest effectiveness as an adjustment template, selecting a node that is consistent with a root cause node type in the historical root cause pattern from the set of candidate root cause nodes as a root cause node, and generating an adjustment strategy based on the adjustment template and a current execution strategy; when no matching historical root cause pattern is found, selecting a node with the largest cumulative weight from the set of candidate root cause nodes as a root cause node, determining an adjustment strategy type according to a root cause node type and an already generated execution strategy, generating an instruction parameter adjustment strategy when the root cause node is a node corresponding to a trigger instruction identifier, generating a processing logic adjustment strategy when the root cause node is a node corresponding to an intermediate processing link identifier, and generating a state threshold adjustment strategy when the root cause node is a node corresponding to an influence state identifier; adding the root cause node, the topological features, and the adjustment strategy to the root cause knowledge graph as a new root cause pattern.

[0011] In a second aspect of the embodiment of the application, a system for bidirectional interaction between a host computer and a test platform is provided, including: a protocol adaptation module configured to cause the host computer to obtain capability description information of the test platform and construct protocol adaptation rules, generate a test instruction sequence, assign an instruction identifier to each test instruction, and send the test instruction sequence to the test platform; The load control module is used to receive test data returned by the test platform. The test data carries a traceability sequence and status feedback. When the status feedback meets the load judgment condition, the sending frequency of subsequent test instructions is adjusted. The execution plan is determined based on the feasibility feedback returned by the test platform and sent to the test platform. The dependency analysis module is used to construct a directed acyclic graph of dependency relationships based on the source sequence, assign influence weights to dependency edges, update the weights along the dependency edges according to the test data deviation, and extract the set of predecessor nodes when abnormal test data is detected and the dependency paths that meet the priority tracing conditions are selected. The root cause localization module is used to perform subgraph matching to identify common predecessor subgraphs from a set of predecessor nodes of multiple abnormal test data. Based on the cumulative weight of nodes in the common predecessor subgraph on the dependency path, the root cause node is determined, and the execution strategy is optimized and adjusted to generate an adjustment strategy which is then sent to the test platform.

[0012] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0013] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0014] This invention achieves a visual representation of the dependencies between test data by assigning identifiers to test instructions and constructing a directed acyclic graph of dependencies based on the tracing sequences returned by the test platform, thereby improving the accuracy of data analysis and tracing capabilities. By using subgraph matching technology to identify the common predecessor subgraphs of multiple abnormal data points and determining the root cause node based on cumulative weights, it enables multi-dimensional and multi-angle analysis of the root causes of faults, improving the accuracy of problem diagnosis. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the bidirectional data interaction method between the host computer and the testing platform according to an embodiment of the present invention. Figure 2 Generate a flowchart for root cause analysis and adjustment strategies for abnormal data. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0018] Figure 1 This is a flowchart illustrating the bidirectional data interaction method between the host computer and the testing platform according to an embodiment of the present invention. Figure 1 As shown, the method includes: The host computer obtains the capability description information of the test platform and constructs protocol adaptation rules, generates a test instruction sequence and assigns an instruction identifier to each test instruction before sending it to the test platform; The test data returned by the test platform is received. The test data carries a traceability sequence and status feedback. When the status feedback meets the load determination condition, the sending frequency of subsequent test instructions is adjusted. The execution plan is determined based on the feasibility feedback returned by the test platform and sent to the test platform. Based on the source sequence, a directed acyclic graph of dependencies is constructed, and influence weights are assigned to the dependency edges. The weights are then updated by propagation along the dependency edges according to the test data deviation. When abnormal test data is detected, dependency paths that meet the priority tracing conditions are selected to extract the set of predecessor nodes. For the set of predecessor nodes of multiple abnormal test data, subgraph matching is performed to identify a common predecessor subgraph. The root cause node is determined based on the cumulative weight of the nodes in the common predecessor subgraph on the dependency path. The execution strategy is then optimized and adjusted to generate an adjustment strategy, which is sent to the test platform.

[0019] In one optional implementation, the steps of the host computer obtaining the capability description information of the test platform and constructing protocol adaptation rules, generating a test instruction sequence and assigning an instruction identifier to each test instruction before sending it to the test platform include: Receive capability description information returned by the test platform, the capability description information including supported instruction set types, data interface formats and resource constraint parameters, and mark the capability description information with a version number; Based on the instruction set type, determine the instruction categories that need protocol conversion; for each instruction category, extract the difference features between the source instruction format and the target instruction format; construct a field mapping relationship table in conjunction with the data interface format; determine the test platform load judgment conditions based on the resource constraint parameters; integrate the field mapping relationship table and the load judgment conditions to form a protocol adaptation rule and associate it with the version number. Periodically retrieve the current capability description information and compare it with the stored version. When a change is detected, rebuild the field mapping relationship table and update the load judgment conditions for the changed part, generate new version protocol adaptation rules and establish a mapping relationship between the new and old versions. A test instruction sequence is generated according to the new version protocol adaptation rules. The version number is embedded in the instruction identifier of each test instruction, so that the test instruction carries the version information of the protocol adaptation rules it uses and is sent to the test platform.

[0020] For example, the host computer sends a capability query request to the testing platform via a network interface. This request is in JSON format and includes a request identifier and a timestamp. Upon receiving the query request, the testing platform returns capability description information containing supported instruction set types, data interface formats, and resource constraint parameters. After receiving the capability description information, it assigns a version number to it. The version number consists of a major version number and a minor version number, such as "V2.1," where the major version number indicates a significant change in the instruction set architecture, and the minor version number indicates a compatibility update. Simultaneously, it records the effective timestamp of this version and stores the mapping relationship between the capability description information and the version number in a local database.

[0021] The test platform supports multiple instruction sets, such as RISC, CISC, or custom instruction sets. For each instruction set requiring protocol conversion, the differences between the source and target formats are extracted. These differences include field order, field length, data type, and encoding method. For example, if the source instruction uses big-endian byte order while the target instruction requires little-endian byte order, the byte order conversion rule must be recorded. After obtaining the differences, the impact of the data interface format on field transmission is further analyzed. Data interface formats include serial, parallel, and Ethernet interfaces, each with different requirements for data encapsulation, transmission order, and frame structure. The conversion rules determined by the differences are combined with the encapsulation methods required by the interface format to create a mapping table from source instruction fields to target instruction fields for each interface format. This table includes information such as field name, position, length, conversion function, and encapsulation format. For example, if the "measurement range" field in the source instruction needs to be mapped to the "range" field in the target instruction, and unit conversion and serial interface-specific frame header encapsulation are required, then the conversion function is recorded as "value*1000" (assuming conversion from meters to millimeters), and the serial frame format is marked as "0xAA+range+checksum".

[0022] While completing the field mapping, the resource constraint parameters in the capability description information are analyzed to establish a load judgment mechanism. Resource constraint parameters include memory capacity, processor performance, and concurrent processing capabilities. Threshold conditions are set, such as classifying a high-load state when memory utilization exceeds 80% or CPU utilization exceeds 70%. Simultaneously, load level classifications are established, such as low load (green), medium load (yellow), and high load (red), and corresponding test command sending strategies are configured for each level, such as reducing the command sending frequency or splitting large batches of commands under high load conditions.

[0023] After constructing the above field mapping table and load determination conditions, the two are integrated to form a protocol adaptation rule, which is then associated with the version number. The protocol adaptation rule is saved in XML format, including a version identifier, effective date, instruction mapping section, and load control section. The mapping section describes in detail the conversion rules for each type of instruction, and the load control section defines the instruction processing strategy under different load conditions.

[0024] To ensure the timeliness of protocol adaptation rules, a scheduled task is established to periodically (e.g., hourly) retrieve the current capability description information of the test platform and compare it with the stored version. The comparison process uses a field-by-field hash value calculation method: first, the SHA-256 hash value of each field in the capability description information is calculated and compared with the hash value of the corresponding field in the stored version to identify newly added, deleted, and modified fields; then, a change list is generated to record the specific change location, change type (added / deleted / modified), and change content. When a change is detected, the changed part is extracted and a change log is recorded. Changes include adding instruction types, modifying field formats, or updating resource parameters.

[0025] Based on the changes in the change list, the field mapping table is rebuilt for the changed parts. For example, if the test platform adds support for high-precision measurement commands, a new mapping rule is created for this command type, defining how to convert the standard measurement commands from the host computer into a platform-specific format. At the same time, the load determination conditions are updated, such as adjusting resource usage thresholds to adapt to changes in the test platform's performance.

[0026] Based on the updated mapping table and load balancing criteria, new version protocol adaptation rules are generated, and a mapping relationship between the old and new versions is established. The new version rules retain the basic architecture of the original rules, updating only the changed parts to ensure compatibility. A version transition matrix is ​​created to record the transition path from any old version to the new version, supporting the correct parsing of historical commands.

[0027] After the protocol adaptation rules are updated, a test instruction sequence is generated according to the new version of the rules. The instruction sequence is designed according to the test scenario requirements and includes initialization instructions, parameter setting instructions, and execution instructions. Each instruction is processed by the protocol adaptation rules and converted into a format that the test platform can recognize.

[0028] To ensure correct parsing of commands, the version number is embedded in the command identifier of each test command. The command identifier consists of a prefix, a version identifier, and a sequence number. For example, "CMD-V2.1-0001" indicates the first command using the V2.1 version protocol rules. By carrying version information in the commands, the testing platform can correctly parse the commands according to the corresponding version of the protocol rules, ensuring correct processing even during protocol rule updates.

[0029] The host computer sends the test command sequence to the test platform via a communication channel. During the transmission process, the load status of the test platform is monitored in real time, and the command transmission strategy is dynamically adjusted according to the load conditions. For example, the transmission frequency is reduced or the command is transmitted in batches under high load conditions to ensure the stability and reliability of test execution.

[0030] Through the above implementation method, adaptive protocol conversion between the host computer and the test platform is realized, which effectively solves the communication compatibility problem between heterogeneous systems and improves the flexibility and stability of the test system.

[0031] In one optional implementation, the steps of receiving test data returned by the test platform, the test data carrying a traceability sequence and status feedback, adjusting the sending frequency of subsequent test commands when the status feedback meets the load determination conditions, and determining an execution plan based on the feasibility feedback returned by the test platform and sending it to the test platform include: The source sequence and status feedback are parsed from the received test data, and the status feedback includes resource occupancy status and instruction processing response time. The resource occupancy status is compared with the resource occupancy threshold in the protocol adaptation rules, and the instruction processing response time is compared with the response delay threshold. When either threshold is exceeded, the load determination condition is determined to be met. When the load determination condition is met, an adjustment coefficient is calculated based on the resource occupancy status and instruction processing response time. The sending frequency of subsequent test instructions is reduced based on the adjustment coefficient, and an execution strategy is generated. The execution strategy is sent to the test platform, and feasibility feedback is received. The feasibility feedback includes a determination of whether the execution strategy is acceptable. If acceptable, the execution strategy is used as the execution plan. If unacceptable, the execution strategy is regenerated based on the suggested parameters in the feasibility feedback and sent to the test platform as the execution plan. When the load determination condition is not met, the current test instruction sending frequency is maintained.

[0032] For example, during the operation of the test system, test data is received from the test platform. This data includes traceability sequences and status feedback information. Test data is typically transmitted in JSON or XML format for easy parsing and processing. The traceability sequences and status feedback are extracted from the received test data. The traceability sequence is a unique identifier used to track the execution path of test instructions; the status feedback includes two key indicators: resource usage status and instruction processing response time.

[0033] Resource utilization status includes parameters such as CPU utilization, memory utilization, and network bandwidth utilization, usually expressed as a percentage. Command processing response time is the time interval from receiving a command to completing its processing, measured in milliseconds. These parameters form the basis for judging the system load status.

[0034] Maintain a protocol adaptation rule base, which defines thresholds for various resource usage parameters. For example, the CPU utilization threshold is set to 85%, memory usage to 80%, and network bandwidth usage to 75%. Thresholds for command processing response time, such as 200 milliseconds, are also defined. When any parameter exceeds its corresponding threshold, the load condition is deemed met, and the test command sending frequency needs to be adjusted.

[0035] When the load determination conditions are met, an adjustment coefficient is calculated based on resource utilization and instruction processing response time. The adjustment coefficient is calculated using a weighted average method, assigning different weights to different resource parameters according to their importance. For example, if CPU utilization is 90% (5 percentage points above the threshold), memory utilization is 85% (5 percentage points above the threshold), and response time is 250 milliseconds (50 milliseconds above the threshold), given a CPU weight of 0.4, a memory weight of 0.3, and a response time weight of 0.3, the weighted average of the excess portion is: 0.4 × (90% - 85%) / 85% + 0.3 × (85% - 80%) / 80% + 0.3 × (250ms - 200ms) / 200ms = 0.04. This weighted excess value is then converted into an adjustment coefficient using a linear mapping formula. The mapping formula is: Adjustment coefficient = 1 - (Weighted excess value × Amplification factor), where the amplification factor is set to 5. This value is calculated based on the minimum adjustment coefficient of 0.6 and the maximum expected excess value of 0.08, i.e., Amplification factor = (1 - 0.6) / 0.08 = 5. Substituting the weighted excess value of 0.04 into the above calculation: Adjustment coefficient = 1 - (0.04 × 5) = 0.8, indicating that the command sending frequency will be reduced to 80% of the original. To ensure that the adjustment coefficient is within a reasonable range, upper and lower limits are set: 0.6 is used when the calculated result is less than 0.6, and 1.0 is used when the calculated result is greater than 1.0.

[0036] Based on the calculated adjustment coefficient, the sending frequency of subsequent test commands is reduced. For example, if the original sending frequency was 100 commands per second, after using an adjustment coefficient of 0.8, the new sending frequency is 80 commands per second. Simultaneously, an execution strategy document is generated. This document is organized in a structured format and includes the following fields: Strategy Identifier: Used to uniquely identify this adjustment strategy, for example, "STR-20251219-001"; Adjustment Type: Indicates that this adjustment belongs to the frequency reduction type; Target Sending Frequency: Records the adjusted command sending rate, which is 80 commands per second in this example; Adjustment Ratio: Records the adjustment coefficient value of 0.8; Trigger Reason: Records in detail the various resource states that triggered the adjustment, including CPU utilization exceeding the threshold of 85% (90%), memory usage exceeding the threshold of 80% (85%), and response time exceeding the threshold of 200 milliseconds (250 milliseconds); Expected Effect: Records the expected resource improvement after implementing this strategy, including expected CPU utilization to decrease to 75%, memory usage to decrease to 70%, and response time to decrease to 180 milliseconds; Strategy Validity Period: Defines the validity period of this execution strategy, for example, set to 300 seconds, after which a re-evaluation is required.

[0037] After the execution strategy is generated, it is sent to the testing platform for feasibility assessment. The testing platform evaluates the feasibility of the execution strategy based on the current operating status and resource configuration, and returns feasibility feedback. The feasibility feedback includes an acceptance status (acceptance or rejection) and suggested parameters, provided when rejected. The testing platform's suggested parameter generation mechanism is as follows: For each resource usage parameter, the maximum instruction frequency that the resource can withstand is calculated based on the current actual usage. The calculation method is: Resource-capable frequency = Current sending frequency × (Threshold / Current resource usage). Taking CPU as an example, when CPU utilization is 90%, the threshold is 85%, and the current frequency is 100 instructions per second, the CPU-capable frequency = 100 × (85% / 90%) ≈ 94 instructions / second; when memory usage is 85% and the threshold is 80%, the memory-capable frequency = 100 × (80% / 85%) ≈ 94 instructions / second; when the response time is 250 milliseconds and the threshold is 200 milliseconds, the response time-capable frequency = 100 × (200 / 250) = 80 instructions / second. After the calculation is completed, the minimum value of the calculation results for each resource is taken as the suggested frequency, which is 80 messages per second in this example. If the host computer's suggested frequency of 80 messages per second is still higher than the actual capacity of the test platform, for example, if the actual bearable frequency is only 70 messages per second due to other background tasks occupying resources, the test platform will return the suggested parameter of 70 messages per second in the feasibility feedback.

[0038] When feasibility feedback indicates that the execution strategy is acceptable, it is directly adopted as the final execution plan. For example, if the test platform confirms that the command sending frequency can be reduced to 80 commands per second, this execution strategy is adopted. When feasibility feedback indicates that the execution strategy is unacceptable, the execution strategy is regenerated based on the suggested parameters in the feedback. Suppose the test platform believes that 80 commands per second is still too high and suggests reducing it to 70 commands per second. Based on this suggestion, the execution strategy is regenerated, the adjusted sending frequency is set to 70 commands per second, the adjustment factor is recalculated as 70 / 100 = 0.7, the target sending frequency field in the execution strategy document is updated to 70 commands per second, the adjustment ratio field is updated to 0.7, and the expected values ​​in the expected effect field are adjusted accordingly. Then, this new strategy is sent to the test platform as the execution plan.

[0039] If the load assessment criteria are not met, maintain the current test command sending frequency. This indicates that the current test load is within the test platform's capacity and no adjustment is needed. Simultaneously, continue monitoring the status feedback returned by the test platform to make timely adjustments as required.

[0040] This invention enables intelligent control of test load, which ensures the effectiveness of testing, avoids excessive consumption of test platform resources, and improves overall testing efficiency and the reliability of test results.

[0041] In one optional implementation, the steps of constructing a directed acyclic graph of dependencies based on the source sequence, assigning influence weights to dependency edges, updating the weights along the dependency edges according to the test data deviation, and extracting the set of predecessor nodes by filtering dependency paths that meet the priority tracing conditions when abnormal test data is detected include: Identifiers for triggering instructions, intermediate processing steps, and influencing states are extracted from the source sequence and mapped to nodes. Directed edges are established based on the order and influence relationship between the identifiers to form a directed acyclic graph with dependency relationships. Initial influence weights are assigned based on the source node type and target node type connected by each directed edge, and a weight evolution sequence is created for each directed edge. The test data is compared with the expected value to calculate the test data deviation. The corresponding target node is located in the directed acyclic graph of the dependency relationship. The influence weight is updated by backpropagating from the target node along the dependency edge and added to the weight evolution sequence. The weight fluctuation characteristics of the dependent edges are calculated based on the weight evolution sequence. When the weight fluctuation characteristics meet the stability condition, they are marked as strong causal dependent edges; otherwise, they are marked as weakly correlated dependent edges. When abnormal test data is detected, abnormal nodes are extracted from the directed acyclic graph of the dependency relationship. The predecessor paths are traversed first from the abnormal nodes along the strong causal dependency edges. The dependency paths are filtered by combining the updated influence weights of the dependency edges, and the predecessor nodes on the dependency paths are extracted to form a predecessor node set.

[0042] For example, identifiers of triggering instructions, intermediate processing steps, and influencing states are extracted from the source sequence and mapped to nodes. Directed edges are established based on the order and influence relationships between the identifiers, forming a directed acyclic graph of dependencies. Specifically, the source sequence is obtained by parsing the system operation log, which includes the instruction execution flow and data processing process. Triggering instruction identifiers (such as "CMD_A" and "CMD_B") are mapped to instruction nodes, intermediate processing step identifiers (such as "PROC_1" and "PROC_2") are mapped to processing nodes, and influencing state identifiers (such as "STATE_X" and "STATE_Y") are mapped to state nodes. When identifier A precedes identifier B in time and the output of A serves as the input or triggering condition of B, a directed edge is established between the node corresponding to A and the node corresponding to B, representing the dependency relationship from A to B.

[0043] For dependency edges between different types of nodes, initial influence weights are set according to the combination of source and target node types: the initial weight from the instruction node to the processing node is set to 0.8, the initial weight from the processing node to the state node is set to 0.7, the initial weight from the state node to the processing node is set to 0.6, and the initial weight from the processing node to the processing node is set to 0.5. A weight evolution sequence data structure is established for each dependency edge. This sequence initially contains one element, which is the initial influence weight value. Subsequently, new weight values ​​and corresponding timestamps are continuously added as weight update operations are performed, forming time series data for analyzing the evolution trend of dependency relationships.

[0044] When a deviation is detected between the test data and the expected value, the state node corresponding to the test data is first identified as the target node. The deviation value δ is calculated using the formula: δ = |actual value - expected value| / |expected value|. Then, starting from the target node, the influence weights are updated by backpropagating along the dependency edges. For direct predecessor nodes, a moving average mechanism is used to update the dependency edge weight W, with the update formula: W' = 0.9 × W + 0.1 × δ, where 0.9 is the historical weight retention coefficient and 0.1 is the new deviation contribution coefficient. For indirect predecessor nodes, a decay mechanism is introduced to reflect the decrease in influence with propagation distance. The decay coefficient of the nth layer predecessor node is set to 0.9ⁿ, and its weight update formula is: W' = 0.9 × W + 0.1 × δ × 0.9ⁿ. After each weight update, the new weight value, along with the current timestamp, is appended to the weight evolution sequence of the corresponding dependency edge in key-value pairs, with the sequence format being {timestamp_1:weight_1,timestamp_2:weight_2,...}.

[0045] After accumulating a certain number of update records in the weight evolution sequence, volatility characteristic analysis is performed on each dependency edge. The weight values ​​from the N most recent updates (N ranging from 10 to 20) are extracted from the weight evolution sequence, and the standard deviation σ and mean μ of these N weight values ​​are calculated. The standard deviation is calculated by squaring the difference between each weight value and the mean, summing all squares, dividing by N, and finally taking the square root of the result. The volatility coefficient CV is defined as the ratio of the standard deviation to the mean, i.e., CV = σ / μ, as an indicator of weight stability. A dual condition for stability determination is set: the volatility coefficient threshold Th is set to 0.2, and the weight threshold is set to 0.6. When a dependency edge simultaneously satisfies CV < 0.2 and μ > 0.6, the dependency edge is marked as a strong causal dependency edge, indicating that the dependency relationship has high stability and sustained influence; otherwise, it is marked as a weakly correlated dependency edge, indicating that the dependency relationship is accidental or has a low degree of influence. Strong causal dependencies are given priority in anomaly tracing, while weakly correlated dependencies are only used as auxiliary references.

[0046] When the deviation of a test data point exceeds a set anomaly threshold (e.g., 0.3, meaning the actual value deviates from the expected value by more than 30%), the corresponding node is marked as an anomaly node, triggering the root cause tracing process. Starting from the anomaly node, a depth-first search algorithm is used to traverse the predecessor path. The traversal strategy prioritizes tracing forward along strong causal dependencies, considering weak dependencies only after exhausting all strong causal paths. During the traversal, each complete predecessor path is recorded, represented as a node sequence: anomaly node ← predecessor node 1 ← predecessor node 2 ← ... ← starting node. For each predecessor path, the path weight is calculated as a quantitative indicator of the path's reliability. The calculation method is the geometric mean of the weights of all dependent edges on the path: path weight = (W_1 × W_2 × ... × W_m)^(1 / m), where W_i is the updated weight of the i-th dependent edge on the path, and m is the number of dependent edges contained in the path. The geometric mean is used instead of the arithmetic mean because the geometric mean is more sensitive to weak links (low-weight edges) in the path and can better reflect the reliability of the entire path. A path weight threshold of 0.5 was set, and dependency paths with a path weight greater than or equal to 0.5 were selected as high-confidence paths. All predecessor nodes (excluding the anomalous nodes themselves) on these high-confidence paths were collected, deduplicated, and formed a predecessor node set. Nodes in this set were sorted according to their frequency of occurrence in the path and the average weight of their respective paths, with nodes having high frequency and large path weights ranked higher, serving as key candidates for subsequent root cause analysis.

[0047] The dependency directed acyclic graph of this invention provides a clear structured representation for system behavior modeling. The weight evolution sequence dynamically reflects the changes in the strength of the dependency. The classification of strong and weak dependency edges significantly improves the tracing efficiency, and the path weight screening mechanism effectively filters out low-reliability interference paths.

[0048] In one optional implementation, the step of backpropagating the update of the influence weights from the target node along the dependency edges and appending them to the weight evolution sequence includes: The initial propagation intensity is determined based on the magnitude of the test data deviation. All incoming edges and their corresponding predecessor nodes are obtained from the target node. For each incoming edge, the combination pattern of the source node type and the target node type connected by the edge is extracted, and the corresponding weight attenuation factor is queried from the preset attenuation factor table. The initial propagation strength is multiplied by the current influence weight of the incoming edge and then multiplied by the weight decay factor to obtain the propagation strength of the predecessor node. The influence weight of the incoming edge is updated according to the difference between the propagation strength and the current influence weight. When the predecessor node has multiple outgoing edges pointing to different successor nodes, the propagation strengths received by all outgoing edges are collected, and a weighted fusion mechanism is used to calculate the total propagation strength of the predecessor node. The weighted fusion mechanism allocates fusion weights according to the degree of anomaly of each successor node. It is determined whether the total propagation strength of the predecessor node is greater than the propagation termination threshold. If it is greater, the propagation continues from the predecessor node to the previous predecessor node. If it is less, the propagation of the branch is terminated. During the propagation process, the weight update value and update time of each dependent edge are recorded and appended to the weight evolution sequence of the dependent edges.

[0049] For example, when test data deviates, a backpropagation mechanism is initiated to update the influence weights of each edge in the dependency graph. The magnitude of the deviation directly determines the initial strength of the propagation process, which is quantified by mapping the test data deviation value δ to a propagation strength range. The mapping uses a piecewise linear function: when the deviation value δ is less than 0.1, the initial propagation strength is set to 0.3; when δ is between 0.1 and 0.3, the initial propagation strength is set to 0.6; and when δ is greater than 0.3, the initial propagation strength is set to 1.0. After determining the initial propagation strength, all incoming edges pointing to the target node are extracted, with each incoming edge associated with a predecessor node. The incoming edge data structure includes fields such as edge identifier, source node identifier, target node identifier, current influence weight, and weight evolution sequence. The identifiers and node type attributes of all predecessor nodes are obtained by traversing the incoming edge set.

[0050] For each incoming edge, the source node type and target node type are extracted to form a composite pattern identifier. Composite patterns are represented by double tuples; for example, "instruction node to processing node" is denoted as composite pattern A, and "processing node to state node" is denoted as composite pattern B. A pre-defined attenuation factor table is maintained, indexed by the composite pattern identifier, storing the corresponding weight attenuation factors. In the attenuation factor table, composite pattern A corresponds to an attenuation factor of 0.95, composite pattern B corresponds to an attenuation factor of 0.90, the composite pattern "state node to processing node" corresponds to an attenuation factor of 0.85, and the composite pattern "processing node to processing node" corresponds to an attenuation factor of 0.80. A query operation is performed in the attenuation factor table using the composite pattern identifier to obtain the weight attenuation factor corresponding to the current incoming edge. If the composite pattern is not defined in the table, a default attenuation factor of 0.75 is used as a conservative estimate.

[0051] The weight update calculation consists of two steps: First, the initial propagation strength is multiplied by the current influence weight of the incoming edge. Then, the product is multiplied by the weight decay factor to obtain the propagation strength received by the predecessor node of the incoming edge. For example, if the current influence weight of an incoming edge is 0.7, the corresponding decay factor is 0.90, and the initial propagation strength is 1.0, then the propagation strength of the predecessor node is calculated as 1.0 multiplied by 0.7 and then multiplied by 0.90, which equals 0.63. Subsequently, the difference between the propagation strength and the current influence weight is calculated; this difference is the weight increment. The incoming edge influence weight is updated by adding the weight increment to the current weight. If the updated weight exceeds the upper limit of 1.0, it is truncated to 1.0; if it is below the lower limit of 0.1, it remains at 0.1. The updated weight value, along with the update time, is appended as a timestamp to the weight evolution sequence data structure of the incoming edge.

[0052] When a predecessor node has multiple outgoing edges pointing to different successor nodes, the predecessor node simultaneously receives propagation intensities from multiple directions. The propagation intensity values ​​received by all outgoing edges of the predecessor node are collected and stored as a propagation intensity list. A weighted fusion mechanism is used to calculate the total propagation intensity of the predecessor node, with the fusion weights determined based on the anomaly level of each successor node. The anomaly level is quantified by the deviation value of the test data corresponding to the successor node; the larger the deviation value, the higher the anomaly level. Specifically, the deviation values ​​of each successor node are normalized so that the sum of all deviation values ​​is 1.0. The normalized deviation value is the fusion weight of the corresponding outgoing edge. The total propagation intensity is obtained by multiplying the propagation intensity of each outgoing edge by its corresponding fusion weight and then summing the results. For example, a predecessor node has two outgoing edges: the first outgoing edge has a propagation intensity of 0.63, corresponding to a successor node deviation value of 0.4; the second outgoing edge has a propagation intensity of 0.54, corresponding to a successor node deviation value of 0.2. The total deviation is 0.4 + 0.2 = 0.6. After normalization, the fusion weights are 0.4 ÷ 0.6 = 0.667 and 0.2 ÷ 0.6 = 0.333, respectively. The total propagation intensity is 0.63 × 0.667 + 0.54 × 0.333 = 0.60.

[0053] A propagation termination threshold of 0.3 is set to determine whether to continue propagating to higher predecessor nodes. When the total propagation strength of a predecessor node is greater than 0.3, that node becomes the new target node and continues the reverse propagation process, repeatedly performing operations such as edge extraction, decay factor query, propagation strength calculation, and weight update. When the total propagation strength is less than or equal to 0.3, it is determined that the influence of that branch has sufficiently decayed, and the propagation of that branch is terminated to avoid unnecessary computational waste. The propagation process adopts a breadth-first strategy, prioritizing the processing of all predecessor nodes at the same level before advancing to higher predecessor levels, ensuring a fair distribution of propagation strength among nodes at the same level.

[0054] Throughout the propagation process, a global weight update log is maintained, recording the weight update value and update time for each dependent edge. The update log uses a key-value pair storage structure, where the key is a combination of the edge identifier and a timestamp, and the value is the updated weight value. After each weight update operation is completed, the update information is immediately appended to the weight evolution sequence of the corresponding dependent edge. The weight evolution sequence is implemented as an ordered list, maintaining chronological order to support subsequent trend analysis and fluctuation characteristic calculations. The sequence length is set to an upper limit of 100 elements; when the length exceeds the limit due to the appending of new elements, the oldest element is deleted to maintain a stable queue length.

[0055] This invention achieves accurate backpropagation of test data deviations to the dependency graph. The weight update process fully considers the differences in node types and the characteristics of propagation decay. The weight evolution sequence provides complete historical data support for dependency stability analysis.

[0056] In one optional implementation, the steps of performing subgraph matching to identify a common predecessor subgraph for a set of predecessor nodes of multiple abnormal test data, determining the root cause node based on the cumulative weight of nodes in the common predecessor subgraph on the dependency path, optimizing and adjusting the execution strategy, generating an adjustment strategy, and sending it to the test platform include: Extract the subgraph structure of the predecessor node set corresponding to multiple abnormal test data from the directed acyclic graph of dependencies, and perform subgraph isomorphic matching on the subgraph structure to identify common predecessor subgraphs; The cumulative weights of each node in the common predecessor subgraph are obtained by tracing back along the dependency path from the abnormal node and accumulating the updated influence weights of each dependency edge. The cumulative weights are then sorted to determine the set of candidate root cause nodes. Extract the topological features of the common precursor subgraph and the node features of the candidate root cause nodes. Based on the topological features and node features, query the root cause knowledge graph for matching historical root cause patterns. When a match is found, extract the adjustment method and parameters of the historical root cause pattern as an adjustment template, and generate an appropriate adjustment strategy in combination with the current execution strategy. When no match is found, adjust the generated execution strategy according to the candidate root cause nodes to generate a new adjustment strategy and update the root cause knowledge graph. Send the adjustment strategy to the test platform.

[0057] Combination Figure 2The flowchart for abnormal data root cause analysis and adjustment strategy generation is illustrated. For example, when multiple abnormal test data are detected, the set of predecessor nodes corresponding to each abnormal data is extracted from the directed acyclic graph (DAG). The extraction operation locates the position of the abnormal node in the graph structure by using its identifier, recursively obtaining predecessor nodes by traversing all incoming edges of that node until a starting node without predecessors is reached. Each abnormal node corresponds to a set of predecessor nodes, and the connecting edges between this set and its internal nodes are extracted to form a subgraph structure. The subgraph structure is stored using an adjacency list, recording node identifiers, node types, incoming edge lists, and outgoing edge lists. When there are three abnormal test data, subgraph S1 containing nodes A, B, C, and D, subgraph S2 containing nodes A, B, E, and F, and subgraph S3 containing nodes A, G, and H are extracted respectively.

[0058] Subgraph isomorphic matching employs a fast filtering strategy based on node degree and type, combined with depth-first search verification. In the degree filtering stage, the in-degree and out-degree of each node in each subgraph are calculated, constructing and sorting degree sequences. For example, the degree sequence of subgraph S1 is {node A in-degree 0 out-degree 2, node B in-degree 1 out-degree 2, node C in-degree 1 out-degree 1, node D in-degree 1 out-degree 0}, and the degree sequence of subgraph S2 is {node A in-degree 0 out-degree 2, node B in-degree 1 out-degree 1, node E in-degree 1 out-degree 1, node F in-degree 1 out-degree 0}. Comparing the degree sequences of each subgraph identifies common degree patterns, revealing that node A has an in-degree of 0 and an out-degree of 2 in all subgraphs. In the type verification stage, the types of nodes with the same degree are checked for consistency. Node A is a command node type in all subgraphs, while node B is a processing node type in both S1 and S2. Through the dual constraints of degree and type, nodes A and B are determined to be candidate common nodes. Depth-first search starts from candidate nodes and verifies whether their adjacency relationships are consistent across all subgraphs. Specifically, it verifies that the edge from node A to node B exists in all subgraphs and that the edge type is the same. If the verification is successful, the structure containing nodes A and B and their connecting edges is extracted as a common predecessor subgraph.

[0059] The cumulative weights of nodes in the common predecessor subgraph are calculated by backtracking the dependency paths. Starting from each anomalous node, the system traverses along the dependency edges towards the predecessor, accumulating the updated impact weights of each dependency edge on the path. For example, if anomalous node X1 travels through path X1 to D to B to A, the weight of the dependency edge X1 to D is 0.75, the weight of edge D to B is 0.68, and the weight of edge B to A is 0.82. Therefore, the cumulative weight of node A in path X1 is 0.75 + 0.68 + 0.82 = 2.25. If anomalous node X2 travels through path X2 to F to B to A, the weight of edge X2 to F is 0.71, the weight of edge F to B is 0.65, and the weight of edge B to A is 0.82. Therefore, the cumulative weight of node A in path X2 is 0.71 + 0.65 + 0.82 = 2.18. An abnormal node X3 travels from X3 to H and then to A via path X3. The edge from X3 to H has a weight of 0.79, and the edge from H to A has a weight of 0.88. The cumulative weight of node A on path X3 is 0.79 + 0.88 = 1.67. The final cumulative weight of node A is calculated by averaging the cumulative weights of the same node across different paths. The final cumulative weight of node A is (2.25 + 2.18 + 1.67) ÷ 3 = 2.03. Similarly, the final cumulative weight of node B is calculated. The cumulative weights on the three paths are 1.43, 1.36, and not applicable, respectively. The average is (1.43 + 1.36) ÷ 2 = 1.40.

[0060] The cumulative weights of all nodes in the common predecessor subgraph are sorted in descending order, and the top K nodes with the highest weights constitute the candidate root cause node set. The value of K is dynamically adjusted according to the size of the subgraph: K is 2 when the number of nodes in the subgraph is less than 5, K is 3 when the number of nodes is between 5 and 10, and K is 5 when the number of nodes is greater than 10. In the current case, the subgraph contains 2 nodes, K is 2, and the candidate root cause node set contains node A with a cumulative weight of 2.03 and node B with a cumulative weight of 1.40.

[0061] Topological feature extraction focuses on the structural attributes of the common predecessor subgraph, including the total number of nodes, total number of edges, average node degree, maximum path length, and number of critical paths. The current subgraph has 2 nodes, 1 edge, an average node degree of 1.0, a maximum path length of 1, and the number of critical paths is defined as the number of paths with a cumulative weight exceeding 2.0, which is 2 in this case. Node feature extraction focuses on each node in the candidate root cause node set, including node type, cumulative weight, in-degree, out-degree, and centrality in the subgraph. Node A's features are instruction node type, cumulative weight 2.03, in-degree 0, and out-degree 2; node B's features are process node type, cumulative weight 1.40, in-degree 1, and out-degree 2. Centrality is calculated using the degree centrality method, dividing the node degree by the maximum degree of the subgraph. In the current subgraph, node A has a total degree of 0 + 2 = 2, node B has a total degree of 1 + 2 = 3, the maximum degree of the subgraph is 3, the centrality of node A is 2 ÷ 3 = 0.67, and the centrality of node B is 3 ÷ 3 = 1.0.

[0062] The root cause knowledge graph is stored in the form of a graph database. Nodes represent historical root cause patterns, and edges represent the evolutionary relationships between patterns. Each pattern node contains a topological feature vector, a node feature vector, an adjustment method identifier, and adjustment parameter fields. Query operations are performed by calculating the similarity between the feature vector of the current common predecessor subgraph and the feature vectors of each pattern in the knowledge graph. The similarity is measured using Euclidean distance. The topological features and node features are concatenated into a unified vector, and the square root of the sum of the squares of the differences in each dimension between the current vector and the pattern vector is calculated. A similarity threshold of 0.3 is set; a match is considered successful when the Euclidean distance is less than 0.3. Assuming that pattern M1 exists in the knowledge graph with topological features of 2 nodes, 1 edge, average degree 1.0, maximum path length 1, and 2 critical paths, and node features of a first node instruction type cumulative weight of 2.1 and a second node processing type cumulative weight of 1.5, the calculated Euclidean distance is 0.12, which is less than the threshold, indicating a successful match.

[0063] After a successful match, the adjustment method identifier "reduce command sending frequency" is extracted from pattern M1, with an adjustment parameter of frequency reduction coefficient 0.75. The adjustment template is combined with the current execution strategy, which has a command sending frequency of 80 messages per second. After applying the reduction coefficient, this is adjusted to 80 × 0.75 = 60 messages per second. The generated adjustment strategy document includes the strategy identifier "STR-20251219-002", adjustment type "frequency reduction", target sending frequency of 60 messages per second, adjustment basis "root cause node A has a cumulative weight of 2.03 for command nodes", reference pattern "M1", and expected effect "reduce command node load by 30%".

[0064] When no historical root cause pattern is matched in the query, an adjustment strategy is determined based on the node type with the highest cumulative weight in the candidate root cause node set. Node A is an instruction node type. An instruction parameter adjustment strategy is generated for the instruction node, specifically increasing the execution interval parameter of the test instruction from the current 50 milliseconds to 50 + 25 = 75 milliseconds to slow down the instruction triggering rate. The newly identified common predecessor subgraph topological features, node features, adjustment method identifier "increase instruction interval", and adjustment parameter "interval increment 25 milliseconds" are encapsulated into a new root cause pattern, assigned the pattern identifier "M10", and inserted into the root cause knowledge graph. The insertion operation simultaneously establishes evolutionary edges with similar patterns. By calculating the feature similarity between the new pattern and existing patterns, evolutionary edges are connected to pattern pairs with similarity higher than 0.5, and the association between patterns is recorded to facilitate subsequent reasoning.

[0065] After the adjustment strategy is generated, it is sent through the test platform's communication interface. The message is in JSON format and includes fields for strategy identifier, adjustment type, target parameters, effective time, and validity period. Upon receiving the message, the test platform parses the strategy type and calls the corresponding execution module based on the adjustment type: for frequency reduction, it calls the frequency control module; for parameter adjustment, it calls the instruction generation module. The execution module applies the adjustment parameters to update the runtime configuration, records the strategy execution log including the strategy identifier, execution time, execution status, and resource changes, and feeds back to the host computer to complete the closed loop.

[0066] This invention achieves precise localization from multiple anomaly sources to common root causes, subgraph isomorphic matching effectively identifies the correlation between anomalies, cumulative weight quantifies the influence of nodes, knowledge graph query reuses historical experience to accelerate decision-making, and autonomous adjustment and knowledge updating in unmatched scenarios ensure continuous optimization capabilities.

[0067] In one optional implementation, the step of generating an adjustment strategy and updating the root cause knowledge graph by querying and matching historical root cause patterns in the root cause knowledge graph based on the topological features and node features includes: Search the root cause knowledge graph for historical root cause patterns that match the topological and node features; When a matching historical root cause pattern is found, the most effective historical adjustment strategy is extracted as the adjustment template. Nodes with the same type as the root cause nodes in the historical root cause pattern are selected from the candidate root cause node set as root cause nodes. An adjustment strategy is generated based on the adjustment template and the current execution strategy. When no matching historical root cause pattern is found, the node with the largest cumulative weight is selected from the candidate root cause node set as the root cause node. The adjustment strategy type is determined according to the root cause node type and the generated execution strategy. When the root cause node is the node corresponding to the trigger instruction identifier, an instruction parameter adjustment strategy is generated. When the root cause node is the node corresponding to the intermediate processing stage identifier, a processing logic adjustment strategy is generated. When the root cause node is the node corresponding to the influence state identifier, a state threshold adjustment strategy is generated. Root cause nodes, topological features, and adjustment strategies are added as new root cause patterns to the root cause knowledge graph.

[0068] For example, the root cause knowledge graph is constructed using a node-edge-attribute graph structure. Nodes represent historical root cause pattern instances, and edges represent inheritance or evolutionary relationships between patterns. Each pattern node stores attribute fields such as a topological feature vector, a node feature vector, a root cause node identifier, adjustment strategy content, effectiveness score, and application frequency. The topological feature vector contains five dimensions: total number of nodes, total number of edges, average node degree, maximum path length, and number of critical paths. The node feature vector contains five dimensions: root cause node type, cumulative weight, in-degree, out-degree, and centrality. The query operation combines the topological features of the current common predecessor subgraph and the node features of candidate root cause nodes into a query feature vector. This vector has 10 dimensions, with the first 5 dimensions representing topological features and the last 5 dimensions representing node features.

[0069] The matching algorithm uses weighted Euclidean distance to calculate similarity. The query feature vector is compared dimension-by-dimensionally with the feature vector of each pattern node in the knowledge graph, and the square of the difference in each dimension is calculated. A weight coefficient of 0.4 is assigned to the topological feature dimension, and a weight coefficient of 0.6 is assigned to the node feature dimension, reflecting the higher importance of node features for root cause identification. The square root of the sum of the weighted squared differences is then used to obtain the weighted Euclidean distance. A matching threshold of 0.35 is set; a successful match is considered achieved when the weighted Euclidean distance is less than 0.35. For example, if the query vector is {2,1,1.0,1,2,Instruction type,2.03,0,2,0.67}, and the feature vector of pattern M5 in the knowledge graph is {2,1,1.0,1,2,Instruction type,2.10,0,2,0.70}, the sum of squares of the differences in each dimension of the topological features is 0, the cumulative weight difference in the node features is 2.10-2.03=0.07, which squares to 0.0049, and the centrality difference is 0.70-0.67=0.03, which squares to 0.0009. The weighted sum of squares is 0.4×0+0.6×(0.0049+0.0009)=0.00348. Taking the square root of 0.00348 gives 0.059, which is less than the threshold of 0.35, so a match is determined.

[0070] When a query returns multiple matching historical root cause patterns, the optimal pattern is selected based on the effectiveness score. The effectiveness score is calculated based on the execution effect of historical adjustment strategies, and the score calculation method is: anomaly elimination rate × 0.6 + resource optimization rate × 0.4. The anomaly elimination rate is defined as the reduction in the number of anomalies after the implementation of the adjustment strategy, and the resource optimization rate is defined as the reduction in the consumption of critical resources. For example, if the adjustment strategy associated with pattern M5 has been executed 10 times in history, with an average anomaly elimination rate of 0.85 and an average resource optimization rate of 0.72, the effectiveness score is 0.85 × 0.6 + 0.72 × 0.4 = 0.798. The effectiveness score of pattern M8 is 0.756. The pattern with the highest score, M5, is selected, and the adjustment method identifier "reduce command sending frequency" is extracted from its adjustment strategy field. The adjustment parameters include a frequency reduction coefficient of 0.75 and a reduction duration of 300 seconds.

[0071] The current root cause node is selected from the candidate root cause node set, with the node type matching the root cause node type in the historical root cause pattern. The root cause node type for pattern M5 is the instruction node. The candidate root cause node set includes node A (instruction type, cumulative weight 2.03) and node B (processing type, cumulative weight 1.40). Node A is selected as the root cause node. The frequency reduction coefficient of 0.75 in the adjustment template is applied to the previously generated execution strategy "STR-20251219-001". This execution strategy currently sets the instruction sending frequency to 80 messages per second. Based on the root cause analysis results, further optimization is performed, and the adjusted target frequency is 80 × 0.75 = 60 messages per second. The generated adjustment strategy document serves as an optimized version of the execution strategy. The strategy identifier is incremented to "STR-20251219-003", the adjustment type is "frequency reduction", the target sending frequency is 60 messages per second, the root cause node identifier is "Node A", the adjustment basis is "M5 validity score of matching historical patterns 0.798", the reduction duration is 300 seconds, the expected anomaly elimination rate is 0.85%, and the expected resource optimization rate is 0.72. The adjustment strategy also records the generation timestamp and version number. The version number is associated with the current protocol adaptation rule version to ensure consistency between the strategy and the test platform's capability description.

[0072] When the query does not return a matching historical root cause pattern, the self-adjustment strategy generation process is triggered. The candidate root cause nodes are sorted in descending order of cumulative weight, and the node with the highest weight is selected as the root cause node. Assuming node A has a cumulative weight of 2.03, which is the maximum, node A is identified as the root cause node. The adjustment strategy type is determined based on node A's node type attribute. Node A corresponds to a trigger instruction identifier and is classified as an instruction node. An instruction parameter adjustment strategy is generated for the instruction node type. The adjustments include modifying the instruction execution interval, adjusting the instruction priority, or limiting the number of concurrent instructions. The specific adjustment plan is determined by analyzing the characteristics of the test instructions associated with node A. The current execution interval parameter of this instruction is extracted as 50 milliseconds. Based on the need to reduce load, the interval is increased by 50%, i.e., an increment of 50 × 0.5 = 25 milliseconds. The adjusted interval is 50 + 25 = 75 milliseconds. The generated adjustment strategy document contains the strategy identifier "STR-20251219-004", adjustment type "instruction parameter adjustment", target execution interval 75 milliseconds, root cause node identifier "node A", adjustment basis "node A's cumulative weight of 2.03 is the maximum value and the type is instruction node", and adjustment parameter "interval increment 25 milliseconds".

[0073] When the root cause node corresponds to an intermediate processing stage identifier, a processing logic adjustment strategy is generated. Processing logic adjustments include modifying data processing algorithm parameters, adjusting caching strategies, or optimizing computing resource allocation. For example, if root cause node B is a processing node type, and the associated processing stage is a data filtering module, with a current filtering threshold of 0.5, the adjustment strategy raises the threshold to 0.65 to reduce the amount of data passing through and lower the subsequent processing load. The adjustment strategy document records the adjustment type as "Processing Logic Adjustment," the target filtering threshold as 0.65, and the threshold increment as 0.15. When the root cause node corresponds to an impact status identifier, a status threshold adjustment strategy is generated. Status nodes are associated with the resource status monitoring of the test platform, and the adjustment strategy modifies resource usage thresholds or response time thresholds. For example, if root cause node C is a status node associated with CPU utilization status, and the current threshold of 85% triggers frequent alarms, the adjustment strategy lowers the threshold to 80% to trigger load control earlier. The adjustment strategy document records the adjustment type as "Status Threshold Adjustment," the target CPU threshold as 80%, and the threshold adjustment amount as 5%.

[0074] The self-generated adjustment strategy needs to be encapsulated as a new root cause pattern and added to the knowledge graph. The new pattern node contains the topological feature vector of the current common predecessor subgraph {2,1,1.0,1,2}, the node feature vector of root cause node A {instruction type,2.03,0,2,0.67}, the root cause node identifier "Node A", the adjustment strategy content "instruction parameter adjustment interval increment 25 milliseconds", an initial effectiveness score of 0.5, and 1 application count. The initial effectiveness score is set to a moderate value of 0.5, and the score is dynamically updated based on the actual effect feedback of the pattern in subsequent applications. The pattern node is assigned a unique identifier "M15" and inserted into the pattern set of the knowledge graph. The insertion operation simultaneously analyzes the similarity between the new pattern and existing patterns, calculating the weighted Euclidean distance between the feature vector of the new pattern and the feature vectors of all existing patterns. When the distance is between 0.35 and 0.60, an evolutionary edge is established, indicating that there is some correlation between the patterns but they are not completely identical; the edge weight is set to the reciprocal of the similarity. For example, the distance between the new model M15 and the existing model M5 is 0.45, and the weight of the evolutionary edge is 1 ÷ 0.45 = 2.22. The evolutionary edge supports reasoning and knowledge transfer between models. When the effectiveness score of a model is significantly improved, 10% of the score increment is propagated along the evolutionary edge to similar models as an indirect effect contribution.

[0075] The knowledge graph is stored using a graph database engine, supporting efficient graph traversal queries and real-time updates. The query interface receives feature vector input and returns a list of matching patterns, while the update interface receives new pattern data and performs insertion and edge creation operations. The database is configured with an indexing strategy, creating a combined index on the topological and node feature fields of pattern nodes to accelerate vector comparison for similarity calculation. A caching mechanism maintains the 100 most recently accessed pattern nodes, reducing database access latency from repeated queries. The knowledge graph supports version management, recording a version snapshot each time a pattern is added or a score is updated. The version number uses a timestamp format for easy backtracking and anomaly recovery.

[0076] This invention enables the continuous accumulation and intelligent reuse of root cause knowledge, accelerates decision response through historical pattern queries, ensures the reliability of adjustment strategies through effectiveness scoring, guarantees the ability to handle unknown scenarios through autonomous adjustment capabilities, and supports the continuous optimization of experience through dynamic updates of the knowledge graph.

[0077] A second aspect of the present invention provides a bidirectional data interaction system between a host computer and a testing platform, comprising: The protocol adaptation module is used by the host computer to obtain the capability description information of the test platform and construct the protocol adaptation rules, generate a test instruction sequence and assign an instruction identifier to each test instruction before sending it to the test platform; The load control module is used to receive test data returned by the test platform. The test data carries a traceability sequence and status feedback. When the status feedback meets the load judgment condition, the sending frequency of subsequent test instructions is adjusted. The execution plan is determined based on the feasibility feedback returned by the test platform and sent to the test platform. The dependency analysis module is used to construct a directed acyclic graph of dependency relationships based on the source sequence, assign influence weights to dependency edges, update the weights along the dependency edges according to the test data deviation, and extract the set of predecessor nodes when abnormal test data is detected and the dependency paths that meet the priority tracing conditions are selected. The root cause localization module is used to perform subgraph matching to identify common predecessor subgraphs from a set of predecessor nodes of multiple abnormal test data. Based on the cumulative weight of nodes in the common predecessor subgraph on the dependency path, the root cause node is determined, and the execution strategy is optimized and adjusted to generate an adjustment strategy which is then sent to the test platform.

[0078] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0079] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0080] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0081] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for bidirectional data interaction between a host computer and a testing platform, characterized in that: include: The host computer obtains the capability description information of the test platform and constructs protocol adaptation rules, generates a test instruction sequence and assigns an instruction identifier to each test instruction before sending it to the test platform; The test data returned by the test platform is received. The test data carries a traceability sequence and status feedback. When the status feedback meets the load determination condition, the sending frequency of subsequent test instructions is adjusted. The execution plan is determined based on the feasibility feedback returned by the test platform and sent to the test platform. Based on the source sequence, a directed acyclic graph of dependencies is constructed, and influence weights are assigned to the dependency edges. The weights are updated by propagation along the dependency edges according to the test data deviation. When abnormal test data is detected, dependency paths that meet the priority tracing conditions are selected to extract the set of predecessor nodes. For the set of predecessor nodes of multiple abnormal test data, subgraph matching is performed to identify a common predecessor subgraph. The root cause node is determined based on the cumulative weight of the nodes in the common predecessor subgraph on the dependency path. The execution strategy is then optimized and adjusted to generate an adjustment strategy, which is sent to the test platform.

2. The method according to claim 1, characterized in that, The steps involved in the host computer acquiring the capability description information of the test platform, constructing protocol adaptation rules, generating a test instruction sequence, assigning an instruction identifier to each test instruction, and sending it to the test platform include: Receive capability description information returned by the test platform, the capability description information including supported instruction set types, data interface formats and resource constraint parameters, and mark the capability description information with a version number; Based on the instruction set type, determine the instruction categories that need protocol conversion; for each instruction category, extract the difference features between the source instruction format and the target instruction format; construct a field mapping relationship table in conjunction with the data interface format; determine the test platform load judgment conditions based on the resource constraint parameters; integrate the field mapping relationship table and the load judgment conditions to form a protocol adaptation rule and associate it with the version number. Periodically retrieve the current capability description information and compare it with the stored version. When a change is detected, rebuild the field mapping relationship table and update the load judgment conditions for the changed part, generate new version protocol adaptation rules and establish a mapping relationship between the new and old versions. A test instruction sequence is generated according to the new version protocol adaptation rules. The version number is embedded in the instruction identifier of each test instruction, so that the test instruction carries the version information of the protocol adaptation rules it uses and is sent to the test platform.

3. The method according to claim 1, characterized in that, The steps of receiving test data returned by the testing platform, wherein the test data carries a traceability sequence and status feedback, adjusting the sending frequency of subsequent test commands when the status feedback meets the load determination conditions, and determining the execution plan based on the feasibility feedback returned by the testing platform and sending it to the testing platform include: The source sequence and status feedback are parsed from the received test data, and the status feedback includes resource occupancy status and instruction processing response time. The resource occupancy status is compared with the resource occupancy threshold in the protocol adaptation rules, and the instruction processing response time is compared with the response delay threshold. When either threshold is exceeded, the load determination condition is determined to be met. When the load determination condition is met, an adjustment coefficient is calculated based on the resource occupancy status and instruction processing response time. The sending frequency of subsequent test instructions is reduced based on the adjustment coefficient, and an execution strategy is generated. The execution strategy is sent to the test platform, and feasibility feedback is received. The feasibility feedback includes a determination of whether the execution strategy is acceptable. If acceptable, the execution strategy is used as the execution plan. If unacceptable, the execution strategy is regenerated based on the suggested parameters in the feasibility feedback and sent to the test platform as the execution plan. When the load determination condition is not met, the current test instruction sending frequency is maintained.

4. The method according to claim 1, characterized in that, The steps of constructing a directed acyclic graph of dependencies based on the source sequence, assigning influence weights to dependency edges, updating the weights along the dependency edges according to the test data deviation, and extracting the set of predecessor nodes by filtering dependency paths that meet the priority tracing conditions when abnormal test data is detected include: Identifiers for triggering instructions, intermediate processing steps, and influencing states are extracted from the source sequence and mapped to nodes. Directed edges are established based on the order and influence relationship between the identifiers to form a directed acyclic graph with dependency relationships. Initial influence weights are assigned based on the source node type and target node type connected by each directed edge, and a weight evolution sequence is created for each directed edge. The test data is compared with the expected value to calculate the test data deviation. The corresponding target node is located in the directed acyclic graph of the dependency relationship. The influence weight is updated by backpropagating from the target node along the dependency edge and added to the weight evolution sequence. The weight fluctuation characteristics of the dependent edges are calculated based on the weight evolution sequence. When the weight fluctuation characteristics satisfy the stability condition, they are marked as strong causal dependent edges. When abnormal test data is detected, abnormal nodes are extracted from the directed acyclic graph of the dependency relationship. The predecessor paths are traversed first from the abnormal nodes along the strong causal dependency edges. The dependency paths are filtered by combining the updated influence weights of the dependency edges, and the predecessor nodes on the dependency paths are extracted to form a predecessor node set.

5. The method according to claim 4, characterized in that, The steps of backpropagating from the target node along the dependency edges to update the influence weights and appending them to the weight evolution sequence include: The initial propagation intensity is determined based on the magnitude of the test data deviation. All incoming edges and their corresponding predecessor nodes are obtained from the target node. For each incoming edge, the combination pattern of the source node type and the target node type connected by the edge is extracted, and the corresponding weight attenuation factor is queried from the preset attenuation factor table. The initial propagation strength is multiplied by the current influence weight of the incoming edge and then multiplied by the weight decay factor to obtain the propagation strength of the predecessor node. The influence weight of the incoming edge is updated according to the difference between the propagation strength and the current influence weight. When the predecessor node has multiple outgoing edges pointing to different successor nodes, the propagation strengths received by all outgoing edges are collected, and a weighted fusion mechanism is used to calculate the total propagation strength of the predecessor node. The weighted fusion mechanism allocates fusion weights according to the degree of anomaly of each successor node. It is determined whether the total propagation strength of the predecessor node is greater than the propagation termination threshold. If it is greater, the propagation continues from the predecessor node to the previous predecessor node. If it is less, the propagation of the branch is terminated. During the propagation process, the weight update value and update time of each dependent edge are recorded and appended to the weight evolution sequence of the dependent edges.

6. The method according to claim 1, characterized in that, The steps of performing subgraph matching to identify a common predecessor subgraph from a set of predecessor nodes of multiple abnormal test data, determining the root cause node based on the cumulative weight of nodes in the common predecessor subgraph on the dependency path, optimizing and adjusting the execution strategy, generating an adjustment strategy, and sending it to the test platform include: Extract the subgraph structure of the predecessor node set corresponding to multiple abnormal test data from the directed acyclic graph of dependencies, and perform subgraph isomorphic matching on the subgraph structure to identify common predecessor subgraphs; The cumulative weights of each node in the common predecessor subgraph are obtained by tracing back along the dependency path from the abnormal node and accumulating the updated influence weights of each dependency edge. The cumulative weights are then sorted to determine the set of candidate root cause nodes. Extract the topological features of the common precursor subgraph and the node features of the candidate root cause nodes. Based on the topological features and node features, query the root cause knowledge graph for matching historical root cause patterns. When a match is found, extract the adjustment method and parameters of the historical root cause pattern as an adjustment template, and generate an appropriate adjustment strategy in combination with the current execution strategy. When no match is found, adjust the generated execution strategy according to the candidate root cause nodes to generate a new adjustment strategy and update the root cause knowledge graph. Send the adjustment strategy to the test platform.

7. The method according to claim 6, characterized in that, Based on the topological features and node features, the system queries and matches historical root cause patterns in the root cause knowledge graph. When a match is found, the system extracts the adjustment methods and parameters of the historical root cause patterns as adjustment templates and combines them with the current execution strategy to generate an appropriate adjustment strategy. When no match is found, the steps for adjusting the generated execution strategy based on the candidate root cause nodes, generating a new adjustment strategy, and updating the root cause knowledge graph include: Search the root cause knowledge graph for historical root cause patterns that match the topological and node features; When a matching historical root cause pattern is found, the most effective historical adjustment strategy is extracted as the adjustment template. Nodes with the same type as the root cause nodes in the historical root cause pattern are selected from the candidate root cause node set as root cause nodes. An adjustment strategy is generated based on the adjustment template and the current execution strategy. When no matching historical root cause pattern is found, the node with the largest cumulative weight is selected from the candidate root cause node set as the root cause node. The adjustment strategy type is determined according to the root cause node type and the generated execution strategy. When the root cause node is the node corresponding to the trigger instruction identifier, an instruction parameter adjustment strategy is generated. When the root cause node is the node corresponding to the intermediate processing stage identifier, a processing logic adjustment strategy is generated. When the root cause node is the node corresponding to the influence state identifier, a state threshold adjustment strategy is generated. Root cause nodes, topological features, and adjustment strategies are added as new root cause patterns to the root cause knowledge graph.

8. A two-way data interaction system based on a host computer and a testing platform, used to implement the method of any one of claims 1-7, characterized in that, include: The protocol adaptation module is used by the host computer to obtain the capability description information of the test platform and construct the protocol adaptation rules, generate a test instruction sequence and assign an instruction identifier to each test instruction before sending it to the test platform; The load control module is used to receive test data returned by the test platform. The test data carries a traceability sequence and status feedback. When the status feedback meets the load judgment condition, the sending frequency of subsequent test instructions is adjusted. The execution plan is determined based on the feasibility feedback returned by the test platform and sent to the test platform. The dependency analysis module is used to construct a directed acyclic graph of dependency relationships based on the source sequence, assign influence weights to dependency edges, update the weights along the dependency edges according to the test data deviation, and extract the set of predecessor nodes when abnormal test data is detected and the dependency paths that meet the priority tracing conditions are selected. The root cause localization module is used to perform subgraph matching to identify common predecessor subgraphs from a set of predecessor nodes of multiple abnormal test data. Based on the cumulative weight of nodes in the common predecessor subgraph on the dependency path, the root cause node is determined, and the execution strategy is optimized and adjusted to generate an adjustment strategy which is then sent to the test platform.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images