Industrial IoT control methods for adjusting multiple types of operating parameters

Abstract

This invention discloses an industrial IoT control method for adjusting multiple types of operating parameters, relating to the field of industrial automation control technology. The method includes the following steps: S001, establishing a timing observation baseline for multi-level redundant paths, injecting micro-amplitude identification pulses into all control nodes, generating command delay distribution curves and resource occupancy trajectories to reveal potential conflict sources and provide initial conditions. This invention reveals conflict sources by establishing a timing observation baseline, identifies competing nodes using a loop retrieval graph and forms a conflict list, issues single-source control tokens to achieve link convergence, monitors token stagnation combined with snapshot rollback and backup path takeover to avoid interruptions, performs delay shaping after takeover to ensure stable command delivery, and finally dynamically updates topology weights, token priorities, and circuit breaker thresholds to construct a self-evolving closed loop, achieving high reliability and high security in industrial IoT control.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, and more specifically to an industrial Internet of Things (IoT) control method for adjusting multiple types of operating parameters. Background Technology

[0002] Industrial IoT control with multi-type operating parameter allocation refers to the use of distributed sensing and interconnection to collect real-time data on various operating parameters (such as temperature, pressure, flow rate, current, voltage, speed, torque, and process time) involved in the production process or equipment operation within an Industrial IoT environment. Based on intelligent analysis and decision-making algorithms, the system dynamically adjusts and collaboratively optimizes the parameter configuration of each working stage. This method not only supports the joint allocation of multi-dimensional parameters but also enables adaptive control and collaborative response across devices and processes, thereby improving the flexibility, autonomy, and operational efficiency of the production system. Its core lies in leveraging the real-time interconnection and data fusion capabilities of the Industrial IoT to integrate various heterogeneous devices and sensor nodes into a unified control network, enabling efficient dynamic adjustment of key parameters under different operating conditions, and achieving intelligent optimization and safety assurance of the production process.

[0003] The existing technology has the following shortcomings:

[0004] In existing technologies, to improve the reliability and fault tolerance of industrial IoT control, multi-level redundant control paths are typically used to achieve dynamic allocation of key parameters. However, during the allocation of various types of operating parameters, allocation commands are prone to loop deadlocks in multi-level redundant control paths due to problems such as improper network structure design, command priority conflicts, or failure of real-time scheduling mechanisms. In this situation, different control nodes continuously and repeatedly contend for control, and the core allocation command cannot be ultimately confirmed by any node and sent to the actual execution end. This causes the allocation command to remain within the network for a long time, unable to be successfully implemented in critical process stages. As a result, important process stages are in an uncontrolled state without effective regulation for extended periods, and equipment consistently operates in high-risk ranges exceeding safety tolerances, which can easily lead to serious equipment damage, process instability, and even production safety accidents.

