Distributed execution system for edge tasks based on terminal idle computing power

Abstract

The application relates to the technical field of data processing, in particular to an edge task distributed execution system based on terminal idle computing power, which comprises a cloud platform, a directory generation module, a matching module, a scheduling module, a task migration module and a local scheduling engine. The application maps original computing power information of a heterogeneous terminal into a value that can be uniformly compared by constructing a computing power unit value standardization measurement, establishes a calculable mapping relationship by using a similarity matching algorithm based on a feature vector, and effectively solves the problem that a large amount of terminal idle computing power resources cannot be converged and utilized, thereby causing low overall computing power network resource utilization, by combining a global power consumption prediction model with a terminal local dynamic threshold determination, relying on periodic progress synchronization and state monitoring, and effectively organizing and scheduling the terminal as a computing power supply party in addition to regarding the terminal as a computing task unloading party.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an edge task distributed execution system based on the idle computing power of a terminal. Background Technology

[0002] With the continuous surge in the number of connected IoT devices globally and the rapid growth in demand for real-time intelligent computing at the edge, a large number of 4G / 5G communication terminals with built-in basic computing power, such as CPEs, Dongles, and portable WiFi, are undertaking primary communication functions, but their built-in processor computing power resources have long been severely idle, forming a massive but extremely dispersed, heterogeneous, and ineffective "silent computing power" resource pool. At the same time, scenarios such as industrial inspection and urban governance have increasingly urgent needs for low-latency, high-concurrency distributed computing. Traditional centralized cloud computing and edge scheduling models oriented towards standard servers are unable to cope with this fundamental mismatch between resources and demands—that is, how to efficiently, stably, and sustainably organize and schedule the massive, heterogeneous, dynamic, and resource-constrained fragmented computing power of terminals to meet the needs of large-scale edge intelligent tasks has become a key challenge driving the development of computing power networks into the terminal.

[0003] Chinese Patent Publication No. CN115915276A discloses an online scheduling device and method for energy-constrained terminal tasks based on edge computing. The device includes: a terminal task offloading model and an energy harvesting model, a service function caching model, a task edge computing model, and an online problem-solving algorithm module. Its features are: the terminal task offloading model and energy harvesting model are responsible for describing a renewable energy harvesting model for energy-constrained IoT terminals, a wireless communication time calculation module between the IoT terminal and the edge computing server deployed on a 5G micro base station, and a task offloading decision calculation module for the IoT terminal; the service function caching model is responsible for constructing a model describing the edge computing server deployed on a 5G micro base station. The system includes: a cache capacity limit calculation module for the computing server and a service cache decision calculation module; a task edge computing model module, which describes the processing time of computing tasks offloaded from IoT terminals by the edge computing server, and constructs a long-term average communication and computing energy consumption and communication and computing latency weighted and minimized objective function based on the terminal task offloading model and the service function caching model; and an online problem-solving algorithm module, which, based on the constructed long-term average IoT terminal communication and computing energy consumption minimization optimization function, applies the Lyapunov optimization method to decouple the multi-timeslot stochastic optimization problem into a single-timeslot deterministic problem, and iteratively obtains the optimal solution of the single-timeslot problem based on the Lagrange dual subgradient method.

[0004] Therefore, the existing technology has the following problems: The core optimization goal of the device is to offload terminal tasks to edge servers to minimize terminal energy consumption, completely ignoring the potential of the terminal's own computing power to be aggregated and utilized as a resource, which easily leads to insufficient elasticity of overall computing power supply and structural waste of resources; The device relies on an architecture that makes centralized optimization decisions on edge servers, which is difficult to adapt to the scalability requirements required for real-time scheduling of massive, highly dynamic IoT terminals. Summary of the Invention

[0005] To address this, the present invention provides an edge task distributed execution system based on idle terminal computing power. This system overcomes the problem in the prior art where the massive idle terminal computing power resources cannot be aggregated and utilized, resulting in low overall computing power network resource utilization, because the prior art only treats the terminal as a computing task offloading party and fails to effectively organize and schedule it as a computing power supplier.

[0006] To achieve the above objectives, the present invention provides an edge task distributed execution system based on idle computing power of a terminal, comprising:

[0007] A cloud platform is used to standardize computational tasks to be executed into several task descriptors containing task feature vectors;

[0008] The directory generation module is used to generate standardized computing power unit values ​​and aggregate them based on the raw computing power information reported by each execution terminal in real time, through a preset conversion model, in order to generate a computing power pool directory.

[0009] The matching module is used to extract terminal feature vectors from the computing pool directory based on the task descriptor, calculate the matching similarity between the terminal feature vectors and the task feature vectors, and generate a candidate terminal list and a corresponding preliminary task splitting scheme according to the matching similarity.

[0010] The scheduling module is used to call the corresponding power consumption model according to the power supply type of each candidate terminal in the candidate terminal list, predict the execution power consumption of the candidate terminal after executing the preliminary task splitting scheme, and eliminate a number of execution terminals with excessive power consumption according to the comparison result of the execution power consumption and the preset power consumption threshold, so as to form a task allocation instruction set.

[0011] The task migration module is used to select a backup terminal from the computing power pool directory based on the computing power unit value of the corresponding execution terminal when the execution terminal is detected to be faulty, and send the fault breakpoint information and context to the backup terminal to continue the computing task.

[0012] A local scheduling engine is used to determine the real-time load and execution power consumption of each execution terminal based on the task allocation instruction set, and add the computing task to the local queue for execution after the determination is passed.

[0013] Furthermore, the directory generation module includes:

[0014] The data receiving unit is used to receive the running status data periodically reported by the execution terminal, which includes raw CPU utilization and memory bandwidth information;

[0015] A unit value calculation unit is used to calculate the computing power unit value based on the original computing power information and the operating status data, using the preset conversion model.

[0016] The directory generation unit is used to aggregate the computing power unit value with the geographical location and network status of the execution terminal to generate the computing power pool directory.

[0017] Furthermore, the matching module includes:

[0018] The task feature extraction unit is used to extract the task computing power requirement, task latency requirement and task type code from the task descriptor.

[0019] The terminal feature extraction unit is used to extract computing unit values, historical average response latency, and geographical or network distance to the task data source from the computing power pool directory.

[0020] A similarity calculation unit is used to construct the task feature vector into a first vector, construct the terminal feature vector into a second vector, and calculate the cosine similarity between the first vector and the second vector to obtain the matching similarity.

[0021] Furthermore, the scheduling module is also used to generate a globally unique subtask identifier and a corresponding progress synchronization interface for each subtask in the task allocation instruction set, and to send the subtask identifier and the progress synchronization interface along with the task allocation instruction set to the corresponding execution terminal.

[0022] Furthermore, the local scheduling engine includes:

[0023] The feasibility determination unit is used to predict the execution power consumption based on the task allocation instruction set, the real-time status data of the execution terminal and its built-in power consumption model consistent with the scheduling module, and compare the prediction result with the local dynamic threshold to obtain the comparison result.

