Full-stack collaborative intelligent scheduling method and system for AIoT end side cloud heterogeneous resources

Abstract

The invention provides an AIoT end side cloud heterogeneous resource-oriented full-stack collaborative intelligent scheduling method and system, and is applied to the technical field of intelligent Internet of Things. By extracting the task intermediate state information and the execution progress identifier at the preset processing boundary and packaging the task intermediate state information and the execution progress identifier into the equipment-independent task state data packet, accurate storage of the task state and seamless migration across heterogeneous nodes are realized. The target computing resources are determined through intelligent scheduling, and the resource utilization rate and the scheduling efficiency of the whole system are improved. In addition, the integrity verification and version management mechanism of the task state data packet further ensures the data reliability in the task migration process, effectively prevents scheduling failure, and ensures the continuity and stability of services. Therefore, the method has the beneficial effects that the task execution efficiency, the system stability and the energy efficiency in the edge cloud heterogeneous resource environment of the AIoT end can be remarkably improved.

Description

Technical Field

[0001] This application relates to the field of intelligent Internet of Things (IoT) technology, and in particular to a full-stack collaborative intelligent scheduling method and system for heterogeneous resources of AIoT edge-cloud. Background Technology

[0002] In the edge-cloud collaborative environment of the Intelligent Internet of Things (AIoT), complex tasks typically require multi-layered resource collaboration to complete. However, existing scheduling methods are mostly based on macro-level indicators such as CPU utilization and bandwidth, treating tasks as units that can be migrated as a whole, ignoring intermediate state inheritance, cross-layer migration costs, and the continuity of the task chain. Therefore, in dynamic scenarios such as sudden increases in terminal load or resource contention, task reallocation often leads to problems such as redundant calculations, scheduling oscillations, execution out of control, and soaring energy consumption due to context loss.

[0003] Taking smart manufacturing parks as an example, if the scheduler mistakenly treats idle periods at the edge as zero-cost, it can easily concentrate a large number of low-priority, long-cycle tasks on the edge, thereby crowding out processing resources for high-priority tasks. Furthermore, the significant heterogeneity of edge nodes means that some nodes experience continuous saturation of dedicated AI chips and accumulating cache due to overload, while other nodes remain idle for extended periods. This uneven distribution of resources can cause congestion on 5G or wired links when overloaded nodes suddenly transmit data, resulting in transmission latency jitter and packet loss. Consequently, the cloud cannot obtain real-time resource status and can only make scheduling decisions based on outdated information, creating a vicious cycle.

[0004] In this scenario, real-time tasks are frequently interrupted due to edge queuing or transmission timeouts, resulting in the loss of critical results and business disruption. Simultaneously, edge nodes experience escalating energy consumption and localized overheating due to sustained high loads, forcing the cloud to allocate additional resources for retrying tasks, leading to a sharp decline in overall energy efficiency. Ultimately, the self-adjusting mechanism of the scheduling strategy fails due to noise contamination of feedback data, causing system scheduling failure and severely impacting production efficiency.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] In view of the shortcomings of the prior art, this application provides a full-stack collaborative intelligent scheduling method and system for heterogeneous resources of AIoT edge-cloud, which has the beneficial effect of significantly improving task execution efficiency, system stability and energy efficiency in the environment of heterogeneous resources of AIoT edge-cloud.

[0007] Firstly, a full-stack collaborative intelligent scheduling method for heterogeneous resources in AIoT edge-cloud environments is provided, the method comprising the following steps: S1: Obtain the resource status parameters, network status parameters, and task execution constraint information of the currently executing node; S2: When the resource status parameters or the network status parameters do not meet the task execution constraint information, after the task is executed to the preset processing boundary, extract the boundary output data and task execution progress identifier corresponding to the preset processing boundary; S3: Generate device-independent intermediate task state information based on the boundary output data, and encapsulate the intermediate task state information and the task execution progress identifier into a task state data packet, and store it in a shared storage space accessible to heterogeneous nodes; S4: Determine the target computing resources based on the task status data packet; S5: The target computing resource obtains the task status data packet from the shared storage space and generates a recovery status based on the task intermediate status information in the task status data packet; S6: Based on the task execution progress indicator and the recovery status, continue executing the task in the target computing resources from the processing position after the preset processing boundary.

[0008] Furthermore, the resource status parameters include current resource load, current available storage resources, and current remaining power; the network status parameters include current network latency and current available bandwidth; and the task execution constraint information includes latency constraints. Step S1 includes: S11: Obtain the current resource load, current available storage resources, current remaining power, current network latency, and current available bandwidth of the currently executing node; S12: Obtain the latency constraints corresponding to the task; S13: Compare the current resource load, current available storage resources, current remaining power, current network latency, and current available bandwidth with the constraints corresponding to the latency constraints to determine whether the resource status parameters or the network status parameters do not meet the task execution constraint information.

