A network-aware real-time task allocation method for industrial control mainboard

Abstract

The application relates to the technical field of distributed computing and task scheduling, in particular to a network perception real-time task distribution method for an industrial control mainboard, which comprises the following steps: identifying a risk running time node based on network delay and packet loss rate; splitting an original code file into a plurality of parallel execution subtasks; matching each parallel execution subtask with each processing unit to run each parallel execution subtask; determining the stable output feature of a single original code file based on processing interference intensity; determining the processing fluency feature based on waiting delay amount to determine whether to correct the splitting intensity for the original code file; and determining the task matching feature based on universal execution deviation amount to determine whether to correct the running rate difference standard of adjacent processing units. The granularity of parallel splitting is dynamically adjusted according to the waiting delay in actual operation, and the fluency feedback correction mechanism is used; when the scheduling delay exceeds the expectation, the splitting intensity is increased to disperse the waiting burden, and the task processing efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of task allocation technology, and in particular to a network-aware real-time task allocation method for industrial control motherboards. Background Technology

[0002] Edge intelligent control in the Industrial Internet requires uploading collected equipment status data, sensor data, or control logic code to edge nodes or cloud computing resources for real-time analysis, and quickly feeding back control commands based on the analysis results. Due to the complexity of the field network environment, there may be network latency fluctuations, packet loss, or link congestion between edge nodes and the cloud, or between different computing nodes. If a fixed scheduling strategy is still used, it is easy to cause the output results of subtasks to not be transmitted in a timely manner, which in turn causes subsequent processing units to wait, pipeline to stop, or overall response timeout.

[0003] Chinese Patent Publication No. CN119781943A discloses a real-time task allocation method based on mobile edge computing. The technical solution is as follows: After obtaining a new task issued by a user terminal, the new task is divided into subtasks according to a set objective function and constraints, and these subtasks are allocated to the task cache queues corresponding to the currently available mobile edge nodes. For each task cache queue corresponding to a mobile edge node, the subtasks in each task cache queue are reordered according to a hybrid sensitivity ranking method, resulting in reordered task cache queues. The hybrid sensitivity ranking method uses the ratio of the derivative of the task service delay to the task processing time to calculate a hybrid sensitivity score. Tasks are then distributed to the corresponding mobile edge nodes according to the reordered task cache queues.

[0004] Therefore, the above technical solution has the following problems: it does not take into account the dynamic adjustment of the granularity of parallel splitting based on the actual waiting delay during operation, lacks a smoothness feedback correction mechanism, and cannot increase the splitting intensity to distribute the waiting burden when the scheduling delay exceeds expectations, thus affecting the task processing efficiency. Summary of the Invention

[0005] To address this, the present invention provides a network-aware real-time task allocation method for industrial control motherboards, which overcomes the problems in the prior art that do not consider dynamically adjusting the granularity of parallel splitting based on the actual waiting delay during operation, lack a smoothness feedback correction mechanism, and cannot increase the splitting intensity to distribute the waiting burden when the scheduling delay exceeds expectations, thus affecting the task processing efficiency.

[0006] To achieve the above objectives, the present invention provides a network-aware real-time task allocation method for industrial control motherboards, comprising: Identify risky operational time points based on network latency and packet loss rate; The original code file is split into several subtasks that are executed in parallel. Based on the task bias label of each processing unit, the task type label of each parallel execution subtask, and the estimated processing time of each parallel execution subtask, each parallel execution subtask and each processing unit are matched to run each parallel execution subtask. The processing interference intensity is determined based on the estimated processing time of each parallel execution subtask of the original code file. The stable output characteristics of a single original code file are determined based on the processing interference intensity in order to determine whether to correct the minimum waiting tolerance of each alternative processing unit. The processing smoothness characteristics are determined based on the amount of waiting delay, in order to determine whether to correct the split strength for the original code file; Task matching characteristics are determined based on the general execution deviation to determine whether to correct the operating rate difference standard of adjacent processing units.