[0024] The task queue management unit is used to add the computation task to the local queue for execution after the comparison result is deemed as passing the local feasibility determination.

[0025] Furthermore, the feasibility determination unit includes:

[0026] The data acquisition subunit is used to collect the CPU utilization, power supply type and remaining battery power of the execution terminal in real time.

[0027] The power consumption prediction subunit is used to predict the execution power consumption that will be generated when executing the subtask based on the subtask computing power requirements in the task allocation instruction set, the computing power unit value of the execution terminal, the CPU utilization rate, and the power supply type, by calling the power consumption model.

[0028] The threshold comparison subunit is used to determine the local dynamic threshold based on the power supply type and the remaining battery power, and to compare the computing power unit value with the subtask computing power requirement and the execution power consumption with the local dynamic threshold to obtain the comparison result.

[0029] Furthermore, the threshold comparison subunit is used to set a first reference threshold as the local dynamic threshold when the power supply type is plug-in power supply, and to set a second reference threshold lower than the first reference threshold when the power supply type is battery power supply, and to select a corresponding dynamic adjustment coefficient according to the preset power range in which the remaining battery power is located, and to use the product of the second reference threshold and the dynamic adjustment coefficient as the local dynamic threshold.

[0030] Furthermore, the task queue management unit is used to determine that the comparison result is a local feasibility judgment when the computing power unit value is greater than or equal to the computing power requirement of the subtask and the execution power consumption is less than the local dynamic threshold, and to insert the corresponding subtask into the local queue according to priority to wait for execution, and start the task execution process.

[0031] Furthermore, the task migration module includes:

[0032] A fault monitoring unit is used to monitor and determine the abnormal state of each of the execution terminals in order to identify a number of faulty terminals.

[0033] A backup terminal selection unit is used to select the idle execution terminal in the computing power pool directory with the smallest difference between the computing power unit value of the faulty terminal and the execution terminal as the backup terminal.

[0034] The migration unit is used to send the subtask identifier, real-time progress breakpoint, and complete task context data packet corresponding to the faulty terminal to the backup terminal.

[0035] Furthermore, the fault monitoring unit includes:

[0036] The heartbeat timeout determination subunit is used to determine that a communication abnormality has occurred and to identify the execution terminal as the faulty terminal when no progress report is received from the execution terminal through the progress synchronization interface within a preset first time window.

[0037] The performance anomaly determination subunit is used to determine that a performance anomaly has occurred and to identify the execution terminal as the faulty terminal when the CPU utilization of the execution terminal in the progress report continuously exceeds the safety threshold corresponding to its model.

[0038] The behavior anomaly determination subunit is used to determine that the execution terminal is the faulty terminal when the task execution progress of the execution terminal has no progress within a preset reporting period of a preset number of consecutive determinations.

[0039] Compared with existing technologies, the beneficial effects of this invention are as follows: By constructing a standardized metric for computing power unit values, the original computing power information of heterogeneous terminals is mapped into uniformly comparable values, laying a precise quantitative foundation for upper-layer scheduling; based on this, the system adopts a feature vector-based similarity matching algorithm to establish a computable mapping relationship between task requirements and multi-dimensional attributes of terminal capabilities such as computing power, latency, and location, thereby improving the accuracy and efficiency of task allocation; furthermore, by combining a global power consumption prediction model with terminal local dynamic threshold determination, the system pursues optimal overall energy efficiency while respecting… The system ensures that each terminal operates within physical constraints based on its power supply type and real-time power level, preventing equipment instability caused by overload. Finally, relying on periodic progress synchronization and status monitoring, the fault migration mechanism can select the most suitable successor in a dynamically changing network environment based on the latest progress breakpoint and terminal computing power status, ensuring the ultimate reliability of complex task execution. This effectively solves the problem of low overall computing power network resource utilization caused by the failure to effectively organize and schedule massive amounts of idle terminal computing power resources due to the fact that terminals are only regarded as offloading computing tasks and not as computing power providers.

[0040] Furthermore, by fusing dynamic parameters reflecting the instantaneous load of the terminal with a static benchmark of its inherent performance, a precise and normalized measurement of heterogeneous computing power is achieved. This process essentially maps discrete physical observations into continuous and comparable computing power units. Then, by aggregating this standardized computing power unit with the terminal's spatial location attributes and the network state changing over time in real time, the module constructs a multi-dimensional, high-fidelity dynamic resource topology view. This not only enables upper-layer scheduling to make decisions based on precise quantified computing power supply and real-time network reachability, but more importantly, it unifies the three major physical constraints of computing, communication, and space into scheduling considerations. This allows task allocation to simultaneously meet the requirements of computing power matching, low-latency transmission, and geographical relevance, thereby fundamentally improving the efficiency, reliability, and resource utilization of large-scale distributed computing power resource scheduling.

[0041] Furthermore, by quantifying and vectorizing the multidimensional requirements of tasks on computing resources, time constraints, and inherent types such as computing power, latency, and encoding, and mapping them one-to-one with the inherent processing capabilities, historical performance, and network topology of the terminals, a unified mathematical model for measuring task requirements and terminal supply is constructed. A cosine similarity algorithm is used to calculate the directional consistency of the two in the multidimensional feature space. Essentially, this assesses the overall alignment of the task requirement vector and the terminal capability vector across various mutually constraining physical dimensions, rather than matching a single indicator. This mechanism ensures that scheduling decisions automatically balance the inherent coupling between computational intensity, time sensitivity, and data transmission costs. Mathematically, this guarantees that the selected terminal set not only meets the computing power requirements but also achieves optimal synergy with the task characteristics in terms of historical reliability, network proximity, and overall task allocation in complex heterogeneous environments. Ultimately, this significantly improves the overall efficiency and success rate of task allocation.

[0042] Furthermore, by assigning each atomic computing unit a globally unique identifier generated based on a random algorithm through the scheduling module, the precise differentiation and unambiguous tracking of the execution state of the quantum task in a distributed asynchronous environment are ensured from an information theory perspective. Simultaneously, the standardized progress synchronization interface created with this identifier as the addressing core essentially establishes an independent, reliable, and addressable state feedback channel for each task instance. This transforms the originally black-box, discrete terminal execution process into a white-box, continuously observable streaming state sequence, thereby upgrading task lifecycle management from coarse-grained result waiting to fine-grained process control. This not only provides the upper-layer system with a basis for real-time fault tolerance and dynamic load balancing decisions, but more importantly, by tightly integrating the physical world's computing tasks with the information world's state mapping through identifiers and interfaces, it lays the foundation for building a distributed computing system with high observability, interveneivity, and eventual consistency.