[0009] Furthermore, the task execution progress identifier includes a completed processing node identifier and a pending next processing node identifier; in step S2, after the task execution reaches a preset processing boundary, extracting the boundary output data corresponding to the preset processing boundary and the task execution progress identifier includes the following steps: S21: After detecting that the resource status parameters or the network status parameters do not meet the task execution constraint information, continuously monitor the task execution position; S22: When the task execution position reaches the preset processing boundary, extract the boundary output data corresponding to the preset processing boundary; S23: Generate the task execution progress identifier based on the currently completed processing nodes and the next processing node to be executed.

[0010] Furthermore, in step S3, generating device-independent intermediate task state information based on the boundary output data includes the following steps: S31: Analyze the data dimension, data precision, and data arrangement of the boundary output data; S32: Generate device-independent intermediate state information for the task based on the parsing results.

[0011] Furthermore, the task status data packet also includes a unique task identifier, a preset processing boundary identifier, a timestamp, version information, and an integrity verification identifier; in step S3, encapsulating the task intermediate status information and the task execution progress identifier into a task status data packet and storing it in a shared storage space accessible to heterogeneous nodes includes the following steps: S33: Associate and encapsulate the task intermediate state information, the task execution progress identifier, the task unique identifier, the preset processing boundary identifier, the timestamp, and the version information to generate a task status data packet; S34: Perform integrity verification calculation on the task status data packet, generate the integrity verification identifier, and write it into the task status data packet; S35: Store the task status data packet after writing the integrity verification identifier to the shared storage space.

[0012] Furthermore, step S35 includes: S351: Compare the currently generated task status data packet with historical basic snapshot data that have the same unique task identifier and preset processing boundary identifier, identify the data blocks that have changed, and generate incremental status data blocks; S352: Associate the incremental state data block with the corresponding basic snapshot index and store it in the distributed storage system; the shared storage space includes the distributed storage system.

[0013] Furthermore, step S4 includes: S41: Obtain the state adaptation cost of the candidate computing resources to the task state data packet and the remaining execution cost of the task; S42: Generate scheduling evaluation results based on the state adaptation cost and remaining task execution cost corresponding to each candidate computing resource; S43: Determine the target computing resources based on the scheduling evaluation results.

[0014] Furthermore, in step S5, obtaining the task status data packet from the shared storage space by the target computing resource includes the following steps: S51: Based on the task unique identifier, the preset processing boundary identifier and the basic snapshot index, obtain the corresponding basic snapshot data and incremental status data block from the distributed storage system; S52: Merge the incremental state data block into the base snapshot data to obtain the task state data packet.

[0015] Furthermore, in step S5, generating the recovery state based on the intermediate task state information in the task state data packet includes the following steps: S53: Perform integrity verification on the task status data packet according to the integrity verification identifier; S54: Read the intermediate status information of the task and the task execution progress identifier from the task status data packet; S55: Adapt the format of the boundary output data according to the intermediate state information of the task, and generate a recovery state.

[0016] Secondly, a full-stack collaborative intelligent scheduling system for heterogeneous resources in AIoT edge-cloud environments is provided. This system implements the steps of any of the methods described above, and includes: Acquisition module: Acquires the resource status parameters, network status parameters, and task execution constraint information of the currently executing node; Extraction module: When the resource status parameters or the network status parameters do not meet the task execution constraint information, after the task is executed to the preset processing boundary, extract the boundary output data and task execution progress identifier corresponding to the preset processing boundary; Storage module: Generates device-independent intermediate task state information based on the boundary output data, and encapsulates the intermediate task state information and the task execution progress identifier into a task state data packet, and stores it in a shared storage space accessible to heterogeneous nodes; Determining module: Determines the target computing resources based on the task status data packet; Generation module: The target computing resource obtains the task status data packet from the shared storage space and generates a recovery status based on the task intermediate status information in the task status data packet; Continue execution module: Based on the task execution progress indicator and the recovery status, continue execution of the task in the target computing resources from the processing position after the preset processing boundary.

[0017] Beneficial Effects: This application proposes a full-stack collaborative intelligent scheduling method and system for heterogeneous resources in the AIoT edge-cloud environment. By extracting intermediate task state information and execution progress identifiers from preset processing boundaries and encapsulating them into device-independent task state data packets, it achieves accurate preservation of task states and seamless migration across heterogeneous nodes. Intelligent scheduling determines target computing resources, improving the overall system's resource utilization and scheduling efficiency. Furthermore, the integrity verification and version management mechanism for task state data packets further ensures data reliability during task migration, effectively preventing scheduling failures and ensuring business continuity and stability. Therefore, this application has the beneficial effect of significantly improving task execution efficiency, system stability, and energy efficiency in AIoT edge-cloud heterogeneous resource environments. Attached Figure Description

