Unified resource pooling management method for multiple computing power sources of UAV platforms

Abstract

The present invention relates to the field of resource allocation technology, specifically a unified resource pooling management method for multiple computing power sources of an unmanned aerial vehicle platform, comprising the following steps: parsing the unmanned aerial vehicle business flow to obtain subtask nodes and dependency edges, and measuring the execution time of each subtask on different heterogeneous computing power units. The present invention parses the unmanned aerial vehicle business flow to obtain subtask nodes and dependency edges, and based on the task execution priority ranking, measures the refined execution time of each subtask on the heterogeneous computing power unit, clarifies the actual time consumed in data transmission between computing tasks, and forms a complete basic view of heterogeneous computing power pool scheduling, thereby improving task execution efficiency and resource scheduling accuracy; at the same time, during the resource allocation process, the real-time operating temperature and computing error rate of each computing power unit are continuously monitored, the dynamic health status of the computing unit is intelligently analyzed and calculated, potential failure risks are timely identified, and pre-degradation control signals are actively triggered.

Description

Technical Field

[0001] The present invention relates to the field of resource allocation technology, and in particular to a unified resource pooling management method for multiple computing power sources of an unmanned aerial vehicle platform. Background Art

[0002] The field of resource allocation technology mainly studies how to allocate various heterogeneous computing, storage, network and other resources to tasks or users in an efficient, fair and reasonable manner under limited resource conditions to maximize resource utilization and optimize system performance.

[0003] In actual operation, existing technologies pay insufficient attention to the heterogeneity of computing resources, real-time performance, and fault tolerance. They only consider simple allocation of various resources or resource balancing based on fixed rules. They lack real-time measurement of task execution and are unable to promptly reflect the actual dynamic changes in resource usage during task processing. This delayed response to resource status changes can easily lead to task execution delays, resource load imbalance, or idle resource waste. Therefore, improvement is needed. Summary of the Invention

[0004] The purpose of the present invention is to solve the shortcomings of the existing technology and propose a unified resource pooling management method for multiple computing power sources of an unmanned aerial vehicle platform.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a unified resource pooling management method for multiple computing power sources of a UAV platform, comprising the following steps:

[0006] Analyze drone business flows to obtain subtask nodes and dependency edges, measure the execution time of each subtask on different heterogeneous computing units, calculate the time overhead of data transmission between heterogeneous computing units executing continuous tasks, and build a basic view of heterogeneous computing pool scheduling that includes task graph structure and time overhead;

[0007] Perform topological sorting based on the task graph structure in the heterogeneous computing power pool scheduling basic view to generate a task execution priority sequence. Based on the task execution priority sequence, traverse the ready tasks and calculate the earliest completion time on each heterogeneous computing power unit. Select the unit with the smallest earliest completion time for assignment, and obtain an initial computing power resource allocation decision.

[0008] Determine the currently active heterogeneous computing power unit based on the initial computing power resource allocation decision, continuously obtain the operating temperature and computing error rate, calculate the health score, generate a computing power unit health status time series flow, obtain the health score change trend based on the computing power unit health status time series flow, determine the potential failure risk, and establish a computing power unit pre-degradation trigger signal;

[0009] According to the pre-degradation trigger signal of the computing power unit and the initial computing power resource allocation decision, the risk unit and the critical tasks it carries are locked, a copy of the running status is created for the critical tasks, and a status checkpoint of the task to be migrated is generated. Based on the status checkpoint of the task to be migrated, the task operation is restored on the spare heterogeneous computing power unit with the lowest load, and the updated resource allocation and execution instructions are obtained.

[0010] Preferably, the steps for obtaining the heterogeneous computing power pool scheduling basic view are:

[0011] Parse the drone business flow, extract the dependencies between each subtask node and task defined therein, record the name of the subtask node, task type, and dependency edge information one by one, and generate a set of subtask node and dependency edge information;

[0012] Based on the subtask nodes and dependency edge information sets, the performance parameters and execution efficiency parameters of each heterogeneous computing unit are called respectively. The execution time of each subtask node on different heterogeneous computing units is calculated one by one, and the execution time information of each subtask node is recorded one by one and summarized into a set of heterogeneous computing unit execution time information.

[0013] Based on the execution time information set of the heterogeneous computing power units, the output data size parameters corresponding to the continuous tasks and the network bandwidth parameters between the heterogeneous computing power units are called, and the time consumption of data transmission between continuous subtasks is calculated one by one. It is combined with the subtask nodes and dependency edge information sets to form a complete task graph structure, and generate a basic view of heterogeneous computing power pool scheduling.

[0014] Preferably, the steps for obtaining the task execution priority sequence are:

[0015] Based on the task graph structure in the heterogeneous computing power pool scheduling basic view, traverse each subtask node, extract the subtask node number, the execution time corresponding to the node, the direct predecessor task number and the communication delay between the node and the current node, the direct successor task node number and the corresponding execution time, accumulate the sum of the execution time of all subtask nodes, and generate a node topology feature set;

[0016] Calculating the forward-looking key task weight priority value of each subtask node based on the node topology feature set;

[0017] Based on the forward-looking critical task weight priority value of each subtask node, all subtask nodes are sorted in descending order of the forward-looking critical task weight priority value to generate a task execution priority sequence.

[0018] Preferably, the steps for obtaining the initial computing power resource allocation decision are:

[0019] Based on the task execution priority sequence, the task numbers that have currently met the completion requirements of all predecessor tasks are extracted one by one from the starting position, the status records of the heterogeneous computing power units are compared one by one, the current idle time information of each computing power unit is extracted, and the idle time set of the computing power unit of the current ready task is formed;

[0020] According to the idle time set of the computing unit of the current ready task, the task execution time parameters and the end time parameters of the corresponding predecessor tasks and the data transmission completion time parameters between tasks are called one by one, and the task execution time, the computing unit idle time and the data transmission completion time of all predecessor tasks are compared in turn. The largest time value is selected and added to the task execution time value to generate the earliest completion time set corresponding to the current task of each heterogeneous computing unit;

[0021] Based on the earliest completion time set of the current task corresponding to each heterogeneous computing power unit, extract the computing power unit number with the smallest earliest completion time value, assign the current task number to the computing power unit number, and record it as the initial computing power resource allocation decision.

[0022] Preferably, the steps for obtaining the health status timing flow of the computing power unit are:

[0023] Based on the initial computing power resource allocation decision, extract the numbers of all currently active heterogeneous computing power units, call each heterogeneous computing power unit in turn, obtain the actual operating temperature value and the number of calculation errors in each sampling period, continuously record the sampling number, operating temperature value and the number of calculation errors, and form a sampling set of heterogeneous computing power unit temperature data and error data;

[0024] Calculate the dynamic stability perception health score based on the temperature data and error data sampling set of heterogeneous computing power units;

[0025] Based on the dynamic and stable perceived health scores of heterogeneous computing power units in each evaluation cycle, continuous scoring records are organized in sampling time sequence to establish a time series flow of the health status of the computing power units.

[0026] Preferably, the steps of obtaining the pre-degradation trigger signal of the computing power unit are:

[0027] Based on the health status time series flow of the computing power unit, a time sliding window with a fixed step size is set, and the dynamic stability perception health score sequence and the corresponding time index sequence in each sliding window are extracted in chronological order. The start time of each window is marked and all dynamic stability perception health scores are recorded to generate a sliding window health score time series set;