[0043] Furthermore, by embedding a power consumption model consistent with the upper-layer scheduling module within the feasibility determination unit, the system ensures that energy consumption assessment follows the same set of calculation rules based on chip physical characteristics throughout the process from global planning to local execution. This avoids decision conflicts caused by model bias at the source. Simultaneously, the introduced local dynamic threshold is strongly correlated with the terminal's real-time power supply capacity, heat dissipation conditions, and battery chemical state, ensuring that the final determination integrates theoretical predictions with the immediate constraints of physical hardware. The task queue management unit's orderly acceptance of tasks after successful determination essentially provides a buffer and scheduling layer for unpredictable instantaneous load fluctuations, allowing terminals to autonomously arrange the usage sequence of their idle computing power without affecting core functions. This mechanism tightly couples macroscopic scheduling instructions with microscopic device states, enabling each terminal to intelligently participate in global computing power collaboration while ensuring its own stable operation. This fundamentally resolves the contradiction between individual reliability and overall efficiency in distributed computing, achieving a synergistic improvement in system robustness and resource utilization.

[0044] Furthermore, by standardizing the ratio of subtask computing power requirements to the terminal's specific computing power capacity, the task load is transformed into a theoretical utilization rate of CPU computing resources. This transformation establishes a quantitative bridge from application layer instructions to hardware layer load. Then, by calling a power consumption model calibrated based on chip physical characteristics, this unit couples and analyzes three types of dynamic and static parameters: theoretical computing power utilization, real-time CPU load, and power supply circuit characteristics. This accurately predicts the incremental power consumption that will be triggered by executing the subtask. This process profoundly reflects the semiconductor physics-based mapping relationship between computational load and energy consumption. Finally, the threshold comparison subunit dynamically generates a local power consumption threshold based on the real-time power consumption reflecting the device's energy state and the power supply type that determines the heat dissipation boundary, and compares the predicted power consumption with this threshold. This mechanism essentially weighs the computational benefits of the task against the safe operating costs of the device under the current energy state and heat dissipation conditions in real time. This allows the terminal to make autonomous and precise admission decisions based on its instantaneous, multi-dimensional physical state, ensuring at the atomic level that every computing power sharing does not sacrifice device stability and user experience, achieving a micro-unity of global efficiency and terminal autonomy in distributed scheduling.

[0045] Furthermore, by identifying the essential differences in terminal power supply methods—namely, abundant energy supply but limited by heat dissipation when plugged in, and limited total energy and the need to consider discharge curve characteristics when battery powered—differentiated benchmark threshold setting principles were established. Even further, in battery powered scenarios, by mapping the remaining battery charge—a physical quantity reflecting the state of chemical energy storage—to a linear dynamic adjustment coefficient, the local power consumption threshold can exhibit a step-like or continuous decay as the charge decreases. Essentially, this incorporates the battery's discharge characteristics and safe operating boundaries into the real-time decision-making model. This ensures that when allocating computing power tasks to battery-powered devices, the system can automatically and pre-adjust the acceptable power consumption limit based on the device's current energy reserve level. This proactively avoids unexpected device shutdowns or battery damage caused by over-discharge, fundamentally guaranteeing the terminal's battery life and hardware lifespan during computing power sharing, and achieving refined and adaptive management of the energy status of heterogeneous terminals.

[0046] Furthermore, by setting both computing power sufficiency and power safety as dual prerequisites for tasks to enter the execution queue, and performing final verification before insertion, a final line of defense is constructed in the process to ensure the stable operation of the terminal itself. The local queue is organized using a min-heap data structure with priority as the key value, so that task scheduling can strictly follow the preset urgency order. This is essentially an optimal sorting of discrete task requests on the timeline, thereby ensuring that critical computing is always responded to first. In conjunction with the thread management mechanism of the underlying operating system, execution threads are dynamically woken up or requested according to the queue load, realizing elastic matching and on-demand supply between computing resources and tasks to be processed. This allows the terminal to maintain absolute control over its own resources under complex dynamic loads, ensuring that it can execute external computing tasks efficiently and orderly, and at any time prioritize the smoothness and responsiveness of its own core functions. Ultimately, a precise balance and seamless collaboration between external computing power sharing and internal service stability is achieved.

[0047] Furthermore, by establishing anomaly monitoring mechanisms across three dimensions—communication, performance, and behavior—a three-dimensional fault perception network is constructed from three fundamental levels: network connectivity, hardware load sustainability, and computing process activity. The judgment threshold for each dimension is set based on inherent rules at the corresponding physical or logical level. When a failure is detected in any dimension, the module immediately triggers a migration process and selects a backup terminal based on the principle of "minimum difference in computing power unit value." This principle essentially aims to reconstruct a computing environment and performance expectations similar to the original terminal on a new physical node to the greatest extent possible, ensuring the continuity and efficiency of task execution. This design enables the system to transform sporadic, heterogeneous node failure events into a predictable and manageable standardized recovery process. This not only significantly reduces the risk of a single node failure to the global task, but more importantly, by deeply embedding fault-tolerant logic into the scheduling system, it endows the large-scale distributed computing network with damage localization and self-healing capabilities similar to those of a living organism, thereby constructing a highly reliable task execution guarantee in a dynamic and unreliable terminal network environment. Attached Figure Description

[0048] Figure 1 This is a schematic diagram of the edge task distributed execution system based on the idle computing power of the terminal in this embodiment;

[0049] Figure 2 This is a schematic diagram of the catalog generation module in this embodiment;

[0050] Figure 3 This is a schematic diagram of the matching module in this embodiment;

[0051] Figure 4 This is a schematic diagram of the local scheduling engine in this embodiment. Detailed Implementation

[0052] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

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

[0054] Please see Figure 1 As shown, this is a schematic diagram of an edge task distributed execution system based on idle computing power of a terminal in this embodiment. This embodiment provides an edge task distributed execution system based on idle computing power of a terminal, including:

[0055] Cloud platform 1, which is used to standardize the computing tasks to be executed into several task descriptors containing task feature vectors;

[0056] The catalog generation module 2 is connected to the cloud platform. It is used to generate standardized computing power unit values ​​and aggregate them based on the raw computing power information reported by each execution terminal in real time, through a preset conversion model, in order to generate a computing power pool catalog.

[0057] Matching module 3, which is connected to the cloud platform and the directory generation module respectively, is used to extract terminal feature vectors from the computing pool directory based on the task descriptor, calculate the matching similarity between the terminal feature vectors and the task feature vectors, and generate a candidate terminal list and a corresponding preliminary task splitting scheme according to the matching similarity.

[0058] The scheduling module 4, which is connected to the matching module, is used to call the corresponding power consumption model according to the power supply type of each candidate terminal in the candidate terminal list, predict the execution power consumption of the candidate terminal after executing the preliminary task splitting scheme, and remove the corresponding execution terminal when the execution power consumption is greater than the preset power consumption threshold, so as to form a task allocation instruction set.