[0018] Figure 1 This is a flowchart of a full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud.

[0019] Figure 2 This is a flowchart of a full-stack collaborative intelligent scheduling system for heterogeneous resources of AIoT edge-cloud.

[0020] Figure 3 This is a schematic diagram of a full-stack collaborative intelligent scheduling system for heterogeneous resources of AIoT edge-cloud.

[0021] Labeling Explanation: 201. Acquisition Module; 202. Extraction Module; 203. Storage Module; 204. Confirmation Module; 205. Generation Module; 206. Continue Execution Module. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and marked in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] Please refer to Figure 1 A full-stack collaborative intelligent scheduling method for heterogeneous resources in AIoT edge-cloud environments, comprising the following steps: S1: Obtain the resource status parameters, network status parameters, and task execution constraint information of the currently executing node; S2: When the resource status parameters or network status parameters do not meet the task execution constraints, after the task execution reaches the preset processing boundary, extract the boundary output data and task execution progress identifier corresponding to the preset processing boundary. S3: Generate device-independent intermediate task state information based on boundary output data, and encapsulate the intermediate task state information and task execution progress identifier into a task state data packet, and store it in a shared storage space accessible to heterogeneous nodes; S4: Determine the target computing resources based on the task status data packet; S5: The target computing resource obtains the task status data packet from the shared storage space and generates a recovery status based on the intermediate task status information in the task status data packet; S6: Based on the task execution progress indicator and recovery status, continue the task execution in the target computing resources from the processing position after the preset processing boundary.

[0025] The method proposed in this application achieves seamless migration and recovery of tasks between heterogeneous nodes by introducing a mechanism for generating and storing intermediate task state information, effectively avoiding redundant calculations and resource waste caused by context loss in traditional scheduling methods. By accurately identifying the task execution progress and generating recovery states, it ensures the coherent execution of tasks on different computing resources, thereby improving scheduling efficiency and system stability in the AIoT edge-cloud collaborative environment.

[0026] In step S1, resource status parameters refer to the real-time status of the current execution node in terms of network, storage, computing, etc., including current resource load, currently available storage resources, and current remaining power. These resource status parameters reflect the carrying capacity and operating efficiency of the current execution node and can be collected periodically by deploying a monitoring agent on the current execution node.

[0027] Network status parameters refer to the quality indicators of the connection between the current execution node and the external network, including current network latency and current available bandwidth. These network status parameters directly affect the transmission efficiency and real-time performance of task data and can be obtained through network probing tools or API interfaces.

[0028] Task execution constraints refer to the conditions that a task must meet during execution, such as latency constraints. These constraints can be obtained directly from the task's metadata or scheduling requests.

[0029] To determine whether resource status parameters or network status parameters meet the task execution constraints, this application further proposes that step S1 includes: S11: Obtain the current resource load, current available storage resources, current remaining power, current network latency, and current available bandwidth of the currently executing node; S12: Obtain the latency constraints corresponding to the task; S13: Compare the current resource load, current available storage resources, current remaining power, current network latency, and current available bandwidth with the constraints corresponding to the latency constraints to determine whether the resource status parameters or network status parameters do not meet the task execution constraints.

[0030] In practical applications, latency constraints include at least three constraints: maximum allowable processing latency, maximum allowable transmission latency, and maximum allowable queuing latency.

[0031] When making a judgment, first obtain the computational workload and data volume of the task. These two parameters are usually written in the task description and can be directly extracted from the description.

[0032] Then, based on the current resource load and the computational workload of the task, the processing time required for the task is estimated. This estimation method is based on the assumption of linear resource scaling, modeling the task execution time as the task's computational workload divided by the currently available computing power plus a fixed overhead. That is: ,in, C represents the processing time required for the task; C represents the computational load of the task. This represents the amount of computation that can be processed per unit time, which can be obtained through hardware specifications or simple benchmark tests. L represents the current resource load. It is a very small positive number (such as 0.01) to prevent the denominator from being zero when L=1; The overhead is a fixed cost independent of computational cost and can be measured by executing an empty task.

[0033] Then, based on the current network latency, the current available bandwidth, and the amount of data in the task, calculate the estimated transmission time required for the task. The specific calculation method is: transmission time required for the task = amount of data / current available bandwidth + current network latency.

[0034] Continue to estimate the queuing time required for the task based on currently available storage resources, remaining battery power, and the amount of data in the task. The calculation method is as follows: ,in, Let Q be the queuing time required for the task, and Q be the amount of data for the task. α is the amount of data that can be processed per unit time; α is the storage impact factor, which is obtained based on the currently available storage resources. If the currently available storage resources are greater than or equal to the minimum storage space required by the task, then α=1; otherwise, α=0, which means that the task cannot be enqueued and the queuing time required is infinite; β is the power impact factor, which is obtained based on the current remaining power. If the current remaining power is greater than or equal to the minimum power required by the task, then β=1; otherwise, β=0, which means that the current execution node is unavailable and the queuing time required is infinite.

