Task load balancing and scheduling method and system for internet of things edge computing nodes

Abstract

This invention discloses a task load balancing scheduling method and system for IoT edge computing nodes. The method collects node operating status and task demand characteristics, calculates initial adaptability scores and generates priority scheduling weights, and constructs a task allocation sequence. During task execution, migration is implemented to achieve initial load balancing. Path optimization and real-time feedback are combined to update scheduling weights and balancing strategies, forming adaptive scheduling rules. Historical operating records are integrated to assess interruption risks and generate a task-node mapping sequence. Node capacity is corrected through resource overflow stress testing. Finally, considering environmental fluctuations and task dependency topology, the optimal task allocation result is determined. This invention effectively improves the load balancing, scheduling robustness, and resource utilization efficiency of edge computing systems.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and specifically to a task load balancing scheduling method and system for IoT edge computing nodes. Background Technology

[0002] Currently, with the rapid development of IoT technology, massive numbers of terminal devices are continuously connecting to networks and are widely used in scenarios such as industrial control, intelligent transportation, and medical monitoring. To reduce data transmission latency and alleviate cloud pressure, edge computing is gradually becoming an important component of the IoT system. By deploying processor chips with certain computing capabilities at edge nodes close to the data source, data analysis and task processing can be completed locally, thereby improving the system's real-time performance and overall operating efficiency. However, edge nodes are usually limited by resources such as computing power, storage, and energy consumption. How to achieve efficient task allocation under limited resources has become a key technical problem in edge computing applications.

[0003] In one existing technology, a fixed-rule task allocation method is used to schedule tasks for edge nodes. This method allocates tasks based on preset node capability parameters. However, in practical applications, the state of nodes in the edge network changes continuously with time, load, or external interference. For example, in intelligent transportation systems, intersection edge devices need to process vehicle data in real time to optimize traffic light control. However, due to differences in device performance and dynamic load changes, uneven resource allocation can easily occur, leading to some nodes being overloaded while others are idle, thereby reducing the overall system operating efficiency.

[0004] Existing technologies suffer from the inability to flexibly adjust task allocation strategies based on the real-time status of nodes, resulting in low system resource utilization. Summary of the Invention

[0005] This invention provides a task load balancing scheduling method and system for IoT edge computing nodes to solve the problems of poor task execution stability and low system resource utilization in the prior art.

[0006] Firstly, to address the aforementioned technical problems, this invention provides a task load balancing scheduling method for IoT edge computing nodes, comprising:

[0007] Collect the running status of edge nodes, extract the task requirement features of the task to be processed, and calculate the node adaptability of each node to the task requirement features based on the running status and the task requirement features.

[0008] Based on the node adaptability and combined with the task execution constraints extracted from the task requirement features, the priority scheduling weight of each task is calculated, the task queue is sorted, and a task allocation sequence is generated.

[0009] Tasks are issued according to the task allocation sequence, and during task execution, tasks are migrated according to the node load status to obtain a preliminary balanced load distribution.

[0010] Path optimization is performed based on the load distribution status, and environmental deviations are captured using a real-time feedback mechanism. The priority scheduling weights and load balancing strategies are updated based on the environmental deviations to generate adaptive scheduling rules.

[0011] The adaptive scheduling rule is applied and combined with the historical running records of candidate nodes to assess the probability of execution interruption. Based on the interruption risk probability, tasks and nodes are matched to generate a mapping sequence for subsequent processing.

[0012] Perform resource stress testing on the mapping sequence and identify overloaded tasks. Remap the overloaded tasks to neighboring nodes and update the allocation index to generate a risk correction sequence.

[0013] Based on real-time environmental parameters and the logical dependency topology between tasks, resource load compensation and node performance reassessment are performed on the risk correction sequence to determine the optimal task allocation result.

[0014] Secondly, the present invention provides a task load balancing scheduling system for Internet of Things (IoT) edge computing nodes, comprising:

[0015] The node adaptability evaluation module is used to collect the running status of edge nodes, extract the task requirement features of the task to be processed, and calculate the node adaptability of each node to the task requirement features based on the running status and the task requirement features.

[0016] The priority weight generation module is used to calculate the priority scheduling weight of each task based on the node adaptability and the task execution constraints extracted from the task requirement features, and to sort the task queue to generate a task allocation sequence.

[0017] The dynamic load migration module is used to issue tasks according to the task allocation sequence and migrate tasks according to the node load status during task execution to obtain a preliminary balanced load distribution.

[0018] An adaptive rule generation module is used to optimize the path for the load distribution state, capture environmental deviations using a real-time feedback mechanism, update the priority scheduling weights and load balancing strategies based on the environmental deviations, and generate adaptive scheduling rules.

[0019] The interruption risk assessment module is used to apply the adaptive scheduling rules and combine them with the historical running records of candidate nodes to assess the probability of execution interruption, match tasks and nodes according to the interruption risk probability, and generate a mapping sequence for subsequent processing.

[0020] The resource overflow stress testing module is used to perform resource stress testing on the mapping sequence and identify overloaded tasks, remap the overloaded tasks to neighboring nodes and update the allocation index, and generate a risk correction sequence.

[0021] The global allocation optimization module is used to perform resource load compensation and node performance reassessment on the risk correction sequence based on real-time environmental parameters and logical dependency topology between tasks, and to determine the optimal task allocation result.

[0022] Compared with the prior art, the present invention has the following advantages:

[0023] (1) This invention captures environmental deviations through a real-time feedback mechanism and dynamically updates task priority weights and load balancing strategies accordingly. Compared with traditional fixed-rule scheduling methods, this invention can sense real-time fluctuations such as network bandwidth jitter and node performance degradation in IoT edge networks, and automatically generate adaptive scheduling rules for parameter compensation, ensuring that the scheduling logic is always highly matched with the current physical environment, effectively avoiding scheduling failures caused by environmental interference.

[0024] (2) Before the formal allocation of tasks, this invention applies adaptive rules combined with the historical operation records of nodes to quantitatively assess the probability of execution interruption risk, and conducts resource overflow stress tests based on this. This dual guarantee mechanism of prediction + simulation verification can identify potential high-risk nodes and resource overload risks in advance, and realize the proactive remapping of tasks through risk correction sequences, thereby reducing the probability of task crashes and node downtime from the source and solving the stability problem caused by uneven resource allocation in edge computing.

[0025] (3) In the final decision-making stage, this invention not only focuses on the computing power of a single node, but also deeply analyzes the logical dependency topology between tasks. By coupling real-time environmental parameters with the topology structure and dynamically updating node scores and resource requirements, this invention can accurately balance the local processing efficiency of computing tasks with the communication overhead between nodes. This globally optimal allocation strategy eliminates execution bottlenecks caused by task chain dependencies, realizes fine-grained scheduling of computing power and bandwidth resources in edge network environments, and significantly improves the overall system operating efficiency. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the task load balancing scheduling method for IoT edge computing nodes provided in the first embodiment of the present invention.

[0027] Figure 2 This is a schematic diagram of the structure of a task load balancing scheduling system for IoT edge computing nodes provided in the second embodiment of the present invention. Detailed Implementation

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

[0029] Reference Figure 1 The first embodiment of the present invention provides a task load balancing scheduling method for IoT edge computing nodes, including steps S11 to S17:

[0030] S11, collect the running status of edge nodes, extract the task requirement features of the task to be processed, and calculate the node adaptability of each node to the task requirement features based on the running status and the task requirement features.

[0031] S12, based on the node adaptability and combined with the task execution constraints extracted from the task requirement features, calculate the priority scheduling weight of each task, sort the task queue, and generate a task allocation sequence.

[0032] S13, tasks are issued according to the task allocation sequence, and during task execution, task migration is performed according to the node load status to obtain a preliminary balanced load distribution status.

[0033] S14, perform path optimization based on the load distribution status, capture environmental deviations using a real-time feedback mechanism, update the priority scheduling weights and load balancing strategies based on the environmental deviations, and generate adaptive scheduling rules.