[0059] The task migration module 5 is connected to the directory generation module and the scheduling module respectively. When the execution terminal failure is detected, it selects a backup terminal from the computing power pool directory based on the computing power unit value of the corresponding execution terminal, and sends the failure breakpoint information and context to the backup terminal to continue the computing task.

[0060] The local scheduling engine 6 is connected to the scheduling module and the task migration module respectively. It is used to make a local feasibility determination on the real-time load and execution power consumption of each execution terminal based on the task allocation instruction set, and add the computing task to the local queue for execution after the determination is passed.

[0061] In this embodiment, the edge task distributed execution system physically comprises three layers, from top to bottom:

[0062] The cloud platform layer, deployed in a remote data center or public cloud, consists of a cluster of high-performance servers. As the system's global management hub and task deployment entry point, it logically does not directly connect to terminals, but communicates with one or more edge schedulers in the lower layer via a wide area network.

[0063] The edge scheduling layer consists of distributed edge schedulers, each physically deployed in a network location closer to the terminal, such as an operator's base station, a campus core gateway, or a regional data center. It connects to the cloud platform layer via fiber optic cable or dedicated line, and to the terminals it manages via a local area network or 4G / 5G mobile network, forming a regional computing power management node with a coverage radius of approximately 1-10 kilometers.

[0064] The terminal execution layer consists of a massive number of heterogeneous IoT communication execution terminals, including but not limited to CPE, Dongle, DTU, and portable WiFi devices. These terminals, as providers of computing resources and the final executors of tasks, access the network wirelessly or via wired means and register with the nearest edge scheduler within their respective network areas.

[0065] In this embodiment, a secure encrypted channel, such as a TLS-based VPN, is established between the cloud platform and the edge scheduler. The cloud platform is responsible for receiving external computing task requests and standardizing them. The standardized task descriptors are then sent to the edge scheduler in the target area through this channel. Conversely, the edge scheduler aggregates and reports data such as task execution results and computing pool status statistics to the cloud platform. The edge scheduler integrates a directory generation module, a matching module, a scheduling module, and a task migration module. These modules interact with each other through an internal bus or software interface, forming the core of the regional scheduling. The directory generation module periodically receives status data reported by all registered execution terminals within its jurisdiction via a wireless network; the task allocation instruction set generated by the scheduling module is also sent to the corresponding terminal via the network. The execution terminal embeds a local scheduling engine. This engine interacts directly with the terminal's hardware performance counters, power management unit, and network stack through the terminal operating system kernel driver interface to collect data and perform execution control. The local scheduling engine receives instructions, reports status, and exchanges data with the corresponding module in the edge scheduler through the network communication stack on the device.

[0066] In this embodiment, the computing power unit value is a standardized value used to uniformly measure the computing power of heterogeneous terminals. It is generated as follows: the directory generation module and the heterogeneous computing power conversion module built into the terminal convert the raw computing power information reported by the terminal, such as chip model, clock speed, and number of cores, into a value in units of "CU" using a preset conversion model. The preset conversion model in this embodiment is: Computing power unit value = (Chip baseline DMIPS value × Dynamic calibration coefficient) / 100, where the dynamic calibration coefficient is obtained by comprehensively considering factors such as CPU utilization and memory bandwidth usage. The preset conversion model can be established through the following steps: by running standard testing programs such as Dhrystone, the baseline DMIPS value of each chip model is actually measured or obtained from an authoritative database; the computing power unit value is defined as a standard computing power, for example, 1CU = 100 DMIPS. Based on this, a basic conversion is established: basic computing power unit value = baseline DMIPS value / 100; the dynamic calibration coefficient is a real number between 0.5 and 1.2, which is obtained by monitoring the real-time performance data of the terminal and using a linear or nonlinear regression model. In this embodiment, the dynamic calibration coefficient = a × (1 - CPU utilization) + b × (1 - memory bandwidth utilization) + c, where a and b are weights obtained by training with historical data, and c is a constant term obtained by training with historical data.

[0067] In this embodiment, the task descriptor is a data structure generated by the cloud platform that provides a standardized description of the computing task. It includes at least the following fields: a globally unique task ID, the total computing power requirement per CU, the maximum allowable latency, the task type encoding (e.g., video decoding, AI inference, data encryption), the input data source address, and a derived task feature vector. This feature vector is a multi-dimensional array used for quantitative comparison during the matching process. The computing power pool directory is a dynamic database maintained by the edge scheduler, serving as the core basis for its scheduling decisions within the region. Each record corresponds to a registered terminal, and its fields include at least: terminal ID, real-time computing power unit value, real-time network status (e.g., latency, packet loss rate), geographical location information, power supply type, remaining battery power, and a terminal feature vector extracted from historical data. Matching similarity refers to the quantified value of the fit between the task requirements and the terminal capabilities, calculated by the matching module using an algorithm. In this embodiment, this is achieved by vectorizing the task feature vector and the terminal feature vector and calculating their cosine similarity. The calculation result is a scalar between 0 and 1, with a larger value indicating a higher degree of matching. Local feasibility determination is a crucial step in granting terminal autonomy. When the local scheduling engine receives a task allocation instruction, its feasibility determination unit does not execute immediately. Instead, it first predicts the power consumption increment that will be generated by executing the task based on the terminal's real-time load and power consumption model, such as instantaneous CPU utilization, and compares it with a local dynamic threshold dynamically calculated based on power supply type and power consumption. Only when the predicted power consumption is lower than the threshold and the local idle computing power meets the requirements is the determination "passed," and the task is added to the execution queue. This mechanism ensures that scheduling decisions do not impair the stability of the terminal itself or the user experience. Fault breakpoint information refers to the key data used by the task migration module to resume the task when the terminal fails. It originates from the encrypted progress report periodically reported by the faulty terminal through the progress synchronization interface during task execution. This information includes at least the subtask identifier, the precise percentage or checkpoint number in the overall task progress, and the partial calculation results generated up to the breakpoint.

[0068] In this embodiment, the power consumption model is constructed based on the inherent electrical characteristics of the terminal chip and the dynamic load during operation, specifically represented by a calculable mathematical formula. The core parameters of this model are obtained through experimental calibration: for each type of execution terminal, in a laboratory environment, the steady-state power consumption under different stable computing loads is measured using precision power monitoring equipment, and the corresponding CPU utilization is recorded; subsequently, linear regression methods such as least squares are used to fit the collected data points, thereby obtaining the key static and dynamic power consumption coefficients in the power consumption model of that terminal model. During system operation, when the scheduling module or local scheduling engine predicts the execution power consumption of a task, it calls the calibrated model corresponding to the target terminal of that task. During prediction, the model uses the computing unit value requested by the task as the core input variable, substitutes it into the linear formula for calculation, and its output is the predicted execution power consumption value. This model, by mapping the computing task requirements to concrete and measurable energy consumption, provides a quantitative decision-making basis for the system to perceive and constrain power consumption during scheduling and execution.