[0035] Finally, the processing time required for the task, the transmission time required for the task, and the queuing time required for the task are compared with the maximum allowable processing delay, the transmission time required for the task, and the queuing time required for the task. If all three comparison results are within the maximum allowable delay of the delay constraint, it can be determined that the resource status parameters or network status parameters satisfy the task execution constraint information; otherwise, it is determined that they do not satisfy the constraint.

[0036] In practical applications, when the task execution constraints are met, the task can be processed on the current execution node without needing to be scheduled to other nodes. This situation is outside the scope of this application and will not be discussed further.

[0037] If the condition is not met, proceed to step S2. In step S2, the preset processing boundary refers to one or more key nodes pre-defined in the task execution flow. At these key nodes, the intermediate state of the task can be safely saved and restored.

[0038] Boundary output data refers to the intermediate result data generated when the task execution reaches the preset processing boundary. Task execution progress indicators are information used to mark which stage or processing node the task is currently executing, and therefore include indicators of completed processing nodes and indicators of the next processing node to be executed.

[0039] When a task cannot continue to complete at the current execution node, the system will wait for the task to reach a preset processing boundary. For example, the preset processing boundary for a video processing task is the completion point of a certain video frame. Once the boundary is reached, the system will extract the output data of the currently processed frame (i.e., boundary output data) and record the number of frames that the task has completed and the identifier of the next frame to be processed (i.e., task execution progress identifier).

[0040] Specifically, in step S2, after the task execution reaches the preset processing boundary, extracting the boundary output data and task execution progress identifier corresponding to the preset processing boundary includes the following steps: S21: After detecting that the resource status parameters or network status parameters do not meet the task execution constraints, continuously monitor the task execution location; S22: When the task execution position reaches the preset processing boundary, extract the boundary output data corresponding to the preset processing boundary; S23: Generate task execution progress indicators based on the currently completed processing nodes and the next processing node to be executed.

[0041] The task execution position can be achieved by embedding checkpoints or callback functions in the task execution logic, so that the current position can be obtained in real time during the task execution process.

[0042] When the task execution position precisely reaches the preset processing boundary, the system extracts the boundary output data corresponding to that boundary. This data consists of intermediate results from all calculations prior to that processing boundary and can be used to restore the task state.

[0043] The "Completed Processing Node" identifier indicates which processing node the task has successfully executed to, while the "Next Processing Node to be Executed" identifier specifies which processing node the task should resume execution from after recovery. The generated task execution progress identifiers ensure seamless completion of the task after it is scheduled to other computing nodes.

[0044] In step S3, the intermediate state information of the task refers to the task execution state information generated based on the boundary output data, which is independent of the specific device. This device independence allows the task to migrate and resume between different types of nodes.

[0045] A task status data packet is a data structure that encapsulates intermediate task status information and task execution progress indicators together, and is used to transmit and store task status between different nodes.

[0046] Shared storage space refers to a storage area that can be accessed by different nodes, such as in a distributed storage system.

[0047] Furthermore, in step S3, generating device-independent intermediate task state information based on the boundary output data includes the following steps: S31: Analyze the data dimension, data precision, and data arrangement of the boundary output data; S32: Generate device-independent intermediate state information for the task based on the parsing results.

[0048] Specifically, boundary output data may exist in various formats, and its structure, precision, and arrangement may be related to a specific execution device or platform. Therefore, when parsing boundary output data, we start with the data dimensions, data precision, and data arrangement to transform it into a standard intermediate representation that is independent of any specific hardware or software environment, thus obtaining device-independent intermediate task state information.

[0049] In this context, data dimension refers to the size or shape of the boundary output data in different directions. For example, for image data, it could be width, height, and number of channels; for tensor data, it could be the length of each axis. Understandably, for other types of data, data dimension corresponds to different suitable representations, which will not be listed here.

[0050] Data precision refers to the numerical representation method used for data, such as floating-point numbers (single precision, double precision), integers (8-bit, 16-bit, 32-bit), etc.

[0051] Data arrangement refers to the order in which data is organized in memory or storage media, such as row-major order, column-major order, or channel-major order. Different devices or frameworks may use different arrangement methods.

[0052] The above data is stored in a preset universal format, which can be the industry standard: Protobuf + raw byte stream format, so that the intermediate state information of the task can be correctly understood and recovered on any different node, avoiding data parsing errors or functional abnormalities caused by device differences.