[0028] Calculating a degradation severity index corresponding to each sliding window according to the sliding window health score time series set;

[0029] Based on the degradation severity index, when the degradation severity index of any sliding window is greater than the set warning threshold, the end time point of the sliding window is immediately located, and a pre-degradation control signal is output to generate a computing power unit pre-degradation trigger signal.

[0030] Preferably, the step of obtaining the status checkpoint of the task to be migrated is:

[0031] According to the pre-demotion trigger signal of the computing power unit, the corresponding relationship between tasks and computing power units recorded in the initial computing power resource allocation decision is matched one by one, the computing power unit number corresponding to the pre-demotion signal and the numbers of all currently executed tasks are extracted, and the corresponding relationship between risk units and carrying tasks is formed;

[0032] Based on the correspondence between the risk unit and the task it carries, the real-time task status data of the corresponding task number is called one by one, and the memory image at the time of task execution, the instruction execution location, and the current value of the task-related register are recorded one by one to create a running status copy of the critical task;

[0033] Based on the running status copy of the critical task, the memory image and register status of all tasks therein are extracted and marked one by one, the consistency of the memory image and register status is verified and encapsulated to form a status checkpoint of the task to be migrated that can be used for migration recovery.

[0034] Preferably, the steps of obtaining the updated resource allocation and execution instructions are:

[0035] Based on the status checkpoint of the task to be migrated, the current number of tasks, the length of the real-time processing queue, and the current resource occupancy rate of all standby heterogeneous computing power units are extracted one by one, and the sums and sorts are performed item by item to obtain the number of the standby heterogeneous computing power unit with the lowest load;

[0036] According to the number of the standby heterogeneous computing power unit with the lowest load, the memory image and register state data stored in the state checkpoint of the task to be migrated are called, the extracted memory images are loaded one by one into the memory area of ​​the corresponding standby heterogeneous computing power unit, and the register state data are reloaded in sequence, and the running state of each task is restored one by one to form a restored task running state copy;

[0037] According to the restored task running status copy, a new correspondence between tasks and computing power units is generated one by one, the computing power resource scheduling record is updated, and the next executable program instruction sequence after the task is restored is generated one by one to form updated resource allocation and execution instructions.

[0038] Compared with the prior art, the advantages and positive effects of the present invention are:

[0039] The present invention obtains subtask nodes and dependency edges by parsing the drone business flow, and based on the task execution priority sorting, measures the refined execution time of each subtask on the heterogeneous computing power unit, clarifies the actual time consumption of data transmission between computing tasks, and forms a complete basic view of heterogeneous computing power pool scheduling, thereby improving task execution efficiency and resource scheduling accuracy; at the same time, in the resource allocation process, it continuously monitors the real-time operating temperature and computing error rate of each computing power unit, intelligently analyzes and calculates the dynamic health status, promptly identifies potential failure risks and actively triggers pre-degradation control signals, quickly constructs task status checkpoints to be migrated, and actively migrates tasks to the spare heterogeneous computing power unit with the lowest load to resume operation, thereby enhancing the resource scheduling reliability and overall system robustness during drone task execution, avoiding the risk of task execution interruption due to unexpected failures of heterogeneous computing power resource units, and ensuring the continuous and stable output of drone platform computing power resources and the quality of task completion. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 Schematic diagram of the steps of the present invention. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0042] See also Figure 1 The present invention provides a technical solution, a unified resource pooling management method for multiple computing power sources of a UAV platform, comprising the following steps:

[0043] Analyze drone business flows to obtain subtask nodes and dependency edges, measure the execution time of each subtask on different heterogeneous computing units, calculate the time overhead of data transmission between heterogeneous computing units executing continuous tasks, and build a basic view of heterogeneous computing pool scheduling that includes task graph structure and time overhead;

[0044] Perform topological sorting based on the task graph structure in the heterogeneous computing pool scheduling basic view to generate a task execution priority sequence. Based on the task execution priority sequence, traverse the ready tasks and calculate the earliest completion time on each heterogeneous computing unit. Select the unit with the smallest earliest completion time for assignment to obtain the initial computing resource allocation decision.

[0045] Based on the initial computing resource allocation decision, the currently active heterogeneous computing units are determined. The operating temperature and computing error rate are continuously obtained, the health score is calculated, and a time series flow of the computing unit health status is generated. Based on the time series flow of the computing unit health status, the health score change trend is obtained, the potential failure risk is determined, and a trigger signal for the computing unit pre-degradation is established.

[0046] According to the pre-degradation trigger signal of the computing power unit and the initial computing power resource allocation decision, the risk unit and the critical tasks it carries are locked, a copy of the running status is created for the critical tasks, and a status checkpoint of the task to be migrated is generated. Based on the status checkpoint of the task to be migrated, the task operation is resumed on the spare heterogeneous computing power unit with the lowest load, and the updated resource allocation and execution instructions are obtained.

[0047] The steps to obtain the basic view of heterogeneous computing pool scheduling are as follows:

[0048] Parse the drone business flow, extract the dependencies between each subtask node and task defined therein, record the name of the subtask node, task type, and dependency edge information one by one, and generate a set of subtask node and dependency edge information;

[0049] Based on the subtask nodes and dependency edge information sets, the performance parameters and execution efficiency parameters of each heterogeneous computing unit are called respectively. The execution time of each subtask node on different heterogeneous computing units is calculated one by one, and the execution time information of each subtask node is recorded one by one and summarized into a set of heterogeneous computing unit execution time information.

[0050] Based on the execution time information set of heterogeneous computing power units, the output data size parameters corresponding to continuous tasks and the network bandwidth parameters between heterogeneous computing power units are called, and the time consumption of data transmission between continuous subtasks is calculated one by one. It is combined with the subtask nodes and dependency edge information set to form a complete task graph structure, generating a basic view of heterogeneous computing power pool scheduling.

[0051] Specifically, the drone business flow is parsed. The business flow is defined in a structured description language (for example, YAML or XML). The file is scanned line by line by a syntax analyzer to automatically identify and extract the subtask nodes marked as "task" and the inter-task dependencies marked as "dependency". For each identified subtask node, the system will extract its unique "name" field as the name of the subtask node and the "type" field as the task type. For example, the task type can be specifically classified as image preprocessing, target detection, path planning or data return, and its input data description and output data description are recorded. For each For each identified dependency edge, the system will record its "source" field and "destination" field, which correspond to the name of the predecessor task and the name of the successor task node respectively, and then organize the extracted information into structured data records, where each subtask node is recorded as a data structure containing the node's unique identifier, node name, and specific task type, and each dependency edge is recorded as a data structure containing the source node identifier and the target node identifier. Finally, all node records and edge records are integrated into a unified set to generate a subtask node and dependency edge information set that contains all subtask node attributes and their interconnected topological relationships.