[0007] Furthermore, the process of determining the stable output characteristics of a single original code file based on the processing interference intensity includes determining that a single original code file has weakly stable output characteristics when the processing interference intensity is greater than the preset processing interference intensity, and determining the minimum waiting tolerance for correcting each alternative processing unit.

[0008] Furthermore, the minimum waiting tolerance of each candidate processing unit is corrected, wherein the increase in the minimum waiting tolerance is positively correlated with the processing interference intensity.

[0009] Furthermore, the waiting delay is determined based on the actual waiting time of each alternative processing unit.

[0010] Furthermore, the process of determining the smoothness feature based on the waiting delay includes determining the weak smoothness feature when the waiting delay is greater than the preset waiting delay, and correcting the splitting intensity of the original code file.

[0011] Furthermore, the splitting strength of the original code file is adjusted, where the increase in splitting strength is positively correlated with the amount of waiting delay.

[0012] Furthermore, the general execution deviation is determined based on the waiting delay of each original code file.

[0013] Furthermore, the process of determining task matching features based on the general execution deviation includes determining each original code file as an abnormal task matching feature when the general execution deviation is greater than the preset general execution deviation, and correcting the running rate difference standard of adjacent processing units.

[0014] Furthermore, the operating rate difference standard of adjacent processing units is corrected based on the general execution deviation, wherein the increase in the operating rate difference standard is positively correlated with the general execution deviation.

[0015] Furthermore, the processing interference intensity is the variance of the estimated processing time of each parallel subtask in the original code file.

[0016] Compared with existing technologies, the beneficial effect of this invention lies in quantifying the degree of time dispersion within the code by calculating the interference intensity. When the interference intensity is high, the minimum waiting tolerance of the alternative processing units is adaptively increased, thereby alleviating scheduling conflicts caused by time mismatch between subtasks, making task allocation more in line with actual execution fluctuations, and improving task operation stability.

[0017] Furthermore, by monitoring the actual waiting delay to quantify the smoothness of processing, when the smoothness decreases, the code splitting intensity is dynamically increased, and the task is refined into more parallel subtasks, thereby improving scheduling flexibility and resource utilization, effectively alleviating queue congestion, and further improving task running efficiency.

[0018] Furthermore, by analyzing the overall execution deviation of multiple code files, a general execution deviation is obtained to evaluate the quality of global task matching. When the deviation exceeds the standard, the standard for the difference in running speed between adjacent processing units is increased, forcing the selection of processing units with a sufficiently large speed difference for pairing. This reduces pipeline stalls and improves the consistency of allocation and system throughput in a multi-tasking environment. Selecting processing units with a sufficiently large speed difference for pairing reduces the lag and queuing of pre-processing output results between adjacent processing stages. When the post-processing unit has sufficient processing capacity margin, even if the pre-processing output results arrive in a concentrated manner or the actual execution time fluctuates, the post-processing unit can quickly process the corresponding task, reducing the probability of waiting and blocking, and effectively improving the system throughput. Attached Figure Description

[0019] Figure 1 This is a block diagram of a network-aware real-time task allocation system for an industrial control motherboard, according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating the steps of a network-aware real-time task allocation method for an industrial control motherboard according to an embodiment of the present invention. Figure 3 This is a logic decision diagram for determining the stable output characteristics of a single original code file based on the processing interference intensity in an embodiment of the present invention; Figure 4 This is a logic decision diagram for determining the smoothness feature of processing based on the waiting delay amount in an embodiment of the present invention; Detailed Implementation To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0020] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0021] It should be noted that in the description of this invention, the terms "upper", "lower", "left", "right", "inner", "outer", etc., which indicate the direction or positional relationship, are based on the direction or positional relationship shown in the drawings. This is only for the convenience of description and is not intended to indicate or imply that the device or element must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of this invention.