[0034] S15, apply the adaptive scheduling rules and combine them with the historical running records of candidate nodes to evaluate the execution interruption risk probability, match tasks and nodes according to the interruption risk probability, and generate a mapping sequence for subsequent processing;

[0035] S16, Perform resource stress testing on the mapping sequence and identify overloaded tasks, remap the overloaded tasks to neighboring nodes and update the allocation index to generate a risk correction sequence;

[0036] S17. Based on real-time environmental parameters and the logical dependency topology between tasks, resource load compensation and node performance re-evaluation are performed on the risk correction sequence to determine the optimal task allocation result.

[0037] In step S11, the running status of edge nodes is collected, the task requirement features of the task to be processed are extracted, and based on the running status and the task requirement features, the node adaptability of each node to the task requirement features is calculated, including:

[0038] Collect real-time data streams from edge nodes and perform multi-dimensional parameter analysis to extract feature components including calculation frequency, transmission delay, and memory usage.

[0039] Collect real-time data streams from edge nodes and perform multi-dimensional parameter analysis to extract feature components including calculation frequency, transmission delay, and memory usage.

[0040] Each of the aforementioned feature components is normalized and used as row vectors to construct a running state matrix reflecting the real-time availability of the node;

[0041] Parse the task metadata of the task to be processed and extract the time constraint parameters and computing power requirement parameters. Calculate the urgency quantification coefficient based on the time constraint parameters and construct a resource feature vector reflecting the task requirements by combining the computing power requirement parameters.

[0042] The resource feature vector and the running state matrix are weighted and mapped to obtain the matching degree evaluation value of each candidate node, and the matching degree evaluation value is determined as the node fitness.

[0043] Specifically, a data acquisition module is deployed for each edge node to obtain real-time operational data by calling the system monitoring interface of the node's operating system. Three core feature components are extracted: the calculation frequency value reflects the node's current processing capability, obtained by reading the actual CPU operating frequency, in GHz; the transmission latency value reflects the communication efficiency between the node and the task data source, obtained by sending probe data packets to the target node and calculating the round-trip time, in milliseconds; and the memory utilization value reflects the availability of the node's storage resources, calculated as a percentage of the ratio of used memory to total memory.

[0044] The extracted feature components are normalized using a min-max normalization method to map feature values ​​of different dimensions to the 0-1 range. The normalized features are then arranged into row vectors in order of computation frequency, transmission latency, and memory usage, with one row vector corresponding to each node. All node row vectors are stacked row by row to construct an M×3 dimensional operational state matrix (M being the total number of edge nodes). This matrix reflects the current availability status of each node in real time.

[0045] Parse the task metadata (usually stored in JSON or XML format) of the task to be processed, and extract the time constraint parameters and computing power requirement parameters. The time constraint parameters include the task submission time and deadline, the difference of which is the allowed execution time. The computing power requirement parameters include the required number of CPU cores, memory capacity, and estimated execution time.

[0046] An urgency quantification coefficient U is calculated based on time constraint parameters. This coefficient reflects the time urgency of the task. The calculation formula is as follows: , where Tr is the remaining time, i.e., the time difference between the current moment and the task deadline, and T is the allowed execution time. The function's value range is between 0 and 1, with the coefficient approaching 0 when the remaining time is sufficient and approaching 1 when the remaining time is extremely short. The normalized CPU core requirement, urgency metric, and memory capacity requirement are arranged column-wise to construct a 1×3 dimensional resource feature vector. This vector comprehensively reflects the task's demand characteristics for node resources and its time sensitivity.

[0047] The resource feature vector is weighted and mapped to the runtime state matrix. First, a feature weight vector is defined, comprising three components: computation frequency weight, transmission latency weight, and memory utilization weight. These weights are dynamically adjusted based on the task type. For example, for computationally intensive tasks, the feature weight vector can be set to [0.5, 0.2, 0.3], representing a 50% weight for computation frequency, 20% for transmission latency, and 30% for memory utilization.

[0048] Each row of the running state matrix is ​​element-wise multiplied with the resource feature vector to obtain an M×3 intermediate matrix. The intermediate matrix is ​​then weighted and summed for each row according to its feature weight vector. This is done by multiplying each of the three elements in each row by its corresponding feature weight and then summing the sums. A higher matching score indicates that the node is more suitable for executing the current task. The calculated matching score is used as the node fit score for each candidate node; this score is a value between 0 and 1 and is used for subsequent node selection and task allocation decisions.

[0049] In step S12, based on the node adaptability and the task execution constraints extracted from the task requirement features, the priority scheduling weight of each task is calculated, and the task queue is sorted to generate a task allocation sequence, including:

[0050] Obtain the queue of tasks to be scheduled, parse the preconditions and postconditions between tasks, and construct a directed acyclic graph that maps the logical links between tasks as a dependency topology graph.

[0051] Traverse the task nodes in the dependency topology graph, estimate the execution time of each task based on historical execution records, and perform a weighted fusion calculation between the task execution time and the node adaptability to obtain the priority scheduling weight.

[0052] Based on the priority scheduling weight, tasks at the same in-degree level in the dependency topology graph are sorted in descending order to generate a sorted index containing hierarchical constraint information;

[0053] The storage structure of the task queue is reorganized according to the sorting index, and the execution path of the dependency topology is dynamically adjusted when a blockage is detected. The adjusted task queue is then used as the task allocation sequence.

[0054] Specifically, the task queue to be scheduled is obtained from the task scheduling system. Each task carries a task description file containing information such as task identifier, input data dependencies, output data definitions, and a list of preceding tasks. The preceding and following constraints in the task description file are parsed. The preceding constraints indicate which tasks the current task must wait for to complete before it can execute, and the following constraints indicate which tasks the current task will provide input data to after it completes.

[0055] A directed acyclic graph (DAG) is constructed as the dependency topology graph. Nodes in the graph represent tasks, and directed edges represent dependencies. If task A is a prerequisite task for task B, a directed edge is created from node A to node B. After construction, the topological properties of the graph are checked to ensure there are no circular dependencies. If a cycle is detected, a dependency conflict error is reported. The dependency topology graph is stored using an adjacency list structure. Each node maintains a list of predecessor nodes, a list of successor nodes, and an in-degree value. A task with an in-degree of 0 indicates no prerequisite dependencies and can be scheduled immediately.

[0056] Traverse all task nodes in the dependency topology graph and estimate the execution time for each task. Query the task execution history database for historical tasks of the same or similar type as the current task, extract their actual execution time data, and calculate the estimated time by weighting the execution times of these historical tasks.

[0057] If a task type is encountered for the first time without any historical records, a parameterized estimation method based on the task type's standard configuration is used. The baseline execution time per standard unit of workload is extracted from the configuration library according to the task type. (e.g., the standard processing time for a single core to process 1GB of data), and then adjust based on the actual workload of the current task. The specific calculation formula is as follows: ,in The input data size for the current task (in GB). Standard data size (unit: GB), Unallocated computing resources (unit: number of CPU cores) Standard computing resource requirements (unit: number of CPU cores), As a data size impact factor, To calculate the resource impact factor.

[0058] The priority scheduling weight is obtained by weighted fusion calculation of task execution time and node adaptability. First, the task execution time is normalized, using reciprocal normalization to make the normalization value smaller for longer execution times. For example, for scenarios requiring fast response, a setting can be configured... =0.3、 =0.7; For scenarios that prioritize overall throughput, this can be set to... =0.6、 =0.4. A higher calculated priority scheduling weight value indicates a higher task priority.

[0059] Tasks in the dependency topology graph are sorted according to their priority scheduling weights. First, the dependency topology graph is hierarchically divided, and a topological sorting algorithm is used to assign tasks to different in-degree levels. Level 0 contains all tasks with an in-degree of 0, i.e., tasks with no prerequisites; Level 1 contains all tasks whose prerequisites are at Level 0; and so on, with tasks at Level k having prerequisites distributed from Level 0 to Level (k-1). Tasks at the same in-degree level are sorted in descending order of their priority scheduling weights, with tasks having higher weights listed first and receiving priority scheduling opportunities. A sorting index is generated, recording the sorting results for tasks within each level. The data structure is a two-dimensional list, where the first dimension represents the level number, and the second dimension is a list of task identifiers sorted by priority within that level.