[0052] Based on the subtask nodes and dependency edge information set, the system first calls the performance parameters and execution efficiency parameters of each heterogeneous computing power unit (such as central processing unit CPU, graphics processing unit GPU, field programmable gate array FPGA) from a pre-built device specification database. The performance parameters include the number of cores of the unit, clock frequency (in GHz), number of floating-point operations per second (GFLOPS) and other hardware indicators. The execution efficiency parameter is a lookup table established through preliminary benchmark tests. The table records the execution efficiency coefficients of different task types on specific computing power units. For example, the efficiency coefficient of a matrix multiplication-intensive target detection task on the GPU is 0.9, and on the CPU it is 0.5. Then, the system traverses each subtask node and selects the subtask node according to its task type and relationship. The computational complexity of the connection (for example, the estimated total number of operations) is combined with the performance parameters and execution efficiency parameters of each heterogeneous computing power unit to calculate its execution time one by one. For example, for a target detection task that requires 10 billion floating-point operations, the execution time on a GPU (with an effective computing power of 500 GFLOPS) is calculated to be 10 billion operations divided by 500 GFLOPS, which is equal to 0.02 seconds, while the execution time on a CPU (with an effective computing power of 20 GFLOPS) is 0.5 seconds. The system performs this calculation for each combination of tasks on each computing power unit, and associates the calculated execution time with the corresponding task identifier and unit identifier. Finally, all these records are aggregated into a two-dimensional matrix of heterogeneous computing power unit execution time information.

[0053] Based on the execution time information set of heterogeneous computing units, first, the output data size parameters associated with each subtask node are called from the drone business flow definition. For example, the output of an image preprocessing task may be an image data of 2MB in size, while the output of a target detection task may be a coordinate list of 10KB in size. At the same time, the system retrieves the network bandwidth parameters between heterogeneous computing units from a preset hardware topology configuration file. The parameters are stored in the form of a bandwidth matrix, which defines in detail the effective rate of data transmission between any two computing units. For example, the bandwidth between the CPU and the integrated GPU through the PCIe bus is 16GB / s, while the bandwidth between two independent digital signal processors (DSPs) through a dedicated link is 1GB / s. If two tasks are in the same computing unit, The system calculates all possible data transmission time consumptions when the two tasks are assigned to different computing units based on the two consecutive subtasks connected to each dependency edge in the task graph. The calculation method is to divide the output data size of the predecessor task by the network bandwidth between the two corresponding computing units. The calculation result forms a transmission time cost set corresponding to the combination of computing units. Finally, this transmission time cost set is integrated with the previously generated subtask node and dependency edge information set and the heterogeneous computing unit execution time information set to jointly construct a complete, weighted directed acyclic graph structure, where the node weight is the execution time vector of the task on each unit, and the edge weight is the time cost set of data transmission between different units, thereby generating a basic view of heterogeneous computing pool scheduling.

[0054] The steps to obtain the task execution priority sequence are:

[0055] Based on the task graph structure in the heterogeneous computing pool scheduling basic view, traverse each subtask node, extract the subtask node number, the corresponding execution time of the node, the direct predecessor task number and the communication delay between the node and the current node, the direct successor task node number and the corresponding execution time, accumulate the sum of the execution time of all subtask nodes, and generate a node topology feature set;

[0056] According to the node topology feature set, the forward-looking key task weight priority value of each subtask node is calculated. The calculation formula is:

[0057] ;

[0058] in, For subtask nodes The forward-looking key task weight priority value, For subtask nodes The set of predecessor task numbers, For the precursor task The forward-looking key task weight priority value, For the predecessor task To the subtask node The data transmission time cost, For subtask nodes The execution time, For subtask nodes The set of successor task numbers of

[0059] is the sum of the execution time of all subsequent tasks, is the sum of the execution time of all subtask nodes in the task graph;

[0060] Based on the forward-looking critical task weight priority value of each subtask node, all subtask nodes are sorted in descending order of the forward-looking critical task weight priority value to generate a task execution priority sequence.

[0061] Specifically, based on the task graph structure in the basic view of heterogeneous computing pool scheduling, the system uses a depth-first or breadth-first traversal algorithm to perform a complete scan of all subtask nodes in the graph. In this process, for each currently accessed subtask node, the system accurately extracts its unique subtask node number from the task graph structure, and calls the average execution time of the node on all heterogeneous computing units calculated in the previous step as its benchmark execution time. At the same time, the system backtracks to find all dependency edges directly pointing to the current node, records the source nodes of these edges, that is, the numbers of the direct predecessor tasks, and extracts the average communication delay recorded on these edges between all computing unit combinations, and then The system continues to explore forward, finding all dependency edges starting from the current node, recording the destination nodes of these edges, that is, the numbers of the direct successor task nodes, and also extracting the average execution time corresponding to these successor nodes. After traversing all nodes and extracting the above information, the system adds up the benchmark execution time of all subtask nodes to obtain a cumulative execution time representing the total computing load of the entire business flow. Finally, the number of each node, the benchmark execution time, the predecessor node list, the communication delay list with the predecessor node, the successor node list, the execution time list of the successor node, and the cumulative execution time of the entire graph are integrated and encapsulated into a structured data set to generate a node topology feature set.

[0062] formula: The benefit of the formula is that by introducing a forward-looking weighting factor , not only considers the latest time to reach the current task (i.e. The system also evaluates the proportion of the computational load of all subsequent subtasks to the total load. This design allows subtasks that are connected to large and time-consuming task chains to receive higher priority weights, allowing them to be prioritized in scheduling decisions. This avoids the problem of short-sightedly executing some locally optimal short tasks first, which causes delays on subsequent longer critical paths and increases the overall task completion time.

[0063] For subtask nodes The forward-looking critical task weight priority value is a comprehensive score used to quantify the scheduling priority of the task. This value is not directly measured, but is recursively calculated based on the topological position of the task in the graph, its own computing cost, and its impact on the subsequent task flow through this formula. For the entry task node without any predecessor task, its priority value calculation is The value of the item is 0.

[0064] For subtask nodes The predecessor task number set is directly extracted from the node topology feature set generated in the previous step, and contains all the predecessor task numbers that must be set in the subtask node. The unique number of the directly upstream task that is completed before the task is started. For example, in a UAV reconnaissance task flow, if the "target recognition" task (numbered 4) must be started after both the "image acquisition" (numbered 2) and the "image preprocessing" (numbered 3) tasks are completed, then the predecessor task number set of task 4 is .

[0065] For the precursor task The forward-looking key task weight priority value is calculated in the direction from the entry node to the exit node after topological sorting the task graph. When the priority value is Priority value All have been calculated and stored and can be directly called. For example, before calculating the priority value of task 4, the priority value of task 2 has been calculated. The priority value of task 3 is 25.5. It is 28.1.

[0066] For the predecessor task To the subtask node The data transmission time cost is obtained from the basic view of heterogeneous computing pool scheduling by converting the predecessor task The output data size is divided by the load of the predecessor task and subtask nodes The average network bandwidth between two computing units is calculated. For example, the output data of task 2 is 5MB, the output data of task 3 is 4MB, and the average communication bandwidth between computing units in the system is tested to be 200MB / s. Second, Second.

[0067] For subtask nodes The execution time here is not for a specific computing unit, but is obtained by extracting the execution time of the task on all available computing units from the execution time information set of heterogeneous computing units and calculating the average value. The average value is used as a representative of the inherent computational complexity of the task. For example, if the execution time of task 4 on the CPU is 0.15 seconds and the execution time on the GPU is 0.05 seconds, then its average execution time is Second.

[0068] For subtask nodes The set of successor task numbers, which contains the tasks from the subtask node Starting from the task graph, all downstream tasks (including direct and indirect successors) that can be reached are collected by subtask nodes. Perform a depth-first search (DFS) or breadth-first search (BFS) traversal on the subgraph of the starting point to determine the number of tasks. For example, if there are two tasks after Task 4, "Threat Assessment" (numbered 5) and "Route Replanning" (numbered 6), and there is no task after Task 5 and no task after Task 6, then the set of successor task numbers for Task 4 is .

[0069] is the sum of the execution time of all subsequent tasks, which is the sum of the execution time of all subsequent tasks. The average execution time of each successor task in ) are accumulated to obtain, for example, if the average execution time of task 5 is The average execution time of Task 6 is 0.20 seconds is 0.25 seconds, then for task 4, the sum of the execution time of all its successor tasks is Second.