[0053] Traditional AIoT edge-cloud heterogeneous resource collaborative scheduling methods typically only encapsulate and store intermediate task state information and execution progress identifiers during task state migration. However, in complex heterogeneous environments, challenges arise in task lifecycle management, state tracing, data consistency assurance, and fault recovery. For example, when multiple instances of the same task exist or state snapshots of the same task at different points in time, intermediate state information and progress identifiers alone are insufficient for effective differentiation and management. Failure to address these issues may lead to task state data confusion, recovery errors, or difficulties in effective version control and integrity verification, thereby affecting the reliability and efficiency of the entire scheduling system. To address this, this application further proposes that the task state data packet also includes a unique task identifier, a preset processing boundary identifier, a timestamp, version information, and an integrity verification identifier. In step S3, encapsulating the intermediate task state information and task execution progress identifier into a task state data packet and storing it in a shared storage space accessible to heterogeneous nodes includes the following steps: S33: Associate and encapsulate the intermediate state information of the task, the task execution progress identifier, the unique identifier of the task, the preset processing boundary identifier, the timestamp and the version information to generate a task status data packet; S34: Perform integrity verification calculations on the task status data packet, generate an integrity verification identifier, and write it into the task status data packet; S35: Store the task status data packet after writing the integrity verification flag to the shared storage space.

[0054] During the encapsulation process, in addition to the core intermediate task state information and task execution progress indicators, a series of important metadata are added. The task unique identifier is a globally unique string used to accurately identify this task instance throughout the distributed system. The pre-defined processing boundary identifier explicitly indicates at which specific node in the task flow this state snapshot was generated. The timestamp records the precise moment the snapshot was generated, which is crucial for version control and determining whether the state is outdated. Version information includes the model version number, algorithm version number, or runtime environment version number that the task depends on, which helps ensure environment compatibility when restoring the task.

[0055] All this information is serialized together to form a preliminary task status data packet. Next, to ensure data integrity during storage and transmission, a cryptographic hash function, such as a 256-bit secure hash algorithm, is applied to the entire content of this data packet. The calculated hash value is the integrity verification identifier. This identifier is appended to the end of the data packet.

[0056] Finally, this final task status data packet, containing integrity verification identifiers, is sent and stored in a shared storage space. This shared storage space can be a distributed key-value store system deployed at the edge, such as a highly available Radisson cluster, or an object storage service in the cloud. Since all potential target computing resources can access this shared space, this lays the foundation for reliable task migration and recovery.

[0057] An integrity verification identifier is a digital credential used to verify whether a task status data packet retains its original state during storage and transmission. During the encapsulation phase, the encapsulation module uses a cryptographic hash algorithm to perform a digest calculation on the entire binary packet content, including intermediate task states, execution progress, and various metadata, generating a fixed-length signature. This signature is tightly bound to the data packet. When the target computing resource receives the data packet, it uses the same algorithm to re-hash the received content and compares the new signature bit-by-bit with the original verification identifier carried in the packet. This mechanism effectively detects bit flips caused by network transmission noise, data corruption due to storage media failure, and potential malicious tampering. The recovery process only begins when both are completely identical, ensuring the logical correctness of task recovery and preventing task crashes caused by loading incorrect states.

[0058] In a preferred embodiment, to optimize storage efficiency, especially for tasks that require frequent state snapshots, the step of storing task state data packets can be incremental. Specifically, step S35 includes: S351: Compare the currently generated task status data packet with historical base snapshot data that have the same unique task identifier and preset processing boundary identifier, identify the data blocks that have changed, and generate incremental status data blocks; S352: Associate the incremental state data block with the corresponding basic snapshot index and store it in the distributed storage system; the shared storage space includes the distributed storage system.

[0059] This implementation maintains a historical snapshot. When a new task status packet is generated, the entire packet is not stored directly. Instead, the new packet is compared block-by-block with the stored snapshot that shares the same task identifier and boundary identifier. In many cases, most of the data in consecutive snapshots is the same or similar, with only a small portion changing. By comparing these snapshots, the changed data blocks can be precisely identified.

[0060] Then, only these identified incremental state data blocks are actually stored. During storage, these incremental blocks are associated with an index pointing to the underlying snapshot they depend on. In this way, the task state at any given point in time can be completely reconstructed using a base snapshot and a series of subsequent incremental data blocks. This incremental storage method significantly reduces storage space usage and network transmission load, improving the efficiency and scalability of the entire state management system. Distributed storage systems are well-suited for implementing the storage and management of such incremental snapshots.

[0061] In step S4, the target computing resource refers to the computing node selected according to the scheduling strategy for continuing to execute the task, which can be an end device, an edge server, or a cloud server.

[0062] Furthermore, step S4 includes: S41: Obtain the state adaptation cost of candidate computing resources to the task state data packet and the remaining execution cost of the task; S42: Generate scheduling evaluation results based on the state adaptation cost and remaining task execution cost corresponding to each candidate computing resource; S43: Determine the target computing resources based on the scheduling evaluation results.

[0063] Specifically, candidate computing resources are nodes that are candidates to receive tasks.