[0069] The preset power consumption threshold is a dynamic threshold value used to determine whether a terminal can safely carry computing power tasks. It depends on the thermal design power consumption of the terminal chip and the output capability of the real-time power supply circuit. It is usually set between 50% and 90% of the terminal's maximum sustainable safe power consumption. In this embodiment, it is set to 70% of the terminal model's nominal TDP. This can maximize the terminal's computing power contribution potential while ensuring the long-term stable operation of the terminal hardware, and at the same time reserve a safety margin for instantaneous computing loads.

[0070] By constructing a standardized metric for computing power unit values, the raw computing power information of heterogeneous terminals is mapped into uniformly comparable values, laying a precise quantitative foundation for upper-layer scheduling. Based on this, the system employs a feature vector-based similarity matching algorithm to establish a computable mapping relationship between task requirements and multi-dimensional attributes of terminal capabilities, such as computing power, latency, and location, thereby improving the accuracy and efficiency of task allocation. Furthermore, by combining a global power consumption prediction model with local dynamic threshold determination at the terminal, the system, while pursuing optimal overall energy efficiency, respects and protects the physical operational constraints of each terminal based on its power supply type and real-time power consumption, avoiding equipment instability caused by overload. Finally, relying on periodic progress synchronization and status monitoring, the fault migration mechanism can select the most suitable successor in a dynamically changing network environment based on the latest progress breakpoint and terminal computing power status, ensuring the final reliability of complex task execution. This effectively solves the problem of low overall computing power network resource utilization caused by failing to effectively organize and schedule massive amounts of idle terminal computing power resources due to treating terminals merely as offloading points for computing tasks rather than as computing power providers.

[0071] Please see Figure 2 As shown, this is a schematic diagram of the directory generation module in this embodiment. In this embodiment, the directory generation module includes:

[0072] The data receiving unit 21 is used to receive the running status data periodically reported by the execution terminal, which includes raw CPU utilization and memory bandwidth information.

[0073] Unit value calculation unit 22, which is connected to data receiving unit, is used to calculate computing power unit value based on the original computing power information and the operating status data through the preset conversion model;

[0074] The directory generation unit 23 is connected to the unit value calculation unit to aggregate the computing power unit value with the geographical location and network status of the execution terminal to generate the computing power pool directory.

[0075] In this embodiment, the data receiving unit receives runtime status data packets reported by the execution terminal at fixed intervals through the MQTT proxy service deployed on the edge scheduler. These packets are encapsulated in JSON format and verified by digital signatures. The unit value calculation unit then queries the pre-stored chip baseline DMIPS value based on the terminal identifier in the packet and calculates the standardized computing power unit value by combining the real-time CPU utilization and memory bandwidth occupancy rate in the packet with the built-in conversion model engine. Finally, the directory generation unit aggregates the received computing power unit value, the real-time latency and connection status obtained through the active network probe, and the geographical location information extracted from the device registration database, and updates it to the memory database it maintains, thereby generating a computing power pool directory that provides a unified query interface to the outside world.

[0076] By fusing dynamic parameters reflecting the instantaneous load of terminals with static benchmarks of their inherent performance, a precise and normalized measurement of heterogeneous computing power is achieved. This process essentially maps discrete physical observations into continuous and comparable computing power units. Furthermore, by aggregating these standardized computing power units with the spatial location attributes of terminals and the network state changing over time in real time, the module constructs a multi-dimensional, high-fidelity dynamic resource topology view. This not only enables upper-layer scheduling to make decisions based on precise quantified computing power supply and real-time network reachability, but more importantly, it unifies the three major physical constraints of computing, communication, and space into scheduling considerations. This allows task allocation to simultaneously meet the requirements of computing power matching, low-latency transmission, and geographical relevance, thereby fundamentally improving the efficiency, reliability, and resource utilization of large-scale distributed computing power resource scheduling.

[0077] Please see Figure 3 As shown, this is a schematic diagram of the matching module in this embodiment. In this embodiment, the matching module includes:

[0078] The task feature extraction unit 31 is used to extract the task computing power requirement, task latency requirement and task type code from the task descriptor.

[0079] Terminal feature extraction unit 32 is used to extract computing unit values, historical average response latency, and geographical or network distance to the task data source from the computing power pool directory.

[0080] The similarity calculation unit 33 is connected to the task feature extraction unit and the terminal feature extraction unit respectively, and is used to construct the task feature vector into a first vector, construct the terminal feature vector into a second vector, and calculate the cosine similarity between the first vector and the second vector to obtain the matching similarity.

[0081] In this embodiment, the task feature extraction unit receives and parses the task descriptor from the cloud platform, quantizing the task computing power requirement, task latency requirement, and task type code into numerical values, which together form a multi-dimensional first vector. At the same time, the terminal feature extraction unit queries the records of each terminal from the computing power pool directory, quantizing its standardized computing power unit value, the average response latency calculated based on historical logs, and the distance to the task data source calculated through geographical location or network topology into numerical values, forming the corresponding second vector. Subsequently, the similarity calculation unit normalizes the obtained first and second vectors, and calls the preset mathematical library function to perform vector dot product and modulus calculation, finally outputting the cosine value of the angle between the two as the matching similarity. This value is directly used to sort all candidate terminals and generate a list.

[0082] By quantifying and vectorizing the multidimensional requirements of tasks on computing resources, time constraints, and inherent types such as computing power, latency, and encoding, and mapping them one-to-one with the inherent processing capabilities, historical performance, and network topology of terminals, a unified mathematical model for measuring task requirements and terminal supply is constructed. A cosine similarity algorithm is used to calculate the directional consistency of these two requirements in a multidimensional feature space. Essentially, this assesses the overall alignment of the task requirement vector and the terminal capability vector across various mutually constraining physical dimensions, rather than matching a single metric. This mechanism ensures that scheduling decisions automatically balance the inherent coupling between computational intensity, time sensitivity, and data transmission costs. Mathematically, this guarantees that the selected terminal set not only meets the computing power requirements but also achieves optimal synergy with the task characteristics in terms of historical reliability, network proximity, and overall task characteristics. Ultimately, this significantly improves the overall efficiency and success rate of task allocation in complex heterogeneous environments.

[0083] Specifically, the scheduling module is also used to generate a globally unique subtask identifier and a corresponding progress synchronization interface for each subtask in the task allocation instruction set, and to send the subtask identifier and the progress synchronization interface along with the task allocation instruction set to the corresponding execution terminal.

[0084] In this embodiment, the scheduling module generates a globally unique string conforming to the UUID version 4 standard as a subtask identifier for each subtask item in the task allocation instruction set. At the same time, a corresponding RESTful style progress synchronization interface is created for each subtask on the edge scheduler side. The URL of this interface uses the subtask identifier as the path parameter and has a pre-configured authentication mechanism. Finally, the scheduling module encapsulates the task allocation instruction set containing the subtask identifier, interface URL, execution parameters, and resource description together through a secure link and sends it to the target execution terminal.