[0022] Furthermore, it should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0023] Please see Figure 1 As shown, it is a module block diagram of a network-aware real-time task allocation system for an industrial control motherboard according to an embodiment of the present invention. The system of the present invention includes: The network sensing module is used to determine the jitter value based on the standard deviation of network delay in each detection period, and to identify risky operation time nodes based on the jitter value; after identifying the risky operation time node, the network sensing module controls the operation of the original code file quantization module. The code preprocessing module includes a code splitting unit for splitting the original code file into several parallel execution subtasks, and a subtask feature labeling unit for labeling each parallel execution subtask with a task type label; wherein each parallel execution subtask is logically relatively independent. The code execution module is connected to the code preprocessing unit and includes several processing units for handling parallel execution subtasks. Each processing unit is labeled with a task bias label. The task matching module, which is connected to the code preprocessing module and the code preprocessing unit respectively, is used to match each parallel execution subtask and each processing unit based on the task type label and the estimated processing time of each parallel execution subtask. The original code file quantization module is connected to the code preprocessing module, the code preprocessing unit and the task matching module respectively. It is used to determine the processing interference intensity based on the estimated processing time of each parallel execution subtask of the original code file, and to determine the stable output characteristics of a single original code file based on the processing interference intensity, so as to determine whether to correct the minimum waiting tolerance of each alternative processing unit. A smoothness verification module, connected to the network awareness module, code preprocessing module, code preprocessing unit, task matching module, and raw code file quantization module, determines processing smoothness characteristics based on waiting latency to determine whether to adjust the splitting intensity of the raw code file. Splitting intensity is the number of subtasks into which the raw code file is split for parallel execution. Splitting intensity reflects the degree of parallelization in the raw code file. High splitting intensity means splitting the raw file into more and smaller subtasks, facilitating more flexible allocation to multiple processing units for parallel execution. In a single embodiment, the splitting intensity can be adjusted by regulating the target parallelism parameter, specifying the desired number of parallel execution subtasks, and then adjusting the code analyzer's splitting strategy inversely based on the desired number of parallel execution subtasks to achieve the target splitting intensity adjustment.

[0024] The causal analysis module is connected to the network perception module, the code preprocessing module, the code preprocessing unit, the task matching module, the original code file quantization module, and the fluency verification module, respectively. It is used to determine the task matching characteristics based on the general execution deviation, so as to determine whether to correct the running rate difference standard of adjacent processing units.

[0025] In a single embodiment, the network sensing module is used to determine the standard deviation of network latency for each detection period as the network jitter value. When the network jitter value exceeds a risk threshold, the current time point is identified as a risky running time point. The risk threshold can be determined using the historical baseline method, which involves statistically analyzing the distribution of network jitter values ​​for each time period in historical data and calculating the 95th percentile as a baseline value to obtain the risk threshold. By identifying network risk nodes in advance, blindly initiating task allocation in unstable network environments is avoided, thus improving the overall anti-interference capability of the system.

[0026] In a single embodiment, code can be divided into independent subtasks through program analysis, which is existing technology and will not be elaborated further. The subtask feature labeling unit can label task types based on computational features, including access-intensive tasks that frequently read and write databases, nested-intensive tasks with multiple nested loops, and recursion-intensive tasks with frequent creation and destruction of function stacks.

[0027] In this embodiment, task bias labels include access-dense bias labels, nested-dense bias labels, and recursive-dense bias labels.

[0028] In a single embodiment, each processing unit corresponding to an access-intensive bias label is configured with a large-capacity cache and high-bandwidth memory architecture to reduce access latency; each processing unit corresponding to a nested-intensive bias label is configured with a CPU supporting the AVX-512 instruction set to maintain a high speedup ratio for nested rule loops; and each processing unit corresponding to a recursive-intensive bias label is configured with a RISC architecture to ensure efficient function calls.