[0064] State adaptation cost refers to the total resource overhead incurred in restoring a task from shared storage space to a state where the target computing resources are available. The calculation formula is: ,in, The cost of state adaptation This refers to the size of the task status data packet, specifically the number of bytes in the task status packet. The available bandwidth (bytes / second) between the current candidate computing resource i and the shared storage can be obtained from network monitoring. Set a fixed initialization time for the current candidate computing resource i. This time can be determined in advance through experiments (e.g., the average time from receiving data to the task being executable). If the node types are the same, they can be set to the same constant.

[0065] The remaining execution cost of a task refers to the estimated total resource consumption on specific candidate computing resources from the start of the pre-defined processing boundary until the task is fully completed. The calculation method is as follows: ,in, R represents the remaining execution cost of the task, and R represents the remaining computational cost of the task, which is obtained by multiplying the number of remaining operators by the average time consumed per unit operator. The computational capacity that candidate computing resource i can process per unit time can be obtained through hardware specifications or simple benchmark tests. The current resource load of the current candidate computing resource i. It is a very small positive number (such as 0.01) used to prevent when When the denominator is 1, the denominator is zero.

[0066] After acquiring the costs of all candidate resources, the scheduler uses a pre-defined evaluation function to weight these two costs, generating a comprehensive scheduling evaluation result for each candidate resource. This result directly reflects the overall merits of migrating the task to that candidate resource. Finally, the scheduler selects the candidate resource with the best scheduling evaluation result as the final target computing resource. During the weighted calculation, the initial weights for both state adaptation cost and remaining task execution cost can be set to 0.5. During actual runtime, a trigger-based adjustment is performed. The trigger-based adjustment conditions are: if the available bandwidth is lower than a preset threshold (e.g., 10 Mbps), indicating that the migration process is susceptible to network bottlenecks, the state adaptation cost weight is reduced to 0.3, and the remaining task execution cost weight is correspondingly increased to 0.7, prioritizing nodes with strong computing power and reducing reliance on network transmission. If the remaining task execution time is less than a preset urgency threshold (e.g., 1 second), indicating that the task needs to be completed quickly, the remaining task execution cost weight is increased to 0.7, and the state adaptation cost weight is reduced to 0.3, emphasizing subsequent execution efficiency. In all other cases, the weights remain balanced. Through the aforementioned triggering conditions, the two weights can be adjusted in a lightweight and adaptive manner based on the system state and task characteristics, ensuring the stability of scheduling decisions while enabling rapid response in extreme scenarios, thereby improving overall scheduling performance.

[0067] In step S5, the recovery state refers to the state generated by the target computing resources based on the intermediate state information of the task, which is used to restore the task execution context.

[0068] Specifically, in step S5, the process of obtaining the task status data packet from the shared storage space by the target computing resource includes the following steps: S51: Based on the task's unique identifier, the preset processing boundary identifier, and the basic snapshot index, retrieve the corresponding basic snapshot data and incremental status data blocks from the distributed storage system; S52: Merge the incremental state data blocks into the base snapshot data to obtain the task state data packet.

[0069] The target computing resource receives a base snapshot index containing a unique task identifier, a preset processing boundary identifier, and the snapshot version to which it needs to be restored. Using this information as a query keyword, the target computing resource sends a request to the distributed storage system. The distributed storage system first locates and returns the complete base snapshot data based on the base snapshot index. Then, it searches for and returns all incremental state data blocks recorded between the base snapshot version and the target snapshot version.

[0070] After acquiring the base snapshot and all relevant incremental data blocks, the target compute resource performs a merge operation locally. Incremental state data blocks are applied sequentially to the base snapshot data, overwriting or modifying the old data with the new data. Once all incremental blocks have been merged, a complete task state data packet is obtained, perfectly consistent with the original node at the time of the interruption.

[0071] After successfully acquiring and reconstructing the task state data packet, the target computing resource needs to transform it into an executable state. Further, in step S5, generating the recovery state based on the intermediate task state information in the task state data packet includes the following steps: S53: Perform integrity verification on the task status data packet based on the integrity verification identifier; S54: Read intermediate status information and task execution progress indicator from the task status data packet; S55: Adapt the format of the boundary output data based on the intermediate state information of the task to generate the recovery state.

[0072] The target computing resource will recalculate the 256-bit hash value of the entire received task status data packet using its secure hash algorithm and compare it with the integrity check flag appended to the end of the data packet. If they match perfectly, the data packet is intact and untampered with during transmission and storage, and processing can continue. If they do not match, the data is corrupted, the recovery process will be immediately aborted, and an error will be reported to the superior scheduler. A retransmission or rollback to an earlier valid snapshot may be requested.

[0073] After the verification is successful, the target computing resource will parse the data packet and extract the core task intermediate status information and task execution progress indicators.