[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide an industrial Internet of Things (IoT) control method for adjusting multiple types of operating parameters, in order to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: an industrial IoT control method for adjusting multiple types of operating parameters, comprising the following steps:

[0008] S001, establish the timing observation baseline of multi-level redundant paths, inject micro-amplitude identification pulses into all control nodes, generate instruction delay distribution curves and resource occupation trajectories, which are used to reveal potential conflict sources and provide initial conditions;

[0009] S002, based on the instruction delay distribution curve and resource occupation trajectory, construct a loop retrieval graph, calculate the instruction return probability and stagnation duration, identify closed loop structures and competing nodes, and form a conflict list;

[0010] S003, issue a single-source control token according to the conflict list. The token flows unidirectionally along the shortest reliable path. Control nodes that do not hold a token are prohibited from writing to the execution end, ensuring unique control and making the control process converge to a single link.

[0011] S004: During the token circulation process, monitor the token stagnation status, dynamically compare the instruction delay distribution curve with the token position, and if the token stagnation exceeds the threshold, cancel the current loop, roll back to the last stable snapshot, and start the backup path takeover to avoid control interruption due to path failure.

[0012] S005, after the backup path takes over, delay shaping is performed on the allocation command. The sending cycle, load window and queuing weight are dynamically adjusted using real-time residual information to reduce the self-oscillation effect caused by path switching and ensure that the allocation command is stably delivered to the execution end.

[0013] S006, after the dispatch instructions are executed stably, comprehensively analyzes the execution residuals, circuit breaker records and takeover times, dynamically updates the topology weights, token priorities and circuit breaker thresholds, and builds a self-evolving closed-loop mechanism to continuously reduce deadlock risk and achieve a closed-loop logic throughout the entire process.

[0014] Preferably, step S001 includes:

[0015] During the initialization of multi-level redundant paths, each redundant path is divided into a continuous link consisting of a head input node, an intermediate transmission node, and a tail execution node.

[0016] Under a unified time reference, a small-amplitude identification pulse that does not affect process execution is injected into all control nodes, and a unique timestamp is assigned before the identification pulse is issued.

[0017] When identifying the pulse passing through each control node, the arrival time and departure time are recorded, and the calculation time, storage space usage ratio and communication bandwidth usage ratio of the node during the pulse passage are recorded simultaneously.

[0018] After the pulse transmission is identified, the data recorded by each node is summarized and sorted. The transmission time difference of the identified pulse between adjacent nodes is calculated to form a delay distribution curve. At the same time, the calculation duration, storage space usage ratio and communication bandwidth usage ratio are combined to form a resource usage trajectory, thereby constructing a time-series observation baseline that can truly reflect the node behavior and the operation status of the path.

[0019] Preferably, step S002 includes:

[0020] Based on the obtained instruction delay distribution curve and resource usage trajectory, all control nodes are mapped as independent points, and the average transmission delay and resource usage of each point are marked. The connection relationship between nodes is mapped as directed edges and the average transmission time is marked, thus forming a loop retrieval graph covering all redundant paths.

[0021] By combining the instruction delay distribution curve and resource usage trajectory, each directed edge and node is analyzed to calculate the instruction backflow probability and stagnation duration, thus obtaining path-level risk parameters and node-level risk parameters.

[0022] In the loop retrieval graph, all paths are traversed one by one to identify closed loop structures and calculate the average backflow probability and cumulative stagnation time. Closed loops with risk indicators exceeding the threshold are marked as potential conflict loops, and the nodes with the highest backflow probability and stagnation time within the loop are marked as competing nodes.

[0023] The identification results are compiled into a conflict list that includes closed loop numbers and path descriptions, closed loop risk indicators, and a list of competing nodes, to provide a basis for the subsequent issuance of control tokens.

[0024] Preferably, step S003 includes:

[0025] After generating the conflict list, based on the backflow probability, stagnation duration and resource consumption level in the conflict list, the node that is not in the closed conflict loop and has the lowest risk index is selected as the token starting node, and a unique number and arbitration cycle timestamp are assigned when generating the token to ensure uniqueness.

[0026] When determining the token transfer path, based on the path information in the conflict list, the average latency, cumulative stall time and resource usage ratio of each node are compared to select the path with the shortest transmission time and the lowest risk, and it is stipulated that the tokens will flow in a unidirectional order along this path.

[0027] During the token transfer process, the node receiving the token needs to verify the number, timestamp, and status flag. Only after the verification is successful can it obtain the permission to write to the execution end. After writing is completed, the token must be transferred to the next node within the specified time limit. Nodes that do not hold a token are prohibited from writing allocation instructions to the execution end.

[0028] After the token completes one round of circulation and returns to the starting node, the transmission delay, write result and stagnation status are confirmed. If an anomaly is found, the corresponding node is marked as a high-risk node and the conflict list is updated to ensure that the control process converges to a single link and forms a dynamically optimized closed loop.

[0029] Preferably, step S004 includes:

[0030] When a token enters the control node, the arrival time and dwell time are recorded and compared in real time with a pre-established instruction delay distribution curve. When the actual dwell time exceeds the normal range, an anomaly is initially determined.

[0031] By combining resource usage patterns to confirm anomalies, when the computation time continues to rise, the storage space usage ratio approaches full capacity, the communication bandwidth usage ratio increases significantly and the dwell time exceeds a preset threshold, it is determined that the node has entered a blocked state.

[0032] Once it is confirmed that the token stall has exceeded the threshold, the current loop is immediately revoked, all related nodes are prohibited from continuing to write, and the execution end and node state are rolled back to the stable snapshot of the last successful execution, restoring the key parameter values, token number and path order;

[0033] After the rollback is completed, a backup path with short average latency, low stagnation time and safe resource consumption is selected as the new path based on the conflict list and loop retrieval graph. A new token is regenerated at the starting node and passed to the execution end along the backup path to ensure the continuous and stable allocation process. The abnormal node information is updated to the conflict list to form a dynamic closed loop.

[0034] Preferably, step S005 includes:

[0035] After the backup path takeover is completed, the residual information of the transmission process before and after the takeover is obtained, and a residual table is formed that includes node number, residual delay, computation time, storage usage ratio and bandwidth usage ratio.

[0036] The sending interval of the allocation command is dynamically adjusted according to the residual table. When the node delay difference exceeds the snapshot reference value by 10 milliseconds, the sending interval is extended to twice the original value. When the overall transmission speed of the node is more than 5 milliseconds faster than the snapshot reference value, the sending interval is shortened to 70% of the original value.

[0037] While adjusting the transmission cycle, the load window is dynamically controlled. When the node storage occupancy rate exceeds 85% and the communication bandwidth occupancy rate exceeds 75%, the load window is reduced to half of the original set value. When the node storage occupancy rate is less than 50% and the communication bandwidth occupancy rate is less than 40%, the load window is expanded to twice the original set value.

[0038] Based on the adjustment of sending cycle time and load window, the queuing weight is optimized. When the residual delay exceeds 15 milliseconds, the instruction is assigned a priority value of 10 and transmitted in advance in the queuing order. When the residual delay is less than 5 milliseconds, the instruction is assigned a priority value of 2 and transmitted in the queuing order. This ensures that the allocation instruction is finally smoothly delivered to the execution end. After delivery, the residual information is recorded to update the basis for subsequent path optimization.

[0039] Preferably, step S006 includes:

[0040] After the dispatch instructions are executed stably, the operation data is collected and three types of data are generated: execution residual, circuit breaker record, and takeover count. The execution residual is the difference between the actual transmission time and the reference time of the stable snapshot. The circuit breaker record is the number of times the circuit breaker is triggered, the node number and the corresponding computing resource consumption, storage space usage ratio and communication bandwidth usage ratio. The takeover count is the number of times the backup path is used in the current loop and the duration.

[0041] After data collection is completed, the execution residuals, circuit breaker records and takeover times are analyzed. When the residual of a node is higher than 15 milliseconds and continues for multiple rounds, it is judged as a high-risk node. When a node triggers circuit break more than five times in ten cycles, its reliability is reduced. When a backup path takes over more than six times in ten cycles, its priority is reduced.

[0042] After completing the data analysis, the topology weight, token priority, and circuit breaker threshold are dynamically adjusted based on the results. When a node frequently triggers a circuit breaker, its topology weight is reduced; when a node performs stably, its topology weight is increased; when the path is reliable, its token priority is increased; when a node frequently triggers a circuit breaker erroneously, its circuit breaker threshold is increased; and when a critical node stops and blocks the entire link, its circuit breaker threshold is reduced.

[0043] After the parameters are updated, the updated topology weights are used to recalculate the shortest reliable path, the updated token priority is used to determine the flow order, and the updated circuit breaker threshold is used for stagnation monitoring. This enables path optimization, risk avoidance, and control loop in the new round of operation, ensuring that the control process has self-evolution capabilities and continuously reduces the risk of deadlock.

[0044] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0045] This invention first establishes a timing observation baseline across all control nodes and generates instruction delay distribution curves and resource occupancy trajectories, thus accurately revealing potential conflict sources. Then, it uses a loop retrieval graph to identify closed-loop structures and competing nodes, forming a conflict list to provide a basis for subsequent arbitration. Next, by issuing a single-source control token, the allocation process converges to a single reliable link, eliminating the risk of multiple nodes vying for control. Real-time monitoring of the token's stall status during token transfer, combined with snapshot rollback and backup path takeover, effectively avoids global control interruptions caused by path congestion. After backup path takeover, delay shaping is implemented, using residual information to dynamically adjust the sending cycle time, load window, and queuing weight, eliminating the oscillation effect caused by path switching and ensuring that allocation instructions can be smoothly delivered to the execution end. Finally, through comprehensive analysis of execution residuals, circuit breaker records, and takeover counts, the topology weight, token priority, and circuit breaker threshold are dynamically updated, forming a continuously self-evolving closed-loop mechanism. Therefore, this invention not only ensures the real-time stable allocation of various types of working parameters, but also continuously reduces the risk of deadlock during long-term operation, achieving high reliability, high security and high robustness of industrial IoT control. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0047] Figure 1 This is a flowchart of the industrial Internet of Things control method for adjusting multiple types of working parameters according to the present invention. Detailed Implementation

[0048] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0049] This invention provides, for example Figure 1 The industrial IoT control method for adjusting multiple types of operating parameters, as shown, includes the following steps:

[0050] S001, establish the timing observation baseline of multi-level redundant paths, inject micro-amplitude identification pulses into all control nodes, generate instruction delay distribution curves and resource occupation trajectories, which are used to reveal potential conflict sources and provide initial conditions;

[0051] In industrial IoT control methods involving the allocation of multiple types of operating parameters, to avoid issues such as allocation command delays and loop deadlocks in multi-level redundant paths, it is necessary to first establish a time-series observation baseline that accurately reflects node behavior and path operating status. This observation baseline not only forms complete command delay distribution curves and resource occupancy trajectories but also provides verifiable initial conditions for subsequent conflict identification, arbitration, and recovery. The specific implementation method is as follows:

[0052] During the initialization of multi-level redundant paths, each redundant path is divided into a continuous link consisting of an initial input node, intermediate transmission nodes, and an final execution node, according to the actual layout. To capture the actual propagation within the path, identification pulses with small amplitudes that do not affect process execution are injected into all control nodes one by one under a unified time reference. Each identification pulse is assigned a unique timestamp before being emitted, marking its generation time and corresponding path. As the identification pulse passes through each control node, its arrival and departure times are fully recorded by the acquisition device within that node, along with the node's resource usage during the pulse's passage. This resource usage includes three specific aspects: first, the computation time consumed by the node to process the identification pulse, measured in milliseconds; second, the proportion of storage space used by the node to buffer the identification pulse, measured in bytes and converted to a percentage of the total capacity; and third, the proportion of communication bandwidth used by the node during the identification pulse's passage, measured in bits per second and converted to a percentage of the link's maximum bandwidth. By uniformly injecting and recording data across all nodes, a complete and synchronized set of original data can be ensured to be formed throughout the multi-level redundant path.

[0053] After all identification pulses have been transmitted, the data recorded by each node needs to be summarized and sorted. By calculating the transmission time difference of the identification pulse between adjacent nodes, the delay distribution curve of the redundant path is formed sequentially. Simultaneously, the computation time, storage space usage ratio, and communication bandwidth usage ratio of each node during pulse transmission are combined, and these parameters are arranged in chronological order to form a resource usage trajectory. In this way, each redundant path not only has a curve regarding pulse transmission speed but also a trajectory regarding node resource load, thus achieving a two-dimensional description of the path's operating status. When forming the delay distribution curve, a strict correspondence between the curve and the timestamp must be maintained to ensure no time base deviation occurs during subsequent comparisons. When forming the resource usage trajectory, the continuity of the three types of resource parameters must be maintained to avoid incomplete information due to collecting only one type of parameter.

[0054] After obtaining the latency distribution curve and resource usage trajectory, they need to be compared point by point. Specifically, the arrival and departure times of the identified pulses at each node are analyzed in conjunction with the resource usage level of that node. If a node exhibits significant transmission lag on the latency distribution curve and shows high levels of computing resources, storage space, and communication bandwidth usage during the corresponding time period, it can be determined that this node poses a risk of potential conflict during actual operation. When multiple nodes exhibit similar characteristics within the same time period, the path segment can be further identified as a potentially conflict-intensive area. In this process, every latency curve and resource trajectory must be fully compared to avoid overlooking the cumulative effect of single-point problems. In this way, potential conflict sources can be concretized from the abstract state of "high latency" or "high load" into locatable nodes and path segments.

[0055] After locating potential conflict sources, a complete time-series observation baseline needs to be established based on latency distribution curves, resource occupancy trajectories, and conflict node information. This baseline not only includes latency and resource data for each redundant path but also clearly marks nodes and path segments that may trigger conflicts. In subsequent use, the observation baseline can serve as the initial condition for conflict retrieval, eliminating the need to re-establish observation data during loop identification, control arbitration, and circuit breaker rollback. More importantly, this observation baseline can be updated in every Industrial IoT control cycle, ensuring that the newly generated baseline remains consistent with the current operating state, thereby achieving dynamic adaptation.

[0056] The core function of establishing a time-series observation baseline for multi-level redundant paths and injecting micro-amplitude identification pulses into all control nodes is to provide a comprehensive, accurate, and traceable operational reference for the entire industrial IoT control method. By injecting identification pulses one by one under a unified time reference, the transmission speed of each redundant path and the response behavior of the nodes can be accurately reflected, thus forming a complete command delay distribution curve. Based on this, the resource usage trajectory is obtained by combining the computation time, storage space usage ratio, and communication bandwidth usage ratio of the nodes during the pulse passage. In this way, it can not only intuitively reveal which nodes have abnormal lag, but also clearly determine which nodes may become conflict sources under high load conditions. Compared with traditional methods that rely solely on a single delay indicator or local monitoring data, this step provides a solid data foundation for subsequent loop retrieval and conflict list generation through a two-dimensional and comprehensive approach. In other words, this step is not only about detecting the path status, but also about proactively revealing potential risks, ensuring that the entire control method is built on a quantifiable and verifiable data environment from the beginning, thereby improving the reliability and effectiveness of subsequent arbitration, circuit breaking, and optimization processes.

[0057] S002, based on the instruction delay distribution curve and resource occupation trajectory, construct a loop retrieval graph, calculate the instruction return probability and stagnation duration, identify closed loop structures and competing nodes, and form a conflict list;

[0058] After obtaining the instruction delay distribution curves and resource usage trajectories of multi-level redundant paths, further processing is required to identify potential closed-loop structures and competing nodes within the paths, ultimately forming a conflict list. This step not only integrates and analyzes the basic data but also provides a clear basis for subsequent control arbitration and path selection. The specific implementation method is as follows:

[0059] Based on the established instruction delay distribution curves and resource usage trajectories, all control nodes and their transmission relationships are represented in a graph. Specifically, each control node is mapped to an independent point in the graph, and two core parameters are labeled for this point: the average transmission delay of the identification pulse at this node, and the resource usage of this node when the identification pulse passes through, including the computation resource consumption time, storage space usage ratio, and communication bandwidth usage ratio. Simultaneously, the connections between nodes are mapped to directed edges, and the average transmission time of the identification pulse along each directed edge is labeled. In this way, a loop retrieval graph covering all redundant paths is obtained. This graph not only shows the topological relationships between nodes but also clearly presents the transmission performance of each path and the resource status of each node.

[0060] After constructing the loop retrieval graph, it is necessary to perform quantitative analysis on each directed edge and node, combining the instruction latency distribution curve and resource usage trajectory, to determine the probability of instruction backflow and the dwell time. Specifically, the implementation is as follows: First, compare the arrival and departure times of the identification pulse on different paths. If the round-trip time of a certain path is significantly close to or exceeds the average of other paths, it indicates that there is a risk of instruction backflow through that path, and this risk is expressed as a percentage as the backflow probability. Second, at the node level, compare the difference between the dwell time of the identification pulse in the node and the baseline normal transmission time. If the dwell time of a node increases significantly when the identification pulse passes through, and the node's computational resource consumption, storage usage ratio, and bandwidth usage ratio all remain at high levels, then it can be determined that the node has a large dwell time. In this way, each path has a clear backflow probability, and each node has a clear dwell time. These parameters strictly correspond to the latency distribution curve and resource trajectory obtained in the previous step, thereby ensuring the continuity and reliability of the data.