[0029] In this embodiment, the estimated processing time of each parallel execution subtask is determined using machine learning prediction. Based on the determined total estimated processing time of each preceding task for a single parallel execution subtask, candidate processing units are determined. These candidate processing units are those that are idle after the total estimated processing time and whose labels correspond to them. The running rate of the preceding processing units is higher than that of the following processing units. For the processing of a single original code file, the processing unit processed first is considered a preceding processing unit relative to the processing unit processed later. The running rate of each processing unit is the rate at which a single processing unit processes standard code.

[0030] In this embodiment, the alternative processing unit remains idle for an estimated idle waiting period to wait for the output results of the preceding processing tasks and runs the corresponding parallel execution subtasks. The estimated idle waiting period includes the corresponding estimated processing time of the processing unit and the minimum waiting tolerance extended forward and backward based on the estimated start time. The estimated start time is determined based on the estimated processing time of each preceding task.

[0031] Please see Figure 2 The diagram shown is a flowchart illustrating the steps of a network-aware real-time task allocation method for an industrial control motherboard according to an embodiment of the present invention. The method of the present invention includes: S1, identify risky runtime nodes based on network latency and packet loss rate; S2 splits the original code file into several parallel execution subtasks; S3, based on the task bias label of each processing unit, the task type label of each parallel execution subtask, and the estimated processing time of each parallel execution subtask, match each parallel execution subtask with each processing unit to run each parallel execution subtask. S4. Based on the estimated processing time of each parallel execution subtask of the original code file, determine the processing interference intensity. Based on the processing interference intensity, determine the stable output characteristics of a single original code file to determine whether to correct the minimum waiting tolerance of each alternative processing unit. S5 determines the smoothness characteristics of the processing based on the amount of waiting delay, in order to determine whether to correct the split strength of the original code file. S6, determine the task matching characteristics based on the general execution deviation to determine whether to correct the running rate difference standard of adjacent processing units.

[0032] Specifically, the original code file quantization module includes: The code quantization subunit is used to determine the variance of the estimated processing time of each parallel execution subtask of the original code file as the processing interference strength. The processing interference strength is used to characterize the execution reliability of each parallel execution subtask of a single original code file. The greater the processing interference strength, the more significant the difference in the estimated execution time of each subtask after the original code file is split, the lower the time coupling between subtasks, the higher the probability of the time of the later subtask waiting for the completion of the earlier subtask in actual operation, and the lower the overall execution reliability.

[0033] Please see Figure 3 As shown, this is a logic decision diagram for determining the stable output characteristics of a single original code file based on the processing interference intensity in an embodiment of the present invention. The original code file quantization module further includes: The output feature quantization subunit is used to determine a single original code file as a weakly stable output feature when the processing interference intensity is greater than the preset processing interference intensity, and to determine the minimum waiting tolerance for each alternative processing unit; when the processing interference intensity is less than or equal to the preset processing interference intensity, it determines a single original code file as a strongly stable output feature, and determines that each alternative processing unit continues to run using the current operating parameters.

[0034] In a single embodiment, the preset interference intensity can be determined by simulation experiments, recording the interference intensity value when obvious waiting congestion begins to appear, analyzing each calibration, and taking the average value of the obtained interference intensity values ​​when obvious waiting congestion appears.

[0035] Specifically, the original code file quantization module further includes: The processing control subunit is used to correct the minimum waiting tolerance of each candidate processing unit for a single original code file based on the processing interference intensity. The increase in the minimum waiting tolerance is positively correlated with the processing interference intensity. The greater the processing interference intensity, the more drastic the execution time fluctuation of each subtask, and the higher the risk of subsequent tasks being affected by the delay of the preceding tasks. The greater the minimum waiting tolerance, the longer the buffer waiting window reserved for each processing unit. The minimum waiting tolerance is used to absorb time fluctuations and reduce the probability of matching failure due to instantaneous delay.

[0036] In this embodiment, the time dispersion within the code is quantified by calculating the interference intensity. When the interference intensity is high, the minimum waiting tolerance of the alternative processing units is adaptively increased, thereby alleviating scheduling conflicts caused by time mismatch between subtasks, making task allocation more in line with actual execution fluctuations, and improving task operation stability.