[0060] The task queue's storage structure is reorganized based on the sorted index, transforming the original queue into a new queue organized hierarchically and by priority. Tasks are arranged sequentially according to their hierarchy, and within the same hierarchy, they are arranged from highest to lowest priority. During scheduling, the reorganized queue can be traversed sequentially, executing tasks layer by layer, with node resources allocated within each layer according to priority. To support dynamic adjustments, task status flags are maintained in the queue structure, including statuses such as waiting, ready, executing, completed, and blocked.

[0061] The system monitors task status in real time during task execution, detecting blocking conditions (task execution timeout, node failure leading to task failure, insufficient resources, etc.). Upon detecting blocking, a dynamic adjustment mechanism is triggered: if a task times out, the suitability score is recalculated based on the real-time node load status, and a node with higher suitability is selected for task migration; if a node fails, incomplete tasks on that node are marked as failed, the failed path is removed from the dependency topology graph, the scheduling weight of the affected tasks is recalculated, and they are reinserted into the appropriate level; if resources are insufficient, the scheduling order is adjusted based on task urgency and priority, postponing lower-priority tasks.

[0062] The execution path of the dependency topology graph is dynamically adjusted, the task node status flags are updated, the edge connectivity is modified, and the in-degree value of each node is recalculated. For tasks that need to be rescheduled, they are removed from the current level and reassigned to an appropriate level according to the new dependencies. After adjustment, the sorting index is regenerated, and the task queue storage structure is updated. The adjusted task queue is used as the task allocation sequence.

[0063] In step S13, tasks are issued according to the task allocation sequence, and during task execution, task migration is performed based on node load status to obtain a preliminary balanced load distribution state, including:

[0064] Execute the task allocation sequence, obtain the real-time load data of each node and compare it with the preset safety threshold, identify and extract the overload node identifier;

[0065] Based on the real-time remaining execution time of the task, low latency-sensitive tasks are selected from the current tasks corresponding to the overload node identifier as migration sub-items, and a set of tasks to be migrated containing task characteristics and resource quota requirements is constructed.

[0066] Scan candidate neighboring nodes that have network communication links with the overloaded node, evaluate the available remaining capacity of each neighboring node, and use a matching degree optimization algorithm to lock the final target node from the candidate neighboring nodes to take over the set of tasks to be migrated.

[0067] Send a task status suspension command and execute a state transition flow pointing to the final target node, synchronously update the task mapping relationship table of all network devices, and obtain a preliminary balanced load distribution status.

[0068] Specifically, the task scheduling system distributes tasks layer by layer according to the task allocation sequence. Based on priority scheduling weights and node adaptability scores, it sends task description files and execution instructions to target nodes via message queues. Upon receiving the instructions, the node starts the task execution process, loading the necessary resources and data. Monitoring agent modules deployed on each edge node continuously collect real-time load data every 5 to 10 seconds, including four core indicators: CPU utilization, memory utilization, network bandwidth utilization, and disk I / O load.

[0069] Real-time load data is compared with preset safety thresholds. These thresholds are set based on node hardware specifications and the stability requirements of the edge computing scenario, comprehensively considering both system responsiveness and burst load buffering. The CPU utilization threshold is set at 85%, reserving 15% of the computational margin for handling sudden task requests and system scheduling overhead, preventing task queuing delays due to CPU saturation. The memory utilization threshold is set at 80%, reserving 20% ​​of memory space to prevent memory overflow and frequent page swapping, ensuring fast access to task data. The network bandwidth utilization threshold is set at 75%, reserving 25% of bandwidth to handle data transmission peaks and state synchronization traffic during task migration, reducing the risk of network congestion. The disk I / O load threshold is set at 70%, maintaining a 30% I / O margin to avoid disk read / write bottlenecks and prevent log recording, checkpoint saving, and other operations from affecting task execution performance. These thresholds have been verified through load testing in a real production environment, maximizing resource utilization efficiency while ensuring stable system operation. If any node indicator exceeds a threshold, it is considered overloaded. To avoid misjudgments caused by occasional fluctuations, a sliding window mechanism is adopted. An overload state is only confirmed when a certain indicator exceeds a threshold for three consecutive data collection periods. Overload node identifiers are extracted and added to an overload node list, which is maintained in real-time to track information on all nodes currently in an overload state in the system.

[0070] Tasks running on overloaded nodes are filtered based on their real-time remaining execution time. A list of currently executing tasks is retrieved from the nodes corresponding to the overloaded node identifiers. The estimated total execution time and already executed time for each task are read, and the remaining execution time is calculated. The latency sensitivity of tasks is determined based on their remaining execution time. Tasks with longer remaining execution times are relatively less sensitive and suitable for migration because migration incurs time costs, including task state serialization, data transmission, and task recovery on the target node. A latency sensitivity threshold of 30 seconds is set. This threshold is determined based on the average time cost of task migration in an edge computing environment. Typical task migration includes three stages: state packaging (5-8 seconds), network transmission (10-15 seconds), and target node restart (8-12 seconds), with a total time consumption of approximately 25-35 seconds. Therefore, choosing 30 seconds as the criterion ensures that the migration benefits outweigh the costs. If a task's remaining execution time is greater than 30 seconds, it is considered a low-latency-sensitive task and can be included in the migration candidate range. All low-latency-sensitive tasks are selected as migration sub-items.

[0071] A set of tasks to be migrated is constructed, recording the task characteristics and resource quota requirements of each migration sub-item. Task characteristics include task type, task priority, percentage of progress completed, input data size, and output data size. Resource quota requirements include the number of CPU cores, memory capacity, network bandwidth requirements, and storage space requirements for task execution; these parameters are extracted from the task's resource configuration file. The set of tasks to be migrated uses a structured storage format, with each task corresponding to one record containing a task identifier, task characteristic fields, and resource requirement fields. To optimize migration performance, the set of tasks to be migrated is sorted in descending order of task priority, with higher-priority tasks scheduled for migration first, ensuring that critical tasks are not overloaded.

[0072] Scan for candidate neighboring nodes that have network communication links with the overloaded node. Query the list of neighboring nodes of the overloaded node from the network topology management module, and select nodes with network latency less than 20 milliseconds as candidate neighboring nodes. Evaluate the available remaining capacity of each neighboring node by subtracting the currently allocated amount from the total resources to calculate the remaining CPU, memory, network, and storage resources, and normalize them to the interval of 0 to 1. The normalization method is to divide the remaining amount by the total amount to obtain a normalized remaining capacity vector.

[0073] A matching degree optimization algorithm is used to select the final target node. The resource requirement vector of the task to be migrated is multiplied by the remaining capacity vector of the candidate node; the result reflects the node's carrying capacity. The calculation method involves normalizing the task's required resources and multiplying each term by the normalized value of the node's remaining resources, then summing the results to obtain a single task matching degree score. The matching degree scores of the task set across all nodes are accumulated to obtain the overall matching degree. The node with the highest overall matching degree is selected. If the scores are similar, network latency and load rate are compared, prioritizing the node with lower latency and lower load. The final target node is locked, and its identifier and task list are recorded.

[0074] A task status suspension command is sent to the overloaded node. The node stops task process scheduling, serializes the execution context, variable values, progress markers, and other runtime states to generate a state snapshot file, and locks the relevant data files. The execution state migration flow is as follows: First, the snapshot and data files are transferred to the target node using compression and incremental transmission techniques. Second, resources are allocated on the target node, dependent libraries are loaded, and a process sandbox is created to restore the execution environment. Finally, the state snapshot is deserialized, the task is restored to the suspension point, and the process is restarted to continue execution.