[0061] After obtaining the backflow probability and stagnation duration, all possible paths need to be traversed one by one in the loop retrieval graph to identify closed loop structures. Specifically, starting from any control node, the path is traced step-by-step according to the direction indicated by the directed edges. When the path returns to the starting node, a closed loop is considered formed. After identifying the closed loop, the backflow probability of all nodes within the loop is averaged, and the stagnation duration of all nodes is summed to serve as a risk indicator for the closed loop. If this risk indicator exceeds a pre-set safety threshold, the closed loop is identified as a potential conflict loop. Within the same closed loop, if a node has a backflow probability significantly higher than the average level and a stagnation duration at the highest level in the loop, that node is marked as a competing node. This method not only identifies the existence of closed loops but also clearly identifies key nodes within the loop that may escalate conflicts. Unlike existing technologies that only identify closed loops based on static topology, this implementation combines latency and resource consumption characteristics into the graph, more realistically reflecting the dynamic conflict risks during operation.

[0062] After identifying all closed-loop structures and competing nodes, this information needs to be organized to form a complete conflict list. The conflict list should include three parts: the first part is the closed-loop number and path description, detailing the order of control nodes within the loop and the connections between them; the second part is the risk indicators for the closed loop, clearly indicating the average backflow probability and cumulative stagnation time to reflect the severity of the conflict; the third part is a list of competing nodes, listing each marked high-risk node in the loop, along with its backflow probability and stagnation time data. The generation of the conflict list is closely integrated with the preceding steps, utilizing not only the delay distribution curve and resource occupancy trajectory formed by the observation baseline but also the traversal results of the loop retrieval graph. The conflict list will be directly applied in subsequent steps to guide the issuance of control tokens and path arbitration, thereby preventing multiple nodes from simultaneously vying for control and ensuring that allocation instructions can be successfully delivered to the execution end.

[0063] The process of constructing a loop retrieval graph based on instruction latency distribution curves and resource usage trajectories, and calculating instruction backflow probability and stagnation duration to identify closed-loop structures and competing nodes and form a conflict list, primarily transforms the potential operational risks in distributed redundant paths from abstract data states into visualized, quantifiable, and actionable objects. By mapping all control nodes and paths to a directed graph with latency and resource parameters, not only can the path topology be revealed, but the actual operational status of each node can also be clearly reflected. Furthermore, by calculating backflow probability and stagnation duration, risk points where instructions may backflow or linger for extended periods in specific paths can be identified. Loop retrieval combines these high-risk paths into closed-loop structures, revealing complete path segments that could lead to instruction deadlock. Simultaneously, marking the nodes with the most severe stagnation or highest backflow probability within the loop helps to pinpoint competing nodes. The final conflict list centrally presents loop numbers, path composition, risk indicators, and competing node information, providing a clear basis for subsequent token issuance, arbitration, and circuit breaker recovery. Therefore, this step not only acts as a bridge, closely linking basic observation data with subsequent arbitration mechanisms, but also improves the accuracy and reliability of conflict identification. It differs from the traditional method that relies on a single time delay monitoring and has significant creative and engineering application value.

[0064] S003, issue a single-source control token according to the conflict list. The token flows unidirectionally along the shortest reliable path. Control nodes that do not hold a token are prohibited from writing to the execution end, ensuring unique control and making the control process converge to a single link.

[0065] After generating the conflict list, a unique arbitration method is needed to avoid concurrent conflicts caused by multiple control nodes simultaneously issuing instructions to the execution end within a multi-level redundant path. This step involves issuing a single-source control token and specifying that the token flows unidirectionally along the shortest reliable path, ensuring that only one node has instruction writing authority throughout the entire control process, thereby achieving the uniqueness of control and the convergence of the link. The specific implementation method is as follows:

[0066] After generating the conflict list, a unique token initiating node needs to be determined. The selection of the token initiating node is based on the data in the conflict list, prioritizing nodes not within a closed conflict loop and with lower risk indicators. Risk indicators are assessed based on backflow probability and stagnation duration, while also considering the node's position in the latency distribution curve indicating faster transmission speed, and its performance in the resource usage trajectory showing short computation time, low storage space usage, and low communication bandwidth usage. When a token is generated at the initiating node, it is assigned a unique number and an arbitration period timestamp, ensuring that no two or more tokens exist concurrently throughout the redundant path. This measure guarantees unique control from the generation stage, eliminating potential command conflicts during the generation phase compared to traditional methods that rely on broadcast signals for multiple nodes to compete for control.

[0067] After token generation, the token's circulation path needs to be determined. Path selection is based on path information in the conflict list, requiring comparison of average latency, cumulative stall time, and resource utilization levels of each node among multiple candidate paths. The path with the shortest transmission time, lowest stall risk, and where all node resource utilization ratios do not exceed the safety threshold is ultimately selected. When the token begins circulation, it is passed from the starting node to the next node. During transmission, each node must perform verification upon receiving the token. Verification includes checking if the token number matches the number generated by the starting node, if the token timestamp is within the valid range of the current arbitration period, and if the token status marker is complete and intact. Only after successful verification can the node temporarily gain permission to write allocation instructions to the executor, and immediately pass the token to the next node after the write operation is completed. In this way, the token always circulates along a unique and fixed-order path, preventing forks, backflows, or loops in the network, thus ensuring the unidirectionality and reliability of the circulation process.

[0068] During token transfer, nodes without tokens must be strictly restricted to prevent multiple nodes from simultaneously writing to the execution end. Specifically, a permission verification mechanism is implemented at the execution end's write stage. Only nodes holding tokens, after passing verification, can submit allocation instructions to the execution end. Even if a node without a token detects a need to adjust parameters, it can only retain the instruction locally and lacks the ability to write it to the execution end. This mechanism ensures that even if multiple nodes simultaneously detect abnormal conditions, the execution end will only receive a single allocation instruction from the node holding the token, fundamentally avoiding conflicts caused by concurrent writes. To prevent tokens from being stalled for extended periods due to individual node errors, each node holding a token must complete the writing and transfer within a specified time limit. If the time limit is exceeded, the token will be automatically deemed invalid, and a circuit breaker mechanism will be activated to prepare for takeover by a backup path, preventing the entire control link from being blocked due to a single node's stagnation.

[0069] After a token completes a full cycle of circulation and returns to the starting node, the circulation process needs to be verified. The starting node checks whether the transmission latency of all nodes in this cycle is within the normal range, whether all execution end writes were successfully completed, and whether the token experienced any timeouts or stalls in the circulation path. If the check results indicate that all operations are normal, the control process is determined to have stably converged to a single link, and the next arbitration cycle can begin. If an anomaly is found in a node, such as token transmission timeout, instruction not being written, or token loss, the node is marked as a high-risk node, and its risk level is increased when updating the conflict list, so that the node can be avoided as much as possible in the next path selection. Through this closed-loop verification mechanism, not only is the convergence of control on a single link guaranteed, but also dynamic linkage with the conflict list of the previous stage is achieved, making token issuance and path arbitration form a continuously optimized cyclical process.