[0070] is the sum of the execution time of all subtask nodes in the task graph. This value is directly obtained from the node topology feature set generated in the previous step. It is the cumulative sum of the average execution time of all tasks and represents the total computational workload of the entire business flow. For example, if the entire task graph contains 6 tasks from Task 1 to Task 6, and their average execution time is calculated to be 1.50 seconds, then Second.

[0071] Calculation process:

[0072] To calculate the forward-looking critical task weight priority value of subtask node 4 As an example, substitute the parameter values ​​obtained above:

[0073] , , , , , , , .

[0074] First, calculate the latest time item to reach the current node:

[0075] ;

[0076] ;

[0077] ;

[0078] ;

[0079] Next, calculate the forward-looking weight factor term:

[0080] ;

[0081] ;

[0082] ;

[0083] ;

[0084] Finally, add the two parts together to get the final priority value:

[0085] ;

[0086] The result shows that the forward-looking critical task weight priority value of subtask node 4 is 28.25. This value itself has no physical unit. It is a relative priority score. The higher the value, the more critical the task is in the entire business flow and the higher the scheduling priority.

[0087] Based on the forward-looking critical task weight priority value calculated for each subtask node, the system first constructs a list of two-tuples containing (task number, priority value) by combining the numbers of all subtask nodes with their corresponding priority values. For example, (task 1, 15.2), (task 2, 25.5), (task 3, 28.1), (task 4, 28.25), (task 5, 30.5), (task 6, 32.8). Next, quick sort is called to process this list of two-tuples. The sorting rule is to sort the tasks in descending order based on the second element of each tuple, namely the forward-looking critical task weight priority value. During the sorting process, if two or more subtasks have the same priority value, a preset secondary sorting rule is activated to break ties and ensure the uniqueness and determinism of the sorting result. This secondary rule compares the subtask node numbers of these tasks, and the task with the smaller number is assigned a higher priority. After the sorting is complete, the system discards the priority values ​​in the list and only extracts and retains the sorted subtask node numbers, forming a linear list of task numbers from high priority to low priority. This list is the final generated task execution priority sequence.

[0088] The steps to obtain the initial computing power resource allocation decision are:

[0089] Based on the task execution priority sequence, the task numbers that have met the completion requirements of all predecessor tasks are extracted one by one from the starting position, the status records of the heterogeneous computing units are compared one by one, and the current idle time information of each computing unit is extracted to form the idle time set of the computing unit of the current ready task;

[0090] According to the idle time set of the computing unit of the current ready task, the task execution time parameters, the end time parameters of the corresponding predecessor task, and the data transmission completion time parameters between tasks are called one by one. The task execution time, computing unit idle time, and the data transmission completion time of all predecessor tasks are compared in turn. The largest time value is selected and added to the task execution time value to generate the earliest completion time set corresponding to the current task for each heterogeneous computing unit;

[0091] Based on the earliest completion time set of the current task corresponding to each heterogeneous computing power unit, extract the computing power unit number with the smallest earliest completion time value, assign the current task number to the computing power unit number, and record it as the initial computing power resource allocation decision.

[0092] Specifically, based on the task execution priority sequence, a circular scheduler is started. The scheduler starts from the highest priority position in the sequence and extracts the task numbers one by one. For each extracted task, the system queries all the direct predecessor tasks defined in the heterogeneous computing pool scheduling basic view of the task, and checks them against a real-time updated "completed task list". The list records all completed tasks and their completion time. Only when all the direct predecessor tasks of a task appear in the list, the task is judged to be "ready", and the scheduler will select the first task in the priority sequence. The system selects a task that has reached the ready state as the target task to be assigned. Once the target task is determined, the system will immediately traverse all heterogeneous computing power units (for example, central processing units, graphics processing units, and digital signal processors) and access a dynamically maintained "computing power unit status record table". This table maintains an "estimated idle timestamp" for each computing power unit. The timestamp indicates the exact moment when the unit completes all its currently assigned tasks. The system will extract this timestamp information of each computing power unit one by one and associate it with the corresponding computing power unit number to form the computing power unit idle time set of the current ready task.

[0093] According to the idle time set of the computing unit of the current ready task, the system performs an independent completion time estimation calculation for each heterogeneous computing unit for the target task to be assigned. In each calculation, the system first calls the task execution time parameters required for the target task to be executed on the specific computing unit from the execution time information set of the heterogeneous computing unit. At the same time, the system traverses all direct predecessor tasks of the target task and obtains the actual end time of each predecessor task from the "Completed Task List". Then, the system calls the data transmission time cost between the computing unit where the predecessor task is located and the current estimated computing unit from the heterogeneous computing pool scheduling basic view, and compares the end time of the predecessor task with this transmission time cost. Add them together to get the time point when the data of the predecessor task arrives at the current estimated power unit. The system selects the latest one among all the data arrival time points of the predecessor tasks as the "data ready time". Then, the system compares this "data ready time" with the "estimated idle timestamp" of the current estimated power unit, and selects the larger time value of the two as the "earliest start time" of the task on the unit. Finally, this "earliest start time" is added to the execution time value of the task on the unit to calculate the "earliest completion time" of the task on the computing unit, and summarizes the calculation results of all computing units to generate the earliest completion time set for the current task of each heterogeneous computing unit.

[0094] Based on the earliest completion time set for each heterogeneous computing unit corresponding to the current task, the system scans all (computing unit number, earliest completion time) data pairs in the set and locates the computing unit with the smallest "earliest completion time" value through numerical comparison operations. If multiple computing units have the same earliest completion time, one is selected based on a preset static priority list (for example, units are sorted by energy efficiency ratio, with higher energy efficiency ratios given priority) to break the tie. Once a unique computing unit is selected, the system officially assigns the current target task number to that computing unit number and adds this decision, along with the calculated earliest start time and earliest completion time, as a new allocation record to a global scheduling plan. This plan serves as the initial computing resource allocation decision. Simultaneously, the system immediately updates the "computing unit status record table" by updating the "estimated idle timestamp" of the assigned unit to the earliest completion time of this task assignment. After the task completes, the task information is added to the "completed task list" to provide the latest system status for the next round of task scheduling.

[0095] The steps for obtaining the health status timing flow of the computing power unit are as follows:

[0096] Based on the initial computing power resource allocation decision, extract the numbers of all currently active heterogeneous computing power units, call each heterogeneous computing power unit in turn, obtain the actual operating temperature value and the number of calculation errors in each sampling period, and continuously record the sampling number, operating temperature value, and number of calculation errors to form a sampling set of heterogeneous computing power unit temperature data and error data;

[0097] Based on the temperature data and error data sampling set of heterogeneous computing power units, the dynamic stability perception health score is calculated using the following formula:

[0098] ;

[0099] in,

[0100] ;

[0101] in, The dynamic and stable perceived health score of the heterogeneous computing power unit in the current evaluation cycle, is the total number of sampling rounds in the current evaluation cycle, For the The measured value of the operating temperature of the round sampling, The temperature tolerance baseline value set for heterogeneous computing units, For the The number of calculation errors in the round sampling, The exponential adjustment parameter to control the temperature exponential sensitivity, is the health fluctuation penalty constant, is the standard deviation of the instantaneous health factor, For the The instantaneous health factor of the round sampling, For the Instantaneous health factor of round sampling;

[0102] Based on the dynamic and stable perceived health scores of heterogeneous computing power units in each evaluation cycle, continuous scoring records are organized in sampling time sequence to establish a time series flow of the health status of the computing power units.

[0103] Specifically, according to the initial computing power resource allocation decision, all task allocation entries recorded in the decision are first parsed, and the unique numbers of all heterogeneous computing power units assigned at least one task are extracted. These extracted numbers together constitute the set of heterogeneous computing power units in the current active state. Then, the system starts a periodic monitoring process, which sets a fixed sampling period for each active computing power unit. For example, it is set to 100 milliseconds. At the end of each sampling period, the monitoring process actively queries and obtains the real-time operating temperature of the core of the computing power unit through the board management controller (BMC) or a dedicated sensor interface. The system also checks the error correction code (ECC) controller inside the computing unit, reads and records the total number of new, correctable or uncorrectable calculation errors that have occurred since the last sampling point. Each time a sampling is completed, the system generates a data record containing a unique sampling number (for example, a timestamp since startup), the operating temperature value obtained in the current sampling period, and the number of calculation errors. These records are classified by computing unit number and continuously appended to the storage, thereby gradually forming a comprehensive heterogeneous computing unit temperature data and error data sampling set containing real-time status data of all active computing units.

[0104] formula: ,in, , The benefit of the formula is that it uses Sigmoid function and logarithmic function to perform nonlinear modeling on the two key degradation indicators, temperature and calculation error, respectively, to capture the sharp deterioration trend of the health state of the hardware when it approaches its physical limit. On the other hand, it introduces an exponential penalty term based on the standard deviation of the instantaneous health factor. , so that the health score assessment not only focuses on the average health level, but also penalizes drastic fluctuations in health status. This design can identify computing power units with unstable operating conditions and potential sudden failure risks earlier, even if their average temperature and error rate are still within acceptable ranges, thus achieving a more comprehensive and forward-looking quantitative assessment of the health status of computing power units;

[0105] The total number of sampling rounds in the current evaluation period is pre-set according to the monitoring strategy and defines the amount of data samples used to calculate the dynamic stability perception health score. For example, if the sampling period is 100 milliseconds and the evaluation period is set to 10 seconds, the total number of sampling rounds is wheel.

[0106] For the The measured operating temperature value of the round sampling is directly obtained from the heterogeneous computing unit temperature data and error data sampling set formed in the previous step. The index is obtained, which is a direct physical measurement of the core temperature of the computing unit at a specific moment, in degrees Celsius (°C). For example, during the 50th sampling round, the temperature of a GPU is obtained to be 75°C.

[0107] The temperature tolerance baseline value set for the heterogeneous computing power unit is set based on the maximum safe operating temperature in the technical specifications provided by the chip manufacturer. Usually, 85% to 90% of Tjmax is taken as a reasonable tolerance baseline. For example, if the Tjmax of a GPU is 105℃, its temperature tolerance baseline value can be set. .

[0108] For the The number of calculation errors in the round sampling is also collected from the temperature data and error data sampling set of the heterogeneous computing power unit, according to the number of sampling rounds. The index is obtained, which records the total number of calculation error events reported by the hardware in a sampling period. It is a unitless count value. For example, in the 50th sampling period, the number of calculation errors recorded is 1.

[0109] To control the exponential adjustment parameter of the temperature index sensitivity, this parameter determines the steepness of the health score change with temperature. Its value is set based on experience. By stress testing the computing power unit under different loads, observing the correlation curve between its temperature and performance degradation and error rate increase, a value is selected that can make the Sigmoid function curve drop rapidly when it approaches the temperature tolerance baseline value. Value, implementation example, after testing and analysis, set , so that when the temperature exceeds the tolerance reference value by 5°C, the temperature health factor drops below 0.1.

[0110] is the health fluctuation penalty constant, which is used to adjust the sensitivity of the health score to the instantaneous health factor fluctuation. Its value is also calibrated through experiments. By injecting simulated disturbances of different frequencies and amplitudes (such as instantaneous load spikes) into the normally operating system, the analysis is carried out. The relationship between the change of and the actual stability of the system, set a suitable The value is set so that small, normal fluctuations will not cause a significant drop in the health score, while continuous or severe fluctuations will be significantly punished. For example, setting , in order to exert a significant impact on fluctuations above moderate levels.

[0111] and For the Round and The instantaneous health factor of the round sampling is a snapshot of the health of each sampling point during the evaluation period. Its value is obtained by multiplying the temperature and error rate components and is used in the subsequent calculation of the average health level and volatility.

[0112] is the standard deviation of the instantaneous health factor, which is obtained through statistical calculation and quantifies the instantaneous health factor during the evaluation period. The degree of discreteness or fluctuation amplitude of the sequence is the core indicator for evaluating the operating stability of the computing power unit.

[0113] Calculation process:

[0114] Take a GPU in an evaluation cycle ( ) as an example, the parameters are set as follows: , , .