[0037] Specifically, the fluency verification module includes: The single-sided execution quantization subunit is used to determine the waiting delay based on the actual waiting time of each candidate processing unit. The waiting delay characterizes the smoothness of processing of each parallel execution subtask. The larger the waiting delay, the more significant the delay between the actual start time of the task and the estimated start time, and the more significant the situation where the processing unit is forced to idle its local queue due to the output delay of the preceding task, resulting in congestion.

[0038] In a single embodiment, the waiting delay is the average of the actual waiting times of each candidate processing unit corresponding to a single source code file. The actual waiting time is the time interval between the estimated start time and the actual execution time of the corresponding parallel subtask. The actual waiting time characterizes the waiting time from the scheduled execution time to the actual start of task execution, reflecting the processing unit's responsiveness.

[0039] Please see Figure 4 As shown, this is a logic decision diagram for determining the smoothness characteristics of processing based on the waiting delay amount in an embodiment of the present invention. The smoothness verification module of the present invention includes: The one-sided smooth quantization subunit is used to determine weak processing smoothness characteristics and correct the splitting intensity of the original code file when the waiting delay is greater than the preset waiting delay; and to determine strong processing smoothness characteristics when the waiting delay is less than or equal to the preset waiting delay, and to control the code preprocessing module to continue running with the current running parameters.

[0040] In a single embodiment, the preset waiting delay can be set according to the maximum scheduling delay allowed in the system service level agreement.

[0041] Specifically, the fluency verification module includes: The code preprocessing control subunit is used to adjust the splitting intensity of the original code file. The increase in splitting intensity is positively correlated with the amount of waiting latency. The greater the waiting latency, the less parallelism at the current splitting granularity is able to absorb scheduling delays. A greater splitting intensity means dividing the original code into more and finer subtasks, which can increase the opportunities for parallel distribution and reduce the waiting pressure on individual subtasks. Therefore, the higher the latency, the greater the need to increase the splitting intensity to distribute the waiting burden.

[0042] In this embodiment, the smoothness of processing is quantified by monitoring the actual waiting delay. When the smoothness decreases, the code splitting intensity is dynamically increased, and the task is refined into more parallel subtasks, thereby improving scheduling flexibility and resource utilization, effectively alleviating queue congestion, and further improving task running efficiency.

[0043] Specifically, the causal analysis module includes: The batch analysis subunit determines the general execution deviation based on the average wait latency of each original code file. The general execution deviation determines the general situation of each processing unit handling each parallel execution subtask. The larger the general execution deviation, the more systematically the actual subtask execution time deviates from the estimated time during the processing of multiple code files, indicating an anomaly in the performance balancing strategy among processing units.

[0044] Specifically, the causal analysis module further includes: The matching quantization subunit is used to determine that each current source code file is an abnormal task matching feature when the general execution deviation is greater than the preset general execution deviation, and to determine the standard for correcting the running rate difference of adjacent processing units; when the general execution deviation is less than or equal to the preset general execution deviation, it determines that each current source code file is a stable task matching feature, and controls each processing unit to continue to run using the current running parameters.

[0045] In a single embodiment, the preset general execution deviation can be determined by the standard deviation of the mean waiting delay of each code file when the system is running normally in offline testing.

[0046] Specifically, the causal analysis module further includes: The matching standard correction subunit is used to correct the operating rate difference standard of adjacent processing units based on the general execution deviation amount. The increase in the operating rate difference standard is positively correlated with the general execution deviation amount.

[0047] A larger general execution deviation indicates a more significant overall deviation between the actual execution process of each original code file and the estimated execution process, and a more unstable connection in processing capabilities between adjacent processing units. A larger execution rate difference standard indicates a more sufficient processing capacity margin for subsequent processing units relative to preceding processing units, and a more matched ability to receive and process the task results output by preceding processing units. Increasing the execution rate difference standard raises the matching threshold for adjacent processing units.