[0070] The core function of the steps described is to resolve the allocation command conflicts and deadlocks caused by multiple control nodes simultaneously possessing write capabilities in existing multi-level redundant paths. By setting a unique control token, it is ensured that only one node has the authority to transmit allocation commands to the execution end at any given time, fundamentally eliminating the possibility of concurrent writes. The unidirectional token flow mechanism along the shortest reliable path ensures that control is passed sequentially between nodes in a predetermined order, preventing backflow or loops and thus avoiding endless competition in closed loops. For nodes without a token, their write permissions are strictly prohibited. Even if a node detects an abnormal condition, it can only temporarily store the allocation intention and cannot directly write to the execution end. This measure ensures that the execution end always receives only one valid command. Simultaneously, the periodic circulation of the token and the confirmation mechanism of returning to the starting node ensure that the entire control process continuously converges and verifies the stability of the execution link. In summary, this step not only establishes the only arbitration method for cross-node collaborative control in the industrial IoT environment, but also compresses the control process into a single controlled link, significantly improving the orderliness, stability, and security of command issuance, and providing a reliable prerequisite for subsequent fault circuit interruption and backup path takeover.

[0071] S004: During the token circulation process, monitor the token stagnation status, dynamically compare the instruction delay distribution curve with the token position, and if the token stagnation exceeds the threshold, cancel the current loop, roll back to the last stable snapshot, and start the backup path takeover to avoid control interruption due to path failure.

[0072] During the process of token issuance and circulation along the shortest reliable path, the token's transmission status needs continuous monitoring to prevent prolonged stagnation due to node failure, resource exhaustion, or abnormal link latency, which could lead to control being stuck and unable to continue transmission. To this end, this step compares the token's current position with a pre-established instruction latency distribution curve to determine if a timeout occurs. Once stagnation exceeds a threshold, the current loop is immediately revoked, rolled back to the last stable snapshot, and a backup path is initiated to take over, ensuring the continuity of the control process. The specific implementation is as follows:

[0073] When a token enters a node, its arrival time needs to be recorded, and its dwell time at that node needs to be continuously measured. When the token is passed to the next node, its departure time is recorded, thus obtaining the actual dwell time at that node. Simultaneously, this data is compared in real time with the command delay distribution curve obtained when establishing the time-series observation baseline. For example, if the normal transmission time of a node in the command delay distribution curve is 6 to 9 milliseconds, but the monitored actual dwell time reaches 20 milliseconds, it can be preliminarily determined that the node has an abnormal stagnation phenomenon. Through this comparison based on actual measurements and baseline data, it is possible to accurately locate whether there is an unreasonable delay in the token's movement within the pathway, thereby ensuring the scientific rigor and objectivity of the monitoring and judgment.

[0074] After initially determining that a blockage exists, it is necessary to comprehensively confirm whether the blockage exceeds a threshold by combining resource usage trajectory data. The threshold is determined not only by the maximum normal value of the node in the latency distribution curve, but also by the node's resource usage within the corresponding time period. If, within the same time period, the node's computation time continuously increases, its storage space usage ratio approaches full capacity, its communication bandwidth usage ratio increases significantly, and the token dwell time exceeds a preset threshold (e.g., more than twice the normal maximum value), then it can be confirmed that the node has entered a blocked state. At this point, it must be immediately determined that the token cannot continue to flow effectively, otherwise it will cause the entire path to stagnate. Unlike the traditional method that relies on a fixed timeout period for judgment, this step introduces actual usage data of computational resources, storage space, and communication bandwidth in the blockage judgment, making the judgment result more accurate and avoiding misjudgment or omission.

[0075] Once it's determined that token stagnation exceeds a threshold, the current loop must be immediately revoked and the system rolled back to the last stable snapshot. Specifically, this involves: first, halting further token transmission along the path and revoking write permissions on all relevant nodes to prevent abnormal nodes from continuing to control the system. Then, restoring the execution end and node states to the stable snapshot saved during the last successful execution. The stable snapshot stores data including key parameter values ​​for the execution end, the starting number and timestamp of the token in the previous successful circulation, and the node order of the last stable path. Restoring this information ensures that even if an anomaly occurs in the current path, the execution end remains in the most recent reliable state and will not enter uncontrolled operation due to token stagnation. This mechanism effectively provides rollback protection, enabling the control process to recover in abnormal situations.

[0076] After the rollback is complete, the takeover operation of the backup path needs to be initiated immediately. The backup path is selected based on the priority ranking in the previously generated conflict list and loop retrieval graph. Specifically, the path with the shortest average latency, the lowest cumulative downtime, and the resource utilization level of each node within a safe range is selected as the new transmission path. A new token is then generated at the starting node, assigned a new number and a timestamp for the current arbitration period. The new token is passed down the backup path to the execution end level by level. Each node, upon receiving the token, also needs to verify the number and timestamp, and complete the instruction writing and forwarding during the token holding period. Through the takeover of the backup path, anomalies in the original path will not cause control interruption, but will allow instructions to continue to be transmitted to the execution end, ensuring the continuity and stability of the allocation process. Simultaneously, the abnormal data of the original path is recorded and updated in the conflict list, increasing the risk level of the corresponding node so that it can be avoided in subsequent path selections.

[0077] The core function of the steps described is to provide a reliable anomaly detection and recovery mechanism for the entire industrial IoT control process. This involves monitoring the token's stagnation status during token circulation, dynamically comparing the instruction latency distribution curve with the token's position, and if token stagnation exceeds a threshold, canceling the current loop, rolling back to the last stable snapshot, and initiating backup path takeover. Because multi-level redundant paths inevitably experience node resource overload, sudden increases in link latency, or hardware failures, tokens are prone to stagnation or even jamming during circulation. Without effective monitoring and handling, control may remain stuck at a node for an extended period, causing the execution end to lose dispatch instructions and leading to a loss of process control. This step, by comparing the actual time the token spends in the node with the pre-established instruction latency distribution curve, accurately determines whether the token exceeds the normal threshold and confirms whether it has entered a blocked state based on resource usage. Once stagnation is confirmed, control of that path is immediately canceled to prevent the anomaly from spreading; simultaneously, rolling back to the last stable snapshot allows the execution end to quickly return to the most recent safe state, ensuring that process parameters are not erroneously affected; subsequently, backup path takeover is initiated, allowing new tokens to be successfully delivered to the execution end, ensuring uninterrupted dispatching. Therefore, this step achieves a complete closed loop from anomaly detection to safe rollback and path switching, avoiding the global shutdown caused by path failure in existing technologies, and significantly improving the robustness and security of the system.

[0078] S005, after the backup path takes over, delay shaping is performed on the allocation command. The sending cycle, load window and queuing weight are dynamically adjusted using real-time residual information to reduce the self-oscillation effect caused by path switching and ensure that the allocation command is stably delivered to the execution end.

[0079] After the backup path takes over, although the new path ensures the continued transmission of tokens and allocation instructions, differences in transmission latency, node load, and resource usage between the backup and original paths can easily lead to self-oscillations caused by sudden latency fluctuations and resource congestion if left unadjusted. This can cause allocation instructions to experience queuing congestion or instantaneous impact on the execution end within a short period, thus affecting the stability of the execution end. Therefore, latency shaping needs to be implemented after the backup path takes over. By utilizing real-time residual information, the transmission cycle time, load window, and queuing weight are gradually adjusted to ensure that allocation instructions can be stably delivered to the execution end. The specific implementation method is as follows:

[0080] Immediately after the backup path takeover is completed, residual information from the transmission process before and after the takeover needs to be obtained. Residual information is derived by comparing the actual latency of each node in the backup path with the reference latency recorded in the original path's stable snapshot, combined with the node's current computation time consumption, storage space usage ratio, and communication bandwidth occupancy ratio. Specifically, if a node's transmission latency in the backup path is more than 10 milliseconds higher than the snapshot reference value, and its storage space occupancy exceeds 80% and communication bandwidth occupancy exceeds 70%, it can be determined that the node has significant residuals. By performing the same data collection and comparison on all nodes, a complete residual table is generated, including node number, residual latency, computation time consumption, storage occupancy ratio, and bandwidth occupancy ratio. This residual table provides a quantitative basis for subsequent adjustments, unlike existing technologies that rely solely on experience to set compensation time.

[0081] After obtaining the residual table, the transmission cycle of dispatch commands needs to be dynamically adjusted based on the residual information. The transmission cycle refers to the time interval between two consecutive commands. In the backup path, if the residual table shows that the latency difference of some nodes is much higher than the snapshot reference value, the transmission cycle interval needs to be increased, for example, from the original 5 milliseconds to 10 milliseconds, to avoid multiple commands piling up at that node. If the residual table shows that the overall transmission speed of the node is better than the original path, the transmission cycle can be shortened, for example, from the original 10 milliseconds to 7 milliseconds, thereby improving command transmission efficiency. Each cycle adjustment is directly related to the node residual value, ensuring that the adjustment action matches the actual operating conditions, rather than a fixed static setting. This effectively reduces fluctuations caused by differences in the characteristics of the backup path.

[0082] While adjusting the transmission cycle, dynamic control of the load window is also necessary. The load window refers to the number of dispatch commands allowed to enter the backup path within a certain time period. If the residual table shows that a node's storage occupancy is higher than 85% and its communication bandwidth occupancy is higher than 75%, the load window should be reduced, for example, from allowing simultaneous transmission of 10 commands to 6, to reduce the instantaneous pressure on that node. If the node's storage occupancy is lower than 50% and its bandwidth occupancy is lower than 40%, the load window can be expanded, for example, from 6 to 12, to improve overall transmission efficiency. Through this adjustment of the load window, it can be ensured that the backup path will not cause new congestion due to instantaneous command overload during the early takeover phase, ensuring balanced command transmission among all nodes.

[0083] Building upon adjustments to the transmission cycle and load window, further optimization of queuing weights is needed to ensure a reasonable and stable transmission order for different instructions in the backup path. Specifically, when multiple instructions are queued for transmission simultaneously, different priorities are assigned to the instructions based on the latency difference in the residual table. For example, instructions with residual latency exceeding 15 milliseconds are given a higher queuing weight, allowing them to pass through nodes first and preventing further residual expansion; while instructions with residual latency below 5 milliseconds are assigned a lower queuing weight, allowing them to be transmitted later, thus freeing up bandwidth and resources for instructions with high residuals. This priority adjustment makes the transmission order of different instructions in the backup path more reasonable, ultimately ensuring all instructions arrive smoothly at the execution end. After the allocated instructions have been stably deployed at the execution end, the actual residual information needs to be re-recorded as reference data for the next round of path optimization.

[0084] The step of "after the backup path takes over, performing latency shaping on allocation instructions, and dynamically adjusting the sending cycle time, load window, and queuing weight using real-time residual information to mitigate the self-oscillation effect caused by path switching, ensuring that allocation instructions are stably delivered to the execution end" is crucial for ensuring the smooth transmission of allocation instructions and the continuous stable operation of the execution end after the backup path switch. When the original path is revoked due to token stagnation or resource overload, although the backup path can take over the task, it usually differs significantly from the original path in terms of transmission latency, resource load, and node performance. Without adaptation, instructions can easily accumulate excessively or experience sudden congestion in the new path, leading to self-oscillation and causing instruction delays, sudden shocks, or even failures at the execution end. This step compares the actual operation of the backup path with the snapshot baseline by calculating the node residual data in real time, and dynamically adjusts the sending cycle time, load window, and queuing weight based on the difference to gradually eliminate the impact of sudden fluctuations. Adjusting the sending cycle time ensures reasonable instruction intervals, adjusting the load window prevents node overload, and optimizing the queuing weight ensures that instructions with high residuals are transmitted first. This series of actions forms an adaptive shaping mechanism after path switching, enabling dispatch commands to enter the execution end in a balanced and orderly manner. This step avoids the limitations of traditional technologies that rely solely on fixed delays or static queue compensation, achieving real-time balancing and vibration suppression under dynamic conditions, thereby ensuring the continuity and reliability of the execution end throughout the entire industrial IoT control process.

[0085] S006, after the dispatch instructions are executed stably, comprehensively analyze the execution residuals, circuit breaker records and takeover times, dynamically update the topology weight, token priority and circuit breaker threshold, build a self-evolving closed-loop mechanism, and achieve continuous reduction of deadlock risk and full-process logical closed loop;

[0086] Once the dispatch command has been stably delivered to the execution end after being taken over by the backup path and undergoing latency shaping, the process cannot simply stop at the completion of a single execution. Instead, a systematic data analysis and dynamic correction of the entire execution process is needed to continuously optimize network operation in subsequent loops. To this end, it is necessary to comprehensively analyze execution residuals, circuit breaker records, and takeover counts, and update topology weights, token priorities, and circuit breaker thresholds accordingly, forming a continuously evolving closed-loop mechanism. The specific implementation method is as follows:

[0087] After the dispatch instructions are executed stably, it is necessary to collect and organize the operational data completely. The operational data includes three categories: first, execution residuals, which are the difference between the actual time each dispatch instruction takes to travel from the starting node to the execution end and the reference time in the previous stable snapshot; second, circuit breaker records, which include the number of times a circuit breaker operation is triggered during token circulation, the node number where the circuit breaker occurred, the computational resource consumption, storage space usage ratio, and communication bandwidth usage ratio at the time of triggering; and third, takeover counts, which include the number of times the backup path is activated in the current loop and the duration of each takeover. These data need to be matched one by one with the node number and saved in chronological order. Unlike existing technologies that only record partial error data when serious anomalies occur, this step records the complete data regardless of whether the execution is successful or not, thus ensuring the comprehensiveness and continuity of the data.

[0088] After data collection, the three types of data need to be analyzed one by one. For execution residuals, the average and maximum residuals of each node need to be calculated to identify which nodes still have persistent latency after path switching. For circuit breaker records, the frequency of circuit breaker triggering needs to be calculated. If a node triggers a circuit breaker more than five times in ten executions, it is considered to be in a high-risk state. For takeover times, the utilization ratio of backup paths and primary paths needs to be compared. If the takeover frequency of a backup path is significantly higher than that of other paths, for example, more than six times in ten loops, it indicates that the primary path has insufficient stability and its priority needs to be reduced in the next path selection. During the analysis, the execution residuals also need to be compared with the residual table from the previous latency shaping phase to verify the effectiveness of the shaping measures. If the residuals are still greater than 15 milliseconds and persist for multiple rounds, it indicates that the path selection strategy needs further adjustment.