[0075] The task mapping table for all devices across the network is updated synchronously. This table records which node each task is currently assigned to for execution, and its structure includes fields such as task identifier, node identifier, task status, and last update timestamp. After task migration is complete, the node identifier field for the corresponding task in the task mapping table is modified to match the identifier of the final target node. Simultaneously, the task status is updated to "in execution," and the current timestamp is recorded. The updated mapping table entries are pushed to all scheduling nodes and edge nodes in the system via a message broadcast mechanism, ensuring consistent task location awareness across all devices. The update operation employs a transaction mechanism to guarantee the atomicity of the mapping table modifications and prevent inconsistencies in task mapping. After task migration, the system achieves a preliminary balanced load distribution.

[0076] In step S14, path optimization is performed based on the load distribution status, and environmental deviations are captured using a real-time feedback mechanism. The priority scheduling weights and load balancing strategy are updated based on these environmental deviations to generate adaptive scheduling rules, including:

[0077] Obtain multiple candidate task allocation paths under the load distribution state, and determine the estimated completion time of tasks on each path;

[0078] The estimated completion time is compared with the task response time limit requirement to determine the optimized allocation path that meets the time limit constraint, and the real-time execution deviation of the optimized allocation path during task execution is extracted.

[0079] The real-time execution deviation is input into a preset deviation analysis model to calculate the feedback correction coefficient characterizing the impact of environmental fluctuations.

[0080] If the feedback correction coefficient exceeds the preset fluctuation threshold, the dynamic time factor in the priority scheduling weight is calculated synchronously using the feedback correction coefficient, and the weight ratio of the node scoring function in the load balancing strategy is adjusted to jointly constitute the adaptive scheduling rule.

[0081] Specifically, starting from the initial balanced load distribution, multiple candidate task allocation paths are obtained for the tasks to be scheduled. For each task to be allocated, all available edge nodes are queried from the task mapping table, and faulty or overloaded nodes are excluded, with the remaining nodes serving as candidate target nodes. Each candidate target node corresponds to a task allocation path, which is defined as the data transmission link and task execution flow from the task scheduling center to the target node.

[0082] The system collects the real-time transmission latency and the length of the pending queue for each candidate path. Real-time transmission latency is obtained by sending probe packets to the target node and measuring the round-trip time, comprising network transmission latency and node response latency. The total transmission latency is obtained by adding these two parts together. The length of the pending queue is obtained by querying the target node's task queue management module. The queue length represents the total number of waiting and currently executing tasks; a longer queue indicates a heavier node load.

[0083] The estimated completion time for each candidate path is determined by comprehensively considering three factors: transmission latency, queuing time, and task execution time. Queuing time is estimated based on the queue length and the average execution time of tasks in the queue, with the average execution time obtained from historical node statistics. Task execution time uses the value estimated in step S12. These three factors are added together to obtain the estimated task completion time, generating a path evaluation list containing fields such as path identifier, target node identifier, transmission latency, queue length, and estimated completion time.

[0084] The estimated completion time of each candidate path is compared with the task's response time requirement. The response time requirement is extracted from the task metadata and represents the time the task must complete after submission. The estimated completion time is checked against the response time requirement; if it is, the path is marked as feasible; otherwise, it is excluded. The path with the shortest estimated completion time from the feasible paths is selected as the optimized allocation path. If multiple paths have similar completion times, transmission latency and remaining node resource capacity are compared, prioritizing the path with lower latency and more abundant resources.

[0085] During task execution, real-time execution deviations of the optimized allocation path are extracted, including execution time deviations and resource utilization deviations. Execution time deviation is the actual execution time minus the estimated execution time; a positive value indicates a timeout, and a negative value indicates early completion. Resource utilization deviation is the actual resource utilization minus the quota requirement; a positive value indicates exceeding expectations, and a negative value indicates underutilization. Deviation data from all completed or currently executing tasks are collected to generate a deviation sample set.

[0086] The real-time execution deviation is input into a preset deviation analysis model to calculate the feedback correction coefficient. The deviation analysis model uses a weighted moving average method, assigning higher weights to recent deviations (more recent samples have greater weights), and determining the weighting coefficients through exponential decay. The weighted average deviation value is divided by the maximum absolute value of historical deviations and normalized to the range of -1 to 1. The normalized value is the feedback correction coefficient; a positive value indicates that environmental deterioration has led to task delays or increased resource consumption, while a negative value indicates environmental improvement.

[0087] Determine if the feedback correction coefficient exceeds a preset fluctuation threshold. The fluctuation threshold is used to identify significant environmental changes and prevent overreaction to minor fluctuations that could lead to frequent policy fluctuations. The threshold is typically set between 0.15 and 0.25, meaning a policy update is triggered when the deviation reaches 15% to 25% of the expected value. If the absolute value of the feedback correction coefficient is greater than the fluctuation threshold, significant environmental fluctuations are considered, requiring policy adjustment; if it is less than or equal to the threshold, the current policy is maintained.

[0088] When the feedback correction coefficient exceeds the fluctuation threshold, it is used to update the dynamic time factor in the priority scheduling weights. The compensation method involves multiplying the dynamic time factor by a correction factor, where the correction factor equals 1 plus the feedback correction coefficient. When the feedback correction coefficient is positive, the correction factor is greater than 1, the dynamic time factor increases, and the task priority is increased to compensate for delay risks. When the feedback correction coefficient is negative, the correction factor is less than 1, the dynamic time factor decreases, and the task priority is appropriately reduced. The updated dynamic time factor is then re-substituted into the priority scheduling weight calculation formula to recalculate the priority weight values ​​for each task, and the task scheduling order is adjusted according to the new weight values.

[0089] The weighting of the node scoring function in the load balancing strategy is adjusted using a feedback correction coefficient. Specifically, the node scoring function Snode in the load balancing strategy comprehensively considers multiple dimensions such as node computing power, transmission latency, and remaining resource capacity. The normalized performance index values ​​of each dimension are weighted and summed, and the sum of all weighting coefficients is 1.

[0090] The weight adjustment strategy is determined based on the type of deviation. First, the main types of deviations reflected by the feedback correction coefficients are analyzed. For example, if execution time deviation is dominant (the absolute value of the execution time deviation is greater than the absolute value of the resource usage deviation), it is determined to be a latency issue, and the transmission delay dimension weight needs to be increased. And correspondingly reduce the weight of the computing power dimension. The weight adjustment Δw is calculated based on the absolute value of the feedback correction coefficient, and the formula is as follows: η is an adjustment coefficient (usually ranging from 0.05 to 0.15). For feedback correction coefficient, These are the original weight values ​​for the dimensions to be weighted. The weight adjustment range is typically controlled within 5% to 15% of the original weight values ​​to avoid drastic fluctuations that could negatively impact system stability. The adjusted weight vector needs to be re-normalized to ensure that the sum of all weights remains 1.

[0091] Generate adaptive scheduling rules with environment awareness. These rules include updated priority scheduling weights, the weight percentage of the node scoring function in the load balancing strategy, and a strategy configuration file with corresponding triggering conditions. The rules are stored in key-value pair format, including fields such as rule version number, generation timestamp, feedback correction coefficient, dynamic time factor correction value, weights of each dimension of the node scoring function in the load balancing strategy, and fluctuation threshold.

[0092] In step S15, the adaptive scheduling rule is applied and combined with the historical running records of candidate nodes to assess the probability of execution interruption. Based on the interruption risk probability, tasks and nodes are matched to generate a mapping sequence for subsequent processing, including:

[0093] The adaptive scheduling rule is applied to map the real-time running status data of each candidate node to the feature space, generating a node feature vector that reflects the current performance characteristics of the node;

[0094] Based on the feedback correction coefficient, the downtime frequency and network fluctuation value in the historical operation record are weighted and quantified to calculate the historical risk factor of each candidate node.

[0095] Using a preset risk determination function, the node feature vector is correlated and mapped with the historical risk evaluation factor to calculate the probability of execution interruption risk for each candidate node in the current task.

[0096] The priority scheduling weights are corrected using the execution interruption risk probability, and the candidate nodes are reordered based on their adaptability. The mapping sequence is then determined based on the sorting results.