[0074] Finally, the target computing resource reads the metadata about the boundary output data recorded in the task's intermediate state information, such as data dimensions, precision, and arrangement. Then, it performs necessary transformations on this data according to the requirements of its hardware platform and software framework. For example, if the target computing resource's AI inference framework requires the input tensor to be arranged in channel-first order, while the original data is channel-last, a dimension substitution operation will be performed. If the target resource requires 16-bit floating-point numbers, while the original data is 32-bit floating-point numbers, a precision conversion will be performed. After this series of adaptation operations, the generated data is the restored state, which can be directly loaded into the target computing resource's runtime environment, such as into the graphics processor's memory, as input for subsequent computational layers of the model. At this point, all preparation work for task restoration is complete, and the process can proceed to step S6. In step S6, after generating the restored state, the cloud server determines the task's starting execution position based on the task execution progress indicator. Then, it uses the restored state to initialize the task's execution environment and continues executing the video analysis task from its starting execution position. In this way, the task does not need to start from scratch, avoiding repeated calculations and ensuring the continuity and efficiency of the task.

[0075] Please refer to Figure 2 , Figure 3 This application also provides a full-stack collaborative intelligent scheduling system for heterogeneous resources in AIoT edge-cloud, which implements the steps of any of the above methods. The system includes: Module 201: Acquires the resource status parameters, network status parameters, and task execution constraint information of the currently executing node; Extraction module 202: When the resource status parameters or network status parameters do not meet the task execution constraint information, after the task is executed to the preset processing boundary, extract the boundary output data and task execution progress identifier corresponding to the preset processing boundary; Storage module 203: Generates device-independent intermediate task state information based on boundary output data, and encapsulates the intermediate task state information and task execution progress identifier into a task state data packet, which is then stored in a shared storage space accessible to heterogeneous nodes; Module 204: Determines the target computing resources based on the task status data packet; Generation module 205: Obtains task status data packets from the shared storage space from the target computing resources, and generates recovery status based on the intermediate task status information in the task status data packets; Continue execution module 206: Based on the task execution progress indicator and recovery status, continue execution of the task in the target computing resources from the processing position after the preset processing boundary.

[0076] This application's system achieves full-stack collaborative intelligent scheduling of AIoT tasks in heterogeneous resource environments by decomposing complex scheduling methods into a series of cooperating modules. When the acquisition module 201 detects that the resource or network status of the current execution node does not meet the task execution constraints, the extraction module 202 can promptly capture the intermediate state and progress of the task when it reaches the preset processing boundary. Subsequently, the storage module 203 encapsulates this key information into device-independent task intermediate state information and task execution progress identifiers, and encapsulates it into task state data packets, securely storing them in shared storage space to ensure the portability of the task state. The determination module 204 intelligently selects the most suitable task migration target based on the evaluation of the task state data packets and candidate resources. Once the target computing resource is determined, the generation module 205 is responsible for restoring the task state from the shared storage space and transforming it into an executable restored state. Finally, the continuation module 206 uses these restored states and progress identifiers to ensure that the task can seamlessly continue execution from the interruption point on the new computing resources. This modular design makes the entire scheduling process efficient and flexible, and can effectively cope with the resource fluctuations and network instability common in AIoT environments.

[0077] Through the aforementioned system solution, this application provides a concrete and deployable architecture for implementing a full-stack collaborative intelligent scheduling method for heterogeneous resources in the AIoT edge-cloud ecosystem. This system, through clear modular division, enables the efficient and reliable execution of each complex step within the method, thereby significantly improving the resilience, continuity, and execution efficiency of AIoT tasks in dynamic heterogeneous environments. Specifically, this system ensures that, under resource-constrained or poor network conditions, tasks can be promptly and accurately migrated to more suitable computing resources, avoiding task interruptions or performance degradation, and greatly enhancing the robustness and user experience of AIoT applications.

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

Claims

1. A full-stack collaborative intelligent scheduling method for heterogeneous resources in AIoT edge-cloud environments, characterized in that, The method includes the following steps: S1: Obtain the resource status parameters, network status parameters, and task execution constraint information of the currently executing node; S2: When the resource status parameters or the network status parameters do not meet the task execution constraint information, after the task is executed to the preset processing boundary, extract the boundary output data and task execution progress identifier corresponding to the preset processing boundary; S3: Generate device-independent intermediate task state information based on the boundary output data, and encapsulate the intermediate task state information and the task execution progress identifier into a task state data packet, and store it in a shared storage space accessible to heterogeneous nodes; S4: Determine the target computing resources based on the task status data packet; S5: The target computing resource obtains the task status data packet from the shared storage space and generates a recovery status based on the task intermediate status information in the task status data packet; S6: Based on the task execution progress indicator and the recovery status, continue executing the task in the target computing resources from the processing position after the preset processing boundary.