[0089] After the analysis is complete, the topology weights, token priorities, and circuit breaker thresholds need to be adjusted based on the results. For topology weights, if a node exhibits high residuals and frequent circuit breakers across multiple loops, its weight should be reduced, for example, from 5 to 2, to decrease its probability of being included in the main path in future path selections. Conversely, for nodes with residuals below 5 milliseconds across multiple loops and almost no circuit breakers triggered, their weights should be increased, for example, from 3 to 6, to increase their likelihood of entering the main path. For token priorities, if nodes on a path perform stably across multiple executions, the token priority on that path should be increased to allow them to pass through reliable nodes faster during path selection and flow. For circuit breaker thresholds, if some nodes frequently trigger circuit breakers due to slight fluctuations, their circuit breaker thresholds should be increased, for example, from a standstill time of 10 milliseconds to 15 milliseconds, to avoid excessive circuit breaking; while for critical nodes that would cause end-to-end blocking if they were to stand still, their circuit breaker thresholds should be reduced, for example, from 15 milliseconds to 8 milliseconds, to allow them to be isolated more quickly.

[0090] After adjusting the topology weights, token priorities, and circuit breaker thresholds, these updates need to be applied to the next round of token issuance and path selection, thus forming a self-evolving closed-loop mechanism. Specifically, at the start of a new round, the shortest reliable path is recalculated using the updated topology weights, prioritizing nodes with higher weights to construct paths. During token circulation, the token passage order is arranged according to the new priority order to avoid high-risk nodes as much as possible. During stall monitoring, the updated circuit breaker threshold is used as the judgment criterion, making the circuit breaker triggering more closely match the actual operating conditions. In this way, the data from each round of operation directly affects the next round, allowing the control process to be gradually optimized in continuous cycles. The node weight distribution becomes more reasonable, the token priority is more realistic, and the circuit breaker threshold is more in line with the operating environment, thereby continuously reducing the risk of deadlock. Unlike existing technologies where parameter settings remain unchanged, this step, through a dynamic update mechanism, enables the entire control method to have self-learning and self-correcting capabilities, ensuring the stability and high reliability of industrial IoT control during long-term operation.

[0091] The step of "after the stable execution of dispatch instructions, comprehensively analyzing the execution residuals, circuit breaker records, and takeover times, dynamically updating the topology weights, token priorities, and circuit breaker thresholds, and constructing a self-evolving closed-loop mechanism" aims to enable the industrial IoT control process to continuously optimize and self-evolve, thereby effectively reducing the risk of deadlock during long-term operation. This step involves collecting complete operational data after each round of instruction execution, including the actual residuals of instructions at each node, the number and conditions of circuit breaker triggers, and the frequency and duration of backup path takeovers. This data is then compared and analyzed with snapshot benchmarks and latency shaping results to comprehensively reflect the true operational status of nodes and paths. Based on these analysis results, topology weights can be dynamically adjusted, weakening nodes with high residuals and frequent circuit breakers in future path selections while strengthening stable and reliable nodes; token priorities can be optimized, ensuring tokens are prioritized in reliable paths, thereby reducing overall latency; and circuit breaker thresholds can be corrected to avoid efficiency degradation due to excessive triggering while ensuring timely isolation when critical nodes malfunction, guaranteeing operational safety. Through this dynamic update, the result of each execution directly affects the control strategy in the next round, forming a data-driven closed loop. This makes the control process no longer dependent on static configuration, but constantly adapts to complex environments during continuous operation, ultimately achieving more robust, efficient and safe industrial IoT control.

[0092] This invention first establishes a timing observation baseline across all control nodes and generates instruction delay distribution curves and resource occupancy trajectories, thus accurately revealing potential conflict sources. Then, it uses a loop retrieval graph to identify closed-loop structures and competing nodes, forming a conflict list to provide a basis for subsequent arbitration. Next, by issuing a single-source control token, the allocation process converges to a single reliable link, eliminating the risk of multiple nodes vying for control. Real-time monitoring of the token's stall status during token transfer, combined with snapshot rollback and backup path takeover, effectively avoids global control interruptions caused by path congestion. After backup path takeover, delay shaping is implemented, using residual information to dynamically adjust the sending cycle time, load window, and queuing weight, eliminating the oscillation effect caused by path switching and ensuring that allocation instructions can be smoothly delivered to the execution end. Finally, through comprehensive analysis of execution residuals, circuit breaker records, and takeover counts, the topology weight, token priority, and circuit breaker threshold are dynamically updated, forming a continuously self-evolving closed-loop mechanism. Therefore, this invention not only ensures the real-time stable allocation of various types of working parameters, but also continuously reduces the risk of deadlock during long-term operation, achieving high reliability, high security and high robustness of industrial IoT control.

[0093] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. An industrial IoT control method for adjusting multiple types of operating parameters, characterized in that, Includes the following steps: S001, establish the timing observation baseline of multi-level redundant paths, inject micro-amplitude identification pulses into all control nodes, generate instruction delay distribution curves and resource occupation trajectories, which are used to reveal potential conflict sources and provide initial conditions; During the initialization of multi-level redundant paths, each redundant path is divided into a continuous link consisting of a head input node, an intermediate transmission node, and a tail execution node. Under a unified time reference, a small-amplitude identification pulse that does not affect process execution is injected into all control nodes, and a unique timestamp is assigned before the identification pulse is issued. When identifying the pulse passing through each control node, the arrival time and departure time are recorded, and the calculation time, storage space usage ratio and communication bandwidth usage ratio of the node during the pulse passage are recorded simultaneously. After the pulse transmission is identified, the data recorded by each node is summarized and sorted. The transmission time difference of the identified pulse between adjacent nodes is calculated to form a delay distribution curve. At the same time, the calculation duration, storage space usage ratio and communication bandwidth usage ratio are combined to form a resource usage trajectory, thereby constructing a time-series observation baseline that can truly reflect the node behavior and the path operation status. S002, based on the instruction delay distribution curve and resource occupation trajectory, construct a loop retrieval graph, calculate the instruction return probability and stagnation duration, identify closed loop structures and competing nodes, and form a conflict list; S003, issue a single-source control token according to the conflict list. The token flows unidirectionally along the shortest reliable path. Control nodes that do not hold a token are prohibited from writing to the execution end, ensuring unique control and making the control process converge to a single link. S004: During the token circulation process, monitor the token stagnation status, dynamically compare the instruction delay distribution curve with the token position, and if the token stagnation exceeds the threshold, cancel the current loop, roll back to the last stable snapshot, and start the backup path takeover to avoid control interruption due to path failure. S005, after the backup path takes over, delay shaping is performed on the allocation command. The sending cycle, load window and queuing weight are dynamically adjusted using real-time residual information to reduce the self-oscillation effect caused by path switching and ensure that the allocation command is stably delivered to the execution end. S006, after the dispatch instructions are executed stably, comprehensively analyzes the execution residuals, circuit breaker records and takeover times, dynamically updates the topology weights, token priorities and circuit breaker thresholds, and builds a self-evolving closed-loop mechanism to continuously reduce deadlock risk and achieve a closed-loop logic throughout the entire process.