[0085] By assigning a globally unique identifier based on a random algorithm to each atomic computing unit through the scheduling module, the precise differentiation and unambiguous tracking of the execution state of the quantum task in a distributed asynchronous environment are ensured from an information theory perspective. Simultaneously, the standardized progress synchronization interface created with this identifier as the addressing core essentially establishes an independent, reliable, and addressable state feedback channel for each task instance. This transforms the originally black-box, discrete terminal execution process into a white-box, continuously observable streaming state sequence, thereby upgrading task lifecycle management from coarse-grained result waiting to fine-grained process control. This not only provides the upper-layer system with a basis for real-time fault tolerance and dynamic load balancing decisions, but more importantly, it tightly integrates the physical world's computing tasks with the information world's state mapping through identifiers and interfaces, laying the foundation for building a distributed computing system with high observability, interveneability, and eventual consistency.

[0086] Please see Figure 4 As shown, this is a schematic diagram of the local scheduling engine in this embodiment. In this embodiment, the local scheduling engine includes:

[0087] The feasibility determination unit 61 is used to predict the execution power consumption based on the task allocation instruction set, the real-time status data of the execution terminal and its built-in power consumption model consistent with the scheduling module, and compare the prediction result with the local dynamic threshold to obtain the comparison result.

[0088] The task queue management unit 62, which is connected to the feasibility determination unit, is used to add the calculation task to the local queue for execution after the comparison result shows that the local feasibility determination is passed.

[0089] By embedding a power consumption model consistent with the upper-layer scheduling module within the feasibility assessment unit, the system ensures that energy consumption assessment follows the same set of calculation rules based on chip physical characteristics throughout the process from global planning to local execution. This avoids decision conflicts caused by model bias at the source. Simultaneously, the introduced local dynamic threshold is strongly correlated with the terminal's real-time power supply capacity, heat dissipation conditions, and battery chemical state, ensuring that the final judgment integrates theoretical predictions with the immediate constraints of physical hardware. The task queue management unit's orderly acceptance of tasks after successful judgment essentially provides a buffer and scheduling layer for unpredictable instantaneous load fluctuations, allowing terminals to autonomously arrange the usage sequence of their idle computing power without affecting core functions. This mechanism tightly couples macroscopic scheduling instructions with microscopic device states, enabling each terminal to intelligently participate in global computing power collaboration while ensuring its own stable operation. This fundamentally resolves the contradiction between individual reliability and overall efficiency in distributed computing, achieving a synergistic improvement in system robustness and resource utilization.

[0090] Specifically, the feasibility determination unit includes:

[0091] The data acquisition subunit is used to collect the CPU utilization, power supply type and remaining battery power of the execution terminal in real time.

[0092] The power consumption prediction subunit is used to predict the execution power consumption that will be generated when executing the subtask based on the subtask computing power requirements in the task allocation instruction set, the computing power unit value of the execution terminal, the CPU utilization rate, and the power supply type, by calling the power consumption model.

[0093] The threshold comparison subunit is used to determine the local dynamic threshold based on the power supply type and the remaining battery power, and to compare the computing power unit value with the subtask computing power requirement and the execution power consumption with the local dynamic threshold to obtain the comparison result.

[0094] In this embodiment, after receiving the real-time terminal status from the data acquisition subunit, the power prediction subunit first converts the subtask computing power requirement in units of CUs with the current computing power unit value of the executing terminal to obtain the theoretical CPU computing power ratio expected to be used to execute the task. Subsequently, the subunit uses this computing power ratio, the current CPU utilization rate, and the power supply type as joint input parameters to call the power consumption model built into the terminal. This model is essentially a mapping function calibrated according to the electrical characteristics of the terminal chip. It calculates a value representing the incremental power consumption, i.e., the predicted execution power consumption, through the above input parameters, and outputs it for use by the threshold comparison subunit.

[0095] By standardizing the ratio of subtask computing power requirements to the terminal's specific computing power capacity, the task load is transformed into a theoretical utilization rate of CPU computing resources. This transformation establishes a quantitative bridge from application layer instructions to hardware layer load. Furthermore, by calling a power consumption model calibrated based on chip physical characteristics, this unit couples and analyzes three types of dynamic and static parameters: theoretical computing power utilization, real-time CPU load, and power supply circuit characteristics. This allows for accurate prediction of the incremental power consumption that will be triggered by executing the subtask. This process profoundly reflects the semiconductor physics-based mapping relationship between computational load and energy consumption. Finally, the threshold comparison subunit dynamically generates a local power consumption threshold based on the real-time power consumption reflecting the device's energy state and the power supply type that determines the heat dissipation boundary. The predicted power consumption is then compared with this threshold. This mechanism essentially weighs the computational benefits of the task against the safe operating costs of the device under the current energy state and heat dissipation conditions in real time. This enables the terminal to make autonomous and precise admission decisions based on its instantaneous, multi-dimensional physical state, thereby ensuring at the atomic level that every computing power sharing does not come at the expense of device stability and user experience. This achieves a microscopic unity of global efficiency and terminal autonomy in distributed scheduling.

[0096] Specifically, the threshold comparison subunit is used to set a first reference threshold as the local dynamic threshold when the power supply type is plug-in power supply, and to set a second reference threshold lower than the first reference threshold when the power supply type is battery power supply, and to select a corresponding dynamic adjustment coefficient according to the preset power range in which the remaining battery power is located, and to use the product of the second reference threshold and the dynamic adjustment coefficient as the local dynamic threshold.

[0097] The first benchmark threshold is the upper limit of power consumption safety for plug-in powered terminals. It depends on the maximum sustainable heat dissipation capacity of the terminal chip and the rated power of the power adapter. It is usually set between 70% and 90% of the chip's thermal design power (TDP). In this embodiment, it is set to 80% of the chip's TDP, which can fully utilize the terminal's performance while ensuring its long-term stable operation without damage due to overheating. The second benchmark threshold is the initial power consumption limit benchmark for battery-powered terminals. It depends on the maximum safe continuous discharge rate of the battery and the average power consumption of the terminal system. It is usually set between 30% and 50% of the terminal's full-load power consumption. In this embodiment, it is set to 50% of the first benchmark threshold in the plug-in scenario of the same model of terminal. It can significantly slow down the rate of battery consumption while meeting the basic computing power sharing requirements.

[0098] The preset power range is a range of power segments used to dynamically adjust the power consumption threshold of the battery-powered terminal. It depends on the chemical discharge characteristics of the battery and the device's battery life requirements. Usually, it is divided into intervals of 20% or 25% of the battery power. In this embodiment, it is set to four intervals: [80%, 100%] (corresponding to a dynamic adjustment coefficient of 1.0), [50%, 80%] (corresponding to a dynamic adjustment coefficient of 0.8), [20%, 50%] (corresponding to a dynamic adjustment coefficient of 0.6), and [0%, 20%] (corresponding to a dynamic adjustment coefficient of 0.4). This enables the power consumption limit to be positively correlated with the remaining battery energy, achieving refined and adaptive energy consumption management.