[0097] Specifically, adaptive scheduling rules are applied to comprehensively evaluate each candidate node. Real-time operational status data is acquired, including multi-dimensional indicators such as CPU utilization, memory utilization, network bandwidth utilization, disk I / O load, number of processes, temperature sensor readings, and power supply voltage fluctuations. These raw indicator data are then mapped to a distribution space with a mean of 0 and a standard deviation of 1 using the Z-score standardization method, eliminating differences in units and numerical ranges between different indicators to obtain a standardized multi-dimensional indicator vector.

[0098] The standardized multidimensional index vector is used as the original feature representation of the node, containing complete information about the node's operating state. Principal Component Analysis (PCA) is used for dimensionality reduction, projecting the original multidimensional data onto the principal component directions with the largest variance through linear transformation. A covariance matrix is ​​constructed for the standardized index data of all candidate nodes, eigenvalues ​​and eigenvectors are calculated, and the eigenvalues ​​are sorted in descending order. The top K eigenvectors with a cumulative variance contribution rate of 85% or higher are selected to form the projection matrix. The standardized index vector of each node is left-multiplied by the projection matrix to obtain a K-dimensional state representation vector (usually 5 to 8 dimensions). This vector condenses the key information of the node's current performance characteristics and is stored in the node feature library as input for subsequent risk assessment.

[0099] Extract historical operation records for each candidate node within the risk period. The risk period is defined as a time window tracing back from the current moment, typically set to 7 to 30 days in the past, capturing both long-term stability characteristics and recent performance trends. Query the operation log database for all event records within the risk period, including node crashes, task execution failures, network connection interruptions, and resource exhaustion alarms. Analyze the crash frequency; higher crash frequencies indicate poorer node stability. Analyze network-related events, extract network latency fluctuation data, and calculate the network latency standard deviation to obtain the network fluctuation value; a larger standard deviation indicates more unstable network quality.

[0100] The historical records are weighted using the feedback correction coefficient from step S14. This coefficient reflects the current level of environmental volatility; when environmental volatility is significant, the impact of unstable factors in the historical records on current decisions should be amplified. The downtime frequency and network volatility value are multiplied by an environmental sensitivity coefficient (equal to 1 plus the absolute value of the feedback correction coefficient). The weighted normalized downtime frequency and normalized network volatility value are then summed to obtain the quantified historical risk factor for each candidate node. Maximum value normalization is used to obtain a historical risk factor between 0 and 1; a larger value indicates a more unstable historical operating record and a higher risk of future outages.

[0101] A pre-defined risk assessment function is used to map node feature vectors to historical risk factors, calculating the probability of execution interruption for each candidate node in relation to the current task. The risk assessment function is constructed based on a weighted comprehensive evaluation model, comprehensively considering the impact of node state characteristics and historical risk factors on task interruption. The model employs a non-linear mapping function, with inputs including the components x1, x2, ..., xn of the node's high-dimensional state representation vector. k and historical risk factors After weighted summation, the result is mapped to the 0-1 interval using the sigmoid function. (This is related to) the probability of execution interruption. Where w1, w2, ..., w kThese are the weighting coefficients for each component of the state feature. Here, 'b' represents the weighting coefficients of historical risk factors, and 'b' is the bias term. The weighting coefficients are determined through training with historical data. The system's task execution records from the past 3 to 6 months are collected, including node status features, historical risk factors, and label data indicating whether an interruption occurred (1 for interruption, 0 for normal operation), to construct a training sample set. Logistic regression or gradient descent is used to fit the training sample set. The optimal values ​​of each weighting coefficient are obtained through iterative optimization by minimizing the cross-entropy loss function between the predicted probability and the actual label. Specifically, all weights are initialized to random small values ​​(usually between 0.01 and 0.1), and a learning rate η (e.g., 0.01) is set. The predicted risk probability is calculated for each training sample. Calculate the loss The gradient ∇L is obtained by taking the partial derivative of the loss with respect to each weight, and the weights are then updated. Repeat the iterations until the loss converges or the maximum number of iterations (e.g., 1000) is reached. After training, the values ​​of each weight coefficient are obtained.

[0102] For each candidate node, its state representation vector and historical risk factors are substituted into the risk determination function to calculate the interruption risk probability (between 0 and 1) for that node executing the current task. Considering the impact of task characteristics on interruption risk, long-running tasks are more susceptible to node instability than short-running tasks, and computationally intensive tasks are more sensitive to CPU stability than I / O-intensive tasks. Based on the task type and estimated execution duration, the base probability is multiplied by a task sensitivity coefficient (between 0.8 and 1.2), with longer execution durations or higher stability requirements resulting in a larger sensitivity coefficient. The corrected probability is used as the final execution interruption risk probability.

[0103] Priority scheduling weights are adjusted using the probability of execution interruption risk. The adjusted weight is equal to the original weight multiplied by a risk discount factor (equal to 1 minus the probability of execution interruption risk). When the probability of interruption risk is high for a node, the priority weight of tasks on that node is reduced, causing the task to move to the back of the scheduling order. Resources are allocated to tasks with lower risk first, ensuring that the system balances execution reliability with efficient scheduling and reducing the rescheduling cost caused by task interruption.

[0104] Candidate nodes are re-ranked based on their suitability, taking into account factors such as initial suitability score, node rating in adaptive scheduling rules, historical risk factors, and execution interruption probability. Weighting coefficients are assigned to each dimension; for example, initial suitability is 0.35, node rating is 0.30, historical risk factor is 0.20, and interruption probability is 0.15. Historical risk factor and interruption probability are used as negative indicators, converted to positive indicators by subtracting their normalized values ​​from 1. The weighted sum of the normalized values ​​of each dimension yields a comprehensive suitability score, which is then sorted from highest to lowest to reflect the overall suitability of nodes for the current task.

[0105] The task-node mapping sequence is determined based on the sorting results. Following a greedy strategy, tasks are assigned the most suitable available node in descending order of priority. The highest priority task is retrieved from the corrected task priority queue, and the node with the highest overall suitability and currently available is selected from the candidate node sorting list to establish a mapping relationship, updating the node resource occupancy status. This process is repeated until the task queue is empty or all candidate node resources are exhausted. The generated task-node mapping sequence is stored as a list of key-value pairs, containing task identifiers and corresponding node identifiers. The order of the mapping sequence reflects the task execution order.

[0106] In step S16, resource stress testing is performed on the mapping sequence to identify overloaded tasks, the overloaded tasks are remapped to neighboring nodes and the allocation index is updated, and a risk correction sequence is generated, including:

[0107] The estimated resource consumption of each task in the mapping sequence is obtained, and a collision detection is performed with the physical load limit of the corresponding node to obtain the node load surplus.

[0108] If the node load surplus is negative, it is determined that there is a risk of resource overflow, the overloaded node is locked and the subset of pending tasks that triggered the overflow is extracted.

[0109] The subset of tasks to be processed is injected into the remaining available resource pool of neighboring nodes for allocation simulation, and the secondary adaptation degree value of each neighboring node after taking over the subset of tasks to be processed is calculated.

[0110] The nearest node with the highest secondary adaptation value is selected as the traffic splitting target. The subset of tasks to be processed is remapped to the traffic splitting target, and the global task allocation index is updated synchronously.

[0111] The mapping sequence is logically reorganized based on the updated global task allocation index to generate a risk correction execution sequence.

[0112] Specifically, the estimated resource consumption information for each task is extracted from the task-node mapping sequence, including four core resource dimensions: CPU core count, memory capacity, network bandwidth, and storage space. These values ​​are read from the task resource configuration file. For multiple tasks assigned to the same node in the mapping sequence, their estimated resource consumption is summed to obtain the expected total resource requirement for that node. All tasks mapped to node N in the mapping sequence are traversed, and their CPU requirements are summed to obtain the expected total CPU requirement. Similarly, the total requirements for memory, network bandwidth, and storage space are calculated. The expected total resource requirement reflects the resource load that each node needs to bear when executing according to the current mapping sequence.