2. The industrial IoT control method for adjusting multiple types of operating parameters according to claim 1, characterized in that, Step S002 includes: Based on the obtained instruction delay distribution curve and resource usage trajectory, all control nodes are mapped as independent points, and the average transmission delay and resource usage of each point are marked. The connection relationship between nodes is mapped as directed edges and the average transmission time is marked, thus forming a loop retrieval graph covering all redundant paths. By combining the instruction delay distribution curve and resource usage trajectory, each directed edge and node is analyzed to calculate the instruction backflow probability and stagnation duration, thus obtaining path-level risk parameters and node-level risk parameters. In the loop retrieval graph, all paths are traversed one by one to identify closed loop structures and calculate the average backflow probability and cumulative stagnation time. Closed loops with risk indicators exceeding the threshold are marked as potential conflict loops, and the nodes with the highest backflow probability and stagnation time within the loop are marked as competing nodes. The identification results are compiled into a conflict list that includes closed loop numbers and path descriptions, closed loop risk indicators, and a list of competing nodes, to provide a basis for the subsequent issuance of control tokens.

3. The industrial IoT control method for adjusting multiple types of operating parameters according to claim 1, characterized in that, Step S003 includes: After generating the conflict list, based on the backflow probability, stagnation duration and resource consumption level in the conflict list, the node that is not in the closed conflict loop and has the lowest risk index is selected as the token starting node, and a unique number and arbitration cycle timestamp are assigned when generating the token to ensure uniqueness. When determining the token transfer path, based on the path information in the conflict list, the average latency, cumulative stall time and resource usage ratio of each node are compared to select the path with the shortest transmission time and the lowest risk, and it is stipulated that the tokens will flow in a unidirectional order along this path. During the token transfer process, the node receiving the token needs to verify the number, timestamp, and status flag. Only after the verification is successful can it obtain the permission to write to the execution end. After writing is completed, the token must be transferred to the next node within the specified time limit. Nodes that do not hold a token are prohibited from writing allocation instructions to the execution end. After the token completes one round of circulation and returns to the starting node, the transmission delay, write result and stagnation status are confirmed. If an anomaly is found, the corresponding node is marked as a high-risk node and the conflict list is updated to ensure that the control process converges to a single link and forms a dynamically optimized closed loop.

4. The industrial IoT control method for adjusting multiple types of operating parameters according to claim 1, characterized in that, Step S004 includes: When a token enters the control node, the arrival time and dwell time are recorded and compared in real time with a pre-established instruction delay distribution curve. When the actual dwell time exceeds the normal range, an anomaly is initially determined. By combining resource usage patterns to confirm anomalies, when the computation time continues to rise, the storage space usage ratio approaches full capacity, the communication bandwidth usage ratio increases significantly and the dwell time exceeds a preset threshold, it is determined that the node has entered a blocked state. Once it is confirmed that the token stall has exceeded the threshold, the current loop is immediately revoked, all related nodes are prohibited from continuing to write, and the execution end and node state are rolled back to the stable snapshot of the last successful execution, restoring the key parameter values, token number and path order; After the rollback is completed, a backup path with short average latency, low stagnation time and safe resource consumption is selected as the new path based on the conflict list and loop retrieval graph. A new token is regenerated at the starting node and passed to the execution end along the backup path to ensure the continuous and stable allocation process. The abnormal node information is updated to the conflict list to form a dynamic closed loop.

5. The industrial IoT control method for adjusting multiple types of operating parameters according to claim 1, characterized in that, Step S005 includes: After the backup path takeover is completed, the residual information of the transmission process before and after the takeover is obtained, and a residual table is formed that includes node number, residual delay, computation time, storage usage ratio and bandwidth usage ratio. The sending interval of the allocation command is dynamically adjusted according to the residual table. When the node delay difference exceeds the snapshot reference value by 10 milliseconds, the sending interval is extended to twice the original value. When the overall transmission speed of the node is more than 5 milliseconds faster than the snapshot reference value, the sending interval is shortened to 70% of the original value. While adjusting the transmission cycle, the load window is dynamically controlled. When the node storage occupancy rate exceeds 85% and the communication bandwidth occupancy rate exceeds 75%, the load window is reduced to half of the original set value. When the node storage occupancy rate is less than 50% and the communication bandwidth occupancy rate is less than 40%, the load window is expanded to twice the original set value. Based on the adjustment of sending cycle time and load window, the queuing weight is optimized. When the residual delay exceeds 15 milliseconds, the instruction is assigned a priority value of 10 and transmitted in advance in the queuing order. When the residual delay is less than 5 milliseconds, the instruction is assigned a priority value of 2 and transmitted in the queuing order. This ensures that the allocation instruction is finally smoothly delivered to the execution end. After delivery, the residual information is recorded to update the basis for subsequent path optimization.

6. The industrial IoT control method for adjusting multiple types of operating parameters according to claim 1, characterized in that, Step S006 includes: After the dispatch instructions are executed stably, the operation data is collected and three types of data are generated: execution residual, circuit breaker record, and takeover count. The execution residual is the difference between the actual transmission time and the reference time of the stable snapshot. The circuit breaker record is the number of times the circuit breaker is triggered, the node number and the corresponding computing resource consumption, storage space usage ratio and communication bandwidth usage ratio. The takeover count is the number of times the backup path is used in the current loop and the duration. After data collection is completed, the execution residuals, circuit breaker records and takeover times are analyzed. When the residual of a node is higher than 15 milliseconds and continues for multiple rounds, it is judged as a high-risk node. When a node triggers circuit break more than five times in ten cycles, its reliability is reduced. When a backup path takes over more than six times in ten cycles, its priority is reduced. After completing the data analysis, the topology weight, token priority, and circuit breaker threshold are dynamically adjusted based on the results. When a node frequently triggers a circuit breaker, its topology weight is reduced; when a node performs stably, its topology weight is increased; when the path is reliable, its token priority is increased; when a node frequently triggers a circuit breaker erroneously, its circuit breaker threshold is increased; and when a critical node stops and blocks the entire link, its circuit breaker threshold is reduced. After the parameters are updated, the updated topology weights are used to recalculate the shortest reliable path, the updated token priority is used to determine the flow order, and the updated circuit breaker threshold is used for stagnation monitoring. This enables path optimization, risk avoidance, and control loop in the new round of operation, ensuring that the control process has self-evolution capabilities and continuously reduces the risk of deadlock.

Images