[0048] Adjacent processing units are adjacent processing units during the sequential processing of individual source code files.

[0049] The operating rate difference standard is the minimum difference threshold between the operating rate of the preprocessing unit and the operating rate of the postprocessing unit.

[0050] In this embodiment, the overall execution deviation of multiple code files is analyzed to obtain the general execution deviation amount, and the global task matching quality is evaluated. When the deviation exceeds the standard, the running rate difference standard between adjacent processing units is increased, forcing the selection of processing units with a sufficiently large rate difference for pairing, thereby reducing pipeline stalls and improving the consistency of allocation and system throughput in a multi-tasking environment. Selecting processing units with a sufficiently large rate difference for pairing reduces the lag and queuing of pre-processing output results between adjacent processing stages. When the post-processing unit has sufficient processing capacity margin, even if the pre-processing output results arrive in a concentrated manner or the actual execution time fluctuates, the post-processing unit can quickly process the corresponding task, reducing the probability of waiting and blocking, and effectively improving the system throughput.

[0051] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0052] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A network-aware real-time task allocation method for industrial control motherboards, characterized in that, include: Identify risky operational time points based on network latency and packet loss rate; The original code file is split into several subtasks that are executed in parallel. Based on the task bias label of each processing unit, the task type label of each parallel execution subtask, and the estimated processing time of each parallel execution subtask, each parallel execution subtask and each processing unit are matched to run each parallel execution subtask. The processing interference intensity is determined based on the estimated processing time of each parallel execution subtask of the original code file. The stable output characteristics of a single original code file are determined based on the processing interference intensity in order to determine whether to correct the minimum waiting tolerance of each alternative processing unit. The processing smoothness characteristics are determined based on the waiting delay amount to determine whether to correct the splitting intensity of the original code file. The waiting delay amount is determined based on the actual waiting time of each alternative processing unit. The task matching characteristics are determined based on the general execution deviation, in order to determine whether to correct the difference in the running rate of adjacent processing units. The general execution deviation is determined based on the waiting delay of each original code file.

2. The network-aware real-time task allocation method for industrial control motherboards according to claim 1, characterized in that, The process of determining the stable output characteristics of a single original code file based on the processing interference intensity includes determining that a single original code file has weakly stable output characteristics when the processing interference intensity is greater than the preset processing interference intensity, and determining the minimum waiting tolerance for correcting each alternative processing unit.

3. The network-aware real-time task allocation method for industrial control motherboards according to claim 2, characterized in that, The minimum waiting tolerance of each candidate processing unit is corrected, and the increase in the minimum waiting tolerance is positively correlated with the processing interference intensity.

4. The network-aware real-time task allocation method for industrial control motherboards according to claim 3, characterized in that, The process of determining the smoothness characteristics of processing based on the amount of waiting delay includes determining weak smoothness characteristics and adjusting the splitting intensity of the original code file when the amount of waiting delay is greater than the preset amount of waiting delay.

5. The network-aware real-time task allocation method for industrial control motherboards according to claim 4, characterized in that, The splitting strength of the original code file is adjusted, where the increase in splitting strength is positively correlated with the amount of waiting delay.

6. The network-aware real-time task allocation method for industrial control motherboards according to claim 5, characterized in that, The process of determining task matching features based on the general execution deviation includes determining that each original code file is an abnormal task matching feature when the general execution deviation is greater than the preset general execution deviation, and correcting the difference in running speed between adjacent processing units.

7. The network-aware real-time task allocation method for industrial control motherboards according to claim 6, characterized in that, The operating rate difference standard of adjacent processing units is corrected based on the general execution deviation, wherein the increase in the operating rate difference standard is positively correlated with the general execution deviation.

8. The network-aware real-time task allocation method for industrial control motherboards according to claim 7, characterized in that, The interference intensity is the variance of the estimated processing time of each parallel subtask in the original code file.

Images