[0115] First, calculate a round of sampling (for example, The instantaneous health factor of the wheel In this round of sampling, , .

[0116] ;

[0117] ;

[0118] ;

[0119] ;

[0120] The system will perform the above calculations for all 100 rounds of sampling within the evaluation period, and obtain a sequence of 100 instantaneous health factor values. .

[0121] Next, calculate the mean and standard deviation of the sequence. For example, after calculation, the mean value is , the standard deviation is .

[0122] Finally, the dynamic stability perceived health score is calculated :

[0123] ;

[0124] ;

[0125] ;

[0126] The results show that the GPU's dynamically stable perceived health score during the current evaluation cycle is 0.7691, which is lower than the ideal value of 1, reflecting certain health risks for the unit. Specifically, the average instantaneous health factor of 0.85 indicates that its average operating status is acceptable. However, after the exponential penalty of 0.05, the standard deviation lowers the final score from 0.85 to 0.7691, indicating that its operating status has a certain degree of fluctuation, reducing its overall health assessment.

[0127] Based on the dynamic stability-perceived health scores calculated by heterogeneous computing power units in each continuous evaluation cycle, the system maintains an independent data structure for each computing power unit, which stores its historical health score records in chronological order. Each record contains two core fields: the precise timestamp of the end of the evaluation cycle and the dynamic stability-perceived health score value calculated for that cycle. When the new health score calculation is completed, the system appends this new (timestamp, health score) record to the end of the data structure of the corresponding computing power unit. This continuous recording process connects discrete health assessment points into a continuous time series curve, intuitively showing the complete trajectory of the evolution of the health status of each computing power unit over time. Ultimately, these time-sorted health score sequences are organized to establish a computing power unit health status time series stream that can be directly called by subsequent analysis modules.

[0128] The steps to obtain the pre-degradation trigger signal of the computing power unit are as follows:

[0129] Based on the health status time series of the computing power unit, a fixed-step time sliding window is set. The dynamic stability perception health score sequence and the corresponding time index sequence within each sliding window are extracted in chronological order. The start time of each window is marked and all dynamic stability perception health scores are recorded to generate a sliding window health score time series set.

[0130] According to the sliding window health score time series set, the degradation severity index corresponding to each sliding window is calculated using the following formula:

[0131] ;

[0132] in, ;

[0133] in, For the The degradation severity index of a sliding window, is the linear regression slope of the health score over time in the sliding window, The first A dynamic and stable perceived health score, is the average of all dynamic stability perceived health scores within the sliding window, is the number of health score samples in the sliding window, It is the theoretical maximum health score reference value;

[0134] Based on the degradation severity index, when the degradation severity index of any sliding window is greater than the set warning threshold, the end time point of the sliding window is immediately located, and a pre-degradation control signal is output to generate a computing power unit pre-degradation trigger signal.

[0135] Specifically, based on the health status time series stream of the computing power unit, the system applies a time sliding window analysis mechanism for each computing power unit. The width of the sliding window, that is, the number of continuous health score samples included, is set according to the fault feature time scale obtained by analyzing historical fault data. For example, it is set to include 20 continuous dynamic stability perception health score samples. At the same time, a fixed step size is set, for example, the step size is 1 sample, that is, each time a new health score is generated, the window slides forward once. After each slide, the system extracts all dynamic stability perception health scores covered by the current window from the health status time series stream of the computing power unit to form a numerical sequence, and at the same time extracts the time index sequence corresponding to these scores. The time index can be the timestamp of the evaluation period. The system records the start timestamp of the window and the health score sequence in the window as a whole. By continuing this process, the system will generate a series of overlapping window data fragments that evolve over time for each computing power unit. All these fragments are aggregated to generate a sliding window health score time series set.

[0136] formula: ;in, ;

[0137] The benefit of the formula is that it achieves risk warning of the health degradation trend of computing power units by constructing a comprehensive degradation severity index, integrating information from two dimensions: first, through the linear regression slope It captures the rate of change of health score in the short term, that is, the “speed” of degradation; secondly, it is the average health level normalized by To measure the degree to which the current health state deviates from the ideal state, that is, the "position" of degradation, multiply the two and take the negative sign, so that a state that is rapidly declining and already at a lower health level will obtain a very high DSI value, thereby being able to identify high-risk states that are about to fail more sensitively and accurately than simply monitoring the slope or average value;

[0138] is the linear regression slope of the health score over time in the sliding window, which represents the The average rate of change of the dynamic stable perceived health score over time within a sliding window. A negative value indicates a downward trend in the health score. The larger the absolute value, the faster the decline. This slope is calculated by linearly fitting the time index and health score data points within the window using the least squares method.

[0139] The first A dynamic and stable perceived health score, which is directly extracted from the sliding window health score time series set generated in the previous step. It is the first time series in the window. A dynamic and stable perception health score, for example, in a window of size 20, is the first health score at the beginning of the window, is the last health score at the end of the window, which is obtained from the health status timing stream of the computing power unit.

[0140] The average value of all dynamic stability perception health scores in the sliding window, which reflects the average health level of the computing power unit in the current window period. The values ​​are added and divided by the number of samples in the window Calculated.

[0141] The number of health score samples in the sliding window is pre-set and determines the time span of trend analysis. The selection of its value requires a trade-off between response speed and stability of trend judgment. According to experience, for a system with an evaluation period of 10 seconds, setting , that is, analyzing the health data within the last 200 seconds, which can better balance real-time and accuracy.

[0142] The theoretical maximum health score reference value, which represents the health score of the computing power unit under ideal conditions, is based on the dynamic stability perception of the health score. The theoretical maximum value of is 1, so we set .

[0143] Calculation process:

[0144] To calculate the Sliding window degradation severity index For example, the window size , theoretical maximum health score .

[0145] For example, extract the first 20 health score sequences in a window as follows:

[0146] ;

[0147] First, calculate the linear regression slope Required intermediate value:

[0148] ;

[0149] ;

[0150] ;

[0151] ;

[0152] Substitution The calculation formula is:

[0153] ;

[0154] Next, calculate the average health score :

[0155] ;

[0156] Finally, the degradation severity index is calculated :

[0157] ;

[0158] This result shows that in the Within the sliding window, the degradation severity index of this computing power unit is 0.0026.

[0159] Based on the degradation severity index, the system compares each newly calculated index value with a pre-set warning threshold in real time. The setting of the warning threshold is based on the analysis of a large amount of historical normal operation data and known pre-fault data. The specific method is to calculate the degradation severity index of all historical normal operation windows to form a distribution, and then take the 99.9th percentile of the distribution, or the mean plus three times the standard deviation, as a benchmark threshold. For example, by analyzing historical data, the warning threshold is set to 0.005. When the system detects any sliding window of any computing power unit, The calculated degradation severity index, for example, 0.0026 calculated in the previous example, is used. If this value is greater than 0.005, the computing unit is determined to have a significant degradation trend and potential failure risk. The system will immediately lock the sliding window that generates the over-threshold index and accurately locate the end time of the window. Using this time point as the trigger moment, a pre-degradation control signal containing the failure risk unit number and trigger time is output to the system management layer. The generation of this signal marks the official establishment of the computing unit pre-degradation trigger signal, and the subsequent migration and recovery process will be initiated based on this signal.

[0160] The steps to obtain the status checkpoint of the task to be migrated are:

[0161] According to the pre-demotion trigger signal of the computing power unit, the corresponding relationship between tasks and computing power units recorded in the initial computing power resource allocation decision is matched one by one. The computing power unit number corresponding to the pre-demotion signal and the numbers of all currently executed tasks are extracted to form the corresponding relationship between risk units and carrying tasks;

[0162] Based on the correspondence between risk units and tasks, the real-time task status data of the corresponding task number is called one by one, and the memory image at the time of task execution, the instruction execution location, and the current value of the task-related register are recorded one by one to create a copy of the running status of the critical task;

[0163] Based on the running status copies of key tasks, the memory images and register states of all tasks are extracted and marked one by one. The consistency of the memory images and register states is verified and encapsulated to form a status checkpoint of the task to be migrated that can be used for migration and recovery.

[0164] Specifically, based on the fault risk unit number contained in the pre-degradation trigger signal of the computing power unit, the system immediately performs a comprehensive scan and filtering operation on the global initial computing power resource allocation decision. It uses the unit number in the trigger signal as an index to accurately match and filter out all task entries assigned to the risk unit. For each matched entry, the system extracts its corresponding task number and collects these task numbers to form a list of pending tasks. At the same time, the system will also check the current execution status of these tasks, and by querying a real-time task monitoring table, filter out those tasks that have been completed when the trigger signal is generated, and only retain those tasks that are being executed or waiting to be executed in the queue. Finally, the system binds the risk unit number with this filtered list of numbers of all active tasks currently being carried on it to form a clear correspondence between the risk unit and the carried task.

[0165] Based on each task number locked in the risk unit-task mapping, the system immediately sends a state capture instruction to the risk unit hosting these tasks. This instruction triggers a low-level, near-hardware snapshot procedure. For each target task, the procedure first iterates over all memory pages marked as "dirty" in its process space—that is, memory contents that have been modified since the last write to disk—and copies the complete data of these pages into a dedicated memory buffer, forming a memory image at the time the task is running. Next, the procedure reads the value of the program counter (PC) register of the task's current thread. This value precisely points to the memory address of the next machine instruction to be executed, serving as the instruction execution location. At the same time, the procedure also saves the current values ​​of all general registers (for example, EAX and EBX), floating-point registers, and other special registers related to the task context (for example, the stack pointer SP and the base pointer BP). These extracted memory images, instruction execution locations, and register values ​​are recorded as a whole to create a complete copy of the running state for each affected critical task.

[0166] Based on the running state replicas of critical tasks, the system initiates a checkpoint generation program. This program processes each replica one by one. First, it separates the task's memory image and register state data from the replica. Then, the program performs a cyclic redundancy check (CRC32) on the memory image to generate a checksum. This checksum is compared with the memory consistency hash value calculated by the hardware during generation, which may be included in the replica. If the two do not match, the memory image is considered to have been corrupted during the capture process and is marked as an invalid replica. For memory images that pass the checkpoint, the program further checks the legitimacy of the register state. For example, it verifies that the address of the program counter falls within the valid range of the task code segment and that the stack pointer points to a valid stack space, ensuring that all state values ​​are within a reasonable logical range. Only after both the memory image and register state pass these consistency and validity checks does the system encapsulate these two data pieces, along with metadata such as the task's unique identifier and original computing unit number, using a serialization format (for example, Protocol Buffers), to form an independent, atomic, and verified checkpoint of the task state to be migrated, which can be used for migration and recovery.

[0167] The updated steps for resource allocation and execution instruction acquisition are:

[0168] Based on the status checkpoints of the tasks to be migrated, the current number of tasks, the length of the real-time processing queue, and the current resource utilization rate of all standby heterogeneous computing units are extracted one by one. These are accumulated and sorted one by one to obtain the standby heterogeneous computing unit number with the lowest load.

[0169] Based on the number of the standby heterogeneous computing unit with the lowest load, the memory image and register state data stored in the state checkpoint of the task to be migrated are called, and the extracted memory images are loaded one by one into the memory area of ​​the corresponding standby heterogeneous computing unit. The register state data is reloaded in sequence, and the running status of each task is restored one by one to form a restored task running status copy;

[0170] Based on the restored task running status copy, the corresponding relationship between new tasks and computing power units is generated one by one, the computing power resource scheduling record is updated, and the next executable program instruction sequence after the task is restored is generated one by one to form the updated resource allocation and execution instructions.

[0171] Specifically, based on the list of tasks to be migrated contained in the status checkpoint of the tasks to be migrated, the system first selects all non-risky heterogeneous computing power units from the global computing power unit pool, whose dynamic stability perception health score is higher than a preset stability benchmark value (for example, based on historical data statistics, it is set to 0.9, which represents that the unit is in a highly healthy and stable state), to form a candidate set of backup units. Then, for each backup heterogeneous computing power unit in the candidate set, the system accesses the real-time system monitoring interface to synchronously obtain three core load indicators: the total number of currently assigned and executing tasks, the length of tasks waiting to be executed in the processing queue, and a comprehensive resource occupancy rate, which is calculated by analyzing the average CPU core utilization and memory bandwidth utilization in the past second. The system then uses a predefined load evaluation function to combine these three indicators into a comprehensive load score, which is calculated as follows: comprehensive load score = 0.5 × (current number of tasks + queue length) + 0.5 × comprehensive resource occupancy rate, where the weight coefficients are set equal to balance task queuing delays and immediate resource competition. After calculating the comprehensive load scores for all backup units, the system sorts these units in ascending order according to their scores and selects the unit with the lowest score, which is the number of the backup heterogeneous computing power unit with the lowest load.

[0172] Based on the number of the least loaded standby heterogeneous computing unit, the system initiates a task recovery program. This program first requests the operating system or virtual machine manager of the target standby unit to create a new, suspended process execution environment for each task to be migrated. The program then calls each state checkpoint of the task to be migrated one by one, deserializing its stored memory image and register state data from it. For the memory image, the recovery program writes the image data block directly into the virtual address space of the newly created process through a privileged interface, accurately reconstructing the original layout of its code segment, data segment, heap, and stack, and restoring read, write, and execute permissions for each memory page. For the register state data, the program also uses the privileged interface to load the program counter, stack pointer, general registers, and all other architecture-specific register values ​​saved in the checkpoint into the new process's CPU context structure. This process is repeated for each task to be migrated, ensuring that its complete running state is accurately copied to the new computing unit, forming a restored task running state replica that includes all migrated tasks and is ready for activation.

[0173] Based on the restored task's running state replica, the system immediately performs a synchronous update of the global scheduling information. It iterates over each successfully restored task in the replica, extracts its task number, and searches for the corresponding entry in the global computing resource scheduling record. The computing unit number recorded in this entry is updated to the number of the newly selected standby heterogeneous computing unit with the lowest load. The task status field is also updated from "Migrating" to "Recovered," completing the mapping between the new task and the computing unit. Subsequently, the system sends a "resume execution" control instruction to the operating system or virtual machine manager of the standby heterogeneous computing unit hosting these restored tasks. This instruction changes the state of the suspended task process to "Ready," placing it in the scheduler's run queue for that unit. Because the task's program counter and all register states have been accurately reloaded, once the scheduler allocates a CPU time slice to the task, it seamlessly resumes execution from the precise instruction location where it was interrupted. This series of updated scheduling records and the resume execution instructions sent to the standby units together constitute the final updated resource allocation and execution instructions.

[0174] The above are merely preferred embodiments of the present invention and do not limit the present invention in any other form. Any technician familiar with the profession may use the technical content disclosed above to change or modify it into an equivalent embodiment with equivalent changes and apply it to other fields. However, any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. A unified resource pooling management method for multiple computing power sources of a UAV platform, characterized by: The following steps are involved: Analyze drone business flows to obtain subtask nodes and dependency edges, measure the execution time of each subtask on different heterogeneous computing units, calculate the time overhead of data transmission between heterogeneous computing units executing continuous tasks, and build a basic view of heterogeneous computing pool scheduling that includes task graph structure and time overhead; Perform topological sorting based on the task graph structure in the heterogeneous computing power pool scheduling basic view to generate a task execution priority sequence. Based on the task execution priority sequence, traverse the ready tasks and calculate the earliest completion time on each heterogeneous computing power unit. Select the unit with the smallest earliest completion time for assignment, and obtain an initial computing power resource allocation decision. Determine the currently active heterogeneous computing power unit based on the initial computing power resource allocation decision, continuously obtain the operating temperature and computing error rate, calculate the health score, generate a computing power unit health status time series flow, obtain the health score change trend based on the computing power unit health status time series flow, determine the potential failure risk, and establish a computing power unit pre-degradation trigger signal; Locking the risk unit and the critical tasks it carries based on the pre-degradation trigger signal of the computing power unit and the initial computing power resource allocation decision, creating a copy of the running state for the critical task, generating a status checkpoint of the task to be migrated, and resuming the task operation on the spare heterogeneous computing power unit with the lowest load based on the status checkpoint of the task to be migrated, and obtaining updated resource allocation and execution instructions; The steps for obtaining the updated resource allocation and execution instructions are as follows: Based on the status checkpoint of the task to be migrated, the current number of tasks, the length of the real-time processing queue, and the current resource occupancy rate of all standby heterogeneous computing power units are extracted one by one, and the sums and sorts are performed item by item to obtain the number of the standby heterogeneous computing power unit with the lowest load; According to the number of the standby heterogeneous computing power unit with the lowest load, the memory image and register state data stored in the state checkpoint of the task to be migrated are called, the extracted memory images are loaded one by one into the memory area of ​​the corresponding standby heterogeneous computing power unit, and the register state data are reloaded in sequence, and the running state of each task is restored one by one to form a restored task running state copy; According to the restored task running status copy, a new correspondence between tasks and computing power units is generated one by one, the computing power resource scheduling record is updated, and the next executable program instruction sequence after the task is restored is generated one by one to form updated resource allocation and execution instructions.

2. The unified resource pooling management method for multiple computing power sources of a UAV platform according to claim 1 is characterized in that: The steps for obtaining the basic view of heterogeneous computing power pool scheduling are as follows: Parse the drone business flow, extract the dependencies between each subtask node and task defined therein, record the name of the subtask node, task type, and dependency edge information one by one, and generate a set of subtask node and dependency edge information; Based on the subtask nodes and dependency edge information sets, the performance parameters and execution efficiency parameters of each heterogeneous computing unit are called respectively. The execution time of each subtask node on different heterogeneous computing units is calculated one by one, and the execution time information of each subtask node is recorded one by one and summarized into a set of heterogeneous computing unit execution time information. Based on the execution time information set of the heterogeneous computing power units, the output data size parameters corresponding to the continuous tasks and the network bandwidth parameters between the heterogeneous computing power units are called, and the time consumption of data transmission between continuous subtasks is calculated one by one. It is combined with the subtask nodes and dependency edge information sets to form a complete task graph structure, and generate a basic view of heterogeneous computing power pool scheduling.

3. The unified resource pooling management method for multiple computing power sources of a UAV platform according to claim 1 is characterized in that: The steps for obtaining the task execution priority sequence are: Based on the task graph structure in the heterogeneous computing power pool scheduling basic view, traverse each subtask node, extract the subtask node number, the execution time corresponding to the node, the direct predecessor task number and the communication delay between the node and the current node, the direct successor task node number and the corresponding execution time, accumulate the sum of the execution time of all subtask nodes, and generate a node topology feature set; According to the node topology feature set, the forward-looking key task weight priority value of each subtask node is calculated using the following formula: in, For subtask nodes The forward-looking key task weight priority value, For subtask nodes The set of predecessor task numbers, For the precursor task The forward-looking key task weight priority value, For the predecessor task To the subtask node The data transmission time cost, For subtask nodes The execution time, For subtask nodes The set of successor task numbers of is the sum of the execution time of all subsequent tasks, is the sum of the execution time of all subtask nodes in the task graph; Based on the forward-looking critical task weight priority value of each subtask node, all subtask nodes are sorted in descending order of the forward-looking critical task weight priority value to generate a task execution priority sequence.

4. The unified resource pooling management method for multiple computing power sources of a UAV platform according to claim 1 is characterized in that: The steps for obtaining the initial computing power resource allocation decision are as follows: Based on the task execution priority sequence, the task numbers that have currently met the completion requirements of all predecessor tasks are extracted one by one from the starting position, the status records of the heterogeneous computing power units are compared one by one, the current idle time information of each computing power unit is extracted, and the idle time set of the computing power unit of the current ready task is formed; According to the idle time set of the computing unit of the current ready task, the task execution time parameters and the end time parameters of the corresponding predecessor tasks and the data transmission completion time parameters between tasks are called one by one, and the task execution time, the computing unit idle time and the data transmission completion time of all predecessor tasks are compared in turn. The largest time value is selected and added to the task execution time value to generate the earliest completion time set corresponding to the current task of each heterogeneous computing unit; Based on the earliest completion time set of the current task corresponding to each heterogeneous computing power unit, extract the computing power unit number with the smallest earliest completion time value, assign the current task number to the computing power unit number, and record it as the initial computing power resource allocation decision.

5. The unified resource pooling management method for multiple computing power sources of a UAV platform according to claim 1 is characterized in that: The steps for obtaining the health status timing flow of the computing power unit are: Based on the initial computing power resource allocation decision, extract the numbers of all currently active heterogeneous computing power units, call each heterogeneous computing power unit in turn, obtain the actual operating temperature value and the number of calculation errors in each sampling period, continuously record the sampling number, operating temperature value and the number of calculation errors, and form a sampling set of heterogeneous computing power unit temperature data and error data; Calculate the dynamic stability perception health score based on the temperature data and error data sampling set of heterogeneous computing power units; Based on the dynamic and stable perceived health scores of heterogeneous computing power units in each evaluation cycle, continuous scoring records are organized in sampling time sequence to establish a time series flow of the health status of the computing power units.

6. The unified resource pooling management method for multiple computing power sources of a UAV platform according to claim 1 is characterized in that: The steps for obtaining the pre-degradation trigger signal of the computing power unit are as follows: Based on the health status time series flow of the computing power unit, a time sliding window with a fixed step size is set, and the dynamic stability perception health score sequence and the corresponding time index sequence in each sliding window are extracted in chronological order. The start time of each window is marked and all dynamic stability perception health scores are recorded to generate a sliding window health score time series set; Calculating a degradation severity index corresponding to each sliding window according to the sliding window health score time series set; Based on the degradation severity index, when the degradation severity index of any sliding window is greater than the set warning threshold, the end time point of the sliding window is located, and a pre-degradation control signal is output to generate a computing power unit pre-degradation trigger signal.

7. The unified resource pooling management method for multiple computing power sources of a UAV platform according to claim 1 is characterized in that: The steps for obtaining the status checkpoint of the task to be migrated are: According to the pre-demotion trigger signal of the computing power unit, the corresponding relationship between tasks and computing power units recorded in the initial computing power resource allocation decision is matched one by one, the computing power unit number corresponding to the pre-demotion signal and the numbers of all currently executed tasks are extracted, and the corresponding relationship between risk units and carrying tasks is formed; Based on the correspondence between the risk unit and the task it carries, the real-time task status data of the corresponding task number is called one by one, and the memory image at the time of task execution, the instruction execution location, and the current value of the task-related register are recorded one by one to create a running status copy of the critical task; Based on the running status copy of the critical task, the memory image and register status of all tasks therein are extracted and marked one by one, the consistency of the memory image and register status is verified and encapsulated to form a status checkpoint of the task to be migrated that can be used for migration recovery.

Images