[0113] Obtain the physical load limit for each candidate node. This limit defines the maximum resource capacity a node can provide while ensuring stable operation. The physical load limit is typically set to 80% to 90% of the node's hardware configuration, with a 10% to 20% reserve for handling sudden loads and system overhead. Query the physical load limit data from the node configuration management database. Perform collision detection between the expected total resource requirements of each node and the physical load limit, determining whether the expected demand in any of the four resource dimensions exceeds the physical limit. Calculate the node's load surplus by subtracting the expected total resource requirements from the physical load limit. Calculate the surplus for each of the four resource dimensions: CPU surplus, memory surplus, network bandwidth surplus, and storage space surplus. A positive surplus value indicates that the node has remaining capacity in that resource dimension and can handle more tasks; a negative surplus value indicates that the node's demand in that resource dimension exceeds supply, posing a risk of resource shortage. For each node, the minimum value among the surplus values ​​of the four resource dimensions is taken as the overall load surplus value of that node. If the overall load surplus value of a node is negative, it is determined that the node has a risk of resource overflow.

[0114] All nodes with negative overall load margins are identified as overloaded nodes and recorded in a list. All tasks assigned to overloaded nodes are extracted from the task-node mapping sequence to form a subset of tasks to be processed. This subset is sorted in descending order of priority scheduling weight, prioritizing low-priority tasks as migrating them has minimal impact on overall scheduling efficiency. Tasks are selected one by one from the sorted task list, and their resource usage is accumulated. Selection stops when the accumulated value reaches the absolute value of the node's load margin; the selected task set at this point represents the critical tasks triggering the overflow and needs to be reallocated to eliminate the resource overflow risk. If the total resource usage of all low-priority tasks is still insufficient to eliminate the overflow, medium-priority tasks are selected to ensure the overflow risk is completely resolved.

[0115] The simulation involves allocating a subset of tasks to be processed into the remaining available resource pools of neighboring nodes. A neighboring node is defined as one that is no more than two hops away from the overloaded node in the network topology and has a positive overall load surplus. The remaining resource capacity of each neighboring node is queried and equal to the physical load limit minus the resource occupancy of currently allocated tasks. A trial-and-error allocation strategy is adopted. Assuming all tasks in the subset to be processed are migrated to a neighboring node, the expected total resource requirement of that node after migration is calculated to determine if it exceeds the physical load limit. If it does not exceed the limit, the node can handle these tasks; otherwise, the task subset is split into smaller task groups to find neighboring node combinations that can handle some of the tasks.

[0116] The secondary fit of each neighboring node after it has taken on a subset of tasks is calculated, taking into account the node's remaining resource capacity, network distance to overloaded nodes, historical risk factors, and load balancing after taking on tasks. The four evaluation dimensions are normalized: remaining resource capacity is normalized by dividing the actual remaining amount by the physical load limit; network distance is normalized by the reciprocal; historical risk factors are the values ​​calculated in step S15; and load balancing is normalized by calculating the absolute value of the difference between the node's load rate and the system's average load rate after taking on tasks, using 1 minus the absolute value of the difference. The four normalized dimensions are then summed using weighted coefficients, which are set according to the following criteria. The remaining resource capacity weight is set to 0.4 because whether a node has sufficient resources to accommodate the tasks to be migrated is the primary constraint in task remapping scenarios. Resource sufficiency directly determines the feasibility of migration, hence it is given the highest weight. The network distance weight is set to 0.25 because proximity affects the data transmission overhead and subsequent coordination efficiency of task migration; the closer the distance, the lower the migration cost, making it a secondary consideration. The historical risk factor weight is set to 0.20, reflecting the stability and reliability of the nodes. The load balancing weight is set to 0.15 to ensure a more balanced overall load distribution in the system after migration, but it has a relatively low priority in resolving the current overflow problem. The weight allocation follows the principle of "resource priority, distance secondary, risk consideration, and balanced supplementation" to ensure that task remapping can both solve the resource overflow problem and optimize the overall system performance. The calculated secondary fit value is between 0 and 1, with a higher value indicating that the neighboring node is more suitable to handle the subset of tasks to be processed.

[0117] The secondary fitness scores of all neighboring nodes are sorted, and the node with the highest score is selected as the task distribution target. If the node with the highest fitness score cannot handle all the task subsets on its own, a group of nodes with the highest fitness scores is selected to form a task distribution target group. The task subsets are then distributed among these nodes according to their remaining resource capacity. The task subsets are removed from the original mapping of overloaded nodes, and a new mapping between these tasks and the task distribution target nodes is established. The node identifier field of the corresponding task in the task-node mapping table is updated. The global task allocation index is updated synchronously. This index maintains the current allocation status of all tasks in the system, including task identifier, node identifier, task status, allocation timestamp, and other information. The update operation is atomic through a database transaction mechanism to ensure the consistency of the mapping relationship.

[0118] The update notification is pushed to all relevant nodes, including the original overloaded nodes, the target nodes for task relocation, and the task scheduling center. Upon receiving the notification, the original overloaded nodes release the resource quota reserved for the tasks to be migrated, update their local task queues, and remove the migrated tasks. Upon receiving the notification, the target nodes reserve resource quotas for the newly assigned tasks, add the tasks to their local execution queues, and prepare the task execution environment. The task scheduling center updates its task monitoring dashboard to reflect the latest task allocation status, allowing operations personnel to monitor system scheduling in real time. After the update, the system recalculates the load margin for all nodes to verify that the resource overflow risk has been eliminated. If any nodes still have negative load margins, the relocation process is repeated until all nodes have non-negative load margins.

[0119] The task-node mapping sequence is logically reorganized based on the updated global task allocation index. The reorganization operation includes deleting the original mappings of migrated tasks, inserting new mappings for migrated tasks, and adjusting the order of tasks in the mapping sequence to reflect the latest scheduling priorities. The reorganized sequence is sorted according to the expected start time of tasks, with tasks of the same timestamp arranged in descending order of priority weight to ensure that higher-priority tasks receive priority execution opportunities. A consistency check is performed on the reorganized sequence to verify whether the dependencies of all tasks are satisfied, i.e., whether each task's predecessor task was scheduled before the current task. If dependency conflicts are found, the order of related tasks is adjusted to ensure that the topological order constraints of the dependency topology graph are satisfied.

[0120] A risk-corrected execution sequence is generated. This sequence represents the final task scheduling scheme after resource overflow risk elimination and logical reorganization. The risk-corrected execution sequence is stored in a structured data format, containing a sequence version number, generation timestamp, total number of tasks, total number of nodes, and a detailed task-node mapping list. Each record in the mapping list includes fields such as task identifier, node identifier, task priority, expected start time, expected end time, resource quota requirement, and spare node identifier. The sequence also includes resource allocation statistics, recording aggregated metrics such as load rate, load surplus, and number of tasks for each node, used for subsequent execution monitoring and performance analysis.

[0121] In step S17, based on real-time environmental parameters and the logical dependency topology between tasks, resource load compensation and node performance reassessment are performed on the risk correction sequence to determine the optimal task allocation result, including:

[0122] The logical dependency topology between tasks in the risk correction execution sequence is analyzed, the original communication payload of each dependency link is extracted, and the real-time environmental parameters of the current edge network are obtained synchronously.

[0123] The original communication load is compensated by combining the real-time environmental parameters to determine the dynamic resource requirements of each task under the current link state;

[0124] Based on the logical location of each task in the dependent topology, the dynamic resource requirements are mapped to each node, and a comprehensive performance matrix including the data transmission cost of the predecessor task is calculated.

[0125] Based on the comprehensive performance matrix, the risk correction execution sequence is locally fine-tuned using the topology constraint awareness algorithm to lock in the mapping relationship with the shortest total task execution time, thereby obtaining the optimal task allocation result.