[0099] By identifying the fundamental differences in terminal power supply methods—namely, abundant energy supply but limited by heat dissipation when plugged in, and limited total energy and the need to consider discharge curve characteristics when battery powered—differentiated benchmark threshold setting principles were established. Furthermore, in battery powered scenarios, by mapping the remaining battery charge, a physical quantity reflecting the state of chemical energy storage, to a linear dynamic adjustment coefficient, the local power consumption threshold can exhibit a step-like or continuous decay as the charge decreases. Essentially, the battery's discharge characteristics and safe operating boundaries are incorporated into the real-time decision-making model. This ensures that when allocating computing power tasks to battery-powered devices, the system can automatically and pre-adjust the acceptable power consumption limit based on the current energy reserve level, thereby proactively avoiding unexpected device shutdowns or battery damage caused by over-discharge. This fundamentally guarantees the terminal's battery life and hardware lifespan during computing power sharing, achieving refined and adaptive management of the energy status of heterogeneous terminals.

[0100] Specifically, the task queue management unit is used to determine that the comparison result is a local feasibility judgment when the computing power unit value is greater than or equal to the computing power requirement of the subtask and the execution power consumption is less than the local dynamic threshold, and to insert the corresponding subtask into the local queue according to priority to wait for execution, and start the task execution process.

[0101] In this embodiment, the task queue management unit maintains a priority queue based on a min-heap data structure as a local queue. Each subtask to be executed uses its preset priority value as the key for heap sorting. After receiving the pass judgment result from the threshold comparison subunit, the unit first verifies the relationship between the computing power unit value and the computing power requirement of the subtask, and confirms that the execution power consumption is lower than the local dynamic threshold. Then, it inserts the task description object containing the subtask identifier, execution parameters, and priority identifier into the aforementioned min-heap. Finally, the unit checks the status of the current task execution threads in the system. If there are idle threads, they are immediately awakened. If all threads are busy, a new thread is requested through the thread pool interface provided by the operating system. The awakened or newly created thread actively obtains the highest priority task description object from the top of the min-heap and loads it for execution, thereby starting the task execution process.

[0102] By setting both computing power sufficiency and power safety as prerequisites for tasks to enter the execution queue, and performing final verification before insertion, a final line of defense is constructed in the process to ensure the stable operation of the terminal itself. The local queue is organized using a min-heap data structure with priority as the key value, so that task scheduling can strictly follow the preset urgency order. This is essentially an optimal sorting of discrete task requests on the timeline, thereby ensuring that critical computing is always responded to first. In conjunction with the thread management mechanism of the underlying operating system, execution threads are dynamically woken up or requested according to the queue load, realizing elastic matching and on-demand supply between computing resources and pending tasks. This allows the terminal to maintain absolute control over its own resources under complex dynamic loads, ensuring that it can execute external computing tasks efficiently and orderly, and at any time prioritize the smoothness and responsiveness of its own core functions. Ultimately, a precise balance and seamless collaboration between external computing power sharing and internal service stability is achieved.

[0103] Specifically, the task migration module includes:

[0104] A fault monitoring unit is used to monitor and determine the abnormal state of each of the execution terminals in order to identify a number of faulty terminals.

[0105] A backup terminal selection unit is used to select the idle execution terminal in the computing power pool directory with the smallest difference between the computing power unit value of the faulty terminal and the execution terminal as the backup terminal.

[0106] The migration unit is used to send the subtask identifier, real-time progress breakpoint, and complete task context data packet corresponding to the faulty terminal to the backup terminal.

[0107] Specifically, the fault monitoring unit includes:

[0108] The heartbeat timeout determination subunit is used to determine that a communication abnormality has occurred and to identify the execution terminal as the faulty terminal when no progress report is received from the execution terminal through the progress synchronization interface within a preset first time window.

[0109] The performance anomaly determination subunit is used to determine that a performance anomaly has occurred and to identify the execution terminal as the faulty terminal when the CPU utilization of the execution terminal in the progress report continuously exceeds the safety threshold corresponding to its model.

[0110] The behavior anomaly determination subunit is used to determine that the execution terminal is the faulty terminal when the task execution progress of the execution terminal has no progress within a preset reporting period of a preset number of consecutive determinations.

[0111] In this embodiment, the decision subunits in the fault monitoring unit work in parallel. The heartbeat timeout decision subunit monitors reported events from the progress synchronization interfaces of each terminal using an independent watchdog timer. If no heartbeat or progress report is received from a specific terminal when the timer reaches a preset window value, a communication anomaly determination is triggered. The performance anomaly decision subunit parses the received progress reports in real time, comparing the CPU utilization and temperature readings from the terminal sensors with the thresholds preset in the security configuration table for that terminal model. If three consecutive reported data exceed the limits, a performance anomaly determination is triggered. The behavior anomaly decision subunit records and compares the progress percentages reported by the same terminal in adjacent periods. If the percentage does not change within a preset number of consecutive decision periods, a behavior anomaly determination is triggered. When any decision subunit is triggered, the fault monitoring unit marks the terminal as a faulty terminal and notifies the backup terminal selection unit. The backup terminal selection unit then queries the latest computing power pool directory, first filtering out all terminals marked as idle, then calculating the absolute difference between the computing power unit values ​​of these terminals and the faulty terminal's computing power unit value, and finally selecting the terminal with the smallest difference as the backup terminal. Subsequently, the migration unit retrieves the latest progress breakpoint and its complete task context snapshot corresponding to the faulty terminal from persistent storage, encapsulates this data together with the subtask identifier, and sends it to the selected backup terminal through a secure channel, instructing it to load the context from the breakpoint and resume task execution.

[0112] The preset first time window is the maximum waiting time for judging terminal communication connection timeouts. It depends on the typical round-trip latency of the network environment and the urgency of the system's fault tolerance, and is usually set between 5 and 30 seconds. In this embodiment, it is set to 10 seconds, which can promptly identify genuine communication interruption faults while avoiding misjudgments caused by brief network jitter. The preset number of judgments is the number of consecutive exceedances allowed before triggering a performance anomaly. It depends on the fluctuation characteristics of hardware sensor data and the need to avoid instantaneous interference, and is usually set between 2 and 5 times. In this embodiment, it is set to 3 times, which can effectively filter out occasional anomalies caused by instantaneous task peaks or measurement noise, ensuring the accuracy of performance judgments. The preset reporting cycle is the time interval between the terminal sending status reports to the edge scheduler. It depends on the balance between monitoring real-time requirements and system communication overhead, and is usually set between 1 and 10 seconds. In this embodiment, it is set to 5 seconds, which can effectively balance providing sufficient timely status visibility with controlling network bandwidth and terminal power consumption.