2. The full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 1, characterized in that, The resource status parameters include current resource load, current available storage resources, and current remaining power; the network status parameters include current network latency and current available bandwidth; and the task execution constraint information includes latency constraints. Step S1 includes: S11: Obtain the current resource load, current available storage resources, current remaining power, current network latency, and current available bandwidth of the currently executing node; S12: Obtain the latency constraints corresponding to the task; S13: Compare the current resource load, current available storage resources, current remaining power, current network latency, and current available bandwidth with the constraints corresponding to the latency constraints to determine whether the resource status parameters or the network status parameters do not meet the task execution constraint information.

3. The full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 1, characterized in that, The task execution progress indicator includes the indicator of the completed processing node and the indicator of the next processing node to be executed; in step S2, after the task execution reaches the preset processing boundary, extracting the boundary output data corresponding to the preset processing boundary and the task execution progress indicator includes the following steps: S21: After detecting that the resource status parameters or the network status parameters do not meet the task execution constraint information, continuously monitor the task execution position; S22: When the task execution position reaches the preset processing boundary, extract the boundary output data corresponding to the preset processing boundary; S23: Generate the task execution progress identifier based on the currently completed processing nodes and the next processing node to be executed.

4. The full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 1, characterized in that, In step S3, generating device-independent intermediate task state information based on the boundary output data includes the following steps: S31: Analyze the data dimension, data precision, and data arrangement of the boundary output data; S32: Generate device-independent intermediate state information for the task based on the parsing results.

5. A full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 1, characterized in that, The task status data packet also includes a unique task identifier, a preset processing boundary identifier, a timestamp, version information, and an integrity verification identifier; in step S3, encapsulating the task intermediate status information and the task execution progress identifier into a task status data packet and storing it in a shared storage space accessible to heterogeneous nodes includes the following steps: S33: Associate and encapsulate the task intermediate state information, the task execution progress identifier, the task unique identifier, the preset processing boundary identifier, the timestamp, and the version information to generate a task status data packet; S34: Perform integrity verification calculation on the task status data packet, generate the integrity verification identifier, and write it into the task status data packet; S35: Store the task status data packet after writing the integrity verification identifier to the shared storage space.

6. The full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 5, characterized in that, Step S35 includes: S351: Compare the currently generated task status data packet with historical basic snapshot data that have the same unique task identifier and preset processing boundary identifier, identify the data blocks that have changed, and generate incremental status data blocks; S352: Associate the incremental state data block with the corresponding basic snapshot index and store it in the distributed storage system; the shared storage space includes the distributed storage system.

7. The full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 1, characterized in that, Step S4 includes: S41: Obtain the state adaptation cost of the candidate computing resources to the task state data packet and the remaining execution cost of the task; S42: Generate scheduling evaluation results based on the state adaptation cost and remaining task execution cost corresponding to each candidate computing resource; S43: Determine the target computing resources based on the scheduling evaluation results.

8. A full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 6, characterized in that, In step S5, obtaining the task status data packet from the shared storage space by the target computing resource includes the following steps: S51: Based on the task unique identifier, the preset processing boundary identifier and the basic snapshot index, obtain the corresponding basic snapshot data and incremental status data block from the distributed storage system; S52: Merge the incremental state data block into the base snapshot data to obtain the task state data packet.

9. A full-stack collaborative intelligent scheduling method for heterogeneous resources of AIoT edge-cloud as described in claim 5, characterized in that, In step S5, generating a recovery state based on the intermediate task state information in the task state data packet includes the following steps: S53: Perform integrity verification on the task status data packet according to the integrity verification identifier; S54: Read the intermediate status information of the task and the task execution progress identifier from the task status data packet; S55: Adapt the format of the boundary output data according to the intermediate state information of the task, and generate a recovery state.

10. A full-stack collaborative intelligent scheduling system for heterogeneous resources in AIoT edge-cloud environments, characterized in that, The system is used to implement the steps of the method according to any one of claims 1-9, and the system includes: Acquisition module: Acquires the resource status parameters, network status parameters, and task execution constraint information of the currently executing node; Extraction module: When the resource status parameters or the network status parameters do not meet the task execution constraint information, after the task is executed to the preset processing boundary, extract the boundary output data and task execution progress identifier corresponding to the preset processing boundary; Storage module: Generates device-independent intermediate task state information based on the boundary output data, and encapsulates the intermediate task state information and the task execution progress identifier into a task state data packet, and stores it in a shared storage space accessible to heterogeneous nodes; Determining module: Determines the target computing resources based on the task status data packet; Generation module: The target computing resource obtains the task status data packet from the shared storage space and generates a recovery status based on the task intermediate status information in the task status data packet; Continue execution module: Based on the task execution progress indicator and the recovery status, continue execution of the task in the target computing resources from the processing position after the preset processing boundary.

Images