[0126] Specifically, the dependency topology between tasks is analyzed from the risk correction execution sequence. The dependency topology, constructed as a directed acyclic graph in step S12, represents the data dependency between tasks. All dependency links are extracted, and the output data size of the source task is queried as the original communication payload. For multiple predecessor tasks, the communication payload is the sum of all predecessor output data. A sparse matrix of communication payloads is constructed, with rows and columns corresponding to tasks, and elements representing the data transmission volume between task pairs. Real-time environmental parameters of the edge network are synchronously acquired, including bandwidth volatility, packet loss rate, latency jitter rate, and link congestion. Bandwidth volatility is calculated using a sliding window to determine the ratio of the standard deviation to the mean of bandwidth over the most recent 10 sampling periods; packet loss rate is calculated based on the proportion of unacknowledged data packets; latency jitter rate is calculated based on the standard deviation of round-trip delay; and link congestion is determined by querying the router queue occupancy rate, with a value exceeding 70% indicating congestion. An environmental volatility parameter matrix between node pairs is constructed.

[0127] By incorporating real-time environmental parameters, compensation calculations are performed on the original communication payload to obtain dynamic resource requirements. The theoretical transmission time Tth is obtained by dividing the original communication payload by the currently available bandwidth, using the following formula: Rbw, Rloss, Rjit, and Rcon represent bandwidth volatility, packet loss rate, latency jitter, and link congestion, respectively, while w1, w2, w3, and w4 are weighting coefficients. The weighting coefficients are determined based on the actual impact of each environmental factor on transmission latency. Dynamic resource requirements are calculated, including network bandwidth occupancy time (equal to actual transmission time) and communication processing overhead (data size multiplied by a unit processing time coefficient, typically 0.5 to 2 milliseconds of CPU time per MB). A dynamic resource requirement matrix is ​​constructed. Dynamic resource requirements are mapped to nodes based on the task's logical location. Communication costs are included when tasks are assigned to different nodes; when assigned to the same node, bandwidth occupancy is zeroed, and processing overhead is reduced to 10% to 20% of its original value. The data transmission cost is obtained by summing the dynamic resource requirements between the task and its predecessor task.

[0128] Calculate the overall performance matrix. For each task-node mapping, calculate the total completion time (task execution time + predecessor data transmission time + queuing time), and take the reciprocal as the base performance score. Consider the multi-core concurrency capability of the nodes, multiplying by a concurrency coefficient (remaining cores / current number of tasks, maximum limit 2.0). Construct the overall performance matrix, where the row index represents the task to be assigned, the column index represents the candidate node, and the matrix element value is the overall performance score of the corresponding task on that node. Normalize the matrix row-wise by dividing each row element by the maximum value of that row, so that the performance scores of the same task on different nodes are mapped to the 0-1 range for easy comparison.

[0129] Based on the comprehensive performance matrix, a topology constraint-aware algorithm is used to locally fine-tune the risk correction execution sequence. The core of the algorithm is to identify tasks on the critical path, which is the longest path from the starting task to the terminating task in the dependency topology. Using topology sorting and dynamic programming, the earliest start time of each task is calculated forward, and the latest start time is calculated backward. The task whose earliest start time equals its latest start time is the task on the critical path.

[0130] The algorithm prioritizes tasks on the critical path for optimization. It queries the overall performance matrix to determine the performance score of each task across all candidate nodes and selects the node with the highest score as the new target node. If the new target node differs from the current node, it assesses the impact of migrating the task on the total critical path duration (including changes in task execution time and data transmission time between predecessor and successor tasks). If the total critical path duration decreases after migration, a migration operation is performed to update the task-node mapping; otherwise, the current mapping is maintained. Multiple rounds of iterative optimization are conducted, with the critical path recalculated after each iteration. The iteration termination condition is set as follows: if the total critical path duration does not improve after three consecutive iterations or the number of iterations reaches the 20-round limit. During iteration, the current optimal mapping scheme and the corresponding total task execution time are maintained. To avoid the algorithm getting trapped in local optima, a random perturbation mechanism is introduced: a migration operation with a 5% probability that slightly increases the total duration (the increase does not exceed 2% of the current total duration) is accepted. After iterative optimization, the mapping relationship with the shortest total task execution time is selected as the optimal task allocation result. This result satisfies all task dependency topology constraints and minimizes the total task execution time in the current real-time network environment. Stored in a structured data format, it contains detailed information such as the optimized task-node mapping sequence, critical path information, estimated total execution time, and load distribution for each node. This result serves as the final scheduling scheme, which is then distributed to the task execution system to guide the actual task allocation and execution process.

[0131] Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.

[0132] Reference Figure 2 The second embodiment of the present invention provides a task load balancing scheduling system for IoT edge computing nodes, comprising:

[0133] The node adaptability evaluation module is used to collect the running status of edge nodes, extract the task requirement features of the task to be processed, and calculate the node adaptability of each node to the task requirement features based on the running status and the task requirement features.

[0134] The priority weight generation module is used to calculate the priority scheduling weight of each task based on the node adaptability and the task execution constraints extracted from the task requirement features, and to sort the task queue to generate a task allocation sequence.

[0135] The dynamic load migration module is used to issue tasks according to the task allocation sequence and migrate tasks according to the node load status during task execution to obtain a preliminary balanced load distribution.

[0136] An adaptive rule generation module is used to optimize the path for the load distribution state, capture environmental deviations using a real-time feedback mechanism, update the priority scheduling weights and load balancing strategies based on the environmental deviations, and generate adaptive scheduling rules.

[0137] The interruption risk assessment module is used to apply the adaptive scheduling rules and combine them with the historical running records of candidate nodes to assess the probability of execution interruption, match tasks and nodes according to the interruption risk probability, and generate a mapping sequence for subsequent processing.

[0138] The resource overflow stress testing module is used to perform resource stress testing on the mapping sequence and identify overloaded tasks, remap the overloaded tasks to neighboring nodes and update the allocation index, and generate a risk correction sequence.

[0139] The global allocation optimization module is used to perform resource load compensation and node performance reassessment on the risk correction sequence based on real-time environmental parameters and logical dependency topology between tasks, and to determine the optimal task allocation result.

[0140] It should be noted that the task load balancing scheduling system for IoT edge computing nodes provided in this embodiment of the invention is used to execute all the process steps of the task load balancing scheduling method for IoT edge computing nodes in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0141] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0142] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that 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 for those skilled in the art.

Claims

1. A task load balancing scheduling method for IoT edge computing nodes, characterized in that, include: Collect the running status of edge nodes, extract the task requirement features of the task to be processed, and calculate the node adaptability of each node to the task requirement features based on the running status and the task requirement features. Based on the node adaptability and combined with the task execution constraints extracted from the task requirement features, the priority scheduling weight of each task is calculated, the task queue is sorted, and a task allocation sequence is generated. Tasks are issued according to the task allocation sequence, and during task execution, tasks are migrated according to the node load status to obtain a preliminary balanced load distribution. Path optimization is performed based on the load distribution status, and environmental deviations are captured using a real-time feedback mechanism. The priority scheduling weights and load balancing strategies are updated based on the environmental deviations to generate adaptive scheduling rules. The adaptive scheduling rule is applied and combined with the historical running records of candidate nodes to assess the probability of execution interruption. Based on the interruption risk probability, tasks and nodes are matched to generate a mapping sequence for subsequent processing. Perform resource stress testing on the mapping sequence and identify overloaded tasks. Remap the overloaded tasks to neighboring nodes and update the allocation index to generate a risk correction sequence. Based on real-time environmental parameters and the logical dependency topology between tasks, the risk correction sequence is compensated for resource load and re-evaluated for node performance to determine the optimal task allocation result. This involves obtaining the task queue to be scheduled, parsing the pre- and post-constraints between tasks, and constructing a directed acyclic graph that maps the logical links between tasks as a dependency topology graph. The task nodes in the dependency topology graph are traversed, and the execution time of each task is estimated based on historical execution records. The execution time of each task is then weighted and fused with the adaptability of the node to obtain a priority scheduling weight. Based on the priority scheduling weight, tasks in the dependency topology graph at the same in-degree level are sorted in descending order to generate a sorting index containing hierarchical constraint information. The storage structure of the task queue is reorganized based on the sorting index, and the execution path of the dependency topology graph is dynamically adjusted when a blockage is detected. The adjusted task queue is then used as the task allocation sequence.