[0113] By establishing anomaly monitoring mechanisms across three dimensions—communication, performance, and behavior—a comprehensive fault-aware network is constructed, addressing the fundamental aspects of network connectivity, hardware load sustainability, and computing process activity. The judgment threshold for each dimension is set based on inherent rules at the corresponding physical or logical level. When a failure is detected in any dimension, the module immediately triggers a migration process, selecting a backup terminal based on the principle of "minimum difference in computing power unit value." This principle essentially aims to reconstruct a computing environment and performance expectations similar to the original terminal on a new physical node to the greatest extent possible, ensuring the continuity and efficiency of task execution. This design enables the system to transform sporadic, heterogeneous node failure events into a predictable and manageable standardized recovery process. It not only significantly reduces the risk of a single node failure to the global task but, more importantly, by deeply embedding fault-tolerant logic into the scheduling system, it endows the large-scale distributed computing network with damage localization and self-healing capabilities similar to those of a living organism, thereby constructing a highly reliable task execution guarantee in dynamic and unreliable terminal network environments.

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

Claims

1. An edge task distributed execution system based on terminal idle computing power, characterized in that, Comprise: A cloud platform for standardizing computing tasks to be executed into a plurality of task descriptors containing task feature vectors; A catalog generation module for generating a standardized computing power unit value based on real-time received raw computing power information reported by each execution terminal through a preset conversion model, and aggregating to generate a computing power pool catalog; A matching module for extracting a terminal feature vector from the computing power pool catalog based on the task descriptor, calculating the matching similarity of the terminal feature vector and the task feature vector, and generating a candidate terminal list and a corresponding preliminary task splitting scheme according to the matching similarity ranking; A scheduling module for calling a corresponding power consumption model according to the power supply type of each candidate terminal in the candidate terminal list, predicting the execution power consumption of the candidate terminal after executing the preliminary task splitting scheme, and eliminating a plurality of execution terminals with power consumption exceeding the preset power consumption threshold according to the comparison result of the execution power consumption and the preset power consumption threshold, to form a task allocation instruction set; A task migration module for selecting a backup terminal from the computing power pool catalog based on the computing power unit value of the corresponding execution terminal when monitoring the execution terminal failure, and issuing fault breakpoint information and context to the backup terminal to continue the computing task; A local scheduling engine for performing local feasibility determination on the real-time load of each execution terminal and the execution power consumption based on the task allocation instruction set, and adding the computing task to a local queue for execution after passing the determination; The catalog generation module comprises: A data receiving unit for receiving running state data containing raw CPU utilization and memory bandwidth information periodically reported by the execution terminal; A unit value calculation unit for calculating a computing power unit value through the preset conversion model based on the raw computing power information and the running state data; A catalog generation unit for aggregating the computing power unit value together with the geographical position and network status of the execution terminal to generate the computing power pool catalog. 2.The edge task distributed execution system based on terminal idle computing power according to claim 1, wherein, The matching module comprises: A task feature extraction unit for extracting task computing power demand, task latency requirement, and task type code from the task descriptor; A terminal feature extraction unit for extracting computing power unit value, historical average response latency, and geographical or network distance from the computing power pool catalog; A similarity calculation unit for constructing the task feature vector as a first vector, constructing the terminal feature vector as a second vector, and calculating the cosine similarity of the first vector and the second vector to obtain the matching similarity. 3.The edge task distributed execution system based on terminal idle computing power according to claim 2, characterized in that, The scheduling module further generates a globally unique sub-task identifier and a corresponding progress synchronization interface for each sub-task in the task allocation instruction set, and issues the sub-task identifier and the progress synchronization interface together with the task allocation instruction set to the corresponding execution terminal. 4.The edge task distributed execution system based on terminal idle computing power according to claim 3, wherein, The local scheduling engine comprises: a feasibility determination unit configured to predict the execution power based on the task allocation instruction set, real-time state data of the execution terminal, and a power consumption model consistent with the scheduling module built in the execution terminal, compare the prediction result with a local dynamic threshold, and obtain a comparison result; a task queue management unit configured to add the computing task to a local queue for execution if the comparison result is a local feasibility determination pass. 5.The edge task distributed execution system based on terminal idle computing power according to claim 4, characterized in that, The feasibility determination unit comprises: a data acquisition subunit configured to acquire, in real time, CPU usage, power supply type, and battery remaining capacity of the execution terminal; a power consumption prediction subunit configured to predict the execution power generated by executing a subtask based on subtask computing power requirement in the task allocation instruction set, computing power unit value of the execution terminal, CPU usage, and power supply type, and call the power consumption model; a threshold comparison subunit configured to determine the local dynamic threshold based on the power supply type and the battery remaining capacity, and compare the computing power unit value with the subtask computing power requirement and the execution power with the local dynamic threshold, respectively, to obtain the comparison result. 6.The edge task distributed execution system based on terminal idle computing power according to claim 5, wherein, The threshold comparison subunit is configured to set a first reference threshold as the local dynamic threshold when the power supply type is plug-in power supply, and set a second reference threshold lower than the first reference threshold when the power supply type is battery power supply, select a corresponding dynamic adjustment coefficient according to a preset power interval in which the battery remaining capacity is located, and take the product of the second reference threshold and the dynamic adjustment coefficient as the local dynamic threshold.

7. The edge task distributed execution system based on terminal idle computing power according to claim 6, characterized in that, The task queue management unit is configured to determine that the comparison result is a local feasibility determination pass when the computing power unit value is greater than or equal to the subtask computing power requirement and the execution power is less than the local dynamic threshold, insert the corresponding subtask into the local queue for execution according to priority, and start a task execution process. 8.The edge task distributed execution system based on terminal idle computing power according to claim 7, wherein, The task migration module comprises: a fault monitoring unit configured to monitor and determine abnormal states of each execution terminal to determine a plurality of fault terminals; a backup terminal selection unit configured to select an idle execution terminal in the computing power pool directory having a minimum difference in computing power unit value from the fault terminal as the backup terminal; a migration unit configured to distribute the subtask identifier, real-time progress breakpoint, and complete task context data packet corresponding to the fault terminal to the backup terminal. 9.The edge task distributed execution system based on terminal idle computing power according to claim 8, characterized in that, The fault monitoring unit comprises: a heartbeat timeout determination subunit configured to determine that a communication abnormality occurs and the execution terminal is the fault terminal when no progress report is received from the execution terminal on the progress synchronization interface within a preset first time window; a performance abnormality determination subunit configured to determine that a performance abnormality occurs and the execution terminal is the fault terminal when CPU utilization of the execution terminal in the progress report continuously exceeds a safety threshold corresponding to the model of the execution terminal. a behavior abnormality determination subunit configured to determine that the execution terminal is the faulty terminal when a task execution progress of the execution terminal has no progress in a preset reporting period for a preset determination number of times in succession.

Images