2. The task load balancing scheduling method for IoT edge computing nodes according to claim 1, characterized in that, The system collects the operating status of edge nodes, extracts the task requirement features of the task to be processed, and calculates the node adaptability of each node to the task requirement features based on the operating status and the task requirement features, including: Collect real-time data streams from edge nodes and perform multi-dimensional parameter analysis to extract feature components including calculation frequency, transmission delay, and memory usage. Each of the aforementioned feature components is normalized and used as row vectors to construct a running state matrix reflecting the real-time availability of the node; Parse the task metadata of the task to be processed and extract the time constraint parameters and computing power requirement parameters. Calculate the urgency quantification coefficient based on the time constraint parameters and construct a resource feature vector reflecting the task requirements by combining the computing power requirement parameters. The resource feature vector and the running state matrix are weighted and mapped to obtain the matching degree evaluation value of each candidate node, and the matching degree evaluation value is determined as the node fitness.

3. The task load balancing scheduling method for IoT edge computing nodes according to claim 1, characterized in that, The step of issuing tasks according to the task allocation sequence and migrating tasks based on node load status during task execution to obtain a preliminary balanced load distribution includes: Execute the task allocation sequence, obtain the real-time load data of each node and compare it with the preset safety threshold, identify and extract the overload node identifier; Based on the real-time remaining execution time of the task, low latency-sensitive tasks are selected from the current tasks corresponding to the overload node identifier as migration sub-items, and a set of tasks to be migrated containing task characteristics and resource quota requirements is constructed. Scan candidate neighboring nodes that have network communication links with the overloaded node, evaluate the available remaining capacity of each neighboring node, and use a matching degree optimization algorithm to lock the final target node from the candidate neighboring nodes to take over the set of tasks to be migrated. Send a task status suspension command and execute a state transition flow pointing to the final target node, synchronously update the task mapping relationship table of all network devices, and obtain a preliminary balanced load distribution status.

4. The task load balancing scheduling method for IoT edge computing nodes according to claim 1, characterized in that, The process of optimizing paths based on the load distribution status, capturing environmental deviations using a real-time feedback mechanism, updating the priority scheduling weights and load balancing strategies based on the environmental deviations, and generating adaptive scheduling rules includes: Obtain multiple candidate task allocation paths under the load distribution state, and determine the estimated completion time of tasks on each path; The estimated completion time is compared with the task response time limit requirement to determine the optimized allocation path that meets the time limit constraint, and the real-time execution deviation of the optimized allocation path during task execution is extracted. The real-time execution deviation is input into a preset deviation analysis model to calculate the feedback correction coefficient characterizing the impact of environmental fluctuations. If the feedback correction coefficient exceeds the preset fluctuation threshold, the dynamic time factor in the priority scheduling weight is calculated synchronously using the feedback correction coefficient, and the weight ratio of the node scoring function in the load balancing strategy is adjusted to jointly constitute the adaptive scheduling rule.

5. The task load balancing scheduling method for IoT edge computing nodes according to claim 4, characterized in that, The adaptive scheduling rule is applied and combined with the historical execution records of candidate nodes to assess the probability of execution interruption. Based on the interruption risk probability, tasks and nodes are matched to generate a mapping sequence for subsequent processing, including: The adaptive scheduling rule is applied to map the real-time running status data of each candidate node to the feature space, generating a node feature vector that reflects the current performance characteristics of the node; Based on the feedback correction coefficient, the downtime frequency and network fluctuation value in the historical operation record are weighted and quantified to calculate the historical risk factor of each candidate node. Using a preset risk determination function, the node feature vector is correlated and mapped with the historical risk evaluation factor to calculate the probability of execution interruption risk for each candidate node in the current task. The priority scheduling weights are corrected using the execution interruption risk probability, and the candidate nodes are reordered based on their adaptability. The mapping sequence is then determined based on the sorting results.

6. The task load balancing scheduling method for IoT edge computing nodes according to claim 1, characterized in that, The process of performing resource stress testing on the mapping sequence and identifying overloaded tasks, remapping the overloaded tasks to neighboring nodes and updating the allocation index, and generating a risk correction sequence includes: The estimated resource consumption of each task in the mapping sequence is obtained, and a collision detection is performed with the physical load limit of the corresponding node to obtain the node load surplus. If the node load surplus is negative, it is determined that there is a risk of resource overflow, the overloaded node is locked and the subset of pending tasks that triggered the overflow is extracted. The subset of tasks to be processed is injected into the remaining available resource pool of neighboring nodes for allocation simulation, and the secondary adaptation degree value of each neighboring node after taking over the subset of tasks to be processed is calculated. The nearest node with the highest secondary adaptation value is selected as the traffic splitting target. The subset of tasks to be processed is remapped to the traffic splitting target, and the global task allocation index is updated synchronously. The mapping sequence is logically reorganized based on the updated global task allocation index to generate a risk correction execution sequence.

7. The task load balancing scheduling method for IoT edge computing nodes according to claim 1, characterized in that, The step of performing resource load compensation and node performance reassessment on the risk correction sequence based on real-time environmental parameters and the logical dependency topology between tasks to determine the optimal task allocation result includes: The logical dependency topology between tasks in the risk correction execution sequence is analyzed, the original communication payload of each dependency link is extracted, and the real-time environmental parameters of the current edge network are obtained synchronously. The original communication payload is compensated by combining the real-time environmental parameters to determine the dynamic resource requirements of each task under the current link state; Based on the logical location of each task in the dependent topology, the dynamic resource requirements are mapped to each node, and a comprehensive performance matrix including the data transmission cost of the predecessor task is calculated. Based on the comprehensive performance matrix, the risk correction execution sequence is locally fine-tuned using the topology constraint awareness algorithm to lock in the mapping relationship with the shortest total task execution time, thereby obtaining the optimal task allocation result.

8. A task load balancing scheduling system for IoT edge computing nodes, characterized in that, include: The node adaptability evaluation module is used to collect the running status of edge nodes, extract the task requirement features of the task to be processed, and calculate the node adaptability of each node to the task requirement features based on the running status and the task requirement features. The priority weight generation module is used to calculate the priority scheduling weight of each task based on the node adaptability and the task execution constraints extracted from the task requirement features, and to sort the task queue to generate a task allocation sequence. The dynamic load migration module is used to issue tasks according to the task allocation sequence and migrate tasks according to the node load status during task execution to obtain a preliminary balanced load distribution. An adaptive rule generation module is used to optimize the path for the load distribution state, capture environmental deviations using a real-time feedback mechanism, update the priority scheduling weights and load balancing strategies based on the environmental deviations, and generate adaptive scheduling rules. The interruption risk assessment module is used to apply the adaptive scheduling rules and combine them with the historical running records of candidate nodes to assess the probability of execution interruption, match tasks and nodes according to the interruption risk probability, and generate a mapping sequence for subsequent processing. The resource overflow stress testing module is used to perform resource stress testing on the mapping sequence and identify overloaded tasks, remap the overloaded tasks to neighboring nodes and update the allocation index, and generate a risk correction sequence. The global allocation optimization module is used to perform resource load compensation and node performance reassessment on the risk correction sequence based on real-time environmental parameters and logical dependency topology between tasks, and to determine the optimal task allocation result. This involves obtaining the task queue to be scheduled, parsing the pre- and post-constraints between tasks, and constructing a directed acyclic graph that maps the logical links between tasks as a dependency topology graph. The task nodes in the dependency topology graph are traversed, and the execution time of each task is estimated based on historical execution records. The execution time of each task is then weighted and fused with the adaptability of the node to obtain a priority scheduling weight. Based on the priority scheduling weight, tasks in the dependency topology graph at the same in-degree level are sorted in descending order to generate a sorting index containing hierarchical constraint information. The storage structure of the task queue is reorganized based on the sorting index, and the execution path of the dependency topology graph is dynamically adjusted when a blockage is detected. The adjusted task queue is then used as the task allocation sequence.

Images